? Code executes faster under Java 5 JVM

? Java 5 JVM has a JMX GUI console viewer app. Can write JMX mbeans for app that appear in this console viewer. (Not just J2EE app servers that support JMX, but now can write a JMX mbean to admin any arbitrary Java software.)

? AspectJ 5 will use a new hook available in the Java 5 JVM to do load time aspect weaving. Currently I’m using AspectJ 1.2.1 and do compile time weaving. This is compatible with any JVM version and requires no special runtime support. However, there are powerful reasons to want to do load time weaving of aspects. For example, I’d like to fix a bug in my J2EE app server and automatically have all deployed software (and software yet to be written and deployed) be able to enjoy advantage of the bug fix. With load time weaving of my bug fix aspect this will be possible to do. Naturally I could address bugs in Java class libraries too. (Indeed, I’m interacting with a Sun engineer on how they can begin to use AspectJ to hugely facilitate ordinary developers being able to fix bugs and offer up the bug fix to Sun – their current technique has one downloading their complex development environment for Java which can take 2 to 4 hours to install and set up. The AspectJ approach will be an order of magnitude easier to do so people will have a much lower hurdle to participating in bug fixing with Sun.) BTW, with this new JVM feature, load time weaving of aspects will work even if a custom class loader is being used – that is why its such a powerful new feature!

? Code will look cleaner. Here is a code snippet that was originally written to Java 1.4 and then illustrated as written to Java 5 using some new features:

// Java 1.4 version

return MessageFormat.format( Shared.Rsrc(“ErrMsgFmt1100″),
new Object[] {  prefix, systemId,
new Integer(spe.getLineNumber()),
Shared.newline, spe.getMessage() } );

will now look something like this:

// Java 5 version

return format( rsrc(“ErrMsgFmt1100″),
prefix, systemId, spe.getLineNumber(), newline, spe.getMessage() );

This example used static import, autoboxing, and variable args features of Java 5.

Well, there you have some additional reasons to switch to Java 5. However, there might not be one overarching reason that compells the argument to switch. I think it is the aggregate of these capabilities taken together that makes the case.

Is interesting that I just recently completed migration of my code base from Java 1.4 to Java 5 (and just recently attended a NFJS where went to Java 5 session). I was also doing a migration to a newer J2EE app server version – and that was what lead to more issues in the code needing to be revised.

The developer staff is all now very pleased to be unfettered to use the new features and advantages of Java 5.