ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button
  10 Reasons We Need Java 3.0
Subject:   No
Date:   2004-07-20 21:41:48
From:   grlea
My comments on some of your suggestions:

10. Delete all deprecated methods, fields, classes, and interfaces.

Yeah, I'd like this to happen, but it's easy to see why it hasn't.
Sun has a major pre-occupation with backwards-compatibility, and while it seriously annoys me sometimes, I'm sure there's people that have been very thankful for it (probably those who write software for money and don't want to re-write it with every JDK release).

9. Fix incorrect naming conventions.

Hindsight is always 20/20.
While it'd be nice if some things were named differently, I don't think any programmer who has to maintain any program would be happy about if names were changed.

8. Eliminate primitive data types.

Your argument for doing this is merely that "Java would finally become a pure object-oriented language."
I don't know that anyone really cares about that, and I don't think it's warranted to make such a change just for the sake of perfection.
The most practical problem of primitive->Object conversion and vice-versa is covered by auto-boxing in J2SE 1.5.

5. Convert file formats to XML.

XML is not good on toast, cannot drive you to work, and is of very little use during a triple bypass operation. Shock horror: it's not the solution to everything.
Why try and represent properties files, plain olf name-value pairs, with a hierarchical data format!? Why print the number 2147483647 into 10 bytes (UTF-8) when it can be serialised in 4 bytes (int)?

4. Ditch the AWT.

"Two GUI APIs is one too many."
I'm sure if you mention this to any Eclipse developer they'll realise the futility of their ways and burn all known copies of SWT post-haste.

"Most Java developers ..." were not contacted by the author, but he has read their minds and feels compelled to speak on their behalf.

Seriously, though, there are people who still use AWT (even for new projects) and swear by it.
You can't just delete everything that you, or even "most developers", don't use.

1. Redesign class loading from scratch, this time with human interface factors in mind.

Perhaps the error messages are confusing and the concept a little complicated, but the power is unmatched. We're computer scientists here, not primates. People who need to use class loaders and know how to have done amazing things with them.

Summing Up

Basically, the suggested "way forward" here is to spend a lot of time cleaning up, remove things that you don't use (even though others might find them useful), change some things to be the way you think they should be, throw both backwards- and upwards-compatibility to the wind (making every library ever written useless) and start from scratch again. And you can't understand why Sun doesn't want to do this? If anyone suggested taking this approach on their commercial projects, they'd be laughed at all the way to the welfare office. I believe Java is moving into the future and will continue to do so without any of the changes you've suggested. None of the changes you have suggested would make Java better for me, most of them would annoy me, and some of them would concern me greatly if they happened.