Java yesterday, today and tomorrow

Today I’d like to write a few lines about Java 5.0. It’s surprising how backward-looking I felt when I wrote skeptically here about moving to it. See Migrating to Java 5.0 — Reality or Utopia? (October 5, 2004) and Should We Move to Java 5.0? (May 30, 2005). A lot of time has passed since then, and I’ve been able to go through the transition myself.

I don’t feel so backward-looking now. With hindsight, I’d even say it was a fairly rational view. The biggest change Java went through was the introduction of generics.

How superficial we scribblers were, myself included, when we covered the introduction of generics. The well-worn generic collection example is proof enough. Generics extend the language’s semantics so much that if you don’t study them you’ll probably feel like Alice in Wonderland, and not only when you read source code.

All the other features version 5 introduced were cosmetic improvements. Generics took the language somewhere entirely new. If you want to understand and use generics to their full extent, even Angelika Langer’s phenomenal Generics FAQ, which runs to 300 pages on paper, may not be enough.

There are plenty of concepts to learn, including raw types, wildcards, wildcard capture, type erasure, type argument inference, generic classes and generic methods (the last two are very different). You also need to understand, for example, the distinction between a generic class and a particular parameterization of it, and that there’s no inheritance relationship between the different parameterized types. They’re incompatible.

There are more than a few traps like that to work through. To understand or implement a use of generics you may even need to put yourself in the compiler’s shoes. Speaking of the compiler, what do you think it will do with the following example? Will it compile?

public class Foo {
    
  public static  T doSomething(){
   return doSomethingII();
  }
    
   
  public static  U doSomethingII(){
   return (U) new Object();
  } 
}

If you think it will, you’re right. If you think it won’t, you’re right too! It depends on the compiler. If you use the one from the Sun SDK (tested on 1.5.0_04 and 1.5.0_05), you’re out of luck. With the Jikes compiler, you win. Eclipse and Tomcat use it, for example.

By the way, do you know how to change the code so the Sun SDK compiler accepts it too? You can only change the generics.

That’s Java today. Ask yourself whether you really need and will use the features of version 5, and whether they might end up doing more harm than good. Ed Burnett’s point of view in Better, faster, stupider Java inspired me while I was thinking about this.

Mylar is a plug-in for Eclipse and, being written from scratch, the developers decided to use all the newest features of JSE 5. One little problem, not everybody could use JSE 5. For example there is no JSE 5 support on RedHat Linux with GCJ. Oh, there probably will be someday, and maybe there are workarounds with retroweaver or something but that’s not the point.

Language guys love to tweak. I know, because I’m a language guy myself. I used to work on compilers, code generators, libraries, and debuggers. We were always adding new stuff, new commands, special keywords, etc. Did our users thank us for it? Maybe the one or two that wanted the new things, but the vast majority would just groan when a new release came out. What will this break now? Will I have to upgrade? Will I have to use somebody else’s code that requires this new thing before I’m ready? Has it been ported to all the machines I need to run on? Boring, I know, but very practical and important issues.

And what will Java look like tomorrow?