Digital Edition

SYS-CON.TV
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

Ten years on from Java's inception, however, I question whether both of these goals are still relevant in theory or practice.

A large amount of the Java code that I can think of was built against a specific JRE level that was then shipped with the product. This makes sense in a commercial environment where you need to diligently test the product against a set of scenarios and then provide some kind of guarantee to users that the software will execute on their machine with the same resilience as it did in the system test environment. This kind of assurance is best underwritten by shipping the same version of the JRE that the product was built and tested against. When it comes to different operating systems and platforms, you typically find different download packages and separate builds, so at some part of the process the "write once, ship everywhere" commandment almost always gets broken.

On one level it seems a shame when you have to bundle a JRE with a product to ensure it's going to work in the field, but it's a practice that's common among those who are allowed to do so. Doing so increases one's footprint, making installation more complex as well as possibly precipitating a specific license agreement, depending on the kind of product being created. However, you only have to look at the number of Java products that include their own /jre/ directory to see that this is a widespread practice. In the products I've worked on where we include a JRE, the development team always get criticism from users who try to hack around the /jre/ directory and attempt, usually unsuccessfully, to perform their own upgrade. Telling said irate users to wait for the product version that contains an officially upgraded and tested JRE frustrates them; however, it's easier than dealing with people who can't get the original product to work at all because the system JRE is at the wrong level and requires upgrading.

There is no malice or conspiracy theory involved with shipping and not allowing replacement of a product's JRE. It simply is a way of underwriting the finished product as being a complete solution. I recently had to work on version 2.0 of a product whose version 1.0 manual told the user to download about 40M of open source from a number of possible sources, then another 20M of JRE, before unzipping the 2M product onto the directory structure in the correct place. For version 2.0 as well as working on the release's functional line items, we changed it to include every piece of runtime stack it needed to sit on top of the operating system. Our users were ecstatic that they no longer had to sticky tape the solution together by themselves.

A friend of my brother's recently asked me to fix a copy of their very slick, Java-based peer-to-peer file-sharing software. The fix involved downloading a back level of the JRE that, ironically, their support forums insisted had to come from a specific JRE vendor before the product would even bring up the splash page. All of this incompatibility and futzing around with "Get Java Now" icons doesn't help to promote the image of Java in the users' minds; rather it poisons their experience and reinforces their perception that Java is something complex that causes install and upgrade headaches. Likewise I've never been a fan of "Java" splash screens on my phone - ironic given I'm a huge fan and proponent of all things Java, but I, like the desktop user who has to struggle and upgrade/downgrade/hardcode the JRE version, want my computer to do the job that I ask it to do without a commercial break from my spark plug vendor as I attempt to negotiate rush hour traffic.

About 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.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

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).




ADS BY GOOGLE
Subscribe to the World's Most Powerful Newsletters

ADS BY GOOGLE

We are seeing a major migration of enterprises applications to the cloud. As cloud and business use ...
SYS-CON Events announced today that Silicon India has been named “Media Sponsor” of SYS-CON's 21st I...
DXWorldEXPO LLC announced today that "IoT Now" was named media sponsor of CloudEXPO | DXWorldEXPO 20...
In this presentation, you will learn first hand what works and what doesn't while architecting and d...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22n...
Everyone wants the rainbow - reduced IT costs, scalability, continuity, flexibility, manageability, ...
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT...
SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 1...
DXWorldEXPO LLC announced today that All in Mobile, a mobile app development company from Poland, wi...
Most DevOps journeys involve several phases of maturity. Research shows that the inflection point wh...
Andi Mann, Chief Technology Advocate at Splunk, is an accomplished digital business executive with e...
DXWorldEXPO LLC announced today that ICOHOLDER named "Media Sponsor" of Miami Blockchain Event by Fi...
Today, we have more data to manage than ever. We also have better algorithms that help us access our...
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held Novemb...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: D...
DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, ...
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22...
SYS-CON Events announced today that IoT Global Network has been named “Media Sponsor” of SYS-CON's @...
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018,...
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news an...