Welcome!

The Source for All Things Java

Joe Winchester

Subscribe to Joe Winchester: eMailAlertsEmail Alerts
Get Joe Winchester via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Java JVM Swapping - Safe Practice or Unsafe Risk?

A goal that's almost enshrined in the Java fundamental commandments, as Sun took out an advertising campaign to back it up
By Joe Winchester
Article Rating:
December 24, 2007 11:00 PM EST
Reads:
 17,098

One of the most fundamental design principles of Java is captured in its motto "Write Once, Run Anywhere." It describes how a .class file encodes its instructions at the bytecode level, allowing portability between different machines that, through a specific virtual machine implementation, resolve the bytecodes into executable instructions to give the program life. It's a goal that's almost enshrined in the Java fundamental commandments, as Sun took out a high-profile advertising campaign to back up the "100% Pure Java" slogan and engaged Microsoft in battle for their proprietary language extensions.

Another fundamental design principle of Java is that functionality cannot be removed, so a program compiled to run on one version of a Java Runtime Environment (JRE) is able to run on future versions without re-compilation. The idea behind this is that as users upgrade their machine's JRE, they can be confident that none of their Java software will stop working because an API it relied on was removed.

Published December 24, 2007 – Reads 17,098
Copyright © 2007 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Osvaldo Pinali Doederlein 01/11/08 07:26:24 AM EST

What's your point with this article? I suppose you are advocating that Sun desists of maintaining backwards compatibility, preferring to remove old APIs (or add enhancements that require breaking changes)? If this is your idea, the bad news is that the gain would be exceedingly small. Summing all of the bad, old and ugly APIs that would be good candidates for removal would deliver a very small fraction of the latest JRE's size, and also of other costs like continued development and porting. The only exception would be enhancements that need a HUGE compatibility break, e.g. an alternative generics implementation without any compromises to keep old apps (that need non-generified collections etc) binary-compatible with new JREs. But upgrades like this would amount to a different language and massive porting or rewriting efforts for existing code; if you can cope with that, there are options like Groovy, Scala, JRuby etc.

Reality is that the Java compatibility story is exceptional. I have a couple large Java apps that I wrote by 1997-98, didn't receive any maintenance since ~2000 as the project was discontinued, and every year or two I perform a quick preventive maintenance - check out the code from repository, build it with the latest and greatest JDK and IDE, run a quick test - and everything continues working... the number of compiler warnings (like deprecation) increases slowly, the code looks more horrible compared to modern practices (e.g. hundreds of JSP 1.0 files stuffed with scriptlets and no MVC framework at all)... but it works.

And of course I'm not the only programmer that can code properly, there are zillions of Java apps and libraries out there that run reliably on a large number of JRE versions and OS/HW platforms. Yes, this is more common for free & open source apps, simply because FOSS developers usually care about user choice. If you complain that some app doesn't run on a different JRE, a typical commercial vendor's response may be "it's not certified on that JRE, please use the one we ship with the app". But an open source group will answer by fixing the bug (and yes, 90% of the time it IS an application bug) or provide a workaround. BTW, such bugs are typically caught early in FOSS projects, due to the habit of providing source distributions and letting users do their own compilation - with whatever OS, runtimes and compilers they have installed. So the developers get multiplatform testing for free (which is good, because too many FOSS hackers only use things like Linux and will rather touch fresh cat shit than a proprietary OS).