10 Reasons We Need Java 3.0
Pages: 1, 2

6. Fix threads.

Java was the first major language to integrate multithreading as a fundamental feature rather than a special purpose add-on library. Thus, it's not surprising that its designers made a few mistakes and missteps in this area. All of these need to be fixed:

• As Sun's Joshua Bloch wrote, "Thread groups are best viewed as an unsuccessful experiment, and you may simply ignore their existence." (Effective Java, Addison-Wesley, 2001) They don't provide the security they were intended to provide, and the minor functionality they do provide can easily be moved into the Thread class itself.

• The stop(), suspend(), and resume() methods are all rightly deprecated because they have the potential to leave objects in inconsistent states. They should be removed from the Thread class completely.

• The destroy() method isn't implemented. It just clutters the API. Get rid of it.

• It's become widely known that the Java memory model is broken with respect to "the semantics of threads, locks, volatile variables, and data races." Indeed, an expert group has been formed within the JCP to fix this, but not a lot has been heard from it since it was constituted a year ago. Without doubt, this is a hard problem; but maybe removing concern for upwards compatibility can help fix it.

• The non-atomic nature of doubles and longs is a sop thrown to architectures that can't efficiently do 64-bit operations. That's not nearly as much an issue today as it used to be, however, and few VMs ever took advantage of it. If these types aren't made into objects, then they need to be as atomic as the other single-byte types.

• Finally, we should seriously consider the possibility that monitors can be decoupled from objects so that an object can have multiple monitors for different operations. I'm not a thread expert (and I generally embarrass myself whenever I pretend to be one), but I've heard a lot of arguments from both sides on this point, most of which have gone right over my head. If we're redesigning Java threads, maybe we can move this discussion from boozy barroom chats to a serious discussion and figure out if there's some way to reconcile the two sides.

These changes are going to be tricky, and they're going to require changes at all three levels -- the API, the language specification, and the virtual machine. But they are important, if Java is to remain efficient and reliable on the multiprocessor systems of tomorrow.

5. Convert file formats to XML.

Related Series XML Basics for Java Developers, Part 5 In this final in a series of XML basics for Java developers book excerpts from Learning Java, 2nd Edition, get an introduction to XSL/XSLT and Web services. XML Basics for Java Developers, Part 4 In part four in a series of XML basics for Java developers book excerpts from Learning Java, 2nd Edition, learn about validating documents. XML Basics for Java Developers, Part 3 In part three in this series of book excerpts on XML basics for Java developers from Learning Java, 2nd Edition, learn about the Document Object Model (DOM). XML Basics for Java Developers, Part 2 In this second part in a several part series on XML for Java developers from Learning Java, 2nd Edition, learn about SAX and the SAX API. XML Basics for Java Developers, Part 1 This is the first in a series of book excerpts on XML for Java developers from Learning Java, 2nd Edition. This excerpt covers XML fundamentals.

The Java community is already using XML for latter-day file formats like Servlet config files and Ant build files. XML is clean, easy to edit, easy to parse, and easy to debug. It is rightly the first choice of most programmers when designing new file formats. Of course, XML wasn't invented until a couple of years after Java was released. Thus, Java has a number of non-XML file formats that should be ported to XML. Among others, these include JAR manifest files, properties files, and serialized objects. All of these can and should be replaced with well-formed XML.

Serializing objects with XML is perhaps the most surprising suggestion, since serialized objects are binary data and XML is text; however, most data inside objects are just text and numbers at the lowest level; and all of this is well-supported by XML. The limited true binary data inside Java objects can easily be Base-64 encoded. Perhaps most surprisingly, the resulting format should be both smaller and faster than today's binary serialization. Numerous developers have already invented custom XML formats for object serialization, and pretty much all of them have proved more efficient than Java's binary format. The fact is, contrary to popular belief, binary formats are not necessarily smaller or faster than the corresponding text formats, and serialized Java objects are a particularly poorly-optimized binary format. Sun has already implemented an XML-based serialization format for JavaBeans in Java 1.4 in the java.beans.XMLEncoder and java.beans.XMLDecoder classes. Now it just needs to go a step further to cover all serializable objects.

4. Ditch the AWT.

Two GUI APIs is one too many. Most Java developers have chosen to standardize their work on Swing. I agree with them. It's time to merge the Component and JComponent classes, the Frame and JFrame classes, the Menu and JMenu classes, and so forth. In some cases, the classes would come from Swing (JPasswordField, JTable). In others, from the AWT (Font, Color, etc.) Still others (Frame, JFrame) would be merged, typically pulling in most of the code from Swing but retaining the more obvious AWT name. Overall, this would be a huge simplification for GUI development in Java and noticeably cut down on Java's bulk.

As long as we're at it, it's time to get rid of the legacies of the Java 1.0 event model. There's no reason for every component to have a series of confusing handleEvent(), mouseDown(), keyDown(), action(), and similar methods. If they're still being used behind the scenes as part of the infrastructure, at least make them non-public; but I suspect they can be eliminated completely without too much effort.

3. Rationalize the collections.

Java's current collections API is a hodgepodge of different designs implemented at different times. Some classes are thread-safe (Hashtable, Vector). Some aren't (LinkedList, HashMap). Some collections return null when a missing element is requested. Others throw an exception. Let's settle on some standard idioms and metaphors, and design all the classes to fit them, rather the other way around. Probably the easiest way to do this would be to eliminate Vector and Hashtable completely. An ArrayList can do anything a Vector can do and a HashMap can replace a Hashtable.

2. Redesign I/O.

Related Reading Java I/O By Elliotte Rusty Harold

The original Java developers were Unix programmers, Windows users, and Mac dilettantes. The I/O APIs they invented were more than a little Unix-centric in both obvious and not-so-obvious ways, and really didn't port very well. For instance, initially they assumed that the file system had a single root. This is true on Unix, but false on Windows and the Mac. Both the new and old I/O APIs still assume that the complete contents of a file can be accessed as a stream (true on Windows and Unix but false on the Mac).

Some of the problems, especially with regard to internationalization, were fixed in Java 1.1, with the introduction of the Reader and Writer classes and their subclasses. Java 1.2 fixed some of the more glaring inadequacies in the file system API. Still more were fixed in Java 1.4 with the new I/O APIs.

The job isn't done yet. For instance, even in Java 1.4 there still isn't a reliable means to copy or move a file -- pretty basic operations, I think you'll agree. To date, attempts to design a better file-system API have foundered on the need to be upwards-compatible with the atrocious Java 1.0 I/O classes. The time has come to reconsider everything in java.io. Some of the more urgently needed changes are:

• The File class needs to represent a real file on the file system rather than a file name. It should provide full access to the file's metadata, support various naming conventions, allow for operations on the file itself, such as copying, moving, and deleting, and in general, recognize that a file is more than just a bucket of bytes.

• The PrintStream class is a disaster. It should be removed. System.out and System.err can be PrintWriters instead. (Sun originally planned to make this change in Java 1.1, but decided it would break too much existing code.)

• The readUTF() and writeUTF() methods in DataInputStream and DataOutputStream don't actually support UTF-8. What they support is 90% real UTF, 10% meat-byproduct. There's nothing actually wrong with the formats they support, except that this causes problems for inexperienced users who use them to read and write UTF-8, and then wonder why their code breaks when exchanging data with conformant software from other languages. These methods should be renamed readString() and writeString().

• The Reader and Writer classes desperately need a getCharacterSet() method that can help determine which characters the writer can safely output.

• Encodings should be identified with IANA-registered names like ISO-8859-1 and UTF-16 instead of Java class names like 8859_1 and UTF16.

• Buffering I/O is one of the most important performance optimizations a program can make. It should be turned on by default. The base InputStream, OutputStream, Reader, and Writer classes should have their own internal buffers, rather than requiring them to be chained to a BufferedInputStream/ BufferedOutputStream/ BufferedReader/ BufferedWriter. Filters can check whether the stream they're chained to is buffered before deciding whether or not to use their own buffers.

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

No single topic is as confusing to new users as the class path. I get almost daily e-mail from novice readers asking me to explain the "Exception in thread 'main' java.lang.NoClassDefFoundError: HelloWorld" error messages they keep seeing. I've been writing Java for seven years and I'm still occasionally baffled by class loader issues. (Pop quiz: When is class A that implements interface B not an instance of interface B? When A and B are loaded by two different class loaders. I lost half a day to that one just last week, and after I mentioned my problem on a mailing list, one talented programmer friend told me he lost two weeks to the exact same bug.)

I'll freely admit that I don't know how the class loader should be fixed. It's clearly one of the trickier areas of Java. I do know that the current system is far too difficult. There has to be a better way.

Summing Up

This top-ten list is just a beginning. There are lots of other areas where Java could be improved, if we allow ourselves to throw off the straitjacket of upwards compatibility: replacing integer constants with type-safe enums, removing confusing and unnecessary classes like StringTokenizer and StreamTokenizer, making Cloneable a true mixin interface or perhaps eliminating it completely, renaming the Math.log() method the Math.ln() method, adding support for true design by contract, eliminating checked exceptions (as Bruce Eckel has advocated), limiting objects to a single thread as in Eiffel, and much more.

We can argue about exactly which changes are necessary, and which ones may cause more harm than good. But one thing's for sure: if Java fails to change, if it refuses to correct its well-known problems, there are other languages waiting in the wings written by some very sharp programmers who have learned from Java's mistakes and are eager for the opportunity to replace Java in the same way Java replaced earlier flawed languages. Java must not be forever handicapped by mistakes made seven years ago in Java 1.0. There comes a point where we need to throw off the chains of backwards compatibility and move boldly into the future.

Elliotte Rusty Harold is a noted writer and programmer, both on and off the Internet. His previous books include "Java Network Programming", Third Edition, "XML in a Nutshell", Third Edition, and "Java I/O", all from O'Reilly.

---

Return to ONJava.com.