Most Read Latest News Blog Resources

Beginning this issue, Allen Holub joins SD Times as our Java Watch columnist. A leading architect, consultant and instructor in C/C++ and Java, he has written eight books, including "Taming Java Threads" (Apress).




May 1, 2004 — 
JAVA WATCH:

Missed Opportunities

By Allen Holub

May 1, 2004 -

Java's "Tiger" release (version 1.5) is due out later this year. I'll have many things to say about the changes that Sun has made to the language, but in this column, I want to address some of the downside. Just to head off the flames, bear in mind as you read this column, that I like Java. I program in it almost exclusively and think that it's a great language for what it does. I am not the enemy.

Sun, however, blows it on occasion, and it seems reasonable to discuss the downside as well as the upside. I don't intend to trash 1.5 so much as to give you a heads-up so that you can be thinking about how you might want to use (or not use) some of the new functionality.

The new Tiger release is noteworthy in that it introduces significant features to the language itself. Some of these features (among them, enums, a new "foreach" form of the for statement, and a set of concurrency utilities to help you get multithreaded applications under control) are long overdue. Other features (static imports) are hideously bad ideas. The largest addition to the language is generics: a C++-template-like addition to Java.

I can't possibly talk about all the new stuff in a single column, so I'll discuss the new pros and cons of these features gradually, over the course of several issues. Another resource is the article "J2SE in a Nutshell," found atjava.sun.com/developer/technicalArticles/releases/j2se15.

Before talking about Tiger, however, let's talk about politics. Several of the new features in Java 1.5 are there because Microsoft has added similar features to its C# language. I really hate the idea of a compiler-level arms race. Language features should be added because they improve the language, not because the other guy does it.

Take autoboxing (please). With autoboxing, if you use a primitive-type object (like a double) in an object-like context (like a Collection insert), the compiler creates an object wrapper (like a Double), initializes it from the primitive, and uses the resulting object. Autoboxing is in Java because Microsoft put it in C#. Unfortunately, autoboxing is far from the best solution to the problem of primitive types being treated inconsistently; it would be vastly better to make the primitives honest-to-god classes.

For example, if double were a real class, you could insert it into a Collection without fuss. So, you'd find a cosine by saying x.cos() rather than Math.cos(x). Therefore, you'd be able to derive classes from double to add operations, and so on.

There's absolutely no reason why Java's primitive types could not be real classes. The argument that it's more "efficient" to have two categories of types is specious-the compiler can optimize primitive-as-object operations down to essentially the same code as it creates now.

It is certainly easier for the compiler writer if primitives are segregated from the main typing system, but I don't think that the convenience of the compiler writer is a valid reason for adding a significant inconsistency to the language. If an int were an instance of a genuine built-in class, then autoboxing would be completely unnecessary.

My gripe, then, is that Sun didn't take the opportunity to really fix the primitive-type problem. Instead, it just aped the boys in Redmond and introduced a poorly thought-out feature to the language.

Another example of a missed opportunity is in Tiger's concurrency utilities. These classes make it easier to write multithreaded programs by providing a set of Posix-like threading-support classes. Don't get me wrong-having these classes is a giant leap forward. The real problem, however, is that threading itself is poorly understood and easy to get wrong, and the new classes don't help at all in solving this fundamental problem.

The core difficulty is that threading, as implemented in Java, is fundamentally procedural in nature (you synchronize procedures, not objects), and this procedural worldview clashes with the object-oriented paradigm. (I hate that word, but can't think of a better one.) That is, an object-oriented programmer wants to think about asynchronous messages, not about threads.

Some languages (Ada, PL/M, etc.) solve this problem elegantly by directly supporting asynchronous messages in the language itself. To my mind, Java should have solved the threading problem in the same way: by introducing language-level support for asynchronous messages.

I'm disappointed that Sun didn't take the opportunity offered by a major release of Java to really fix a few serious flaws in the language. I don't like the Band-Aid solutions that it has actually used. Whether Sun's failure was caused by timidity, lack of imagination or internal politics is immaterial. Tiger represents a missed opportunity, and that's a pity.


Share this link: http://www.sdtimes.com/link/27844
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading



 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

4/12/2010 to 4/14/2010
Las Vegas
Penton Media

4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

4/19/2010
New York City
Flagg Management

4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG