RFR 8134941: Implement ES6 template literal support

Andreas Woess andreas.woess at oracle.com
Fri Nov 6 14:33:42 UTC 2015

Hannes, Attila,

thanks for your reviews and sorry for the late reply.

>> Template literals are always scanned as a whole, quote-to-quote (as 
>> with EditStringLexer). This turned out to be a problem with embedded 
>> functions in expressions and lazy/optimistic compilation on: 
>> Parser#skipFunctionBody would skip over the body and restart lexing 
>> at the RBRACE, forgetting about the embedding string context. I've 
>> worked around this in skipFunctionBody by skipping over to the RBRACE 
>> directly if it is already in the token stream (which it is because 
>> we've already scanned to the end quote).
> It took me some time to figure this out. Maybe some more explanatory 
> comments would be good. Does this also apply in other cases?
 From the top of my head I'd say no, because we don't start the lexer at 
arbitrary positions, but only at a brace, and no other case comes to 
mind where we could end up with different tokens here. Yes, some more 
comments wouldn't have hurt. :)
It would probably be good to use the same code for scripting-mode `exec 
strings` which still have this and the quoting issue I mentioned.

> We can probably file the issues as separate bugs and fix them later. 
> One thing I want to do is add some more tests. Although your test 
> script covers a lot of stuff (for its size) I would like to add a bit 
> to it.
Please do!
Regarding caching of template objects: yes, we should follow the spec 
here, I deliberately left that out because I wanted to focus on the 
parser changes.

> I’m sometimes in two minds about RuntimeNode (especially the fact that it currently can’t receive primitive parameters), but I have to admit that in this particular case it made the integration of the feature into the runtime fairly easy; it was really the parser parts that were tricky.
Yes, I like how simple it was to add runtime support with this approach, 
but you can certainly do better. Originally, I thought about adding 
another LiteralNode, but it would've been unnecessary complexity.

- Andreas

More information about the nashorn-dev mailing list