Is Java still alive in the enterprise?

Ruby, Python, Swift, Go, Erlang, Rust, Decay, Corrosion, Decomposition… I’m getting facetious, of course, but aren’t you confused too? There are so many trendy programming languages around these days that it’s almost an embarrassment of riches. It’s kinda like being invited to a feast made entirely of tapas, hundreds of them, and not knowing where to start. What about Java? I haven’t heard much in the news about Java these days on the tech sites I stay tuned into. Is Java dead? Or has it simply become boring?

IEEE Spectrum magazine, a typical boring publication for engineering-minded professionals like myself, recently ranked Java at just below Python and C in popularity among Spectrum readers (go figure) and slightly above C# and C++. BetaNews also thinks Java is still hot and they rank it as the most popular programming language, though they suggest that C is gaining ground. Yet if you troll the boards of sites like Reddit and Quora and other social media tech destinations, you can find almost every year loud prognostications that “Java is dead, long live X,” where X is the latest, hottest, trendiest new programming language. This occurs especially whenever there is a new revelation about some massive new security hole discovered in the Java runtime or some other component of the Java environment.

The truth is, however, that it depends on whom you talk to. Many of my IT pro colleagues work in large enterprises, either for big corporations or for multinationals like IBM. Java seems to be very much alive in such places, so I reached out to several colleagues to glean their thoughts concerning the good, bad, and ugly of Java. To get us thinking about this subject, here are three different comments I received from colleagues.

Java: A necessary evil

Our first comment is from James, who works in IT at a university:

“Java is a necessary evil, as a number of standalone and web applications here at the university require this platform. Oracle has tried of late to mitigate security risks, which is great, but in the process has created new headaches for administrators and end users. When Google announced dropping support for NPAPI in version 45 of Chrome, things got worse. We fielded support calls as NPAPI is disabled in the current version. I would be interested, though, in hearing how other enterprise admins are handling Java and other high-risk third-party software. We have been able to uninstall on a handful of systems but in general, our strategy has been protect workstations (firewall/IPS, blacklists, EMET, GPO’s, virus protection) and keep Java up to date using App Deployment Toolkit through SCCM. Speaking of keeping Java updated… Is it just me or is Oracle intentionally making Java more difficult to support in an enterprise?”

A continuous issue

Another colleague who has had concerns about Java is Jeffrey, He offered the following observations:

“One aspect of Java management not addressed is the presence of multiple private Java JREs on one system. While there may be a systemwide Java installation for use with browsers and applets, each application that relies on Java (for example, Open Office or Oracle Database Server) might install its own private copy of Java. Depending on the version of the application installed (particularly legacy applications), there may be multiple series of Java installed (i.e., Java 1.4.x, 1.5.x, 1.6.x), all of which need to be updated. While Oracle provides free support for Java 1.7 (7.x) and 1.8 (8.x), if the vendor is no longer supporting the application, the older versions require a special Java subscription (for third-party applications) or Oracle support (for Oracle applications) to obtain the current patched versions in these series. Even if an administrator knows every instance of Java on a system (a big if), updating Java (even within a series) requires testing and might cause functional or performance issues. You may recall that several years ago, Oracle discovered a floating point error in the then current versions of Java. In response, Oracle released a tool to identify all versions installed on a particular system and patch vulnerable versions. Hopefully, administrators have tools to identify all versions of Java installed on a system in most organizations, but smaller organizations may not have such tools. In any case, patching may still be problematic, particularly for legacy applications and critical applications that require extensive testing of new Java versions prior to operational deployment. And this is not just a theoretical consideration. I supported a large organization where this was a continuous issue, because of multiple servers, each installed with multiple Java-based applications (particularly legacy applications, some of which were Oracle, and some of which were third party), and the regular updates of Java released by Oracle.”

Now that’s just FUD

While some who work in IT may feel like James and Jeffrey that Java is either a necessary evil or a continuous issue to deal with, others like Dave, who is a systems manager, take a different stance on the matter:

“Concerning the recent questions about Java in the enterprise, specifically around security concerns: There’s quite a bit of FUD and misinformation in the industry about Java, even among Java shops that should know better. I know, because I’ve been a party to Norex calls with other Java shops panicking about Java security that wasn’t even relevant to how they used Java. The media screams about a Java ‘vulnerability’ without distinguishing between Java deployment approaches, and then everyone with any association with Java panics. Just as some people still believe there’s a relationship between Java and JavaScript (there isn’t. At all.), some believe that Java is a monolithic runtime that’s only used and deployed in one way. Not the case at all.

Avoiding applets, and a reliance on the Java browser plugin, will plug nearly all major vulnerabilities. Our enterprise development has been largely Java for well over a decade now, and we’ve avoided applet development like the plague. Browser plugins introduce a much larger ‘surface area’ to be attacked than a local client or server installation of a Java runtime. They essentially punch a hole in your firewall and allow rogue remote code to execute within your browser — if the sandbox is compromised due to an exploit, you’ve just granted the enemy access to your local environment and the corporate network.

We’ve developed and deployed many dozens of Java applications across our enterprise, but none are run from a browser — that was a conscious decision we made from the start. Unfortunately, we do have some purchased third-party solutions that require applet support, and those have been our only real pain point. When faced with a mandatory Java upgrade to patch a security hole (as with Java 7 prior to Update 51 a couple years ago), we’ve struggled to find a secure, compatible Java version that all of these apps were compatible with, since you can only have a single ‘system’ JRE active (which happens to also provide the plugin). We’re leaning on our vendors to reduce or eliminate the applet requirement, and I would love to see Oracle drop support for applets and deprecate their use. Unlikely, considering they now push it as a selling point for JavaFX, the successor to Swing that allows you to write your GUI once and run as thick client or web — my fear is shops will be attracted to this ‘feature’ without understanding its consequences.

Outside of the browser, with proper traditional client and server security (firewalls, ACLs, etc.), Java runtimes have historically carried very little risk (nearly all such risks were of internal attack, not external). Unlike with the browser plugin, which is owned by the one-and-only ‘system’ JRE, you can deploy multiple Java client runtimes and point each application to their own version if necessary, making Java upgrade impact less of an issue. We’ve adopted this model with our enterprise Java deployments, where the app bundles its desired JRE and runs independently of the ‘system’ JRE or any other JRE on the same host.”

Just manage it right!

Finally, there are colleagues like Jeremy Moskowitz, a Microsoft MVP and founder of PolicyPak Software. When I asked Jeremy about Java’s problems, he replied as follows:

“As a Group Policy MVP, when I was posed the question of ‘How are we supposed to manage X in the enterprise?’ I built a company around it. And we’ve been going like gangbusters since 2012. We manage hundreds of applications, like Java, Firefox, Flash, and everything else nearly impossible to manage. Here are some videos on how we manage Java. And we have hundreds of thousands of seats under management doing it this way.”

Be sure to also check out Jeremy’s website, where he maintains a blog and has some additional resources on Group Policy and offers both live and online training.

Photo credit: Pixabay