RFR: 8150219: ReferenceError in 1.8.0_72

[Sundararajan Athijegannathan]

Sorry, leave my comment on Compilable. CompiledScript does have evals
accepting Bindings, ScriptContext. My comment is applicable to Invocable
though.

-Sundar


On 6/14/2016 8:02 AM, Sundararajan Athijegannathan wrote:
> 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
>>>