With Java 1.5 released today, it got me wondering how many weeks it will take until I’m comfortable reading the new language syntax. Tiger’s changes are the first major syntax changes to the language in seven years, when features like anonymous inner classes were introduced in JDK 1.1.

After reading Java code on a regular basis over the past six years, I can read Java code quickly. The syntax is second nature. Common idioms have become nearly standardized. And there are only a few common coding styles out there. But Tiger has a lot of new syntax. How long until reading code, like the snippets below, becomes second nature?


Map<String, Integer> m = new TreeMap<String, Integer>();

Code like the above is fairly easy to read. But code like (from java.util.AbstractCollection):

public boolean addAll(Collection<? extends E> c) {
Iterator<? extends E> e = c.iterator();
// ...

is a little less clear. When I first looked at this code, my first question was: Does that compile? A question mark extending an “E”? I’m sure I’ll get used to reading code with generics over the next few months. But today, I say, “Huh?”

Static imports

getContentPane().add(new JPanel(), CENTER);

With the above code, I’ll first look around for a static final CENTER declared at the top of the program. When that fails, I’ll do a text search. And I still won’t see CENTER declared anywhere. Then I’ll realize it’s a static import, a terrible new feature allowed by writing code like import <i>static</i> java.awt.BorderLayout.* at the top of the class. Bleccch.


Annotations probably will be the toughest new syntax for my eyes to scan over quickly and learn to ignore the boilerplate fluff in order to get to the meat of the code. For example, when I read a line like:

public static final void doSomething(int i) {
// ...

my brain quickly skims past the modifiers and sees that it’s a method declaration for doSomething.

But this code, taken from the Sun article J2SE 5.0 in a Nutshell, slows me down a lot trying to figure out what’s being defined.

import java.lang.annotation.*;
@Retention(java.lang.annotation.RetentionPolicy.RUNTIME) @interface debug  {
boolean devbuild() default false;
int counter();
public class MetaTest {
final boolean production=true;
@debug(devbuild=production,counter=1) public void testMethod()  {

Not only do annotations add more verbose modifiers to methods like testMethod above, my eyes see syntax like:

boolean devbuild() default false;

and stop dead because of this alien syntax. (It defines an annotation type with a default value.)

I’m not saying annotations are bad. I like the concept of annotations. For instance, coding EJBs promises to become slightly easier, and remove the need for running the code through a pre-processor like XDoclet. And when you mark a method with the built-in @Override annotation, the compiler can tell you that you must have mistyped your method public String toStrng rather than allowing you to happily assume you are overriding the toString method in Object — and spend hours puzzling over why your code isn’t working.

Ultimately, I think annotations will allow creative people to write interesting code. For example, Cedric Beust’s TestNG uses annotations for unit tests. TestNG’s annotations allow you to write unit tests that don’t need to extend a class or implement an interface, and allow you to mark a method as being part of one or more test suites rather than having to write separate test-suite classes.

On the other hand, I suspect some developers will go crazy with custom annotations and write a lot of cluttered code. Since annotations allow an unlimited amount of “stuff” inside them, I’m guessing I’ll see multiline annotations that bury a method declaration beneath the clutter unless I’m using an IDE with syntax highlighting to point it out. Eventually, though, we’ll settle into some standard annotations, and peer pressure will embarrass those who overuse annotations for marginal gain.

And soon, I know I’ll get used to reading those annotation tags. My eyes will learn to skim over the annotations, glean the basic meaning, and see the code beneath. Just like the other new language features in JDK 1.5, we’ll settle on some comfortable, common idioms so they become second nature. But until then, I’ll be spending some time learning to read Java again.