Anders Norås' blog

The difference between cats and dogs

Earlier today I went “sleeping with the enemy” – I attended a Java user’s group meeting. The topic of the day where the new features in Java 5 (“Tiger”) and a quick peek into what is planned for Java 6 (“Mustang”) and Java 7 (“Dolphin”).
Just like the .NET community, the Java community is facing extensive changes to their programming language.

The key new features of the Java 2 Standard Edition version 5.0 are:

• Generics
• Enhanced “for” loop, which basically means “for-each” support.
• Boxing and unboxing
• Typesafe enums
• Static import
• Annotations

In addition there is a new version of the Enterprise Java Beans (EJB) framework, changes to the class library amongst other things.
As a C# programmer many of the new features, such as boxing, “for-each” and annotations, are already commonplace.  Others, such as generics, are similar to the new features in .NET 2.0.
Unlike the .NET community, who welcome the new features with open arms, the new features are not that popular with the Java community.
If I was to judge by what many key people in the Java community are saying, they would rather be without these changes for now. Many feel that the new features are being forced upon them and there is a fear in the community that new features such as annotations, akin to .NET attributes, will flood applications with unexpected errors and render them indebuggable.
The Java annotations differ from .NET attributes by having support for compile-time code injection, in addition to metadata retrieval via reflection. This gives the debugging argument some validity, but apart from that I think they’re all crying wolf.
Attributes is a feature I’ve come to love in .NET. As reflected attributes are interpreted by the hosting application, unknown metadata on an object should not affect or be of importance to this application. I’ve heard arguments like “If transactions are controlled by annotations what will happen if the hosting application has no knowledge of these attributes?” This is theoretically a relevant problem, but in reality no sane person would run a transacted object outside a transacted environment without being aware of the implications. Compile-time code injection should be familiar to most enterprise Java developers. XDoclets, a much used Java based open source technology, is a framework for code generation and injection.

Novice developers find it difficult to write strongly typed collections. This is highly understandable. When doing this you have to relate to multiple interfaces and base classes. On top of that, it is dead right boring to do. Luckily we have tools like Code Smith to help us out. Unfortunately, not many novice developers are aware of such tools.
This has caused many mission critical applications to have collections in their cores without support for “for-each” iteration, databinding or any of the other features we are used to with regular .NET collections. Generics are a panacea to this. Still, members of the Java community have strong objections to generics being introduced in the Java language. The arguments against generics range from them being different from similar features in Python to the Java Virtual Machine not having proper support for them.

One should expect the JVM to have some limitations ten years after its first release. The mistakes made in the design of the virtual machine are fundamental to the improvements made in .NET. With new languages such as Groovy running atop the JVM, I see it moving in the direction of .NET. This and the ability to introduce the Tiger features prove that Sun did a good job designing it.

Cats and dogs are different. I can’t really see the problem with Java 5. These features make the language easier to use, opening it for a larger audience. In the same time they make the lives of many Java developers much easier. It might be that these features hinder some developers in their work, but this group will be ridiculously small compared to those who benefit from these improvements.