JDK-8154127 : Need to document that JavaScript to Java bindings use weak references
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u102,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-04-13
  • Updated: 2020-01-31
  • Resolved: 2016-06-29
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 8 JDK 9
8u112Fixed 9Fixed
Related Reports
Cloners :  
JDK-8169204 - Need to document JSObject Call and setSlot APIs to use weak references
Relates :  
JDK-8169341 - Broken JavaScript-to-Java callback in WebEngine with 2nd call
Relates :  
JDK-8089681 - WebView leaks memory when containing object acts as javascript callback handler
Relates :  
JDK-8171401 - Release Note: Fixed memory leak when Java objects are passed into JavaScript
Relates :  
JDK-8165302 - Upcall from JavaScript to Java is broken
Relates :  
JDK-8178878 - [WebView] Java method not getting called from HTML
Relates :  
JDK-8168625 - Java WebView communication between java and javascript fails in Java 8 U112
Description
In order to fix JDK-8089681 we now use weak references in the WebKit JavaScript bridge code to hold onto Java objects that are bound to JavaScript objects using JSObject.setMember.

Applications that rely on the previous, buggy behavior might be surprised by the fact that objects that are not strongly held by the application are subject to garbage collection even though they are bound to a JavaScript object.

We should document this fact in the WebEngine documentation in the section on "Calling back to Java from JavaScript".
Comments
Changeset: 978f6947b8f5 Author: mbilla Date: 2016-06-29 22:51 +0530 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/978f6947b8f5 Note: Removed the second copy of "onClick" statement.
29-06-2016
Looks great. And I do think you might remove the second copy of the "onclick" as being redundant, although not a big deal either way, so it's up to you. +1
29-06-2016
webrev: http://cr.openjdk.java.net/~mbilla/8154127/webrev.03/ Incorporated above comments from kevin.. Note: Regarding above point 4, i added below code before the line " When a user clicks the link, it does not guarantee to execute the callback method {@code exit}." Please let me know, in case if below code is redundant and can be removed ? <pre><code> &lt;a href="" onclick="app.exit()"&gt;Click here to exit application&lt;/a&gt; </code></pre>
29-06-2016
Looks better. A few more comments: 1. The words "Objects", "Weak", and "References" should not be capitalized in the following: Note that the Java Objects bound using JSObject.setMember are implemented using Weak References. 2. You might use {@code JavaApplication} in the following: Note that in the above example, the application holds a reference to the JavaApplication instance... 3. You might want to add a comma before "new JavaApplication()" (and maybe enclose it in @{code ... } ? ) In this case, since the property value is a local object "new JavaApplication()", the value may be GC'ed in next GC Cycle. also, I missed this last time...you should spell out "GC'ed" as "garbage collected" (and you don't need to capitalize Cycle), so: In this case, since the property value is a local object, "new JavaApplication()", the value may be garbage collected in next GC cycle. 4. The following sentence was in the .00 version, and it would be good to restore it (right after the sentence about "in the next GC cycle"). When a user clicks the link, it does not guarantee to execute the callback method {@code exit}.
28-06-2016
webrev: http://cr.openjdk.java.net/~mbilla/8154127/webrev.02/ Incorporated above suggestions by kevin..
28-06-2016
This looks like a good start, but I have two comments: 1. I recommend to add a note in the previous section, "Mapping Java objects to JavaScript values", indicating that Java Objects bound using JSObject.setMember are implemented using weak references. This is clearer than just mentioning it in the example section. Something like this: ------------------- ...This is a JavaScript object that acts as a proxy for the Java object, in that accessing properties of the JavaRuntimeObject causes the Java field or method with the same name to be accessed. + <p> + Note that the binding from the JavaScript object to the corresponding Java object is implemented using weak references. This + means that the Java object can be garbage collected, causing subsequent accesses to the JavaScript objects to have no effect. ------------------- 2. The lead-in to the second example doesn't quite flow. Something more like the following might be better? --------- Note that in the above example, the application holds a reference to the JavaApplication instance. This is required for the callback from JavaScript to execute the desired method. In the following example, the application does not hold a reference to the Java object: JSObject window = (JSObject) webEngine.executeScript("window"); window.setMember("app", new JavaApplication()); In this case, since the property value is a local object, "new JavaApplication()", the value may be GC'ed in next GC Cycle. ... --------------------------------------
28-06-2016
webrev: http://cr.openjdk.java.net/~mbilla/8154127/webrev.00/
27-06-2016
I removed the non-reg-9 label because this issue was exposed by the fix for JDK-8089681, which went into 8u102. Following that fix applications will break if they rely on former, undocumented behavior. So I think this is a must fix for 9 with a backport to 8u (it would be good to get this doc change into 8u112).
01-06-2016