Java’s popularity is a function of market position, the perception of one product compared to its competitors. When it first came out, Java was positioned against C++, to which it compares favorably. Yes, I miss operator overloading and a handful of other items, but these are outweighed by the fact that Java prevents entire classes of errors made by C++ developers. All of this was done before, but Sun was able to make it mainstream and practicable.
Now the Java vs. C++ battle is effectively over. Today Java’s market position is measured against a variety of languages, most frequently C#, Python, and Ruby. For many of us, Java compares much less favorably to these than to C++. Proponents of these languages love to show problems solved in a handful of lines, with a Java-based solution including dozens of lines of boilerplate code. The poor Java developer is then pushed around and has his lunch money stolen.
Naturally, much of the Java community wants to do something about this. So closures and type inference have been proposed for Java 7, and the debate in the Java community begins. Some say “Hooray, Python programmers will stop making fun of me!” Others object “Don’t we already have enough constructs to worry about in this language?” Throw in the glacier-like JCP, and we have no idea what the next release of Java will look like.
Can we fix Java?
I am sympathetic to both arguments. The language is getting big. If only we could get rid of artifacts like primitive types and arrays, we could remove clutter and make conceptual room for more advanced concepts. Even so, I still land firmly in the pro-closure camp. This is partially for selfish reasons; I got hooked on them while hacking in functional languages at night, and want to use them in my day job. My company uses Java because it is actually the right choice for us. No other platform offers that combination of portability, reliability, tooling, and performance. Too bad it’s not with a better language.
With this in mind, the rumblings of the last few years make sense, and the future is clear. It’s not about Java at all, it’s about the JVM. And Sun is positioning the JVM to become a light, efficient virtual machine available everywhere. Consider everything that has happened:
- JavaFX has been announced, creating a simple, declarative model to compete with the likes of Flex.
- Sun has committed to releasing an update to Java 6 that will shrink the minimal JRE download to two megabytes.
- Sun hired Charles Nutter to make JRuby a first-class language for the JVM. The 1.0 release nears.
- Glassifish – the open-source application server sponsored by Sun – will run JRuby applications directly in v3, and be pluggable for new hosts. Java SE and EE need never enter the picture.
- The JVM is now available under the GPL, which should increase availability on Linux.
- The 2007 JavaOne conference included a Scala session for the first time
But what about the mean time?
The reality is Java-the-language will be around for some time to come, at least until a clear successor is established. Sun and other members of the JCP have an opportunity to define the language’s legacy. As Guy Steele famously said, Java “managed to drag a lot of them [C++ programmers] about halfway to Lisp.” Now Java can drag programmers one step closer to Lisp, and set the stage for the next generation of languages.
Of course, I’m referring to closures. Users of functional languages will attest how working with such constructs changes how you think. By adding closures to Java, we do more than provide a powerful tool for those of us already familiar with the construct. We introduce a large community to a better way of solving many problems. We’ll see if it sticks, but I can’t think of a better way to spread a thought model many believe to be superior.
Update: I actually don’t think Java sucks. It meets the early goal as a straightforward replacement for C++ very well. I do believe we can create a language that is better than Java based on what we’ve learned over the last decade.