How Java Got in the Door in the First Place

Before getting into the comparison I should explain why I originally switched. The operative reason was that the .com startup company I was working for wanted to make a cross-platform, web-based document editing system. In other words the user would design a complex document including images using a browser and then be able to generate and download the completed document. After studying this problem I came to the conclusion that the best solution would be to use a combination of Java and the rich text format. A VB/Word combination was unworkable for several different reasons one being that it would not run on non-windows platforms.

Once I started leaning towards Java there were two enormous attractions it held for me:

    - transparency
    - object-oriented
    - the powerful GUI toolkit, Swing

You can almost date my interest in Java to the appearance of Swing. Before Swing Java was a toy for applets as far as I was concerned, but Swing changed all that. Not only could you write a GUI, but you had lower-level control than was possible in VB. I write big client applications like the OPeNDAP Data Connector. Using native tools like MFC takes much more effort than VB to build interfaces so for programs like this you either have to spend millions on a large team or use a rapid development solution like VB. Nevertheless I often found VB's lack of low-level control limiting. For example, VB could not dynamically create controls. If you had a form which had a dynamic number of input boxes you would have to pre-create, say, 50 boxes, hide them and then as they were needed make them visible and move them into position. What a hack! Swing was like a dream--you had high-level convenience with low-level control and ability to dynamically generate controls.

One thing I really liked about Java was transparency. Everything was open: the VM was open, you could download the source code to reference implementation. You could download all the source code to all the libraries. Compared to VB which is completely sealed and opaque this was highly attractive. In many cases internal bugs in VB would cause difficulties, delays and problems. Often VB would work, but you couldn't figure out how it worked for an advanced behavior. None of this has ever been a problem in Java. You just read the source code and see exactly what it does.

Finally Java had a much more sophisticated object-oriented capability that included inheritance. C++ was out for me and my development team because it would have been much more expensive by an order of magnitude to develop in C++. With Java we could develop for the same money as VB but be using a better language.

.NET is Spawned

For the next two years that is how things stood. I happily programmed away in Java while Microsoft fulminated about future plans. They were determined to imitate Java and replace it feature-by-feature if necessary with their own, hopefully superior, product. By 2002 these plans finally resulted in runnable code: .NET had become a reality. No longer would it be Java versus VB. Now it was Java versus C#.

Microsoft also flirted with their Java: J++. This flavor of Java had some nice features such as good native connectivity to Windows which was a real benefit in the days before the JNI specification existed. I took a look but was quickly disillusioned. All of the class libraries and runtimes were locked up in undocumented dlls. It was just like VB--totally proprietary and opaque. Even more disconcerting was the walk I took through the VM. Microsoft kept the source code to the VM secret so I disassembled and examined the binary as I had done years earlier for VB. It was like night and day. Internally Visual Basic's virtual machine is a work of art. It is largely the work of one guy and it is elegant and efficient in the extreme in its design. The J++ VM was a mess. It was obviously written by a large team and the design was byzantine. It gave me a bad omen.

But what about C#? When .NET arrived Java programmers were not impressed because J2EE was already way ahead. I have never been interested in J2EE but for the lack of an alternative it swept the corporate world by storm and Microsoft was for once on the outside looking in. For a shop committed to J2EE C# has no meaning, but objectively is it better?

.NET Does Not Measure Up

Looking back on the last three years my feeling is that .NET has not measured up to the high standard Java has evolved from either the standpoint of an enterprise developer or an applications developer (like me). In enterprise it is obvious that Java is superior. In fact, .NET is not even in the same league as J2EE which can run freely on unix, mainframe systems and super-clustered architectures. Compared to Apache and the servlet model, IIS is weak and flawed to the point of being pathetic. When it first came out IIS was nifty but now it is so outclassed the J2EE guys just sneer at it. A much more interesting comparison is in application development, my field.

For me Java greatly surpasses C#. I freely admit that overall C# is a better language, but that is not really important. For heaven's sake I spent years programming in Visual Basic which has a syntax written for a third grader. If I cared about the language they would have had to lock me up a long time ago. Frankly I don't really like Java, especially its ridiculous exception scheme, its failure to provide labeled jumps, its lack of constants and enumerations, and its tire old C imitations, but for an applications developer the language is not important. It would make no difference if it was Urdu. What is important is the libraries.

In the libary department the heavyweight bout is between Swing and Windows Forms and it's a knockout: Swing wins. Windows Forms is mostly a thinly crafted front-end to the old Windows widgets so not only can you forget cross-platform use, but all the benefits of object-oriented development are missing. For example, Swing uses a strict MVC architecture across the board. All the components use separated data models which can all be extended. All the layout and rendering elements also can be extended and overridden. None of this true for Windows Forms. Also the event model in Windows Forms is much more clumsy which is not surprising given its failure to use an object-oriented design.

Scratching the surface a little deeper the disparity becomes more glaring. For applications developers eventually you will at some time or another have to move out of off-the-shelf widgets and do your own drawing. In my application I do extensive screen drawing and image manipulation. The Windows Forms drawing toolkit is rudimentary compared to the Java 2D API. Java 2D and the advanced imaging API are light years ahead of anything available in Windows. What I do could not even be done in C#. I would have to painfully write non-portable native code that I would have graft onto my C# program were I working in that environment. In Java my drawing and forms GUI live in the same place. In some cases I use hybrid canvases that have both Swing and custom drawn components. Trying to do this in Windows Forms would not be reliable.

Java Community Process Outproduces Even Microsoft

The advantages of the Java libraries over .NET's goes way beyond the Java 2D API. If you look at all the Java APIs for security/cryptography, graphics, data, networking, enterprise, web development and so on they just dwarf Microsoft's offering. Many of the Java APIs have no corresponding Windows functionality. Even more telling is that the source code for all of these APIs can be instantly downloaded for free. If I want to see how a programmer at Sun implemented the RSA algorithm I can download all their code and comments in less than a minute (if I don't already have it on my machine). Good luck trying to find the source code for Microsoft's security implementations.

The advanced technology and multiplicity of the Java libraries is being strongly benefited by the Java community process. Sun actively solicits outsiders to contribute and help development of its libraries. This is enriching the libraries way past anything that any single company, even Microsoft, can provide. Also, the openness of Java has resulted in many companies creating public tools in a way that is sadly unavailable to Microsoft developers. For example, take a look at IBM's Alphaworks. It's a whole world of hundreds and hundreds of high-quality tools that are all Java-based and free. There are at least a dozen different compilers for Java, all free and many with public source code. C# has one compiler and it is not free. The same is true for IDE's, debuggers, the list goes on and on.

Conclusion

If anything I think that in the last three years Java has extended its lead over Microsoft technology. At one time Microsoft was the only game in town (except for Delphi) when it came to rapid development, but Java has changed all that and never looked back. A year or two ago I would have said, "Let's wait and see if Microsoft can come up with something better." Now the clock has run out and Java's superiority is accelerating unbounded. Sun has showed the world a new way of doing business in development software and Microsoft must face the reality that it may never catch up.