RFR: 8150219: ReferenceError in 1.8.0_72

[Sundararajan Athijegannathan]

Sorry, I'm not sure I'm comfortable with this fix :(

Global.setScriptContext sets the ScriptContext for the *current thread*
[because that Global class methods set thread local]. This means that
this ReferenceError goes away only for the thread in a new Global is
created and associated with that ScriptContext. For other threads,
you'll continue to get ReferenceError.

The root of the issue is the Invocable's methods are expected to use the
default ScriptContext. That means that if you eval code or put globals
in  another ScriptContext, you can't do Invocable calls on it! That is
the limitation of javax.script. While eval's have ScriptContext,
Bindings accepting variants, there are no similar methods exists for
Invocable and Compilable. These two use script engine's default
ScriptContext!

BTW, there is clear Nashorn alternative - which is to use
jdk.scripting.api.scripting.ScriptObjectMirror's call or eval method.
These take care of using the right global in which the function was
defined - lexical scoping is respected as expected!

Besides the current "fix" works only the particular thread which feels
wrong as well.

-Sundar

On 6/14/2016 1:04 AM, Attila Szegedi wrote:
> +1
>
>> On 13 Jun 2016, at 18:56, Hannes Wallnöfer <hannes.wallnoefer at oracle.com> wrote:
>>
>> Please review 8150219: ReferenceError in 1.8.0_72:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150219
>> Webrev: http://cr.openjdk.java.net/~hannesw/8150219/webrev.00/
>>
>> This is a bit of a compromise that partially restores the behavior we had before JDK-8138616 by associating a ScriptContext with a Nashorn Global, but only in the very specific case where a script is evaluated with a non-default ScriptContext that does not have a Nashorn Global yet, and the Global is created for that specific ScriptContext. Also, we use the existing setScriptContext method and ThreadLocal field in Global instead of introducing an extra field as we had it before. 
>>
>> The purpose is to make functions obtained from such globals use the ScriptContext they were evaluated with. 
>>
>> Thanks,
>> Hannes
>>