This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 228121

Summary: Assertion using b82 of JDK8 trying to use JavaFX projects
Product: javafx Reporter: sreimers <sreimers>
Component: ProjectAssignee: Petr Somol <psomol>
Status: RESOLVED FIXED    
Severity: normal CC: charlymoon, tzezula
Priority: P1 Keywords: JDK_8
Version: 7.4   
Hardware: PC   
OS: All   
Issue Type: DEFECT Exception Reporter:
Attachments: Assertion from Nashorn

Description sreimers 2013-03-31 20:25:00 UTC
Created attachment 133242 [details]
Assertion from Nashorn

Trying to run clean and build from project context menu ends with assertion in output window.

This makes JavaFX project type unusable at the moment with b82 of JDK8.
Comment 1 Petr Somol 2013-04-03 12:45:59 UTC
I confirm Nashorn to cause problems with FX Application build scripts. We will polish the scripts because Nashorn is more strict than Rhino. At the same time there is likely a problem in Nashorn interaction as well; currently I am able to get to a state when repeated Clean and Builds (and Runs) result randomly in successess or in errors at various places...

The same problem is reported also at:
https://forums.oracle.com/forums/thread.jspa?threadID=2517913
Comment 2 Petr Somol 2013-04-04 12:57:40 UTC
I discovered that unlike Rhino, Nashorn causes random problems when invoked from Ant scripts. The problem is unstable visibility of Ant classes. To try this, do the following: run NetBeans on JDK8 b82+ and create the simple Java Application project. Edit its build.xml file - add the following overriding target:

<target name="-pre-init">
    <script language="javascript">
        <![CDATA[
            var atst = new org.apache.tools.ant.taskdefs.Manifest.Attribute();
            print("atst = " + atst.toString());
        ]]>
    </script>
</target>

Repeatedly press Clean (or Build or any other such action that invokes -pre-init target). On my PC in roughly one in ten tries this action succeeds as indicated by the output like the following:

ant -f C:\\temp\\fx\\JavaApplication4 -Dnb.internal.action.name=clean clean
atst = org.apache.tools.ant.taskdefs.Manifest$Attribute@1
...
BUILD SUCCESSFUL (total time: 0 seconds)

But in most cases it ends up in the following:

ant -f C:\\temp\\fx\\JavaApplication4 -Dnb.internal.action.name=clean clean
C:\temp\fx\JavaApplication4\build.xml:75: 
javax.script.ScriptException: ReferenceError: "org" is not defined in <eval> at line number 3
	at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:424)
	at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:408)
	at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:379)
	at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:134)
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:487)
	at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108)
	at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81)
	at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103)
	at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
	at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor63.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:487)
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at org.apache.tools.ant.Target.execute(Target.java:435)
	at org.apache.tools.ant.Target.performTasks(Target.java:456)
	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
	at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
	at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
	at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
	at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:283)
	at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:541)
	at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
Caused by: <eval>:3 ReferenceError: "org" is not defined
	at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:66)
	at jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:328)
	at jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:300)
	at jdk.nashorn.api.scripting.NashornScriptEngine.__noSuchProperty__(NashornScriptEngine.java:242)
	at jdk.nashorn.internal.scripts.Script$engine._L36(nashorn:engine/resources/engine.js:38)
	at jdk.nashorn.internal.scripts.Script$\^eval\_.runScript(<eval>:3)
	at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:362)
	at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:201)
	at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:345)
	at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:405)
	... 27 more
BUILD FAILED (total time: 0 seconds)
Comment 3 Petr Somol 2013-04-04 13:39:04 UTC
Another Nashorn related behavior randomness can be observed regarding conversion of return values. In JSR 223 spec, section SCR 3.3.5, it is stated that "Certain return value types such as java.lang.Number, java.lang.String, java.lang.Boolean, java.lang.Character and null should be represented by corresponding script data types." Try the following: run NetBeans on JDK8 b82 and create the simple Java Application project. Edit its build.xml file - add the following overriding target:

<target name="-pre-init">
    <script language="javascript">
        <![CDATA[
            var keys = project.getProperties().keys();
            while(keys.hasMoreElements()) {
                var str = keys.nextElement();
                if(str instanceof String) {
                    print("String: " + str);
                }
                if(str instanceof java.lang.String) {
                    print("java.lang.String; " + str);
                }
            }
        ]]>
    </script>
</target>

Repeatedly press Clean (or Build or any other such action that invokes
-pre-init target). It seems that in some of the runs the returned strings are returned as javascript Strings, but in other runs they are returned as java.lang.String proxies.
Comment 4 Petr Somol 2013-04-08 12:00:09 UTC
*** Bug 227920 has been marked as a duplicate of this bug. ***
Comment 5 Petr Somol 2013-04-08 15:24:04 UTC
Polished build scripts and added workarounds around string related problems described in Comment #3:
http://hg.netbeans.org/jet-main/rev/8b874e6f9614

Unlike before, the build now finishes correctly from time to time. But it still fails randomly on the error described in Comment #2. The current recommendation in case of build failure is to repeat builds until success. This situation will hopefully improve with further JDK8 updates. Remark: alternatively it is possible to run NetBeans on JDK7 and to define JDK8-based FX platform. In such way no failures appear, the only limitation is the use of JDK7 build system.

This is all that can be done on NetBeans side, the error described in Comment #2 can not be fully worked around; unpredictable failure to instantiate Java classes points at possible classpath problems during Nashorn invocation.
We are going to report the issue to JDK bug tracking system.
Comment 6 Petr Somol 2013-04-11 11:06:37 UTC
We filed the issue against JDK under JDK-8011976. There have already been related issues filed under JDK-8011697, and in particular JDK-8010709.

Today I verified that the relevant JDK issues have been fixed in JDK8 b84. With JDK8 b84 the NetBeans build system works correctly as expected, hence changing the status of this bug to fixed (as the fixe from Comment #5 is now sufficient to make things work correctly with JDK8 scripting changes).