My Second Rant on Sun and Java

What's the biggest problem with Java? Sun is in control of its development. Sun has been too slow in improving AWT, Swing, the File classes, the network classes (TCP/IP related mostly but other protocol support as well), and for an assortment of other categories. Some of these API categories are improving. But the changes have taken years longer than they should have. Sun has been too slow about getting around to implementing shared pre-compiled classess across processes too. Java should be improved not just for long-running server processes but also for fat clients and command line utilities. Java should become a better all-around language.

Here are some improvements I'd like to see made to Java. You can also read my previous Java rant.

One of the most important bugs on the Sun Java Bug Parade is "multiple JVM runtimes do not share memory between themselves". This limitation creates a number of problems when running multiple Java processes:

• Each library has to be compiled for each process that starts up. So process start-up is slower.
• Each JIT compiled output goes into a separate in-memory copy and hence more total memory is used.
• Processor cache hits are reduced. Multiple processes that could share the same code don't and so what one process causes to be loaded into CPU cache doesn't get reused when the OS switches control to a different process.

In theory the common libraries could all be precompiled just once and kept in a cache and loaded the first time they are requested. All later processes could make use of the already loaded libraries. This would speed up development, reduce memory needs in some server configurations, and make it more feasible to use Java to write fat client applications. Multiple client apps running on the same machine could share a common compiled in-memory copy of Swing and other core APIs.

Some people respond to this kind of proposal by arguing that DLLs are evil. I'm not arguing exactly for DLLs. I am really arguing for sharing the same set of classes across processes when the processes specify the same sources for those classes. Obviously, if different processes are using the same JVM version then they are going to use the same JVM core classes anyway. This wouldn't have to require the use of DLLs. There could be a master process (which could come as part of the JRE/JDK) that all processes go to for particular jar files and that master process compiles and loads them into memory and JIT compiles them when the first process asks and then the other processes can just map them in. But one could have a way to make a Java process to start up and load its own stuff. One could even make the default be that each process loads from its own classpath from its local environment. But add a command line flag that says "Go ask the central dispatcher to map in the core libraries I need".

Doing that would save memory, increase performance (by increasing cache hits when switching between processes) and speed development. If you have JBuilder or Forte or Eclipse running you could have the IDE tell the main Java process manager to load classes it uses and classes that the target processes use. Then each time you start up a debug session the process could load faster since the standard libs would not have to JIT recompile every time the target process started. You'd only have to reload and re-JIT compile the stuff in your own actively changing classes.

This approach could be extended to include having preloaded copies of non-Sun classes for any libaries that are rarely changing.

Swing: there are people out there writing Java GUI apps. I have no idea how many. But the comp.lang.java.gui Usenet group seems to have quite a few posters in it. There'd be a lot more if Java was easier to write GUI apps in and if Java had richer libraries and if Java apps weren't such big pigs.

Of course, it would take more than shared memory between fat client apps to make Swing more tenable as a library for writing serious client apps. Swing would have to become much richer. The fact that Sun after all this time has expanded Swing's API set so slowly does not bode well for that to happen. Sun is the bottleneck and with Sun's financial problems that is not likely to get any better. What is needed is for Sun to allow the open source community to take over control of development of more API categories of Java. Java needs to be opened up.

AWT, Swing, and SWT: On one hand AWT is faster but it has too few controls and too simple a set of features on the controls it does have. The biggest limitation with AWT is that it was designed to use a lowest common denominatior of underlying native OS controls. On the other hand Swing has more and fancier controls. However, Swing is bigger and slower and still has plenty of bugs. Plus, its controls are still too limited in both number and power as compared to what Win32 has to offer.

Are developers happy with AWT? Well no, not exactly. They want Sun to keep improving AWT. As you can see from that request for enhancement people have lots of complaints about Swing too and that is why many developers come back asking for more AWT improvements.

How fast does Sun fix Swing and AWT bugs? Well, here'sa popular bug that is over 4 years old. They don't all take that long. But some important ones do.

A lot of developers like the Java langauge and think that if only Swing didn't have as many bugs and if only it was smaller, faster, and more feature rich then they could write more client apps in Java. But the years go by and progress on Swing's problems continues to be a case of too little too late.

Then there is the SWT which IBM developed because they wanted speed and size that were more like AWT but IBM gave SWT all sorts of advantages that Sun has been unwilling to give to AWT. On the bright side SWT is open source. But SWT is not available on all OSs, its faster on Windows than in other implementations, and it does not ship with the core JRE or JDK. Plus, since it relies on native controls it is not as likely to be consistent across OS platforms. Plus, since it was originally developed for Win32 to achieve the same functional set on some other platforms may require a greater quantity of coding by the SWT porters.

I compare Basic to Java because I've done a lot in both languages (and in C++ as well and there the standard libraries are much worse than in Java). Using Basic shows me just how handy it is to be able to rely on a very large and well tested set of calls for doing an assortment of things that I do alot. I process a lot of data that has dates and I have to compare dates and calculate durations in days, months, and years. Well, Basic makes it easier to do this than Java does.

I've written a lot of Basic code and ported a fair amount of it to Java. In order to do the porting I had to write functions in Java that did the equivalent of Basic functions that Microsoft has had in Basic for literally at least a decade. For example, as I mentioned in my previous Java rant, date classes in Java lack some capabilities that are commonly used and already available in Basic. But I've also had to write substring matching functions and other functions that I think should already be built into Java. What is needed is a systematic sweep thru the MS Basic library calls to identify all the calls and operations that Basic has that Java lacks equivalents for. Java equivalents then should be written.

My point here is that these functions are not that hard to write and so Java ought to have them. Java has been around for so many years and since one of the major ideas behind it is to avoid having to use platform specific stuff. Well, that makes big standard libraries all the more important. I think Sun lacks sufficient numbers of people working on Java and that is why they are the bottleneck. Plus, they show signs of having a Unix "Real men write their own libraries" mindset which doesn't help.

Developers are unhappy with the class loader. The jBoss people could probably write a good spec on how the class loader ought to work.

The biggest problem with Java for doing math is that it tries so hard to prevent illegal array and pointer use that the checking overhead makes it run slower for many types of math problems. IBM has proposed a multi-dimensional array class for Java in part to make it easier for JVMs to reduce the amount of required array bounds checking that is required. The current Java model of multi-dimensional arrays is really done by array of arrays and so the existing approach also costs more in other ways. There is less locality of access (a series of memory allocation calls go into allocating all the pieces) and more overhead to allocate the arrays since each extra dimension has to be traversed to do a series of new calls to fill in its array pointers.

Name Java processes any name you want to give them. A java.exe command line option to allow you to specify what name the OS will give to a process. Seeing a bunch of processes in the OS process list that are all named java.exe isn't exactly helpful.

Have a way to define Java command line names. Starting Java programs requires that one start the Java process with the class name and potentially other options such as classpath info. It would be nice if there was some way to have a registry where you can define OS-independent aliases for Java program names that have the command line options and even which Java version to use to start each Java class entry point. The Java class shared memory manager (mentioned above) should be what knows about common Java program names. It could keep precompiled Java exes in its cache. Then Java command line utilities could be very fast starting and still share memory for core libraries with other Java processes.

The Sun Community Process needs to come out from under the control of Sun. At least some classes of libraries should be developed totally outside of Sun's control. Sun just doesn't have enough people moving at a fast enough speed to develop all the libraries that Java needs. Enough years have gone by without various deficiencies being addressed that its clear at this point that Sun is too slow on too many parts of Java. Sun's worsening financial condition makes a loosening of their hands on the Java reins even more important.

Sun ought to let compiler makers generate native exes that don't require the exes be distributed with any core Java jar files in order to run. Let Java act more like a normal language.

My view of the library issues is that IBM could lend its support to an effort to organize some meetings of the people like Mr. Harold who care about such things. IBM could start up its own parallel community process to hammer out complete standards with the open source community to develop libraries that would be presented to Sun for inclusion in JREs and JDKs. If Sun won't play ball then other JRE and JDK distributors should just include these libraries in their downloads.

Is this insurrection? Yeah, pretty much. The JDOM libraries were developed outside of Sun's control and the result has been most beneficial. JDOM could serve as a model for how various basic library categories could be developed outside of Sun's control. Collections would be a great next area to tackle in this same manner. They don't require access to underlying OS APIs and therefore a new set of collection libraries could be developed independent of Sun. Of course there are areas where Sun's cooperation is necessary because in order to do the improvements one does have to either change the JVM or make native OS calls. Still, many types of API development could be done without Sun's cooperation.

Its time to identify areas that can be improved without any cooperating from Sun. Then the classes and be developed and made available to everyone. Eventually Sun may agree to make them part of the core but with continued open source licensing for those libs that are developed outside of Sun's control. This is what is needed. Break free of Sun and let a lot more people get involved in improving the core libraries.

Posted by Randall Parker at November 04, 2002 02:14 PM