|
INTEGRATION WATCH: Write to the OS or the JVM?
By Andrew Binstock
 January 1, 2004 — In a recent visit to Sun Microsystems Inc., I was regaled for an hour by Jonathan Schwartz, the company’s charismatic executive vice president of software. Among the many messages Schwartz emphasized was the press’s need to urge developers to write applications for the Java Virtual Machine, rather than to the operating system—even if that operating system is Sun’s own Solaris.
Writing to an intermediate layer like a VM is a mantra that has been repeated so many times that we all nod reflexively in agreement. Despite that agreement, with the notable exception of programs that require Java app servers, we go right back to coding to the operating system.
This is peculiar, perhaps, because operating-system APIs have hardly been faithful servants to developers. Consider Win32, the hideously sewn-together detritus from Microsoft’s application developers. Or the Unix APIs, which were finally standardized long after Unix was on the wane for lack of code portability between the different variants. The first-line victims of these APIs are indeed developers, who must constantly tweak code when new releases of the operating system appear, and must do a fair bit more than tweak if they ever hope to port a codebase to another platform.
So you’d think that the idea of writing apps for the JVM would be such a clear no-brainer that neither Schwartz nor anyone else would still have to be extolling its virtues. But this is not the case, and the reason is fundamental to the problem: Virtual machines must duplicate so much of the operating system’s functionality that they mimic the problem in a different form.
Let’s go back to the beginning.
Virtual machines long predate Java, of course. Since the 1980s, most major vendors of COBOL compilers have sold a product that generates p-code that must be executed by a virtual machine. The benefit is portability and the drawback is performance.
Because sites running COBOL tend not to have critical performance needs, the virtual machine is an elegant and accepted solution. However, its use never spread beyond this niche, even though those sites have acute needs for integration and portability.
On the other side of the world, pre-ANSI C compilers produced fast code that was aggravatingly nonportable. Getting even simple programs to port from Unix to Lattice or Microsoft compilers was a true chore. There were wide disagreements on what was K&R, what were reasonable extensions and so on. Basically, your code was married to the compiler you first compiled it with. Despite this lock-in, C, as we know, became fabulously popular, and ultimately the language of choice for all serious programming.
These two trends suggest that although writing for the VM might make sense, its sensible aspect does not outweigh developers’ innate preference to be closer to the operating system and to the hardware—even at the cost of portability.
Java manifestly advanced VMs by providing a single, fairly complete VM. COBOL VMs were all different. So, while you could run MicroFocus p-code on numerous platforms, you could not run it on the VM from another vendor. Java broke this model by universalizing the VM. But it soon ran into operating-system-like problems.
First, JVMs also started revving APIs. Code that ran on Java 1.0 didn’t work well on 1.1 or on later releases. APIs were marked for deprecation and codebases had to be updated. The AWT-to-Swing transition was another problem. While this evolution has abated somewhat, it’s still emphatically true that porting Java code is no gimme, although it remains far better than most other solutions.
.NET, Microsoft’s virtual machine, is by no means a preferable alternative, in view of the fact that it’s not strictly portable yet. (The Mono port to Linux should be complete by next year, however.) And already the .NET APIs look a lot like operating-system APIs, and they are as profuse as Java’s. (Microsoft’s documentation of the .NET functions now surpasses 7,000 pages.) At this rate, the problem of revised and deprecated .NET APIs is inevitable.
If you want great speed, great portability and steadiness of APIs, products like Trolltech’s Qt C++ library probably make the most sense. But such products do not have a history of great commercial success (consider Visix, XVT and Zinc Software, for example), because developers are gun-shy about grokking a new API set that masks operating-system functions and is supported by only one vendor.
In addition, the lack of a large user base is understandably a concern, despite the products’ general excellence. As a result of finding no great advantage in VMs or in other solutions, programmers instinctively gravitate back to operating-system APIs, where they feel safe, even if eternally tormented. Sun’s Schwartz and soon Microsoft will be singing the same tune to audiences who nod affirmatively, then ignore the message.
Andrew Binstock is the principal analyst at Pacific Data Works LLC
|
|
Advertisement
Click here for a complete listing of Integration Watch Columns
Click here to see a complete Column Archive. |
Back to Top
|