Blah.Blah.Blog

The seven areas I was interested in were:

1. Generics (the big one in most people's minds, and the only one currently supported by IntelliJ 4.0.3... but more on that later)
2. Autoboxing/Autounboxing
3. The foreach style of iterator
4. Static imports
5. Enums
6. Variable length parameter list
7. C-style formatted input and output

Note: Although there are other key changes in Tiger (i.e., metadata, new concurrency libraries courtesy of Doug Lea, and easier RMI stub generation), these weren't as important to me as the basic syntactic additions, which I felt I would be dealing with more regularly.

See below for a screenshot of my IntelliJ editor window showing the source. The reason for the screenshot as opposed just including the code will become apparent a little later on.

After having read quite a lot on these new language features, and now having spent the minimal amount of time implementing them in a completely trivial manner, I have these comments to make:

• I love the new for construct. This form of foreach syntax is present in many other modern scripting languages and should be quick to pickup and use for the vast majority of Java devlopers.

• Ditto for enums. I absolutely hate having to emulate C's enum construct in Java, even following the good suggestions of Joshua Bloch. I think it's great to see this functionality subsumed into the language itself.

• Personally, the static import feature would definitely be a "nice to have" rather than a mandatory requirement. Sure, it does reduce typing when referencing static elements, but I like the scoping context that reading Color.RED gives me, rather than having to peer up into the rafters to see whether the RED I'm seeing has been statically imported from java.awt.Color or is just a poorly named constant from some other package.

• Autoboxing/Autounboxing. Has caused some contentious discussions on several forums of late. I think autoboxing is basically a good thing as it results in being able to write code that works "the way that you would expect it to". By this I mean "emposwering" the JVM to automatically make the type coercion decisions us developers had been placing into our code manually up until now. Interestingly enough, I added autoboxing into my application completely by accident when I passed the variable list of arguments and automatically cast them from primitive ints to Integer objects. Previously, this sort of problem would have resulted in a compilation error and then either an API change, or some amount of hacking to convert one to t'other.

• Variable length parameter lists. Could easily have been omitted IMHO. I like the idea of such a feature, but have so infrequently ever needed the same, even when I was originally developing in C and C++.

• OTOH, I'm a big fan of the introduction of the printf/scanf functionality from C. Like varargs, this new feature is seldom (if ever) needed given the classes in the java.text package, however being able to combine formatting and input/output into a single statement is a huge bonus.

• Lastly, to generics. I had the most trouble getting my fingers around the syntax required for implementing generics. Perhaps, my lack of experience in other template-based collection languages has hurt me here, but I found it physically hard to type the code to declare my collection of Integer objects. However, I suspect this will soon pass given a little more practice. That said, I cannot say I like the result of such typing - the introduction of copious < and > symbols was very distracting when examining the code. Given I cannot remember the last time I actually had to debug a problem that was caused by lack of type safety on collections (or similar objects), my personal jury is still "out" on this new feature.

I have a couple of closing remarks that struck me as I was conducting this exercise:

1. I can distinctly remember reading that the original syntax of the Java language was "based on C, with all the unecessary stuff left out". How far it seems we have travelled since those grand statements; from bare bones language beginnings, Java has certainly matured into a massively bloated general purpose language, with all the attendent syntactic sugar. Indeed, you could easily argue that Tiger adds nothing but sugar to the Java syntax. Either way, I'm still excited about the upcoming changes and looking forward to cutting code in 1.5.

2. You can see from the screenshot, that there is going to need to be considerable rework of IDE AST parsers prior to the final release of Tiger. With the exception of the documented support of generics, IntelliJ 4.0.3 failed to recognize any of the other new features of the language. Furthermore, I discovered a quirky new bug in it's "organize imports" functionality when an import static line exists. The end result of all this was a complete mismatch between what the compiler was telling me about my program and the information reported by IntelliJ. This leads to tremendous cognitive dissonance and an enormous drop in developer efficiency. it's almost worthwhile reverting to GVim or other such arcane editors which are more readily extensible to cope with fundamental syntax changes.

   Pallada, the JDK 1.5 version of IntelliJ, is currently available as a nightly build and looks to be progressing well towards it's stated set of features. I couldn't find any sign of a release date though.