Java, the Coffee Cult

<rant>
The Wictionary defines “cult” as “1. A group or doctrine with religious or philosophical identity viewed as a sect, often existent on the margins of society.”

I have had occasion in the past month to learn Java by the full-immersion method. While there are many ideas and practices embodied in the language and its tools that I admire, I have skeptical of the more extreme claims made for the language. After a month, I am convinced that the Java user community is, in effect, a cult.

Who am I to have an opinion?

I have been working professionally in embedded systems design and implementation for over twenty years. For much of that time, I have found that C remains my language of choice when faced with manipulating bits in the registers of actual hardware devices. Naturally, you can’t escape from the native assembly language of the system’s CPU for some aspects of device drivers, interrupt handlers, and thread scheduling; but for just about everything else, C serves well. When building tools for general use, I have generally reached for C as well, but C++ and Perl are gaining ground.

The customer, however, wants this project to include a substantial chunk of user interface built in Java, with a thin layer (device drivers and low-level routines at most) built in C.

Recent versions of Java are showing signs of becoming a usable language. Version 5 of the Java API introduces a limited kind of template and a first-class enumeration type. But since version 1.0 more than a decade ago we have been hearing claims about Java revolutionizing the world. What happened?

It’s a cult.

One hallmark of a cult is the sweeping claim of a new order and revolutionary changes. Another is isolation of its members from their pasts. The Java Way teaches that Java is the only way. “Write once, run everywhere” they loudly trumpet. But many core technologies sacrifice compatibility with any particular platform on the altar of broad portability. Many of the tutorials at java.sun.com are proud of the fact that Java is not particularly good at playing with others.

If they really wanted to reach a world-changing number of programmers they could open up the JVM to the point where compilers targeting Java bytecode could be written for other languages. Perhaps a few tweaks or minor new features would make it easier to write C++ code that runs in the same JVM and interacts with Java classes. Perhaps someone would even release compilers for FORTRAN, COBOL and BASIC, not to mention Ada, APL, Eiffle, Forth, Haskell, Lisp, Logo, Modula 2, Pascal, Prolog, Scheme, and Smalltalk…

Oh wait, Microsoft actually did just that already. Their oddly named .NET platform is based on a just-in-time compiled virtual machine that has open source implementations available in addition to the “official” release from MS. The open-source implementations run on a variety of platforms (at minimum on Linux and other Unix-like places). MS is responsible for a slew of languages built on it, and I counted a dozen or more research groups using the platform for niche research language projects, while the commercial language vendors are happily eking new life out of APL, COBOL, and FORTRAN on the platform.

But Sun didn’t want to play along, and packed their sandbox up and took it home.

Both platforms weigh in at a hefty 150MB or more for just the platform installation. Both can be installed free for the download time and bandwidth. The Java compilers and development tools are largely also free, and many are open source, while the .NET tools (at least the “official” ones) are all commercial products.

Up to now, I have avoided building utilities and tools in either platform. If I wanted to release a tool internally, it has seemed more productive to require the modest impact of a recent Perl installation which actually is quite portable even back to Windows 9x versions. For products delivered to end users (who in my companies experience are usually running on Windows) rather than among a development team I have generally preferred to build true Windows applications out of C++ and MFC.

To be fair (why, I’m ranting here… oh never mind) a lot of work in Java Swing was devoted to efforts to make its user interface components work well on lots of platforms while making it possible to mimic the look and feel of many of them. That was the result of a lot of hard work by some enormously clever people, and on the two platforms I have personal experience with, it works reasonably well.

Garbage collection has been a feature of Java since before version 1 was released, and it certainly does have benefits by allowing the programmer to stop worrying about memory allocation. But memory is not the only resource that needs an allocation strategy, and because I have yet to fully grok the Java way of handling non-memory resources I won’t try to use my lack of knowledge of a best practice as evidence that there is or isn’t one.

However, users I have talked to over the years rarely, if ever, change platforms. To an end user the idea that the same program (no, the very same binary file) can be executed on more than one platform simply has no value. If that user perceives that performance or usability has been sacrificed, then he may seek another product entirely.

Java is a Coffee Cult.
</rant>