My First Rant On Sun and Java

Elliotte Rusty Harold has written an article 10 Reasons We Need Java 3.0 about why Java needs some big improvements. I agree it needs some big improvements. I even agree with a few of the ones he listed. I even have my own list of desired improvemnts that I'll list in future posts. But first lets go over some of his recommendations.

I'm fairly indifferent to his items 10 thru 4. Actually, that is not entirely true. I'm to varying degrees at least partially opposed to a few of them. One leaps out in particular: I'm opposed to deleting all the deprecated methods. Why? Leave aside that this breaks old code (though that's a good reason). Some of them are still necessary.

Necessary methods that are deprecated? Well, yes. When I compile my source code with JBuilder v5 (which is at JDK 1.3 level; no I haven't upgraded to JB v7 yet) it gives deprecated methods warnings. Here's an example: In java.sql.Date I use getYear(), getMonth(), and other similar methods. Well, calling them generates deprecation warnings. Why? I went and looked in them and they call getField(). But getField() is private. So I can't call it. So then I looked at the Javadoc comments for getYear and I see that it has been deprecated because we are supposed to use Calendar.get(Calendar.YEAR). But in order to do that we have to use Calendar (or really GregorianCalendar). But wait, I'm using java.sql.Date because I'm calling JDBC libraries that want their dates in java.sql.Date types. So why deprecate a class that Sun's own JDBC spec requires us to use?

I'm looking at the source code to the JDK 1.3's version of PreparedStatement. It doesn't have a simple straightforward setCalendar() method. It does have some sort of way of using one version of the setDate() method that you pass both a java.sql.Date and a Calendar object to. But from the poorly written description it sounds like the Calendar object may just have the timezone info to use and may not have the actual date value that you want to set in the database field.

In any case, if you have a java.sql.Resultset (ie if you are getting data back from databases using JDBC calls - but hey, how many people do that?) all your getDate() methods return a java.sql.Date object. There is no getCalendar() or getGregorianCalendar() method. You have to get Date objects from your Resultset. Then you have to do your own conversion from one of them to a GregorianCalendar object. Well, GregorianCalendar doesn't have a constructor that accepts java.sql.Date as an argument (why accept a deprecated type as a constructor argument? after all if it was deprecated there is no need to use it, right?). So you have to do getYear(), getMonth() and so on in order to get the values to pass to the GregorianCalendar constructor. But when you do that your compiler will then complain about using deprecated methods. This is retarded.

Now, maybe they fixed it in JDK 1.4. But why did Sun go deprecating methods in 1.1 (which is what the Javadoc says is when getYear() was deprecated) that you can't stop using?

Its these little details that make me react with a bit of hostility toward suggestions about eliminating deprecated methods.

Item 8: It isn't clear to me that turning the primitive data types into full objects is worth whatever advantages that are supposed to accrue from this. It seems to me that Java has bigger problems. I'm mildly resistant to this idea until I see a lot more written pro and con on it.

Item 4: Why ditch the AWT? Swing is pretty much written on top of AWT anyway. AWT is faster too. I don't see what big advantage is supposed to be gained by doing this. AWT exists and Swing relies on it. And why is Mr. Harold once again so keen to break old code? Java's got enough problems as it is without doing that.

Item 3: Yes, the collections have problems. I would suggest that writing a whole new set of collections classes while keeping the old ones is the way to go. The best way to do that is to have an open source group do it under a LGPL or BSD/Apache style license. Create code that Sun doesn't control. The biggest problem with Java now is that Sun is in charge and they just don't have enough bandwidth to improve everything in Java that needs to be improved.

Item 2: Yes, redesign the IO. Just keep the new classes separate from the old classes. Again, better if a lot of this work could be done by anyone but Sun. That way it can be improved more rapidly. One only has to look at the JDOM effort to see what can be accomplished by open source coders operating out from under the thumb of Sun.

What is great about something like JDOM is that it is getting fixed all the time. You don't have to wait for Sun to rev their JVMs. You can even take the same fixes and run them on various versions of the JDKs. On one hand, as many libraries as possible ought to not be part of the core JDK shipment. On the other hand, beeing able to rev libraries independent of Sun's releases is a really good thing IMO. Okay, then Sun should include libraries like JDOM in the install for ease of distribution but make them separately updateable and not controlled or owned by Sun.

Item 1: Yes, I hear that the class loader has serious limitations. I'm sure the JBoss people know how the class loader ought to work. They went en mass and complained about this issue in the Bug Parade. They are the ones most worked up over the class loader limitations. They rant about the class loader on their developer list (well reasoned rants too IMO).

Okay, so these are my reactions to Mr. Harold's suggestions. In my next post I'll address the things about Java that I think are more important for improving its prospects in the marketplace.

Posted by Randall Parker at September 16, 2002 11:02 PM