There’s been big buzz in the IT world — for what feels like years now, about the demise and deprecation of using and managing Java with enterprise applications. Java has become synonymous with antiquated web technology, security breaches, and limited (if any) support. And if you rely on it, well, you fear the IT world says “shame on you”.
In talking with IT professionals every day at both large and small companies, I find they are consistently surprised about the realities around Java versus the hyped messaging and headlines. I’ve outlined a few of the biggest misconceptions about Java here in an effort to clear the air and lower your blood pressure.
1. Java is dead and no one is developing for it (and you shouldn’t either).
Much like Mark Twain’s famous quip “Reports of my death have been greatly exaggerated” so has the health and future of Java. Most enterprises have already invested heavily with a breadth and depth of applications written in Java and their development teams are steeped in Java. They have a rich, extensive knowledge of the applications and platform design. Those are sunk costs, but these Java-based applications are still very valuable resources. While you could rip out those applications and replace them with more modern architecture, you’d lose valuable intellectual property in the process, spending budget you don’t have – which could be better spent elsewhere. It’s simply not realistic or practical. These Java-based applications can be retired over time, based on business needs to innovate and add functionality.
It may be more accurate to say that many new, modern web applications aren’t developed in Java. But the vast majority of IT teams continue to enhance feature sets with Java-based applications and extend the functionality of these existing applications – many of which are mission critical to the business.
2. Java can’t be secured and therefore is a huge liability.
One of the biggest concerns with Java is that it has many vulnerabilities that can be exploited. It’s got a reputation as the least secure software out there, with people frequently pointing to the sheer number of updates and bulletins from last year alone (was it 70+?). Certainly that doesn’t instill confidence that the current version you’re using is fully secure.
You can auto update your applications with the latest Java version from Oracle, but most enterprises turn that capability off quickly. While updates will address known security vulnerabilities, they will often break other functionality and that could actually end up being much worse. It gets out of control so fast. Many enterprises are running 10-20 different versions of Java; one healthcare organization I met with recently is running over 50 versions because of vendor support or integration requirements. Clearly, organizations resign themselves to run old version on their systems regardless of the vulnerabilities.
“They” say the only way to be absolutely secure is to free yourself of Java entirely. What are your alternatives? Rather than ripping Java out and starting from scratch, there are solutions that “containerize” specific Java versions so they’re only exposed to select applications. You can set Java up to load secure sources and work off in the corner – to be used safely when needed.
3. Running multiple versions of Java in the browser requires virtualization.
Browsers were originally designed to provide feature extensibility as a way to provide support for languages and solutions like Java that weren’t part of the HTML and CSS specifications. This design approach didn’t really consider the need to provide version control mechanisms for loading the 3rd party platform components, limiting the browser to only load the latest components of a given control. This is in stark contrast to the environmental control designs enabled in Windows which have long allowed for multiple runtime environments to be loaded simultaneously side by side.
To overcome this design limitation, many organizations turn to virtualization as a way to deliver packaged browser applications. While Microsoft raises issues on the legal issues surrounding this approach, some organizations are willing to risk legal action or losing product support. For them, the benefits of virtualization – the ability to isolate anything into a discrete image and insulate it from everything else so it works the way you want it – outweighs the compliance risks. But the issues aren’t just contractual; In addition to the legal questions, virtualization often requires the technical equivalent of ‘harvesting the ocean’, including more components, software and 3rd party utilities than absolutely required to ensure any library is available for reference at any time. That includes insecure applications getting access too. Culling down the images to bare bones is possible, but requires extensive time and testing. The clear downside of virtualization is in the costs associated with packaging, support and management issues at scale. A customer once compared virtualization of Java to cracking a walnut with a sledgehammer – it does the job but the waste is great.
What customers really want is the ability to ‘natively’ isolate Java in the browser and find a way to run what they need, where they need, when they need. Trust me – or better yet trust our 100+ customers – that you can isolate Java effectively on a tab by tab basis inside the ‘native’ IE browser, without compromising security and reducing the support burden.
Remember the days of Win32/executable applications that were designed to run on top of the operating system? Heavy client Java apps could rely on environment controls and library load behaviors to ensure a targeted Java version was loaded for a given application. You could install the Java version it needed and it would load it without impacting anything else on the system. Now that apps are running in the browser, that scenario gets a bit more complicated. The entire paradigm is different and it’s not as clearly defined. While you’ve taken away the complexity of managing the desktop, you’ve gained complexity in managing the browser. It’s a trade-off.
Most believe that when you install the latest Java version, it automatically overrides the existing (older version). Not necessarily. When you statically install a new version, it can intentionally leave the older version behind. You may want to do this so the older version can be available to continue to execute specific actions in the application. But now you’ve opened yourself to complications again.
It’s not for the the faint of heart – managing web-based Java resources on your own requires manual configuration, packaging via an SDK and working with certificates. However, there is a browser management solution on the market that makes this entire process dead-easy. (I’m not mentioning any product here, but I think you know who I mean.)
4. Oracle is killing Java, what other sign do you need to see that it’s dead? (see #1)
A few months back Oracle made an announcement about the plans for Java 9. One of their focus areas is around browser based Java applications, and their message was greatly misinterpreted to mean Oracle was dropping the whole platform, not just the browser plug-in. Sort of. Oracle is shifting away from the traditional browser plug in where applets are loaded IN the browser to an approach where Java applets are launched FROM the browser.
Customers will need to make changes to how apps are launched, and in many cases will need to adjust the applets and code itself. From the browser side, Chrome has already begun the process to disable the Java plugin prior to Java 9, and other browser vendors are expected to let support die out when Java 8 is no longer supported.
My read on this change is that Oracle decided the browser plug-in was the source of too many security black eyes and threw in the towel. They thought if they cut off the attack vector, they could stop the attacks. So now it’s gone in Chrome, and I fully expect Microsoft to end IE support before too long. Microsoft has been clear that Edge will never have Java plugin support.
Java as a platform is here to stay for a long, long time – and there are options to gain the security and compatibility you need, without the plug-in.
5. Paying for Oracle support will prevent compatibility issues with upgrades.
I’ve heard about this one a lot in recent months. Enterprises know the road forward is intricate, and no one wants to be the person who didn’t buy support when things break, so many opt to purchase additional support for the patches and updates from Oracle. But instead of getting an actual fix for your problem, you’ll probably only get frustrated (and a hefty invoice).
While you may get someone to pick up the phone, the bar to fix an issue you’ve discovered is astronomically high. You have better chances buying a Powerball ticket. What you’re really buying is a bigger list of download links to self-serve your issue. It’s not personalized support that fixes these issues – especially with older version of Java. You’ll be told to upgrade, but then you already knew that, right?
6. Using proprietary technology like Java will always be more limited than standards.
When HTML5 first came on the market, it was heralded as the best thing ever for developing apps — it was standards based, and way less confining than a proprietary tool like Java. Well, we know how long that lasted. In the short time HTML5 has been a standard, some features have been removed or revamped. So the lesson here is that open standards or proprietary technology, you can still get it wrong.
Feel better? I can tell you confidently – You’re not the only person on the planet still using Java. Not even close. Every organization has technical debt. It’s part of the digital economy and will always be an issue we need to handle. Java’s technical debt may be more expensive than other types given the security and support questions, but it’s normal. It’s part of business. You’re normal. And you’re welcome.
– Matt Heller, Browsium Founder and Chairman
