Dojo build via Node+Closure Compiler produces a Java exception

[sindilevich]

Hello,

Dojo: 1.12.1.
Machine: Windows 7 SP1 x64, i5-6500, 16GB

Dojo build via Node+Closure Compiler produces a Java exception. The exception is written at the end of the build-report.txt file.

The exception is:


JavaException: java.lang.IllegalArgumentException: Can not set final com.google.javascript.jscomp.CompilerExecutor field com.google.javascript.jscomp.Compiler.compilerExecutor to java.lang.Class
java.lang.IllegalArgumentException: Can not set final com.google.javascript.jscomp.CompilerExecutor field com.google.javascript.jscomp.Compiler.compilerExecutor to java.lang.Class
        at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source)
        at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source)
        at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(Unknown Source)
        at sun.reflect.UnsafeQualifiedObjectFieldAccessorImpl.get(Unknown Source)
        at java.lang.reflect.Field.get(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:160)
        at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243)
        at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66)
        at org.mozilla.javascript.gen.c1._c5(Unknown Source)
        at org.mozilla.javascript.gen.c1.call(Unknown Source)
        at org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:108)
        at org.mozilla.javascript.gen.c1._c0(Unknown Source)
        at org.mozilla.javascript.gen.c1.call(Unknown Source)
        at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:401)
        at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3003)
        at org.mozilla.javascript.gen.c1.call(Unknown Source)
        at org.mozilla.javascript.gen.c1.exec(Unknown Source)
        at org.mozilla.javascript.tools.shell.Main.evaluateScript(Main.java:526)
        at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:448)
        at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:414)
        at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:405)
        at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:179)
        at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:100)
        at org.mozilla.javascript.Context.call(Context.java:499)
        at org.mozilla.javascript.ContextFactory.call(ContextFactory.java:511)
        at org.mozilla.javascript.tools.shell.Main.exec(Main.java:162)
        at org.mozilla.javascript.tools.shell.Main.main(Main.java:140)



The POC project consists of a single file, src/app/arrayHelper.js, with the contents as follows:


define(["dojo/_base/declare"], function(declare) {
    "use strict";
   
    return declare("array.helper", [], {
        getLength: function(array) {
            return array.length;
        }
    });
});


The build profile is:


var profile = (function () {
        return {
                basePath: "./src",
                releaseDir: "../../app",
                releaseName: "lib",
                action: "release",
                layerOptimize: "closure.keepLines",
                optimize: "closure.keepLines",
                localeList: "he",
                cssOptimize: "comments.keepLines",
                mini: true,
                stripConsole: "warn",
                optimizeOptions: {
                        languageIn: "ECMASCRIPT6",
                        languageOut: "ECMASCRIPT5"
                },
                defaultConfig: {
                        hasCache: {
                                "dojo-bidi": true,
                                "dojo-undef-api": true,
                                "dojo-built": 1,
                                "dojo-loader": 1,
                                "dom": 1,
                                "host-browser": 1
                        },
                        async: 1
                },
                packages: [{
                        name: "dojo",
                        location: "dojo"
                }, {
                        name: "app",
                        location: "app"
                }]
        };
})();


On the other hand, when running Dojo build via Java -- no exception is written.

Any help is much appreciated!

Thank you.

[dylanks]

A few questions and things to note:

1. declare did not get official support for strict mode until
https://github.com/dojo/dojo/pull/249 landed, which was for Dojo 1.13.
You may choose to backport this patch to 1.12 of course, but it is
considered a change in functionality and won't be backported with an
official release.
2. Which version of Node.js are you using?
3. If you remove the optimizeOptions settings, is this still failing?
4. The first parameter (a named declared class) is generally
discouraged... it's there for legacy loader support, and should only
really be used by the build system).
5. Have you tried your POC in a manner that does not extend a native
prototype, but rather an object?

Regards,
-Dylan

on 2/12/17, 11:42 (GMT-07:00) sindilevich said the following:

> Hello,
>
> Dojo: 1.12.1.
> Machine: Windows 7 SP1 x64, i5-6500, 16GB
>
> Dojo build via Node+Closure Compiler produces a Java exception. The
> exception is written at the end of the *build-report.txt* file.
>
> The exception is:
>
> /
> JavaException: java.lang.IllegalArgumentException: Can not set final
> com.google.javascript.jscomp.CompilerExecutor field
> com.google.javascript.jscomp.Compiler.compilerExecutor to java.lang.Class
> java.lang.IllegalArgumentException: Can not set final
> com.google.javascript.jscomp.CompilerExecutor field
> com.google.javascript.jscomp.Compiler.compilerExecutor to java.lang.Class
> at
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown
> Source)
> at
> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown
> Source)
> at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(Unknown Source)
> at sun.reflect.UnsafeQualifiedObjectFieldAccessorImpl.get(Unknown Source)
> at java.lang.reflect.Field.get(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:160)
> at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243)
> at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66)
> at org.mozilla.javascript.gen.c1._c5(Unknown Source)
> at org.mozilla.javascript.gen.c1.call(Unknown Source)
> at
> org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:108)
> at org.mozilla.javascript.gen.c1._c0(Unknown Source)
> at org.mozilla.javascript.gen.c1.call(Unknown Source)
> at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:401)
> at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3003)
> at org.mozilla.javascript.gen.c1.call(Unknown Source)
> at org.mozilla.javascript.gen.c1.exec(Unknown Source)
> at org.mozilla.javascript.tools.shell.Main.evaluateScript(Main.java:526)
> at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:448)
> at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:414)
> at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:405)
> at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:179)
> at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:100)
> at org.mozilla.javascript.Context.call(Context.java:499)
> at org.mozilla.javascript.ContextFactory.call(ContextFactory.java:511)
> at org.mozilla.javascript.tools.shell.Main.exec(Main.java:162)
> at org.mozilla.javascript.tools.shell.Main.main(Main.java:140)
> /
>
>
> The POC project consists of a single file, *src/app/arrayHelper.js*, with
> the contents as follows:
>
> /
> define(["dojo/_base/declare"], function(declare) {
>     "use strict";
>    
>     return declare("array.helper", [], {
>         getLength: function(array) {
>             return array.length;
>         }
>     });
> });
> /
>
> The build profile is:
>
> /
> var profile = (function () {
>         return {
>                 basePath: "./src",
>                 releaseDir: "../../app",
>                 releaseName: "lib",
> action: "release",
> layerOptimize: "closure.keepLines",
> optimize: "closure.keepLines",
> localeList: "he",
> cssOptimize: "comments.keepLines",
> mini: true,
> stripConsole: "warn",
> optimizeOptions: {
> languageIn: "ECMASCRIPT6",
> languageOut: "ECMASCRIPT5"
> },
> defaultConfig: {
> hasCache: {
> "dojo-bidi": true,
> "dojo-undef-api": true,
> "dojo-built": 1,
> "dojo-loader": 1,
> "dom": 1,
> "host-browser": 1
> },
> async: 1
> },
> packages: [{
> name: "dojo",
> location: "dojo"
> }, {
> name: "app",
> location: "app"
> }]
> };
> })();
> /
>
> On the other hand, when running Dojo build via Java -- no exception is
> written.
>
> Any help is much appreciated!
>
> Thank you.
>
>
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Dojo-build-via-Node-Closure-Compiler-produces-a-Java-exception-tp4007132.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.

--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

[sindilevich]

I reworked my POC, using the Dojo boilerplate project as the POC. I only updated it to using Dojo 1.12.1 and added a simple .cmd file to bootstrap the build more conveniently.

Thus:
1. No strict mode in the POC
2. I use node v7.5.0
3. I removed the optimizeOptions settings, but the same exception was thrown, when running the build with Node
4. Got rid of the named declared class parameter
5. Now, I extend dijit/Dialog instead
6. I forgot to mention, I use Java v1.8.0_121

[dylanks]

In general, only the even number releases of Node.js are considered to
be stable whereas the odd releases are more experimental and problematic.

Do you have the same issue with the latest 6.x, as I'm certain we've not
tried this out with 7.x.

Regards,
-Dylan

on 2/13/17, 10:11 (GMT-07:00) sindilevich said the following:

> I reworked my POC, using the  Dojo boilerplate project
> <https://github.com/csnover/dojo-boilerplate>   as the POC. I only updated
> it to using Dojo 1.12.1 and added a simple /.cmd/ file to bootstrap the
> build more conveniently.
>
> Thus:
> 1. No /strict mode/ in the POC
> 2. I use /node v7.5.0/
> 3. I removed the /optimizeOptions/ settings, but the same exception was
> thrown, when running the build with Node
> 4. Got rid of the /named declared class/ parameter
> 5. Now, I extend /dijit/Dialog/ instead
> 6. I forgot to mention, I use /Java v1.8.0_121/
>
>
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Dojo-build-via-Node-Closure-Compiler-produces-a-Java-exception-tp4007132p4007135.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.

--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

[sindilevich]

I've just clean-installed the latest LTS node - v6.9.5. Unfortunately, the same exception is present in the build-report.txt file.

[neekfenwick]

On 14/02/17 16:25, sindilevich wrote:
> I've just clean-installed the latest LTS node - v6.9.5. Unfortunately, the
> same exception is present in the /build-report.txt/ file.

I wanted to comment, I hit this exception last night and found that it
was because a couple of stray files were left in my work tree after a
'git checkout' should have removed them (they were new files on a dev
branch and I checked out the main branch, where they did not belong).

Checking my build-report.txt file that the dojo build produces in the
output dir, looking down shortly after the lists of included modules,
those marked as non-AMD yet containing AMD modules, etc. etc., I finally
found this:

error(311) Missing dependency.
     module: win/widget/FilterControls; dependency:
dojo/text!./templates/FilterControls.html; error: Error: text resource
(/home/neek/src/WIN/win_ui/src/win/widget/templates/FilterControls.html)
missing

So I had a .js file (FilterControls.js) which used
'dojo/text!./template/FilterConrtols.html' to bring in its template, but
the .html file was not on disk.  'git checkout' had removed that, but
not the .js file that uses it.  This output appeared 12% of the way
through built-report.txt and was not obvious among the other many warnings

As soon as I removed the errant FilterControls.js and re-built, the Java
exception did not appear much later during the optimisation step.

Maybe this hint will help someone down the road :)
Nick
--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

[jandockxppw]

I'm getting more or less the same exception in a build 36 times

JavaException: java.lang.IllegalArgumentException: Can not set final com.google.javascript.jscomp.CompilerExecutor field com.google.javascript.jscomp.Compiler.compilerExecutor to java.lang.Class
java.lang.IllegalArgumentException: Can not set final com.google.javascript.jscomp.CompilerExecutor field com.google.javascript.jscomp.Compiler.compilerExecutor to java.lang.Class
	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
	at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:58)
	at sun.reflect.UnsafeQualifiedObjectFieldAccessorImpl.get(UnsafeQualifiedObjectFieldAccessorImpl.java:38)
	at java.lang.reflect.Field.get(Field.java:393)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:160)
	at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243)
	at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66)
	at org.mozilla.javascript.gen.c1._c5(Unknown Source)
	at org.mozilla.javascript.gen.c1.call(Unknown Source)
	at org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:108)
	at org.mozilla.javascript.gen.c1._c0(Unknown Source)
	at org.mozilla.javascript.gen.c1.call(Unknown Source)
	at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:401)
	at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3003)
	at org.mozilla.javascript.gen.c1.call(Unknown Source)
	at org.mozilla.javascript.gen.c1.exec(Unknown Source)
	at org.mozilla.javascript.tools.shell.Main.evaluateScript(Main.java:526)
	at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:448)
	at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:414)
	at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:405)
	at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:179)
	at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:100)
	at org.mozilla.javascript.Context.call(Context.java:499)
	at org.mozilla.javascript.ContextFactory.call(ContextFactory.java:511)
	at org.mozilla.javascript.tools.shell.Main.exec(Main.java:162)
	at org.mozilla.javascript.tools.shell.Main.main(Main.java:140)

This is with a large project, where the only difference is whether I use dojo-util 1.11.3, versus 1.12.0, 1.12.1, or 1.12.0. There are no exceptions in the build with 1.11.3, there are exceptions when using the 1.12 branch.

This was while tracking down a very weird error: dojo, dijit and dojox are 1.12.2.

The weird error is: there are no issues with the workings of the build in recent Chrome versions, recent Firefox versions, or recent Safari versions, neither on Mac nor Windows. There only is an on / off problem with the code in an older version of EOPdf, using the Classic engine (which is Webkit 2013.something based), that suggests some race condition.

These Java exceptions during the build are now the main suspect for this weird behaviour. Sadly this is impossible to debug (because of EOPdf issues).

't Would help enormously if I could find out which JS files trigger the exception. I find no reference to the files that trigger the exception in the build-report (which is now 60300 lines long). It ends with

Process finished normally
	errors: 0
	warnings: 173
	build time: 71.558 seconds

The 36 JavaExceptions are not reported as errors.

Is there some way to get more pointers from the builder on where things go south?

I will now take a closer look at the compiler options. The documentation about that is still for 1.10, although there are major changes in this respect in 1.12, so that will be a bit difficult.

[jandockxppw]

Further reporting for the masses:

optimize: “uglify”,
layerOptimize: “uglify”,

gives no JavaExceptions

optimize: “uglify”,
layerOptimize: "closure",

gives 36 JavaExceptions

optimize: “closure”,
layerOptimize: “uglify”,

gives 36 JavaExceptions

optimize: “closure”,
layerOptimize: "closure",

gives 36 JavaExceptions

Can somebody explain why I get the same number of JavaExceptions when I use closure once or twice?

[dylanks]

Hi Jan,

Something seems to have been lost in your previous email.

Regards,
-Dylan

on 5/10/17, 07:15 (GMT-07:00) jandockxppw said the following:

> Further reporting for the masses:
>
>
>
> gives no JavaExceptions
>
>
>
> gives 36 JavaExceptions
>
>
>
> gives 36 JavaExceptions
>
>
>
> gives 36 JavaExceptions
>
> *Can somebody explain why I get the same number of JavaExceptions when I use
> closure once or twice?*
>
>
>
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Dojo-build-via-Node-Closure-Compiler-produces-a-Java-exception-tp4007132p4007277.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.

--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest