Wednesday, March 12, 2008
GroupLayout converting Java 6 to Java 5
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..
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:
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.sedIt 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.
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
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.formie '2' is for jdesktop.org and '1' is for Java 6.
9c9
< <auxvalue name="FormSettings_layoutCodeTarget" type="java.lang.Integer" value="2" />
---
> <auxvalue name="FormSettings_layoutCodeTarget" type="java.lang.Integer" value="1"/>
Labels: GroupLayout, java, swing
Sunday, July 22, 2007
Java Fused Multiply Add, aka fma or FMAC
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...
Tuesday, February 13, 2007
At last..
Wednesday, December 21, 2005
Dilbert Blog
having been an avid reader (and subscriber) to the Dilbert cartoon blog for sometime, I was happy to stumble across (by actually going to the dilbert site) the Dilbert Blog - the article I linked there is pretty good.
Saturday, December 03, 2005
Attach API
Cool. The access jconsole has to a JVM is about to be available for other apps. One obvious question is when will script tools like beanshell / groovy / grash provide an agent to run around inside your apps. Of course, since the jconsole app source is probably available, you could just put an extra tab on it for a script console.
An obvious question is, why isn't this a standard API to the JVM? Many companies run multiple VMs (ie different vendors) it would be great to have these tools for any VM.
An obvious question is, why isn't this a standard API to the JVM? Many companies run multiple VMs (ie different vendors) it would be great to have these tools for any VM.