By Matt Heller | Read Time: 3 min 22 sec
Long ago, Larry Ellison promised us that Java would be the future. I think it’s safe to say that Java is indeed a part of our future (present?). Sadly, it’s not the panacea he intended. Instead, Java has become the bane of the existence of many IT and security professionals. As a result, the search for a way to minimize or eliminate Java dependencies has become an Enterprise IT priority.
Despite the desire of organizations to deprecate Java, the reality of a tectonic shift in a foundation is daunting and expensive. Changing core technology isn’t easy or cheap. I believe it is safe to say that Java’s demise will be a protracted one.
While the death cycle for Java is a necessarily slow one, the browser’s period of change has been anything but. More than a year ago, Chrome stopped allowing Java applets in the browser. Firefox ended support long before that. ‘Classic’ Microsoft Edge also ended support, and the new Chromium-based Edge browser follows Google Chrome’s rules. These nullifications have left Internet Explorer as the only alternative for Java-based applets.
With Windows 7 out of support, and IE on life support, what are organizations to do about enabling support for Java applets?
Fortunately, there are some excellent answers available now. Perhaps the best advice is that from Oracle, convert the applets to use Web Start. Unlike the Java applets that are launched conventionally (<applet> tag), Java Web Start applets launch the JVM and run them outside of the browser. This approach maintains full access to functionality but may limit certain behaviors if the applets are designed to interact with browser-based components, etc.
Other approaches to continuing access to Java applets involve containment in one way or another. Virtualization technologies from Microsoft, Citrix, VM Ware, and others can address this need. A cautionary note: Using virtualization for containment is akin to ‘cracking a walnut with a sledgehammer’; It gets the job done, but the results tend to be a bit messy. Containment can be achieved using Browsium solutions, providing an additional benefit: The ability to help scope and manage the overall project, not just resolve issues.
Java, you are despicable!
In the last post (Edge is Coming), we looked at the challenges coming with the end of browser-based support for Java apps. Any discussion of that event is overlapped with the larger question of what to do about Java comprehensively. In talking with organizations of all sizes about Java lifecycle issues, it is consistent that they all see Java as a massive thorn in their side. The problem is, they’re stuck with Java for practical business reasons. At the same time, the browser (read: mini operating system) dependent apps aren’t supported by modern browsers. Add this to Java’s spotty security track record, and it’s clear why there is so much hand ringing.
So, what are organizations to do? Some have pursued the ‘kill Java’ route (often, then, realizing that Java was much more prevalent than expected, leading to more significant projects and bigger budgets). Some don’t even know how to begin scoping the project, so they are stuck (note: we can help with that… Contact [email protected] for more information).
Others have decided to continue maintaining their Java investments, and either let them wind down naturally or at least reduce any new expenditures. The final grouping has agreed to focus on containment for legacy Java-based applications and focus on new technologies that advance the organization.
For those looking to remove Java entirely, time, planning, and funding are all requisites. Organizations looking at variations on the containment approach not only require the same time, planning, and funding; they also add the additional wrinkle of the dreaded “interim planning.” Again, Browsium can help with either the removal or containment solutions (including an interim plan).
Forgetting about Browsium for a minute (gasp!); there are ways to achieve winding down Java without our solutions. Companies have used all kinds of COTS or custom inhouse solutions to work through issues with varying degrees of success. These are complex issues, and trying to use tools designed for other purposes can be messy – They don’t see the right data points, they don’t see the right activities, and worst of all, they are often outside of the browser’s update cycle.
Having a strategy for the Java lifecycle is critical. The end of Java is nigh (kind of), and the industry’s direction is precise. There are options out there – you don’t have to wait until the building is on fire!
By the way, Java will not be the last deprecated technology. Save yourself some long-term pain by looking at today’s Java problems through a longer lens. By enlisting Browsium’s browser solutions today, you will be preparing for the next despicable challenge of tomorrow. You’ll thank us later for building a strategy today.
