JDK-8132743 : Move netscape.javascript package from jdk.plugin to new module
  • Type: Enhancement
  • Component: deploy
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-07-30
  • Updated: 2017-06-08
  • Resolved: 2016-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b109Fixed
Related Reports
Blocks :  
JDK-8132744 - Remove dependency on jdk.plugin from javafx.web
Blocks :  
JDK-8151636 - Revert changes to signature of HostServices::getWindow
Blocks :  
JDK-8151634 - Remove build-time dependency on plugin.jar from FX jake build
Duplicate :  
JDK-8089211 - [Javadoc] JSObject broken links
Relates :  
JDK-8090136 - Remove duplicate copy of netscape.javascript package
Relates :  
JDK-8181821 - Broken link in javadoc for JSObject.getWindow
Relates :  
JDK-8153667 - JDK 9-ea API docs does not include netscape.javascript package
Description
See JDK-8090136 for some of the background on this. We need to create a new jdk module for the netscape.javascript package that is used in liveconnect for AWT and FX applets (to allow an applet to access the applet web page via JavaScript), and also for FX WebVIew in the JavaScript bridge.

The implementation of the JSObject.getWindow(Applet) method will need to move to a class in the plugin module. This should be a reasonably straight-forward refactoring.

This new module will need to be moved to the (open) jdk repo so that we don't have a situation where the open part of FX depends on a closed module to build it.
Comments
Public code review thread: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/006545.html
05-03-2016
The proposal for this issue is to put JSObject, JSException and a service type in to its own module named jdk.jsobject. The service type should be a JDK-internal package, one possible name is jdk.internal.netscape.javascript.JSObjectProvider that is an abstract class or interface with a public abstract method getJSObject(Applet) .JSObject.getWindow(Applet) will be updated to use ServiceLoader to locate the JSObjectProvider implementation and invoke its getJSObject method.
15-02-2016
Dave - can you summarize the open issues of this approach? Refactoring it to jdk.desktop is the easy part but there are issues related to modular JARs. While we explored other alternatives at one point, I recalled that this option seems to be the preferred one. It'd be good to summarize it.
14-01-2016
It has been suggested that we create a new module in jdk named "jdk.desktop" that will contain this and a few other classes, so that will be the approach for this fix.
07-12-2015