techMusings

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:

• 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.

.. except this one is a whole industry while granting draconian powers. Give it up. Support the petition.

OK, so I'm writing Swing code again (which I'm not very good at), and have been using an odd combination of Netbeans 6 to do form design via Matisse (since the Eclipse version is MyEclipse only?) and the rest of the code in Eclipse (since I can't get comfortable in NB yet). Unfortunately, and perhaps because I'm running on Java 6, Matisse defaults to using the Java 6 javax.swing.GroupLayout, but my client is running Java 5 (late discovery). While I could install a new version of Java for them, the lack of Java 6 on my G5 Mac at home tipped me back to 5.

While there is an option in NB to generate using the org.jdesktop packages (enabled now), it won't retrospectively rejig an existing form. Now the APIs while essentially the same code, and different versions so a bunch of things make the process more than changing the imports.

The script below did 95% of the changes my forms needed (in fact just one line in two forms needed a parameter removing -- addComponent had an extra param on a vertical group). Just thought I'd put it out there since I saw a few forum posts asking about this. It would be nice if NB could do this for you, but I suspect it's a low priority item..

$ cat swing6tolayout.sed
s/javax.swing.GroupLayout/org.jdesktop.layout.GroupLayout/g
s/GroupLayout.Alignment/GroupLayout/g
s/javax.swing.LayoutStyle.ComponentPlacement./org.jdesktop.layout.LayoutStyle./g
s/\.addGroup/\.add/g
s/\.addComponent/\.add/g
s/\.addGap/\.add/g

$ sed -f swing6tolayout.sed MyForm.java > tmp.java
$ mv tmp.java MyForm.java

It does make me smile that despite the size / complexity / ability of Eclipse & Netbeans, sed was the easiest way to do this. Wasn't Eclipse supposed to be providing refactoring batches? Or James Gosling's project to manipulate code? Dunno. Sed was already in the toolkit (cygwin), so it won.

Update:
Annoyingly, when you do this, the form reverts to the previous layout type next time you edit in NetBeans. By the power of diff, you can fix this too by changing the MyForm.form file thus:

$ diff JDesk.form Java6.form
9c9
< <auxvalue name="FormSettings_layoutCodeTarget" type="java.lang.Integer" value="2" />
---
> <auxvalue name="FormSettings_layoutCodeTarget" type="java.lang.Integer" value="1"/>

ie '2' is for jdesktop.org and '1' is for Java 6.

Labels: GroupLayout, java, swing

OK, long time, no posts etc.. but I've just posted over on ngGrid a little note about Java floating point performance -- if you want it, vote for it...

As whined about... JNI is finally about to die. Sun have been negligent on this one, imho.