Supporting Java in browsers is only possible for as long as browser vendors are committed to supporting standards based plugins. By late 2015, many browser vendors had either removed or announced timelines for the removal of standards based plugin support, while some are introducing proprietary browser-specific extension APIs. Consequently, Oracle is planning to deprecate the Java browser plugin in JDK 9.By "deprecate", Oracle doesn't mean that the Java plugin will be killed stone dead. Instead they will increasingly hide it, and not encourage users to install it. In due course, the software will be entirely removed. Of course, Oracle isn't dropping support for Java entirely - but with the demise of the unpopular web browser plugin, it hopes users will be happy to switch over to its replacement - the plugin-free Java Web Start technology - which does not rely upon a browser, and is considered a safer way to run Java applications. To be honest, the Java plugin's days have been numbered for some time - with the rise of smartphone usage, and the way most modern browsers are reducing support for plugins. In short, the browser manufacturers - in their quest for greater security and stability - were making the Java plugin irrelevant, regardless of Oracle's plans for their software. Oracle isn't the only company having to recognise that the world is changing. Adobe, developers of the often-attacked Flash plugin, recently made clear that it was moving away from the platform to an HTML5-based future. Oracle has published a white paper (ironically in Adobe PDF format - but you've kept your copy of Adobe Reader updated, right?) explaining how corporations can best migrate to solutions such as Java Web Start. Java version 9 is already available as an early access beta for those who want to get an early ticket for the funeral. I doubt there will be too many mourners. To learn more about Tripwire's vulnerability managment solutions, click here. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.