Caching of CompiledScripts and related time zone issues

Martin Hiller Martin.Hiller at
Mon Nov 28 13:56:44 UTC 2016

Hi Sundar,

thank you for your quick response!

One engine per time zone is the strategy we will pursue, as there are indeed many sessions from the same time zone. I wanted to make sure there isn't a trivial obvious solution that I'm overseeing here (e.g., somehow running a CompiledScript in the context of a different engine or similar).

Best regards,

-----Original Message-----
From: nashorn-dev [mailto:nashorn-dev-bounces at] On Behalf Of Sundararajan Athijegannathan
Sent: Monday, November 28, 2016 2:14 PM
To: nashorn-dev at
Subject: Re: Caching of CompiledScripts and related time zone issues

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