Thursday, November 05, 2009
GWT 2.0 and classpath hell
I had a little visit back to classpath hell yesterday. I'm building an app using GWT for the front end. For mad Mac OS / Java / 3rd party native libs reasons, I wanted to move to OOPHM (29West only do 64bit libs on a Mac..) so I installed GWT 2.0 ms2. It was all looking good, against Firefox (other than needing it's own launch config rather than the eclipse plugin's launch), and ran at a similar speed in dev mode.
[ slight issue is that I then changed project for a few days, forgetting the exact last change.. ]
I then change a section of code to handle a bit of the data model I was getting wrong previously. Time to rerun the unit tests. Bang. Except, the code that dies is inside the protocol buffers library (which I'm using to talk to a back end server). Just to add layers to the confusion I'm calling protobuf methods via reflection (since all the type stuff in protobuf is accessed via non-polymorphic static methods on each class -- eek). Giving me lots of nested exceptions with InvocationTargetException / NoSuchMethodError, implying I though, my reflection code was broken.
Now, various projects are on either protobuf 2.0.2 or 2.2.0. The generated code for one, is not compatible with the libs of the other. I then spend ages looking at classpaths and trying to work out what's change. I write a test class, without any reflection to find I can't even reference a generated class without the exploding. :/
The wierd thing was, OOPHM still worked, calling the same code, it's was just my unit tests that were dying. Eventually I find the culprit, gwt-dev.jar, contains approx half the known Java universe including protobuf 2.2.0. Gaa!! It seems the webapp classloader magic for OOPHM/Jetty was hiding the problem. Luckily, a judicious, if hacky, move of GWT libs to the end of the classpath fixed the problem temporarily.
So I'll end with a plea to both Google and any other software projects -- please do build on top of other stable libraries but either:
PS GWT rocks, thank you Google.
[ slight issue is that I then changed project for a few days, forgetting the exact last change.. ]
I then change a section of code to handle a bit of the data model I was getting wrong previously. Time to rerun the unit tests. Bang. Except, the code that dies is inside the protocol buffers library (which I'm using to talk to a back end server). Just to add layers to the confusion I'm calling protobuf methods via reflection (since all the type stuff in protobuf is accessed via non-polymorphic static methods on each class -- eek). Giving me lots of nested exceptions with InvocationTargetException / NoSuchMethodError, implying I though, my reflection code was broken.
Now, various projects are on either protobuf 2.0.2 or 2.2.0. The generated code for one, is not compatible with the libs of the other. I then spend ages looking at classpaths and trying to work out what's change. I write a test class, without any reflection to find I can't even reference a generated class without the
The wierd thing was, OOPHM still worked, calling the same code, it's was just my unit tests that were dying. Eventually I find the culprit, gwt-dev.jar, contains approx half the known Java universe including protobuf 2.2.0. Gaa!! It seems the webapp classloader magic for OOPHM/Jetty was hiding the problem. Luckily, a judicious, if hacky, move of GWT libs to the end of the classpath fixed the problem temporarily.
So I'll end with a plea to both Google and any other software projects -- please do build on top of other stable libraries but either:
Make it explicit -- leave the versioned jars outside the project jars, fore-warned is fore-armed Protect your clients -- Use a classloader to hide your dependencies, or use a jar-creator (jarjar / onejar etc) to change the namespaces.
PS GWT rocks, thank you Google.
