Caching of CompiledScripts and related time zone issues

Sundararajan Athijegannathan sundararajan.athijegannathan at
Mon Nov 28 13:14:00 UTC 2016

I think you've to go with one engine per timezone (and you could still 
share engines with many sessions - as I'd presume there would many 
sessions in each timezone).

Also, only Date objects (NativeDate instances in nashorn impl.) copy 
timezone from "environment" (per engine object) at the time of object 
creation. It does not seem anyway to avoid this.


On 28/11/16, 4:02 PM, Martin Hiller wrote:
> Hi,
> we are using Nashorn in a web application scenario where currently each session has its own scripting engine. As most of the executed scripts are the same across the different sessions, we actually want to employ a single engine for the whole application and benefit from the common class cache and globally cached CompiledScripts (of course every script would be executed with a separate Global/Bindings).
> However, each session potentially needs to run scripts in its own time zone, which can afaik only be set during engine creation. So it seems to me that one engine per session (or at least one engine per time zone) is the minimum requirement in our scenario, isn't it?
> On the other hand, if we stick to our one-engine-per-session rule, it seems impossible to cache and reuse CompiledScripts on a global level because a CompiledScript is tied to the engine it was created from, and this CompiledScript will therefore always use the time zone of its corresponding engine.
> Is there an easy method or workaround to profit from global caching of compiled scripts in a way that the time zone is retrieved at script runtime and not fixed at engine creation time? Or do you have any other suggestion on how to improve the depicted scenario?
> Thank you for your time!
> Best regards,
> Martin

More information about the nashorn-dev mailing list