Thanks Hannes. I looked at the issue and it answered another question I had as well; I was wondering about the possibility of using a separator other than $ that is legal in Java, but not in JavaScript.
On Thu, May 12, 2016 at 3:08 PM, Hannes Wallnoefer < hannes.wallnoe...@oracle.com> wrote: > Am 2016-05-12 um 23:42 schrieb Vivin Suresh Paliath: > >> Thanks for the explanation Hannes! The issue with $ makes sense; I ran >> into that some time ago - I can't remember the exact situation, but it was >> exactly as you described: the $ introduces ambiguity because it is a valid >> character and so could be part of the name of the original function, and >> not a separator. Would you be able to point me to the location in the >> nashorn source where this mapping/translation is done? It would help me >> learn more about the internals of nashorn. >> > > The method name is created in Parser#createParserContextFunctionNode: > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java#l532 > > The method name for the stack trace is computed in > NashornException#getScriptFrames: > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornException.java#l174 > > I've filed a bug for this: > https://bugs.openjdk.java.net/browse/JDK-8156896 > > Hannes > > >> On Thu, May 12, 2016 at 2:12 PM, Hannes Wallnoefer < >> hannes.wallnoe...@oracle.com <mailto:hannes.wallnoe...@oracle.com>> >> wrote: >> >> Hi Vivin, >> >> What you see is some fuzziness in the translation from JS >> functions to Java methods and from there to the stack traces you see. >> >> When we compile a JS function, we create a Java method with the >> name of the function concatenated to the names of its parent >> functions, using '$' as separator. For anonymous functions we use >> something like L:123 as name where 123 is the line of code where >> the function begins. >> >> This method naming scheme helps a lot in making bytecode easier to >> debug, and to create unique method names within a compilation >> unit. However, it also leads to the stack traces you see, getting >> f$foo in the first case and something like L1:foo in the second >> case, which is rendered as <anonymous> in the stack trace. >> >> Ideally we should reverse this when printing stack traces, >> displaying only the name of the function itself, e.g. "bar" for >> "foo$bar" and "<anonymous>" for "foo$L:3". Unfortunately, "$" is a >> valid character in a JS identifier, so it's not that easy, >> "foo$bar" may also be the name of the original function. >> >> I'm thinking about how to solve this and will probably file an >> issue for it. >> >> Hannes >> >> Am 2016-05-12 um 15:59 schrieb Vivin Suresh Paliath: >> >> I tried this out on in chrome and I get the expected stack >> trace there. Is >> this a bug? >> On May 6, 2016 3:39 PM, "Vivin Suresh Paliath" >> <vivin.pali...@gmail.com <mailto:vivin.pali...@gmail.com>> >> >> wrote: >> >> I have the following code: >> >> *var f = (function() {* >> * return function foo() {* >> * try {* >> * throw new Error();* >> * } catch(e) {* >> * print(e.stack);* >> * }* >> * }* >> *})();* >> >> >> When I call the function, I get the following stacktrace >> as expected >> (mostly; I was expecting *foo* instead of *f$foo*). >> >> *Error* >> * at f$foo (<shell>:1)* >> * at <program> (<shell>:1)* >> >> >> However, if I dynamically construct the function as follows: >> >> *var f = new Function([], "return function foo() { try { >> throw new >> Error(); } catch(e) { print(e.stack); } }")()* >> >> >> I get: >> >> >> *Error* >> * at <anonymous> (<function>:2)* >> * at <program> (<shell>:1)* >> >> >> Is there a reason for this discrepancy? Isn't the second >> version >> effectively the same as the first? Also, why is it *f$foo* >> instead of >> *foo* in the first case? >> >> I am running jdk8u92. >> >> Thanks! >> >> -- >> Ruin untold; >> And thine own sadness, >> Sing in the grass, >> When eve has forgot, that no more hear common things that >> gleam and pass; >> But seek alone to lip, sad Rose of love and ruin untold; >> And thine own mother >> Can know it as I know >> More than another >> What makes your own sadness, >> Set in her eyes. >> >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> i",pack"B32",$_}$j=~m/.{8}/g >> >> >> >> >> >> -- >> *[vivin.net <http://vivin.net>:: github <http://github.com/vivin>:: >> linkedin <https://www.linkedin.com/in/vivin>]* >> > > -- *[vivin.net <http://vivin.net> :: github <http://github.com/vivin> :: linkedin <https://www.linkedin.com/in/vivin>]*
