Bug ID: JDK-8311530 Deprecate jdk.jsobject module for removal

Type: Bug
Component: deploy
Affected Version: 11

Priority: P4
Status: In Progress
Resolution: Unresolved

Submitted: 2023-07-05
Updated: 2024-09-24

JDK 24
24Unresolved

The module jdk.jsobject should be considered for deprecation and removal.
It contains only two legacy classes in the netscape.javascript package; JSObject and JSException.

There is no use within OpenJDK itself.

The class is used by JavaFX within the javafx.web module. Including it from the JDK seems like a leftover backward compatible move that has outlasted the original Applet APIs.

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/20555 Date: 2024-08-12 17:22:47 +0000
05-09-2024
I filed JDK-8337280 to build and include the jdk.jsobject module with JavaFX in support of Option 1.
26-07-2024
jdk.jsobject is a JDK module that delivers a single package, netscape.javascript. It is currently used by JavaFX WebView for Java <--> JavaScript interoperation. Prior to JDK 11, it was also used by the LiveConnect feature of Java Plug-In to allow applets to communicate with the hosting web page. JavaFX, which was unbundled from the JDK in 11, is the only remaining client of the jdk.jsobject APIs. Possible solutions: 0. Continue to deliver the jdk.jsobject module as part of the JDK In this case we would close this issue (JDK-8311530) as "Won't fix". Pros: No change at all to applications or JavaFX Cons: JDK will continue carrying a module that is no longer used except by JavaFX 1. Deliver a copy of the jdk.jsobject module as part of the JavaFX distribution The JavaFX SDK includes a set of modular jars, one for each JavaFX module. If we add a copy of jdk.jsobject to this set of modular jars, applications that use JavaFX via the standalone SDK will not change at all. If the JDK used to run the app includes jdk.jsobject, the module loader will load that one. If not, the module loader will load the one from the modular jar. The JavaFX release also includes a set of jmod files. Similar to the previous case, running jlink from a JDK that include jdk.jsobject will pick up the one from the JDK. Running jlink from a JDK that does not include jdk.jsobject will pick up the one included with the JavaFX jmods. We will need to add the jdk.jsobject modules to the set of JavaFX modules on maven central, and applications that use javafx.web will notice an additional dependency on jdk.jsobject from maven central. This will need to be tested more fully. In order for this option to work, we need to keep the two versions of the jdk.jsobject module in sync, with the only difference being that the one in the JDK will be deprecated for removal, while the one delivered with JavaFX will not be. The jsobject module is stable, and there are no plans to evolve it at all, so this will not be a problem. Pros: Preserves backwards compatibility: applications will continue to run Cons: None that I can think of 2. Deliver the netscape.javascript package in an existing JavaFX module, `javafx.web` I don't think this option is implementable, and is only listed for completeness. Pros: None that I can think of Cons: This is unlikely to work at all, since two modules cannot deliver the same package; if an existing application loads the jdk.jsobject module, it is very likely that the javafx.web module would fail to load. 3. Provide a replacement for JSObject in another package, and include that new package as part of the javafx.web module. We would need to deprecate `WebEngine::executeScript` for removal, and define a replacement method, something like `WebEngine::executeJavaScript`. We would need to allow a sufficient amount of time for applications to transition, after which we could remove WebEngine::executeScript from JavaFX and the jdk.jsobject from the JDK. Pros: Doesn't require JavaFX to ship a copy of the jdk.jsobject module Cons: This would force applications to change, and would require a longer transition period before we could remove jdk.jsobject. It is also more work in JavaFX WebView, since we would need to support both in the interim. We would need to prototype this to determine whether it is feasible to support both the old and new JSObject, possibly by changing the existing implementation to use the new abstract class, and providing an implementation of the old abstract class that delegates to the new one. Alternatively, if we make the replacement JSObject an interface, then the existing class could implement that interface and continue to extend netscape.javascript.JSObject until such time as we remove it. Recommendation: Option 1 seems like the best choice, unless we run into problems that make it infeasible (my initial testing shows that everything works as expected), or if there is an objection to shipping a jdk.* module with JavaFX. Option 3 is the other viable choice, but it has the drawbacks listed in that option.
18-06-2024
I think this would be a good thing to do in JDK 24 or 25 (with removal in a post-25 release).
13-06-2024
Are we ever going to remove this ?
12-06-2024
The intent for this issue was to deprecate for removal it in the JDK. Just giving notice. If a replacement is needed in JavaFX, that would be a separate issue, as would other potential changes required for the transition, for example, not resolving by default.
11-07-2023
Changing the fix version back to "tbd". This is not at all related to JDK 8, since the module system didn't even exist until JDK 9. I'll update the bug report and provide an evaluation.
10-07-2023
Input will be needed from JavaFX and perhaps JavaFX itself can provide the API.
05-07-2023

CSR :	JDK-8338250 - Deprecate jdk.jsobject module for removal
Relates :	JDK-8337280 - Include jdk.jsobject module with JavaFX