Reply

General: Recompile (Some of) The JDK to Ease Debugging

At 2:38 PM on Jul 28, 2005, R.J. Lorimer wrote:

Recently my team at work has been working with the javax.swing.text package a lot (as some of you may know from hearing me complain in my tips previously), and it has been really running me through the ringer on certain occasions. Unfortunately, the techniques for extending classes such as the DefaultStyledDocument become increasingly blurry as the documentation becomes less clear, and the source code becomes more complicated. It's not really a fault of the original styled document authors, it is just a very complicated and abstract problem (managing line breaks and text element positioning), and the implementation is quite complex because of that.

Partly because of this complexity, and partly because of the unusual ways we are using the styled document on my current project, we have had a lot of unusual bugs and problems show up in our application as we are testing in preparation for packaging it up for deploy. This typically requires some form of debugging.

Unfortunately, Swing (as well as the rest of the runtime libraries that ship with Java) is compiled without debug options enabled. I can only assume that this is to prevent the JDK download to balloon to a huge size. There are bugs entered into the Java Bug Database about this specific problem (http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4652184) along with instructions that are supposed to make it possible to do a complete re-compile with debug options on (although I haven't gotten them to work; it's quite an undertaking).

What this really means for a debugger is that you can step into a given method, and can follow the execution, but you won't have any variable information. In some cases this may be sufficient, but in most (particularly when you are dealing with sufficiently complex code such as javax.swing.text.DefaultStyledDocument.ElementBuffer), it becomes nearly useless to even try to debug. Unfortunately, a debugger is a very useful tool to understand what the code is actually doing, and it would be desirable to be able to trace the execution to see where things go wrong.

A co-worker of mine, Adi Rosenblum , was also lamenting the difficulties with not having variable information, and was able to find a workaround that covered our case (and an overwhelming portion of cases I would guess) by repackaging the existing rt.jar with new results from the src.zip file that ships with every JDK. He ended up writing a quick script so that the rest of the team could compile what they needed, and so it could be reused later.

Essentially here is what the script does:

• Takes the source-code you want to recompile, and compiles it with the existing rt.jar as the classpath (with the debug options enabled, obviously).
• Extracts the existing rt.jar into a folder.
• Overlays the result of the newly compiled code on top of the exploded result of the rt.jar.
• Re-jars that exploded result into a new rt.jar.

All the script needs from you is for you to filter out what you want to be compiled, and provide the directory structure, and then for you to move the rt.jar to your JRE installation folder when it is complete.

Please be aware, this script *is* a workaround, and as such, it can't compile some of the more obscure classes that may not be part of the public JDK libraries, and it doesn't do anything about native libraries - so, if you need a *full fledged* debug rt.jar, you might want to read about more here .

To get started then, simply go to the directory where your JDK is installed and get the source zip (should be JDK_HOME/src.zip ). Then, extract that into a temporary folder somewhere. This folder should only have a subset of the classes that are in src.zip - you can play with this set until they all compile correctly, but I have found that taking all of java/**/* , javax/**/* , and all of org/**/* satisfies all of my debugging needs, and compiles fine all the way up to Java 5. This covers XML, java.util, java.lang, java.io, java.nio, javax.swing, java.awt, etc. - so typically is good enough.

Here is a screenshot of my source folder prior to the compilation:

The script is optimized to make compilation as quick as possible, we've found it only takes a couple minutes. Adi discovered that if instead of just telling 'javac' to 'compile everything under the source folder', by giving it a file list produced off of all of the files with a .java extension (which is really the same thing) he was able to make javac literally orders of magnitude faster.

The next step is to set the script up for your platform. All of the variable information is isolated to the top of the script, and is documented quite well. It primarily consists of 1.) where your existing JRE is, 2.) where the source to recompile is, 3.) what level the source should be compiled at, and 4.) where the javac command to use is. Once you have it configured, you should be able to simply execute it. Here is what the top of my script looks like:

@echo off
:: You must set the following variables.
:: SRC_DIR - Location of .java files to be compiled into the new rt.jar
set SRC_DIR=src
:: DESTINATION_DIR - Final location to copy new rt.jar into
set DESTINATION_DIR=.
:: RT_JAR - Full path to the location of an existing rt.jar to use as the source (Will be left unharmed).
set RT_JAR="C:\Program Files\Java\j2re1.4.2_08\lib\rt.jar"
set LEVEL=1.4
set JAVA_BIN=C:\Program Files\Java\j2sdk1.4.2_08\bin\

:: No need to modify anything below this comment.

Once it is done, simply go to the lib directory of the JRE you are debugging with (typically either [JRE_HOME]/lib or [JDK_HOME]/jre/lib), and rename the rt.jar there so you can back it up (say, rt_old.jar). Then, move your new rt.jar in. That's it!

I have attached the script in full so you can peruse it for yourself. I apologize for all you non-Windows users, it is a Windows batch script. The good news is if you can do it with a Windows batch script, it surely can be done with a script on any other platform, and probably better. The script is fairly simple in nature anyway, and is well documented, so hopefully you won't have any problems.

Until next time,

R.J. Lorimer
Contributing Editor - rj -at- javalobby.org
Author              - http://www.coffee-bytes.com
Software Consultant - http://www.crosslogic.com