JDK-8068889 : Calling a @FunctionalInterface from JS leaks internal objects
  • Type: Bug
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-01-13
  • Updated: 2015-09-29
  • Resolved: 2015-01-13
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.
8u40Fixed 9 b47Fixed
Related Reports
Relates :  
When calling from JS to Java, Nashorn filters internal implementation objects; ConsString is converted to String and ScriptObject to ScriptObjectMirror before being passed on. Unfortunately, calling a @FunctionalInterface object is implemented as a separate code path, and this filtering is missing there.

import java.util.function.Function;
import javax.script.ScriptEngine;
import javax.script.ScriptException;
import jdk.nashorn.api.scripting.NashornScriptEngineFactory;

public class CS {
    public static void main(String[] args) throws ScriptException {
        ScriptEngine engine = new NashornScriptEngineFactory().getScriptEngine();
        engine.put("f", new Function<String, String>() {
            public String apply(String t) {
                return t;
        engine.eval("var x = 'a'; x += 'b'; f(x)");

throws java.lang.ClassCastException: jdk.nashorn.internal.runtime.ConsString cannot be cast to java.lang.String
	at CS$1.apply(CS.java:1)
	at ...

it should not throw an exception instead.
SQE is ok to take the fix in 8u40.

Sustaining supports the plan to include this fix in 8u40. Please include this fix in 8u40 if possible as it will ensure that the fundamental issue see by some customers is corrected. To the release team for a decision.

I noticed that Owen Stuart removed the "8u40-critical-request" label from this bug on Wednesday. Regardless of sustaining's decision to include JDK-8065858 in the 8BPR as a workaround, I would still want to have it considered for inclusion into 8u40, as I believe this bug can have impact on other users too, therefore do not think the label should have been removed. I'd like the release team to decide on it as per the Critical Request Process and get either a "-critical-approved" or "-critical-rejected" decision on it.

Sundar identified a regression with this fix in the execution of the full ECMA-262 compliance test suite: JDK-8069002. I have produced a fix for that, but the status of this issue as a critical fix will have to be considered jointly with that (it's a one-liner change with an additional null check).

8bpr request removed as this fix is not going to be included in a 8bpr. Sustaining have elected to include https://bugs.openjdk.java.net/browse/JDK-8065858 in the 8BPR.

SQE is ok to take the fix in 8u40.

Critical Request Template - Justification : This is the root cause for a fairly serious regression with a large customer when updating from Java 7 to 8. - Risk Analysis : Low to no-risk. Nashorn was inadvertedly exposing its internal object to external API expecting a string instead, causing a ClassCastException. This single deficiency was fixed with a small code change. Affected code was moved from a class it lived in historically into a different class that is actually responsible for filtering of internal objects at the API boundary; this moving of code makes the change appear larger than it actually is. The bug is believed to exist since initial Java 8 release. - Webrev : http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-January/004092.html - Testing (done/to-be-done) : Two new tests have been added to ScriptEngineTest.java, part of Nashorn's test suite. Also, Alexander Potochkin is building a version of JDK 8 with this change to test it directly with customer's problem. - Back ports (done/to-be-done) : Backported to 8u-dev; 8u-dev backport needs to be pushed into 8u40 if approved here. No further backports necessary. - FX Impact : N/A - Fix For Release : 8u40