Okay, I tracked this down to an incorrect optimization in code generator for when you use >>=0 to coerce to an uint32 :-(
There is a special case for exactly this usage, where the right-hand-side operand is a literal 0, so we avoid emitting a no-op “ICONST_0; IUSHR” bytecode sequence. It unfortunately wasn’t working correctly for when the left-hand-side operand of a compound-assignment-shift-right was either a property or element access expression (either “obj.foo” or “obj[x]”) Decomposing the compound assignment into an explicit shift and assignment would work around the problem for now: this.length = this.length >>> 0; // Coerce to uint32. I filed <https://bugs.openjdk.java.net/browse/JDK-8170594 <https://bugs.openjdk.java.net/browse/JDK-8170594>> and have a fix for it. Attila. > On 01 Dec 2016, at 07:44, Sundararajan Athijegannathan > <sundararajan.athijegannat...@oracle.com> wrote: > > We do not aim to provide complete compatibility with other JS implementations > on the non-standard properties such as "stack". stack tries to mimic whatever > is done for Java code (no column number for eg.). But, as you've noted there > are enough information on Error objects via other properties like lineNumber, > columnNumber, fileName. It should be possible to write a simple utility > function to format stack string as desired for specific applications. > > Thanks, > -Sundar > > On 01/12/16, 3:32 AM, Art Fiedler wrote: >> When making an implementation of console.count([label]) part of the >> Mozilla's developer docs >> https://developer.mozilla.org/en-US/docs/Web/API/Console/count >> mentions when label is omitted, the function will count the number of times >> count() was called >> on that line... however, if the javascript code has been minified all lines >> of code may be on the >> same line... messing up all console.count() calls... >> >> I was providing that implementation by using new Error().stack and parsing >> the current file:line... >> however I could fix the minify issue if new Error().stack output the column >> also for instance... >> other browser seem to be doing file:line:column in the stack trace. >> Including nodejs see: >> https://nodejs.org/api/errors.html#errors_error_stack >> >> Microsoft Edge's dev console outputs... >> new Error().stack: >> "Error >> at eval code (eval code:1:1)" >> Firefox since FF30: >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stack >> >> Currently nashorn error stacks only include the line number... >> public static void main(String[] args) throws Exception { >> NashornScriptEngineFactory factory = new >> NashornScriptEngineFactory(); >> ScriptEngine scriptEngine = factory.getScriptEngine(); >> scriptEngine.put(ScriptEngine.FILENAME, "myfile.js"); >> scriptEngine.eval("print('fileName: ' + new Error().fileName);"); >> scriptEngine.eval("print('lineNumber: ' + new >> Error().lineNumber);"); >> scriptEngine.eval("print('columnNumber: ' + new >> Error().columnNumber);"); >> scriptEngine.eval("print('stack: ' + new Error().stack);"); >> } >> /* >> fileName: myfile.js >> lineNumber: 1 >> columnNumber: -1 >> stack: Error >> at<program> (myfile.js:1) >> */ >> >> Would be nice to add the column number to the stacks and error object in >> nashorn. >> >> Thanks, >> Arthur Fiedler
