Re: jdk.nashorn.api.scripting.ScriptUtils.wrap

2015-11-09 Thread Kockert, Timo
Since attachments are automatically removed, I created a repository on GitHub: https://github.com/hzpz/nashorn-examples >Hi Sundar, > >thanks for the quick reply! > > > >I attached a small Maven project with two tests. Both tests work fine with >JDK8u60. Both will fail with JDK8u31, the metho

Re: Review request for JDK-8010803: Number to String conversion functionality overhaul

2015-11-09 Thread Hannes Wallnoefer
Am 2015-11-09 um 12:09 schrieb Attila Szegedi: +1. Reviewed the original over the weekend; quite a heroic effort in porting and adjusting this to Nashorn. Big kudos for having the perseverance to get this done! Thanks. It wasn't quite as bad as it looks. The worst actually was to port some o

Re: Review request for JDK-8141541: Simplify Nashorn's Context class loader handling

2015-11-09 Thread Hannes Wallnoefer
+1 Am 2015-11-05 um 16:30 schrieb Attila Szegedi: Please review JDK-8141541 "Simplify Nashorn's Context class loader handling" at for Thanks, Attila.

Re: Review request for JDK-8141538: Make DynamicLinker specific to a Context in Nashorn

2015-11-09 Thread Hannes Wallnoefer
+1 Could there be a performance impact of having the Context lookup in the bootstrap method? Probably not, but I'm always a bit worried about (possibly repeated) context lookups. Hannes Am 2015-11-05 um 15:09 schrieb Attila Szegedi: Please review JDK-8141538 "Make DynamicLinker specific to

Re: Review request for JDK-8141550: Introduce a command line option instead of nashorn.unstable.relink.threshold system property

2015-11-09 Thread Hannes Wallnoefer
Very nice indeed! +1 Hannes Am 2015-11-09 um 15:29 schrieb Sundararajan Athijegannathan: +1 Nice! -Sundar On 11/9/2015 7:57 PM, Attila Szegedi wrote: Please review JDK-8141550 "Introduce a command line option instead of nashorn.unstable.relink.threshold system property" at

Re: Review request for JDK-8141550: Introduce a command line option instead of nashorn.unstable.relink.threshold system property

2015-11-09 Thread Sundararajan Athijegannathan
+1 Nice! -Sundar On 11/9/2015 7:57 PM, Attila Szegedi wrote: Please review JDK-8141550 "Introduce a command line option instead of nashorn.unstable.relink.threshold system property" at for

Review request for JDK-8141550: Introduce a command line option instead of nashorn.unstable.relink.threshold system property

2015-11-09 Thread Attila Szegedi
Please review JDK-8141550 "Introduce a command line option instead of nashorn.unstable.relink.threshold system property" at for Thanks, Attila.

Re: Review request for JDK-8141538: Make DynamicLinker specific to a Context in Nashorn

2015-11-09 Thread Attila Szegedi
We rely on Context.fromClass(clazz) which for compiled scripts will end up being ((ScriptLoader)clazz.getClassLoader()).getContext(), so not even a ThreadLocal.get() is needed; it should be quite light. Attila. > On Nov 9, 2015, at 12:52 PM, Hannes Wallnoefer > wrote: > > +1 > > Could there

Re: Review request for JDK-8141538: Make DynamicLinker specific to a Context in Nashorn

2015-11-09 Thread Hannes Wallnoefer
Am 2015-11-09 um 13:30 schrieb Attila Szegedi: We rely on Context.fromClass(clazz) which for compiled scripts will end up being ((ScriptLoader)clazz.getClassLoader()).getContext(), so not even a ThreadLocal.get() is needed; it should be quite light. Right. Sounds good then. Hannes Attila.

Re: jdk.nashorn.api.scripting.ScriptUtils.wrap

2015-11-09 Thread Kockert, Timo
Hi Sundar, thanks for the quick reply! I attached a small Maven project with two tests. Both tests work fine with JDK8u60. Both will fail with JDK8u31, the method selection test will also fail with newer JDKs up to JDK8u51. The behavior demonstrated by the mapping test was the reason we used

jdk.nashorn.api.scripting.ScriptUtils.wrap

2015-11-09 Thread Kockert, Timo
Hello everyone, on October 7th, Richard Evans posted to this mailing list (with the same subject as me): "Sometime after jdk1.8u32 this method changed to take an internal jdk.nashorn.internal.runtime.ScriptObject argument. This means that code compiled with 1.8u20 will not work with later rel

Re: Review request for JDK-8010803: Number to String conversion functionality overhaul

2015-11-09 Thread Attila Szegedi
+1. Reviewed the original over the weekend; quite a heroic effort in porting and adjusting this to Nashorn. Big kudos for having the perseverance to get this done! Attila. > On Nov 9, 2015, at 11:17 AM, Hannes Wallnoefer > wrote: > > I uploaded a new webrev with fixed copyright headers (adde

Re: Review request for JDK-8010803: Number to String conversion functionality overhaul

2015-11-09 Thread Hannes Wallnoefer
I uploaded a new webrev with fixed copyright headers (added Oracle GPL headers). Otherwise it is pretty much the same as the first one except for minor changes in comments/formatting. http://cr.openjdk.java.net/~hannesw/8010803/webrev.01/ Hannes Am 2015-11-06 um 13:59 schrieb Hannes Wallnoef

Re: jdk.nashorn.api.scripting.ScriptUtils.wrap

2015-11-09 Thread Sundararajan Athijegannathan
The ScriptUtils methods are supposed to be called only from *scripts* - which the javadoc comments makes it very clear. Why do you call it from Java? When calling from script, the particular static type of method parameters should not make any difference. Besides, when crossing Javascript to j