Roundup of String to Java Object Conversion Libraries

Posted by Tim Cull on Sep 07, 2010

Sections

Development,

Architecture & Design

Topics

Java ,

Programming

Tags

Annotations ,

Data Binding

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.

1. Back to top

   More conversion projects

   by Stephen Colebourne

   A wider list of projects is at the bottom of this page.
   
   One point not noted in the article, is that Joda-Convert is a strawman for an approach that the JDK could adopt to conversion - using annotations to identify the method. JSR-311 is one example where a "convention" approach is used (the method must be named...), but the annotation approach would be a useful extension.
   
   Stephen Colebourne

   Reply

2. Back to top

   There are more default mechanisms built into the JDK, why not go with those

   by Michael Hunger

   First is the String constructor or static valueOf factory method that is employed by most of Java's core classes (and its toString equivalent).
   
   Secondly we have the whole java.text Formatters that handle such things already nicely and are also aware of locales and timezones. Also used for formatting I18N strings in Springs MessageSource.
   
   Coming from there a simple approach should incorporate those existing approaches (as Spring 3.0's default converters do).

   Reply

• Older >