Up till now, changes to Java have been pretty much constrained to APIs and the inner workings of the Java 2 platform. All of this will change once the JDK 1.5 has been released. The extent of these changes was revealed in a recent interview with Joshua Bloch (http://java.sun.com/features/ 2003/05/bloch_qa.html). As illuminating as the interview was, it left me with a number of questions, so I started to search for answers by reading JSR 201.

If you read this JSR, you'll find that it doesn't include a critical discussion of the proposed changes, nor is there any supporting documentation that includes a record of such a discussion. In fact, I was unable to find a public record of any critical discussion. Surely those discussions took place. What alternatives were proposed and why were they ultimately rejected? Do the proposed changes represent a direction for the evolution of the language? Take autoboxing, for instance. What problem is it trying to solve and is there an alternative that offers a better solution? Here are some thoughts on this point.

Autoboxing is a concise notation for working with instances of the immutable classes that are used to wrap primitive types. It will allow us to replace code such as "new Integer( ((Integer)map.get(key)).getInt() + 1)" with "map.get(key) + 1". While this code is easier on the eye, does this new syntax tackle the fundamental issue that objects and primitive types are like water and oil? They don't mix unless you add an emulsifier. In Java, the emulsifying agents have been wrapper classes, one for each primitive type. As necessary as these wrapper classes are, they do hinder our ability to operate on the underlying primitive unless we resort to the unpleasant-looking code listed above. Instead of solving the problem, wrapper classes have seemingly shifted the problem elsewhere, which resulted in the JCP Expert Group recommending that autoboxing be added to the language. This begs the question: Couldn't we have solved the problem instead of passing it along? If mixing objects and primitives is the problem, it seems reasonable to suggest that we shouldn't mix them. Instead, let's promote primitives to the status of first class objects with all the rights and privileges. In doing so, we would eliminate the need for wrapper classes and, consequently, for autoboxing.

In the past when I suggested that primitives should be promoted, I was told that this would be incredibly inefficient. My counter to this argument focuses on two points. First, being a first class object is a syntactic or notational convenience. The final compiled representation of integers and other primitives could (and should) be the choice of the implementers (sound familiar?). The second point was really in response to the comments about the differences in efficiency between operating on primitive types and on objects. But what of these differences? Do we really have to experience the cost of method lookups for each operation? To this I reply: Java is a typed language. In other words, we are giving the compiler big hints as to what we are doing. The compiler should be able to use these hints to do the right thing. In fact, current compiler optimizations are the result of far more complicated evaluations. One last point: autoboxing is implicitly creating both new objects and garbage. Though this is not bad in itself, it does remind me of the performance problems that can result from using + to simplistically concatenate strings.

I first thought of offering a counterargument to my proposal, but then realized that it's not my role to do so; it's yours. Furthermore, shouldn't it be the role of the JCP to foster healthy debates on all of its proposals so that we, as a community, know and understand that we are getting the best choices possible? After all, we, the average Java developers, are the ones who sit in the trenches of the Java community, and the JCP can only be our process if we all become more involved in it. You can send your comments to the JSR 201 and JSR 215 Expert Groups.