Brad Cox (I think the same guy who invented Objective C) has released a Java preprocessor called Java+.
Java+ is an open source Java preprocessor (download) that adds these features to any Java compiler:
- Multi-line strings with executable inclusions like Perl and Ruby
- Optionally segregates Java+ strings into ResourceBundle files
- Eliminates the need for JSP or ASP and their need for Java compilers on deployment servers (a security concern)
- Optionally processes only inputs whose outputs are out of date
- Extremely fast. Astonishingly so.
- Adds no overhead, in either space or time
- Graphical and command-line interfaces
- Simple, general, recursive string syntax
- Free software, BSD open source license
- Comprehensive built-in documentation
An article on IBM DeveloperWorks on 5 myths about Java programming:
Myth 1: Garbage collection solves all memory-related problems
Myth 2: Parameters are passed by reference
Myth 3: Atomic operations are thread safe
Myth 4: Synchronized code is the same as a critical section
Myth 5: Waiting threads are awakened in priority order
There was a bit of a surprise for me in this article: Threads can keep their own copies of object variables. So you can assign a value to a variable in one thread and even though that line has executed that doesn't mean another thread reading the same variable will see it. But that isn't so unexpected Certainly with regular code optimizations with registers to hold variables one would expect this sort of thing to happen. It is hard to tell from the article whether Java takes this further than what one would expect to see in just compiled C that did the same thing.
See the discussion in this Javalobby thread of Wee Jin Goh's recent repeat of the C vs Java benchmark that Chris Rijk published over 2 years ago in this Ace's Hardware article. The latest results show the server version of the Sun JVM 1.4.1_01 on a Windows box doing as well as and even better than C compiled with GCC 3.2 to do the same algorithms. You can find a PDF version of Wee Jin Goh's results here. Another interesting point about the results is the big difference between the client and server versions of the Sun JVM. It would also be interesting to see how the IBM JVM compares on the same hardware. Also, keep in mind that GCC 3.2 is probably producing less optimized code than the latest Intel C compiler produces.
The high end Java server vendors do not appreciate the importance of the low end of the market. Microsoft had built its empire by launching its attacks on the top end using products it first has sold into the mass volume low end. The jBoss founding developer Marc Fluery sees the same pattern with MS .NET:
On the contrary, I would argue that Open Source and JBoss in particular are already Sun's best defense against Microsoft .NET. Only Open Source has proven uniquely resilient to a Microsoft onslaught. In the same way that Linux has prevented MS NT from dominating the server operating system, JBoss will prevent .NET from making serious inroads into the application server tier, the crucial gateway to enterprise software applications.
The other players in the J2EE market cannot offer Sun much support against .NET. Last time I talked to Scott Dietzen, CTO of proprietary J2EE market leader BEA Systems, he claimed that they don't see .NET in the marketplace. Not surprising that .NET lacks visibility in the very pricey end of the enterprise market. At JBoss, we see it plenty. Not only do we see .NET coming into the market, we are good at defending the J2EE turf against it.
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.
Given Sun's position selling their own OS and processor design in a market where higher volume lower cost competitors are coming up from the lower end market I wonder whether Sun can stay sufficiently financially viable to continue be the main developer of Java. Here's an article on their financial performance:
Merrill Lynch analyst Steven Milunovich said Sun may cut up to 8,000 jobs this quarter - Sun is due to announce its third-quarter results this Thursday. Milunovich joins Sanford C Bernstein analyst Toni Sacconaghi who is reported to have predicted cuts of between 4,000 to 8,000.
Anyone know whether Sun is laying off any of its Java developers?
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.