Welcome!

Kirk Pepperdine

Subscribe to Kirk Pepperdine: eMailAlertsEmail Alerts
Get Kirk Pepperdine via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java Developer Magazine

Java Developer : Article

Unleashing Tiger

Unleashing Tiger

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.

More Stories By Kirk Pepperdine

Kirk Pepperdine has more than 10 years of experience in OO technologies. In edition to his work in the area of performance tuning, Kirk has focused on building middleware for distributed applications.

Comments (3) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Ploni Almoni 08/14/03 07:39:14 AM EDT

Microsoft, competition - your kiddin' me.
What is .NET if not a replica of the Java Environment. Recall what happened to companies that used to compete with Microsoft - WordPerfect, Netscape etc.
Microsoft does not create competition it only destroys it (as all Monopolies do).

Ron Hunter-Duvar 08/11/03 12:29:00 PM EDT

You are absolutely right that primitive types should be promoted to first class objects. The efficiency argument is bogus. Both Lisp and Smalltalk treat primitives as first class with no efficiency issues (not that these languages are models of efficiency, but their inefficiencies do not result from their primitive handling), by internally tagging them as primitives. The use of these wrapper classes is far more inefficient, with all the object creation and destruction and wrapping and unwrapping overhead.

J Bammi 08/08/03 10:10:18 AM EDT

I read the whole interview:
I live in both the Java and .Net worlds. If i look at the features talked about in the interview, it almost reads like -- lets see what does c# have and Java does not -- lets bring them to the front (modulo generics of course). Sun had their head buried in the sand for over 5 years. .Net just help them pull their heads out (users screaming about these same features were ignored). Bring on the competition!