https://en.wikipedia.org/wiki/NPAPI
Netscape Plugin Application Programming Interface (NPAPI) is a cross-platform plugin architecture used by many web browsers.
It was first developed for Netscape browsers, starting in 1995 with Netscape Navigator 2.0, but was subsequently adopted and implemented by many other browsers, although some browsers later dropped support.
https://java.com/en/download/faq/chrome.xml
NPAPI support by Chrome
The Java plug-in for web browsers relies on the cross platform plugin architecture NPAPI, which has long been, and currently is, supported by all major web browsers. Google announced in September 2013 plans to remove NPAPI support from Chrome by “the end of 2014”, thus effectively dropping support for Silverlight, Java, Facebook Video and other similar NPAPI based plugins. Recently, Google has revised their plans and now state that they plan to completely remove NPAPI by late 2015. As it is unclear if these dates will be further extended or not, we strongly recommend Java users consider alternatives to Chrome as soon as possible. Instead, we recommend Firefox, Internet Explorer and Safari as longer-term options.
https://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html
There’s security:
So far this year, there have been 3 critical patch updates for Java. Each time, there has been one or more (in reality, way more) bugs which allow for an attacker to escape Java’s sandbox and take over your system. Unlike Adobe Flash, where there is some level of cooperation, Oracle and Google are involved in lawsuits, ruling out any engineering integration of up-to-date versions. And, as that link mentioned, NPAPI plugins get to run as the current user, so Chrome can’t really block any bad behavior – meaning that a plugin can easily compromise Chrome’s security model. This alone is enough of a reason to engineer it out – this is literally one of the biggest gaps in web security.
There’s code maintainability:
Java and Silverlight are NPAPI plugins. NPAPI was not developed as a generic plugin interface for any browser; It was developed in 1995 for Netscape, and other browsers just adopted it. A 20+ year old plugin design has flaws and obsolescence that will require increasingly complex code to work around. Workarounds for these things make code harder to maintain, make the code slower, and take away from other bug fixes and enhancements.
There’s openness:
Unlike HTML5, Java (as the plugin implementation) isn’t an open standard. Oracle controls it, and Google can offer all the advice they want, but can’t force any changes short of what they’re doing now. Multiple forces on the web are trying to move away from Silverlight, Flash and Java – because the developers of those plugins have to be begged to work on any other platform, while HTML5 is generally capable of doing almost everything you can do with those.
There’s the true meaning of running Java:
Your bulleted points up there are lovely – and largely moot points. First off, as a developer, I can tell you that while Java is probably the highest percentage of development jobs, a majority of the developers out there use other languages (ie, it’s not 50% of jobs). Most developers and new projects and companies are not choosing Java, largely because of the aforementioned openness. But more importantly, ‘running Java’ is a silly distinction. With Chrome’s change, Java still works on your desktop. You can still launch standard Java desktop applications, and I think Java Web Start would even still work (it’s ultimately a file association). The only thing that will not run at all are Java applets, which are extremely rare now. (And remember, JavaScript IS NOT Java – JavaScript is it’s own language and infrastructure, and browsers support it without plugins.) After this change, your computer still runs Java – but Chrome will not run a single, insecure type of Java program (applets).
Filed under: Uncategorized | Leave a comment »
No fluff, just stuff...that matters. 