In JDK 9, the Java browser plug-in will be a thing of the past
In the version 9 release of JDK, Oracle will finally drop the Java browser plug-in, and nobody is shedding a tear over it.
To the uninitiated, it may have seemed like another damning headline from Oracle, intimating another nail in the coffin of the Java programming language. To the informed enthusiasts who have defended and advocated on the behalf of the world's most popular cross-platform programming language, however, the death of the Java browser plug-in has been received with open arms.
Software developers are not bemoaning the death of the browser-based Java applet, but they are instead collectively wiping their brows, sighing under their breath with the happy knowledge that they can put Java applet technology behind them.
A promise not delivered
Invariably, each browser behaved differently, and each platform and operating system had its own quirks, so the WORA hope turned into WODE.
Running Java programs within a browser was always a great idea, but the reality of cross-platform, write once run anywhere applications (WORA) delivered through the browser never lived up to the promise. Invariably, each browser behaved differently, and each platform and operating system had its own quirks, so the WORA hope turned into WODE: a write once, debug everywhere reality. Compounded by the fact that Java support on handheld devices such as Apple iPhones is completely scant, using browser based-Java applications as a mode of distributed application delivery simply isn't a smart choice in today's world.
In 2012, TheServerSide, the industry's biggest booster of Java-based application development and delivery, questioned the sanity of any organization that depended upon the Java browser plug-in for distributed application deployment. At the time, I wrote the following about applets: "Java Applets don't have any place in a modern enterprise design. Any functionality you need from an Applet can be achieved by intelligently applying JavaScript and leveraging existing JavaScript libraries, and not doing so is a disservice to your users." Since penning that article, nothing has changed. If anything, things have become worse.
A flawed security model
The worst problem is the number of security holes that have been attributed to the Java browser plug-in in recent years. Big headlines have been made out of the potential for hackers to exploit a given shortcoming of the plug-in, creating a great deal of uncertainty and fear in the minds of the everyday user. Java developers were always aware that very few of the publicized Java exploits were attributable to the standard edition of Java that runs desktop applications or powers the back-end servers of the world's biggest banks, governments and insurance companies. But perception can be as important as the reality, and the ongoing discoveries of security flaws with the Java browser plug-in were seriously undermining Java's credibility.
The other problem with the Java applet is that other technologies -- namely JavaScript and the various frameworks it has spawned, including JQuery, Ember, AlloyUI, Angular, Node and others -- are much better at, and more well suited to, delivering content through the browser than Java is. Pulling a quote from the 2012 article mentioned earlier: "Given, there was a point before the time of enlightenment in which Java Applets could do things that were impossible with other Web-based technology. But that three-week window passed us by in about 1998, and enterprise software needs to keep up with the times." Keeping up with the times means using JavaScript, CSS and HTML5 on the browser, and not depending upon plug-ins for anything other than nonfunctional tasks such as custom authentication mechanisms or creating virtual private networks. Content generation through a plug-in doesn't make sense.
It should be noted that application delivery through a browser isn't completely dead. Java Web Start technology still allows for Java Network Launch Protocol (JNLP) files to be delivered through a browser, and when a user runs the file, a Java application will run and be able to connect to the server that delivered the JNLP file to the client.
E*Trade provides a very impressive, Java-based application for monitoring stocks' prices and linking back to their Web-based trading application. The JNLP file is delivered through the browser, and the result is an impressive Java application. So the delivery of Java applications to the end client through a browser isn't completely dead; it's just that the process has changed, and as a result of making the change, the big security hole known as the Java browser plug-in has been permanently plugged.
Will losing the Java browser plug-in change the way you deploy Java applications over the Web? Let us know.
Next Steps:
Promises made by Java 9
Top seven Java platform strategies
Java programming turns 20
