03 February 2015

Write once, run anywhere: or, how to ruin a great idea

This is another one of those ideas in technology that sounds absolutely wonderful until you read the fine print.  The concept of "write once, run anywhere" was put forth by Sun (albeit with slightly different wording) in the late paleolithic, i.e. January of 1990, to coincide with the first public release of Java.

In theory, an application could be coded once, compiled into a platform-neutral executable form, then distributed as a bundle.  The "pre-compiling" of the application would also allegedly give significant performance improvements over an interpreted solution.  Here's where Java went horribly, miserably, and disastrously wrong, though- the language and compiled byte-code were platform-neutral, but the virtual machines in which they would eventually be run were decidedly not platform-neutral.

There are dozens of different Java virtual machines out there, from the stock Sun (now Oracle) "J2SE," enterprise "J2EE," and embedded "J2ME" to IBM's in-house Java VM used by applications like the Lotus suite, to OpenJDK which is part Sun / Oracle work and part clean-room reverse engineering.  Then, of course, there's the non-Java VM for which one writes in Java: Dalvik (the main runtime environment on Android devices until 5.0 'Lollipop').  Predictably, each of these supports a slightly (or drastically) different feature set in byte-compiled programs, to say nothing of differences between versions of the same VM.

At this point, you're probably asking yourself, "hey, why does Guy hate Java?"  The answer is straightforward- I don't.  The language itself has quite a bit to recommend it.  The language solution, however, is practically a perfect parable of how not to deploy a suite of application development tools.

So what's the alternative?  For client / server or distributed applications, develop a good cross-platform standardized, interpreted API for the client-side part, and leave the compiled code server-side.  For purely client-side applications, write them in an interpreted language (try Python).

JavaScript and HTML 5 are far from perfect, but they're at least heading in the right direction.  Implementation incompatibilities between browsers are shrinking weekly, and the HTML 5 ecosystem is moving towards a reasonably harmonious and tolerable state.  Yeah, you still have to account for IE vs. Firefox vs. Safari vs. Chrome in your code, but the differences are becoming fewer in number.  That's progress!  Our favorite WORA suite, in contrast, sinks farther into oblivion with each new release.  It's in such bad shape, in fact, that recent versions include a mechanism to automagically launch obsolete VM versions for specific sites (think IE compatibility mode for Java).  It uses deployment rulesets to establish URL <-> VM pairs for the Java browser plugin to reference.

In summary: if you're primarily a Java developer, don't go anywhere.  We do need and will continue to need you for years to come as we sort out this mess.  If you're in that category, however, and you're less than 50 years old, make sure to learn another language as well.  I hear that Fortran has a good market...

No comments:

Post a Comment

Your comments are welcome. Please keep them professional, courteous, and respectful of the blog author and of other commentors.