A major event is about to happen - the final release of version 1.5 of the core Java platform.

The changes in 1.5 are some of the most important to the Java language. This is a big step for Java and it's not an easy one. People with an existing investment in the platform tend to be very conservative about the language and core platform, usually for good reasons: nobody likes to have their investment rely on something that has been deprecated, made obsolete, and possibly becoming unsupported. Dramatic changes to the Java language upset a lot of people, not just anyone but some of the long-time Java users who have played a part in making Java successful. Language growth is both painful and necessary.

In Guy Steele's famous speech and article "Growing a Language" from 1998, he discusses the growth of programming languages. He explains how Lisp's ability to grow in a seamless way made it large and has kept it alive for an amazingly long time, while behemoths like PL/1, which was designed to solve everything out of the box, never succeeded.

Java is looking more and more like the language for solving everything. It was never a language that supported growth in the way Steele meant. It doesn't have constructs, like macros, that enable developers to extend the language syntax. This means that the growth has had to come through official channels, which is why the 1.5 release is so important to Java. In the early days of Java, every new and major upgrade was a revolution. The differences between the alpha API and 1.0 were huge, and the changes in 1.1 and 1.2 were substantial. With 1.2, Java became big, successful, and "real"; people started depending on it for large projects. The constant revolutions had to be replaced by slower evolution.

However, if Java does not evolve fast enough, something without a history to care about will soon turn Java into a legacy technology. This is a pretty normal cycle in the computing world. One technology gets wide acceptance, but eventually grows large and can't evolve as fast, then something new comes along and replaces it. The Java language has felt some of this. Competing languages, such as C#, Ruby, and Groovy, are not tied to previous decisions and existing architectures. They use this to try to leapfrog Java.

For a long time it seemed as if Sun had decided to accept a slower pace of development so it wouldn't upset existing Java stakeholders. Soon people who were not tied to Java for legacy reasons started looking at these competing languages. The only way to stop this is to have the courage to make the necessary changes, even if they hurt. With J2SE 1.5 I think Sun is finally showing that they have this courage. This is also true for the EJB 3.0 specification, which relies on features from 1.5 to drastically change how EJBs are developed.

It did take a long time for Sun to make these dramatic language changes and this has helped Java's competitors a lot. Considering that, for example, generics have been in the pipeline since at least 1998 and a JSR since 1999, it's amazing that they haven't become a reality until now. I'm not saying that generics should have been added to 1.4 - they weren't ready then - but it doesn't seem as if Sun has made this a high priority until now. You could speculate that the economic crisis at Sun has played a role in this. When everything was going great for Java and Sun, they might have been afraid to make big changes since that could risk what they had. Now that Sun is in a much tougher position, they might be willing to risk a little in order to gain much more.

Does 1.5 provide what Steele wanted? Steele's point was that the language must facilitate language growth; it must supply patterns for extending the language. Steele suggested a few examples, most notably generics and operator overloading. Java 1.5 does contain generics but not operator overloading. However, it does provide one feature that defines a pattern for language growth: annotations. I would love a complete macro facility for Java, but I know that many wouldn't and annotations do give me some of the power that macros would. This is a great thing that moves Java to a position that will allow it to get older and still evolve. Seeing how annotations will be used to revolutionize EJB development, this is truly about growing the language.

Of course, I don't like all the changes in 1.5. For example, static imports are taking Java one step closer to write-only code. If you want to save keystrokes when using common statics, you should tell the IDE that when you type abs(), the IDE should expand it to Math.abs(). The language should not sacrifice readability for the sake of writability; the language needs to work well for both writing and reading, and enable the developer to be efficient by providing help to the IDEs. Static imports should be an IDE feature, not a language feature.

J2SE 1.5 will obviously be one of the main talking points at JavaOne and there are plenty of sessions available. If you want to learn about the new features, I recommend attending TS-1952, "Fast Track to the Java 2 Platform, Standard Edition (J2SE) v1.5," which will be presented by my co-editor, Calvin Austin, as well as Mark Reinhold.