JDK-8090136 : Remove duplicate copy of netscape.javascript package
Type:Bug
Component:javafx
Sub-Component:other
Affected Version:9-repo-jigsaw
Priority:P2
Status:Resolved
Resolution:Fixed
Submitted:2015-03-11
Updated:2016-03-10
Resolved:2015-08-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.
We have two copies of the netscape.javascript package, one in the javafx.graphics module and one in the deploy plugin module.
Comments
I have filed a follow-on issue, JDK-8151636, to revert the changes to the signature of that method. This will avoid the incompatible change discussed above.
I filed JDK-8132743 to track the creation of the new jdk module for netscape.javascript.
30-07-2015
We cannot fix this without either a break in compatibility somewhere or a permanent, unwanted API dependency from javafx.graphics on java.desktop.
I think the "least bad" solution will be to break compatibility for FX applets that use HostServices.getWebContext() to interact with the browser page in the applet. We have far fewer FX applets than legacy Java applets, and only a subset of FX applets would be affected.
The proposed solution is as follows:
1. move the plugin version of the netscape.javascript package to a new jdk.nnnnnn package (name is tbd, but something like jdk.liveconnect or similar). This means that the implementation of the JSObject.getWIndow(Applet) method will need to move to another class in the plugin module. This should be a reasonably straight-forward refactoring. Note that 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. I will file a new JIRA for this.
2. remove netscape.javascript from javafx.graphics, and then change the return type of HostServices.getWebContext() from netscape.javascript.JSObject to Object. The only case where the return value of this method is non-null is in applet mode, in which case the plugin module and the new module containing netscape.javascript will already be present and loaded. The documentation for HostServices.getWebContext() will indicate that callers should cast the return value to netscape.javascript.JSObject. This is the incompatible change in FX that we will need to document in the release notes.
3. The javafx.web module will have a hard implementation dependency on the new jdk.liveconnect module, which in turn will depend on java.desktop. This is not something we will likely be able to get rid of in the future for the web module, but javafx.web already has other dependencies on java.desktop, so this is just something we would need to live with.
30-07-2015
Until #1 is done (moving netscape.plugin to a new module), the javafx.web module will need to depend on the jdk.plugin module (which we cannot do long term). I can then do #2 without having to wait for the refactoring of the plugin code. I will file a follow-on JIRA to remove this dependency and replace it with one on the new module.