One of the subjects that keeps coming up in Bruce Tate’s Beyond Java is the parts of the Java platform that aren’t the Java language. In particular, the JVM. Is it still interesting, or will the JVM become like the mainframe: not going away, but old-fashioned and out of sight?
Tate considers a future in which applications move away from the Java language but go on using the JVM via things like Jython, JRuby, and Rhino. Clearly, this is quite feasible technically; but will it happen?
Why? · There are lot of reasons to expect the JVM to remain near the center of the computing stage. Here are the first three: Installed base, installed base, and installed base.
Which is to say, there are billions of lines of Java code in production today in a huge number of strategic, business-critical, 24/7 applications. A lot of software development—a majority, probably—isn’t new applications but extending and maintaining the existing repertoire. So that work totally has to run on the JVM.
And even the new apps are going to have to interoperate with what’s here now; some of this will presumably be done at-a-distance via Web Services, but there are going to be a lot of cases where it’s going to be a big advantage just to call into the APIs and object models of the existing apps. Which is trivial if you’re running on the same JVM.
Once you get past the installed-base arguments, there are some good technical reasons to run code on the JVM. To start with, a modern JVM is really really fast—competing successfully with compiled C/C++ code. And all over the world, big companies like Sun and IBM and BEA employ fanatically-intense teams of the world’s best programmers who are working on making it faster.
Secondly, the JVM has probably the world’s most advanced and hardened threading API. As regular visitors here know, threading (A.K.A. CMT and TLP) is very, very important.
So given that all the modern beyond-Java alternatives run on VMs of one kind or another, what’s next? Will we go on having one custom VM per language, or will there be a decoupling, with a bunch of different languages running on a small number of VMs? You could make a case on pure engineering grounds for such a decoupling being good design. The leading candidates would the JVM, the Microsoft CLR, and maybe Parrot, if it ever ships.
But Maybe Not · I remember, early in my career, sometime in the mid-Eighties, the first time I was at a real IT-strategy meeting with actual Vice Presidents and CIOs and so on. This was the period when the IT organization was trying to figure out this new “Personal Computer” thing and individual managers were going out and buying them anyhow, IT be damned, because they were useful. At this meeting, the CIO emphasized, to general management agreement, that the crucial thing we had to focus on was the “micro-to-mainframe link” because the only way to to get real business value out of PCs was to integrate them with the real IT infrastructure, which of course was on the mainframe.
Well, we kind of got micro-to-mainframe linkage, but that didn’t make mainframes interesting, and it didn’t make them any more attractive as a place to develop new applications.
So in the Beyond-Java world, is the JVM something that sits in the back room and is run by fusty bureaucratic old guys who grumble about how the kids Don’t Get Real Computing, and is routed around by people who want to Just Get Stuff Done? Or does it join the RDBMS and the web-server as a totally-essential pieces of central infrastructure where cool new stuff shows up all the time?
I think the latter outcome is more likely; but I also think that those who care about Java, for emotional or business reasons, should get to work on encouraging it.
