What's the point of living if you can't love or hate?
JBoss Developer Studio + OpenJDK = FreeTee
Posted by Galder Zamarreño on Jan 23, 2009 • (7) •
Man, I’m so excited and I cannot hide it! I’ve finally managed to set up a JBoss Developer Studio environment where I can rebuild my own OpenJDK / IcedTea JDK and test changes to Java classes in rt.jar. With Max‘s help, I’m baptising this new JDK as FreeTee. For those impatient, go to the Instructions section below.
A bit of history first: Before I joined JBoss, I used to download and run JBoss binaries from sourceforge. The same happened with Java, I downloaded and ran the JDKs available from Sun. After joining JBoss, I started building my own JBoss binaries simply by checking out a specific CVS/SVN tag and then executing the build script. The reason I did this is because it would allow me to quickly browse and step through the code, and I could easily test code changes. At the time though, I was still stuck to using Sun’s closed JDK.
Also when I joined JBoss, I started using IntelliJ, an IDE that both Manik Surtani, JBoss Cache lead, and Bela Ban, JGroups and JBoss Clustering Team Lead, were raving about. I quite liked IntelliJ but my main problem with it is that it was dead slow to load JBoss Application Server code and besides, you had to create your IntelliJ project files individually, whereas the Eclipse ones already came with the AS source code. Remember that this was 2006, way before JBoss AS started to use Maven. So, I ended up in a situation where I was using two different IDEs, IntelliJ for JBoss Cache and JGroups and Eclipse for JBoss Application Server and I can assure you that it’s proper PITA: short cuts are different, way of doing things are different…etc. So slowly, I started to migrate towards Eclipse and while doing so, I discovered JBoss Developer Studio which Max Andersen had been asking me to test for quite a while.
I immediately fell in love with JBoss Developer Studio but not because of all the fancy stuff for persistence and web developers (Seam, RichFaces, Hibernate integration…etc) but because of a small plugin called JBoss Project Archives. This feature enables you to easily create all sorts of deployable archives, i.e. ear, jar, war…etc, from a incredibly simple but efficient and powerful GUI. For example, it allows you to create, in just a few seconds, a complex ear with several filesets each with different includes/exclude patterns. I’ve used Ant and Maven in the past and JBoss Project Archives is much much much faster than any of those at defining output archives. Besides, working mostly supporting JBoss customers, I quite often need to build examples quickly to test things and JBoss Project Archives was the perfect tool for my job as it allowed me to create several different output archives out of a single project containing EJB2/3 beans where I could test inter JAR communication or inter isolated EAR communication.
A couple of months ago I got a new laptop and when I installed Fedora 9 on it (My old laptop was still running Fedora 7), I realised that it came with OpenJDK/IcedTea and I wondered whether there was any way to get the entire source code and import it into Eclipse. Seems like the IDE of choice for OpenJDK/IcedTea is NetBeans and you could find loads of information on how to develop with that IDE but little for Eclipse. Eventually, I stumbled upon Roman Kennke’s “OpenJDK in Eclipse” blog entry where he provided the necessary project archives to build OpenJDK from Eclipse. When I saw this, my brain started to work: what if I used Roman Kennke’s Eclipse project files to get Eclipse to compile OpenJDK, take the output of that and with JBoss Project Archives create a brand new rt.jar? If I did this and the generated an rt.jar that worked with my OpenJDK/IcedTea installation, then I’d be in the same situation as I was with JBoss AS a couple of years back: being able to compile my own OpenJDK classes, being able to quickly step through it and most importantly, being able to quickly change java.*, javax.*, sun.*… classes and see what the impact is. So, here are the instructions:
Building Your Own FreeTee
Aim: To build a fully working OpenJDK/IcedTea JDK from scratch and then use the source classes, the generated classes and the seed rt classes to recompile and build a full new rt.jar from either a JBoss Developer Studio or Eclipse + JBoss Tools environment that works with the created JDK. Note that building OpenJDK/IcedTea from scratch takes some time but you only have to do it once. After that, you regenerate rt.jar from the IDE after making the changes that you want.
Important Note: These set of instructions do not go into modifying and rebuilding any of the C/C++ source code provided by OpenJDK/IcedTea JDK. My C/C++ knowledge is very limited but I’d love to hear from people who have managed to rebuild C/C++ code in OpenJDK/IcedTea from Eclipse with the corresponding C/C++ plugins.
Download JBoss Developer Studio or install JBoss Tools plugins on Eclipse.
Make sure you have all build requirements installed (firefox-devel is now called xulrunner-devel).
Start JBDS/Eclipse, open a new workspace in the installation icedtea* root folder and import all the existing projects which are lib and openjdk.
Execute a full build which will compile all the java classes, run rmic on then and build a new rt.jar.
Important Note 1: When doing a full build, you’ll get loads of rmic errors saying that certain classes do not implement java.rmi.Remote. Ignore these errors as they don’t affect the skeleton/stub generation of RMI classes. It must be said that rmic is pretty stupid. It should be able to work out which classes implement Remote and those that don’t and rmi compile those that need.
Important Note 2: If you compare the size between the standard rt.jar in OpenJDK/IcedTea or Sun’s JDK and the one build by JBoss Project Archives, you’ll spot that the latter is much smaller than the others. This is primarily due to the compression rater of around 2x used by JBoss Project Archives.
Next, let’s remove the originally built rt.jar, link the one generated in the IDE and populate JAVA_HOME with our new JDK: