Moazam Raja: Java

Logging GC output to a file, the differences between Xloggc and verbose:gc

Wed, 09 Jun 2004 22:18:49 GMT

I'm sure people have noticed this little idiosyncrasy in the way that garbage collection log output is handled in the JVM. But if you have not, this is a good data point when preparing to read through GC logs. If you simply use the verbose:gc flag, you'll have GC log output sent to the stdout console. Now, if you use the -Xloggc:[filename] switch, the GC data will be sent to a log file which you can grep through later. But either way, you get the the same GC data ...right? Wrong. The -Xloggc:[filename] switch has the additional effect of turning on the -XX:+PrintGCTimeStamps switch and hence gives your log files the added benefit of time stamps. Wierd! I'd expect both of these switches to have the same exact behavior. I might file an RFE or Bug on this tonight. Oh, for those who want to use it, the -Xloggc switch was introduced in 1.4.0 and newer VMs.

View from the Trenches: Looking at Thread-Dumps, by Alexandre Rafalovitch

Wed, 09 Jun 2004 06:00:40 GMT

Alexandre Rafalovitch, a BEA Backline Support Engineer emailed me about reading thread dumps and his proposal for formatting dump data. I've read through Alexandres article, and while I'm not a big fan of using XML for everything, he definitely presents an excellent view on making thread dumps easier to read and diagnose. The really cool part is that Alexandre has written an application which takes standard thread dump data, converts it into XML, then uses XSLT to convert the data into the format of your choice. I'm actually a bit surprised that there isn't a JSR in progress to address this issue. I think one of the reasons for this is that most developers and users are not interested in the nuances of thread dump readability. Of course, as backline engineers, this topic is near and dear to myself and Alexandre. Alexandre will be presenting this in a session at JavaONE 2004, session TS-1646. I'll be sure to attend.

"What would be a perfect solution here is to be able to convert these thread-dumps into some sort of intermediate structure/language that has flexible structure, can tolerate missing fields, and can be processed by third-party tools in various ways. And, of course, if it can somehow involve a currently popular technology, so much the better. Do we have such an intermediate language? Indeed we do — it is XML. It is somewhat human readable, has many tools written for it, and already has not one but several transformation and reporting technologies built on top of it, such as XSLT, XQuery, and XDB." [full article]

Debugging Backwards in Time - Omniscient Debugging

Tue, 01 Jun 2004 18:15:53 GMT

I can't believe that I didn't know about this before! ODB allows you to do 'Omniscient Debugging' on Java applications, with or without the original source code. The ODB debugger allows "..developers to step backwards through the execution of a program to determine where and how programming errors occurred. By recording each state change in the target application, it allows the developer to navigate "backwards in time" to see what the values of variables and objects WERE, enormously simplifying the task of debugging programs." One page description of the ODB
Article , Debugging Backwards in Time
AADEBUG paper on Omniscient Debugging (pdf)
ODB User Manual

Download the source code of the Java SDK

Mon, 31 May 2004 23:48:35 GMT

Want to look at the code of the JVM or build a test version of your own? Use the source. And look, detailed build instructions are available too!

The ultimate programming font.

Tue, 25 May 2004 23:47:01 GMT

While this is not exactly Java specific, it's one of those things that every developer should have.

Debugging thread related hangs in the JVM

Tue, 25 May 2004 21:27:49 GMT

Once in a while Java users and developers run into problems where their Java application simply seems to hang. No core file is generated, no IO is detected, the process just sits there waiting...for something. Usually these problems can be traced to OS and JVM level threading.

J2SE Update Release Cycles

Tue, 18 May 2004 18:06:55 GMT

Many people are running on very old minor releases of J2SE. I've seen companies running 1.2.2_04 while 1.2.2_17 is out! Here is some info on how the J2SE update cycle works, and why you should upgrade to the newest update releases.

J2SE Code Names

Tue, 18 May 2004 06:42:02 GMT

This little list helps to make sense of those J2SE BugIDs which reference J2SE code names.

VERSION	CODE NAME	RELEASE DATE
JDK 1.1.4	Sparkler	Sept 12, 1997
JDK 1.1.5	Pumpkin	Dec 3, 1997
JDK 1.1.6	Abigail	April 24, 1998
JDK 1.1.7	Brutus	Sept 28, 1998
JDK 1.1.8	Chelsea	April 8, 1999
J2SE 1.2	Playground	Dec 4, 1998
J2SE 1.2.1	(none)	March 30, 1999
J2SE 1.2.2	Cricket	July 8, 1999
J2SE 1.3	Kestrel	May 8, 2000
J2SE 1.3.1	Ladybird	May 17, 2001
J2SE 1.4.0	Merlin	Feb 13, 2002
J2SE 1.4.1	Hopper	Sept 16, 2002
J2SE 1.4.2	Mantis	June 26, 2003
Future Releases
J2SE 1.5.0	Tiger	Not yet released
J2SE 1.5.1	Dragonfly (dragon)	Not yet released
J2SE 1.6.0	Mustang	Not yet released

Previewing your own apps with JGoodies L&F within NetBeans

Mon, 17 May 2004 23:32:31 GMT

Once you have NetBeans running with the JGoodies UI, it's very easy to preview your own applications to see how they would look with the JGoodies UI.

Using JGoodies with NetBeans

Mon, 17 May 2004 22:32:09 GMT

Here is a quick tutorial on using the JGoodies UI library with the NetBeans IDE.