Friday, 20 August 2010


Type conversion to and from a String is a very common application problem. To aid in the process, I've created a small library - Joda-Convert.


There are many libraries designed for converting from one object to another, so why create another. Well, partly because I wanted something focussed on the task of Object to String rather than the larger problem of Object to Object. See this list (bottom of the page) for other projects.

The second reason I wanted to write Joda-Convert was to experiment with annotation based conversion. This is an extension of the principles in JSR-311 (RESTful API) where type conversion is performed by looking for a valueOf static method or a constructor that takes a String. While this approach is very useful, it doesn't support some of my projects like JSR-310, where the static method is named of or parse.

This leads into the third reason. If the annotation based approach is successful, then Joda-Convert is ideally placed to be moved into the JDK. It would be wonderful to see the JDK classes annotated to indicate which methods should be used to convert to and from String.

Using Joda-Convert is easy:

// conversion to String
String str = StringConvert.INSTANCE.convertToString(foo);

// conversion from String
Foo bar = StringConvert.INSTANCE.convertFromString(Foo.class, str);

There are built in converters for many JDK types. It is also possible to create an instance of StringConvert to allow application converters to be registered.

When searching for a converter, if one is not already registered, then the system will search the class for annotations:

public class Distance {

  public static Distance parse(String str) { ... }

  public String getStandardOutput() { ... }


As can be seen, adding the annotations to a class is very simple. The Joda-Convert system will parse the class, find the annotations and create a suitable converter that calls the annotated methods by reflection. The key point is that they can be used on any method, rather than the convention approach used by JSR-311. Consider a class like TimeZone to understand why this is important.

One little known point about annotations is that the annotation class is not needed at runtime. This means that a library like Commons-Lang could add the annotations to their Mutable* classes without actually adding a runtime dependency. If a user chose to not use Joda-Convert then there would be no impact. If a user did choose to use Joda-Convert, then the conversion would just work.

If I can release Joda-Convert soon, then I will add the annotations to Joda-Time and Joda-Money. Hopefully other projects will consider the idea too! (If you're interested, let me know, as it gives an incentive to get the project to v1.0)


Joda-Convert is currently an untested Alpha that exists to test out the annotation idea (although as far as I know it does work). I'd welcome participants that want to help test and finish the JDK conversions. I'd also like to see 'helper objects' added, so a DateTimeFormatter can be used to help convert a DateTime, or a ClassLoader to convert a Class.

Feedback welcome as always!

Tuesday, 17 August 2010

Java generics migration compatibility

A quick call for help on generics.

Joda-Time has the following non-generic interface, with an example dummy implementation:

public interface ReadableInstant extends Comparable {
  int compareTo(Object readableInstant);
public class Dummy implements ReadableInstant {
  public int compareTo(Object readableInstant) { ... }

I've been trying to generify this and maintain backwards binary and source compatibility without success. The following naive implementation works fine for new code:

public interface ReadableInstant extends Comparable<ReadableInstant> {
  int compareTo(ReadableInstant readableInstant);

This doesn't work fine when the old code is combined (unaltered and without recompilation) with the new library.

Firstly, the old code is not source compatible. Dummy does not implement the altered method in the newly generified interface, thus the old code doesn't compile without change.

Furthermore, it is not binary compatible. Imagine a second class Foo that implements the generified version of ReadableInstant. Now consider a class which loads Dummy (unaltered and without recompilation) by reflection as a ReadableInstant and calls compareTo to compare. This will throw an AbstractMethodError. This is because Foo expects there to be a method of the generified form, taking ReadableInstant.

So, its basically a mess. I can't come up with a way to preserve backwards compatibility while adding generics. But I thought the whole point was to allow migration compatibility!

So, I thought that perhaps I'm missing something stupid. If so, please let me know! All the code is in svn (1.6 branch and TRUNK) for anyone wanting to play with real code.

Friday, 13 August 2010

Power corrupts. Absolute power corrupts absolutely.


Oracle, Google and the politics of money












But being crazy seems to be the order of the day.

Oh, and JavaPosse? I'd recommend renaming your podcast pronto!

