Accepted practice for converting an Object to and from a String in Java ?

Question

What is the commonly accepted method for converting arbitrary objects to and from their String representations, assuming that the exact class of the object is known ? In other words, I need to implement some methods similar to the following:

public interface Converter {

    /**
     * Convert this object to its String representation.
     */
    public String asString(Object obj);

    /**
     * Take the String representation of an object produced by asString, 
     * and convert it back to an object of the appropriate class.
     */
    public Object asObject(String stringRepresentation, Class clazz);
}

Ideally, the solution should:

• Use the object's built-in toString() functionality, if possible. Thus, converter.asString(new Integer(5)) should return "5", and converter.asObject("5", Integer.class) should return an Integer with the value of 5.
• Produce output that is human-readable whenever possible.
• Deal with all common Java data types, including java.util.Date .
• Allow me to plug in conversion functionality for my own, custom classes.
• Be reasonably light-weight and efficient.

I understand that there are any number of ready-made solutions that do this (such as Google's protocol buffers, for example), and that I could easily implement a one-off solution myself. My question is not, "how do I solve this problem", but rather, "which one of the many ready-made solutions is the current industry standard ?".

Answer 1

My question is not, "how do I solve this problem", but rather, "which one of the many ready-made solutions is the current industry standard ?".

None of them have emerged as defacto standard.

The closest you can get it "default" XML serialization mechanism which BTW sucks if you pretend to write them by hand ( and It is good enough when you use them automatically )

The next thing closest to an standard and that would be for daily usage, would be JSON to Java, but, well, you know, it is not Java Java

Answer 2

I agree with Oscar that XML might be the preferable form here, if you can tolerate large uncompressed file sizes. To elaborate on his answer, in my experience if you write a fairly straightforward utility class you can serialize your objects into XML with not too much work. To read them back, I would recommend Apache Digester which does a great job of rule-based interpretation.

I would only opt for other file formats if I cared about performance or file sizes, though I eprsonally in most cases prefer the flexibility of XML.

Answer 3

You can look at the svenson library, it converts java objects to json. Its pretty quick and uses annotations to introduce custom converters.

http://code.google.com/p/svenson/

Not long ago I would have proposed an xml serializer, but after playing with couchdb for a couple of days, I serve a new master... json.

Answer 4

Although it is tempting to use or attempt to implement "toString()" as a reversible operation, the purpose of "toString()" is to generate a user-friendly and easily understandable representation of an object, and this goal is often at odds with including enough state information to truly restore the original object.

If you are looking to persist an object, using XML, JSON, or binary serialization is probably the best way to go. The "toString()" function should report a human-friendly representation of an object (e.g. "5", "(3,0,2)", "5+6i", "{1, 2, 3, 4, 5, 6}", "{x => y, z => 3}", etc.). Even in cases where it is possible to completely restore the object from the generated string, the time to write a function to parse each type of (potentially unstructured) text is best conserved via automated XML persistence in favor of time to write the actual application.

Answer 5

I would vote for Json as well and then particularly Gson. It handles generic/parameterized objects very good.

Alternatively, you can also write a generic object converter which does all of the needed conversions with a little help of reflection, such as this example. But if your "API" require that this converter is to be published as an interface to the enduser, then I would only suggest to replace

public Object asObject(String stringRepresentation, Class clazz);

by for example

public <T extends Object> T asObject(String stringRepresentation, Class<T> clazz);

so that one doesn't need to cast it afterwards.