Maybe this session sounds like old hat, but I’m looking for more ammo to add to the list of reasons we should jump to Java 5 from either 1.3 or 1.4, and sooner rather than later. Already on the list is that we’d like to get to Tomcat 5, and introduce Hibernate. In introducing Hibernate, I’d prefer to go straight to H3 with annotations rather than do a double effort of implementing Hibernate with typical mappings or XDoclet, and then moving to annotations. Venkat Subramaniam is presenting.
I’m going to go about this session a bit different and actually post the entry now, and update it as the session progresses.
- Autoboxing – the nice syntax cleanup that turns a bunch of casting from primitives to objects (int to Integer and back). I know that it’s just Java doing all the casting behind the scenes, but I like the way it takes some of the ugly and tedious code out of Java source. The gotcha I wasn’t aware of is that if you write “int myInt = myArray[0];” on an Integer[], and the element in the array has a null value, you get a NullPointerException. Ouch.
- Happier for loops – for(int i=0; i
- enums – nice to finally see a sane way of expressing enums in the Java language. Once again, it’s little more than magic hand-waving behind the scenes, but it’s a real improvement to readability, and short-circuits the constants-as-static-final-variables-in-an-interface anti-pattern, with type-safety as a bonus. Some folks have a real beef with Java shoe-horning these features into the language, I give them a ton of credit for accomplishing their magic in the compiler rather than mangling the runtime with all of these features. I also haven’t seen this magic of adding a method to an enum – very interesting. EnumSet and EnumMap are also news to me.
- varargs – I hadn’t even heard of this until today. More nifty syntax sugar that allows you to supply a variable number of arguments to a method, with type safety. Declare your method public static void doStuff(String…), and you can call it with doStuff(“one”), doStuff(“one”, “2”, “three”) – Java will, behind the scenes, make your method accept a Sttring[], and bundle up your method call parameters into a String[]. Very cool.
- Annotations – one of my favorite new features in Java 5, based on the headache it relieves in creating Hibernate mappings. Defining an interface is quite wacky, but I think far more people will be using annotations than defining them.
- Static Import – Venkat isn’t a fan of this feature, and neither am I. Static import lets you import all of another class’ static methods and call them without even naming the class they belong to. The methods are called just as if they were defined inside the class. This looks like it has major confusion potential, with a minimal value-add.
Rob's Blog - Technology, Atlanta, Startups and Stuff 
Here are some more reasons:
? 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.