That's great to hear, Tal.
The gates for JDK8 are definitely closed, but u20 is scheduled for q3
2014, so you won't have to wait too long. I also think there will be
preview releases available on jdk8.java.net for quite some time before
release.
Thanks for testing and feedback!
Hannes
Am 2
Great work, Hannes!
With the jdk9 version, it seems caching improves performance by two
orders of magnitude. :) And a simple benchmark shows the same code
working twice as fast in Nashorn as compared to Rhino.
This leaves me in a strange position in terms of what to tell my users.
Should I r
Am 2014-03-12 12:44, schrieb Tal Liron:
Hannes, I would like to test this.
It doesn't seem to be on the main Nashorn repository:
http://hg.openjdk.java.net/nashorn/jdk8/nashorn
Is there a separate repository I should be using?
You can get it here:
http://hg.openjdk.java.net/jdk9/dev/nashor
Hannes, I would like to test this.
It doesn't seem to be on the main Nashorn repository:
http://hg.openjdk.java.net/nashorn/jdk8/nashorn
Is there a separate repository I should be using?
On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote:
Hi Tal,
I'm right now pushing a change for JDK-8021350
:03 AM
To: nashorn-dev@openjdk.java.net
Subject: Re: The class cache
Ugh, you're right ...
Well, I do kinda have a hacky solution I could put in: implement my own
PrintWriter wrapper that uses a thread-local.
I think it would be better if stdout and stderr were in Global.
On 03/12/2014 07:
esday, March 12, 2014 6:57 AM
To: nashorn-dev@openjdk.java.net
Subject: Re: The class cache
This architecture is actually still problematic for me.
My specific problem is that I define a different stdout and stderr per
request. Because these are stored in the ScriptEnvironment in the
Context, it mean
on behalf of Tal Liron
Sent: Wednesday, March 12, 2014 6:57 AM
To: nashorn-dev@openjdk.java.net
Subject: Re: The class cache
This architecture is actually still problematic for me.
My specific problem is that I define a different stdout and stderr per
request. Because these are sto
This architecture is actually still problematic for me.
My specific problem is that I define a different stdout and stderr per
request. Because these are stored in the ScriptEnvironment in the
Context, it means I also need a unique Context per request.
Why not make it possible to use Context
To be clear: if I use a single Context for all my uses, then with 8u20
things should automatically work for me?
Is there a timeline for 8u20's release?
On 03/12/2014 06:30 PM, A. Sundararajan wrote:
Actually, the plan is to get to 8u20 - which is an update release
after jdk8 GA.
Script engin
Actually, the plan is to get to 8u20 - which is an update release after
jdk8 GA.
Script engine is associated with a single nashorn Context instance. One
nashorn Context instance may be associated with multiple nashorn Global
instances. The class sharing as of today is per global instance - aft
I did see that change come through, but I thought it was a JDK9
feature... great to know it is for JDK8!
I'll note that I'm not using ScriptEngine, but instead working on the
Scripturian implementation. How will ScriptEngine make sure to reuse the
cache?
Would it be possible to also allow a
Hi Tal,
I'm right now pushing a change for JDK-8021350 that allows sharing
script classes between global scopes. Currently, script classes are
bound to the global object in various ways, so the change is not
trivial, and it's not possible to share compiled scripts between global
scopes with t
In Nashorn, the ClassCache is set per Global instance.
This is fine if your application has only one global instance. However,
my application design involves creating many Global instances.
(Actually, I create and destroy them on the fly per user request in an
HTTP server scenario.) The proble
13 matches
Mail list logo
