BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Roundup of String to Java Object Conversion Libraries

Roundup of String to Java Object Conversion Libraries

This item in japanese

Bookmarks

Stephen Colebourne, of Joda Time fame, ignited a small debate on his blog when he released Joda Convert: a Java library to convert basic Objects to and from Strings using annotations. To help clarify the considerations around String conversion, below is a round-up of some technologies for converting Strings to Objects and vice-versa, starting with Joda Convert.

According to Mr. Colebourne's post, Joda Convert's stated aim is to trade off completeness for simplicity. It allows the author of any Java class to specify arbitrarily-named methods that will convert a String to an instance of that class and vice-versa. For example, a Currency class might have a static method named "fromISOCode(code)" and an instance method named "getISOCode()". By adding the Joda Convert annotations @FromString and @ToString to those methods, applications using the Currency class can do conversion to and from Strings with calls like: "Foo bar = StringConvert.INSTANCE.convertFromString(Foo.class, str);" Such conversion is often useful for writing Web applications that have to parse values from an HTTP GET, for example. Commenters on Mr. Colebourne's blog responded by describing several other alternative efforts.

The first alternative is already built into Java: java.beans.PropertyEditor. A PropertyEditor uses JavaBeans technology to convert Strings to property values. While PropertyEditors have a long heritage in visual editors like IDEs, PropertyEditors can also be used in behind-the-scenes processing. For example, Spring versions before 3.0 use PropertyEditors extensively to support data binding and validation. Unlike Joda Convert, PropertyEditors are intended for many uses, not just converting a String to an Object. For example, PropertyEditors have built-in support for registering PropertyChangeListeners.

J2EE also has its own built-in converter technologies in JavaServer Faces. JSF ships with converters for common types like BigDecimal, Float, DateTime and others as well as providing an interface for custom converter implementations. Custom implementations simply provide code for a "getAsObject" method and a "getAsString" method. JSF converters are strongly tied to JSF, however, so using them outside JSF can be challenging.

There are also third-party alternatives to the built-in Java String converter technologies. One alternative recently shipped in Spring 3.0. Although previous versions of Spring used PropertyEditors, SpringSource choose to implement its own conversion method in Spring 3.0. According to SpringSource:

 

The goals we had when we set out to improve Spring 3's data binding system:
1. Provide a stateless, strongly-typed Type Converter SPI that supercedes JavaBean PropertyEditors
2. Provide a unified Type Conversion API to use anywhere conversion is required, including Spring's DataBinder and Expression Language
3. Allow for type conversion to be driven by Java Annotation metadata
4. Simplify by registering sensible defaults and applying convention-over-configuration

 

SpringSource isn't the only open source organization to roll its own type converter. Several Apache projects have their own type converters like Apache Commons BeanUtils (used in Apache Digester) , the now-dormant Apache Commons Convert and even Apache Struts and Apache Camel.

A few frameworks are also designed to convert more than just Strings to Objects. For example, Dozer is a framework that converts arbitrarily complex objects to other arbitrarily complex objects. Because a String is an Object, it could be used on one side or the other of a Dozer conversion.

Finally, when choosing a conversion technology, developers need to remember that each of the above converters is optimized for its own target environment. For example, Strings sent to and from an HTML input form in a web browser might be different than Strings for the same object written to an XML document. Additionally, even in the same target environment like a web browser, some users might need to see different localizations (e.g. "2010-31-01" vs. "1/31/2010" for dates). Last, but not least, different mediums might support different String encodings. For example, an XML document can use UTF-8, ISO-8859-1 , or many other encodings because it can specify its string encoding on its first line. But strings parsed from a URL can only ever be ASCII.

Rate this Article

Adoption
Style

BT