The 8 Nights of Java – Night 5

Java 5.0 was the biggest change to the language syntax since it came out. The designers of Java managed to complete this impressive feat without removing any existing syntax and by keeping everything backward compatible. They accomplished this by leveraging compile-time enhancements. A compile-time enhancement is a language rule that a developer can use to write and build software with, but that gets stripped out of the compiled file. For example, Generic notations like List<String> are actually removed from a class when it is compiled, resulting in just a List of Objects. This technique allowed the authors of Java to thrust it into the future, with minimal impact on existing implementations.

Jump to: [Night 1 | Night 2 | Night 3 | Night 4 | Night 5 | Night 6 | Night 7 | Night 8]

Java 5.0 Notable Features
Sun release Java 5.0 (codename Tiger) on September 30, 2004.  Notice we went from 1.4 to 5.0? That’s right. Java finally dropped the “1.X” from the name with Java 5.0! Sun realized that they were far out of beta testing of Java (with millions of businesses around the world using their software) and rather than go from 1.4 to 2.0, they decided to just drop the 1. prefix. Key new functionality included:

  • Generics
  • For each loop
  • Autoboxing and unboxing
  • Varargs
  • Enums
  • Static imports

From Scott:

In my opinion, Java 5.0 helped saved Java as a modern development platform. Other languages with more advanced features were coming out, many that were far easier to write with. As I said on Night 2, Collections were powerful, but not particularly easy to use. Dynamic Lists with primitives were such a pain… I mean take a look at this before and after code:

Before Java 5.0:

List data = new ArrayList();
data.add(new Integer(1));
data.add(new Integer(2));
data.add(new Integer(3));
Integer sum = new Integer(0);
for(int i=0; i<data.size(); i++) {
	sum = new Integer(sum.intValue() 
			+ ((Integer)data.get(i)).intValue());

With Java 5.0:

List<Integer> data = new ArrayList<Integer>();
Integer sum = 0;
for(int value: data) {
	sum += value;

It might not seem like a lot, but when you have to write thousands of lines of code that use Collections and other generics, it makes a big difference! The syntax got even shorter in Java 7 with the Diamond (<>) operator!

At the time of it’s release, these changes were quite controversial. Some felt they shouldn’t be stripped out during compilation and should be made part of the JRE. After all, the two code samples above compile to nearly the same thing (except possibly with an iterator), but Java has always been big about backwards compatibility. I think part of what helped to settle the issue is that the drastic improvement and availability of multi-core processors, which made any theorized performance hit negligible compared to the huge benefit of writing simpler, more maintainable, and easier-to-read code. Being the “old man” that I am, I still sometimes call intValue() on an Integer. If you were writing in Java before 5.0, the variable can feel naked without it!

From Jeanne:

I still have my copy of “Java 1.5 Tiger: A Developer’s Notebook” and the stuffed tiger Sun gave out is on my desk at work. This was a great change to the language. Generics made the code so much cleaner and safer. Autoboxing made the code cleaner as well. Enums are awesome too. While I use static imports a lot, I have mixed feelings about them. It’s a bit like the debate on whether to use a wildcard in regular imports. Are static imports clearer than typing the class name in each place. Well, like many things in programming, it depends.

I was looking forward to varargs so much that I designed a class to use them before they were written. I remember writing a class in Java 1.4 with methods taking 1, 2, 3, 4, 5 and 6 String parameters (along with an array version) and a comment to refactor it in Java 5.0 to use varargs. I also remember the feeling when I could get rid of all that crud when we upgraded!

Looking back, I have trouble deciding which is my favorite new feature. I’m torn between generics and autoboxing. Generics makes the code safer, but autoboxing makes the code easier to read. Decisions. Decisions.