How does java run its applets in the browser?

Question

好吧，我们已经很长时间没有在Internet Explorer中运行ActiveX控件了，所以我的问题是Java如何操纵浏览器在网页上显示小程序？

Answer 1

how does java manipulate the browser into displaying the applet on the web page?

It doesn't. The user installs an NPAPI (Netscape Plugin API) plugin which tells the browser it can run Java applets. Then, when the browser sees a Java applet, it fires up the plugin.

It's worth noting that Chrome no longer supports the NPAPI on Linux, and they're scheduled to stop supporting it on Windows in September . As far as I know, officially Mozilla calls NPAPI plugins a "legacy" feature and recommends using other options, but is continuing to support them via click-to-play (at least for now)..

Answer 2

Java Applets consists of compiled byte-code, which is executed under the control of a JVM. Applets may either be untrusted which limits their capabilities or may be trusted which increases their access permissions and allows them to access user data or hardware.

Java applet runs in browser using Java Plug-in technology (hereafter the "Java Plug-in"), which is included in the Java Runtime Environment (JRE), enables Java applets to run in web browsers on the desktop. The Java Plug-in provides powerful capabilities to applets in the web browser. With the Java Plug-in, applets are not run in the JVM inside the browser. Instead, they are executed in a separate process. The same JVM process can be shared between multiple applets, or applets can be placed into different processes depending on whether the existing JVMs match the applet requirements and have enough resources to execute the applet.

A web browser's JavaScript interpreter engine is single thread. The Java Plug-in is capable of managing multiple threads. The Java Plug-in creates a separate worker thread for every applet. Applets themselves may be multi-threaded.

The following figure shows the thread interactions between the JavaScript Interpreter, Java Plug-in, and an applet.

When the JavaScript interpreter is idle, the Java Plug-in executes a JavaScript to Java call on the per applet worker thread (JavaScript Interpreter Not Busy scenario).

When a Java to JavaScript call is in progress and a JavaScript to Java call is made, the latter is executed on the same thread that made the Java to JavaScript call (Round Trip scenario).

When a thread is executing a Java to JavaScript call, another thread wanting to do the same will be blocked till the first thread has received its result and is done (JavaScript Interpreter Busy scenario)

However, Java extension plugin itself is written using NPAPI plugin, the cross-browser API for plugins. Stands for, Netscape Plugin Application Programming Interface. It allowed third-party code in the form of precompiled plugins to be used by the browser to display vendor specific content seamlessly in web pages. Essentially, it lets you call the native binary code from your JavaScript code. But running NPAPI plugin, the code has the full permissions of the current user and has unrestricted access to the local machine. So all in all with NPAPI, security depends on the plugin's good behaviour and most security considerations are up to the plugin developer. For example, plugin instances can load resources from different origins on request of a web page.

Architectural wise, Java needs these privileges to offer the kind of power and control it brings to the table. Java and some versions of Flash and Shockwave still use NPRuntime, and NPAPI needs to be enabled for Java to function correctly in a browser. At the same time many browsers like Chrome consider this (NPAPI plugin) as serious security vulnerability because if the plugin (that uses NPAPI) contains a vulnerability, an attacker might be able to exploit that vulnerability to install malicious software on the user's machine, also sine plugin (java or NPAPI) is exposed directly to web content, making it easier for a malicious web site to manipulate your plugin, which is why it has made it user permission controlled. Another reason why browsers are moving away from this is, NPAPI isn't supported on mobile devices. Also there are newer problems such as jit spraying http://en.wikipedia.org/wiki/JIT_spraying

Though Chrome has officially stopped NPAPI support, As of Chrome Version 42, an additional configuration step is required to continue using NPAPI plugins. (Could only work till Sept 2015)

In your URL bar, enter: chrome://flags/#enable-npapi Click the Enable link for the Enable NPAPI configuration option. Click the Relaunch button that now appears at the bottom of the configuration page.