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

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.

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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.