From sundararajan.athijegannathan at oracle.com Tue Jul 1 11:00:50 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 01 Jul 2014 16:30:50 +0530 Subject: RFR 8047359: large string size RangeError should be thrown rather than reporting negative length Message-ID: <53B294E2.8000700@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8047359/ PS. Also contains minor clean-ups to compile nashorn with -Xlint:all option. Thanks -Sundar From hannes.wallnoefer at oracle.com Tue Jul 1 11:14:54 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 01 Jul 2014 13:14:54 +0200 Subject: RFR 8047359: large string size RangeError should be thrown rather than reporting negative length In-Reply-To: <53B294E2.8000700@oracle.com> References: <53B294E2.8000700@oracle.com> Message-ID: <53B2982E.2000409@oracle.com> Looks good. Hannes Am 2014-07-01 13:00, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8047359/ > > PS. Also contains minor clean-ups to compile nashorn with -Xlint:all > option. > > Thanks > -Sundar From sundararajan.athijegannathan at oracle.com Wed Jul 2 05:34:13 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 02 Jul 2014 11:04:13 +0530 Subject: RFR 8043232: Index selection of overloaded java new constructors Message-ID: <53B399D5.6050609@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8043232/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8043232 Thanks, -Sundar From attila.szegedi at oracle.com Wed Jul 2 08:34:58 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 2 Jul 2014 10:34:58 +0200 Subject: RFR 8043232: Index selection of overloaded java new constructors In-Reply-To: <53B399D5.6050609@oracle.com> References: <53B399D5.6050609@oracle.com> Message-ID: <345D1189-A54A-451D-A009-45863FD385FE@oracle.com> Two remarks: 1. in DynamicMethodLinker.java, you could factor out the return new GuardedInvocation(MethodHandles.dropArguments(invocation, 0, desc.getMethodType().parameterType(0)), Guards.getIdentityGuard(receiver)); part that is appearing in both if and else branch to be outside of the if, guarded with if(invocation == null) (maybe adding an assert invocation != null in the constructor (else) branch if it must not be null in that case (as you aren't testing for it being null there). 2. OverloadedDynamicMethod could save the boolean flag by returning methods.getFirst().isConstructor(). Maybe assert in the OverloadedDynamicMethod constructor that all elements of "methods" return the same value for isConstructor(). Other than these, +1. Attila. On Jul 2, 2014, at 7:34 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8043232/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8043232 > > Thanks, > -Sundar From silverlanguage at gmail.com Wed Jul 2 09:21:10 2014 From: silverlanguage at gmail.com (Sia Lang) Date: Wed, 2 Jul 2014 11:21:10 +0200 Subject: Extremely slow startup performance Message-ID: I'm trying to use Nashorn as a plugin framework. However, code like: engine.eval(new BufferedReader(new FileReader("coffee-script.js"))); easily takes 10-15 seconds. V8 uses a few milliseconds (when using jav8 as scriptengine) In my opinion, Nashorn is so slow on startup it's useless (I have tons of plugin scripts, which accumulates to 2-3 minutes of application startup time due to nashorn - with v8 i'm subsecond!) What's going on? Anything I can do to fix this? Lang From benjamin.sieffert at metrigo.de Wed Jul 2 09:39:50 2014 From: benjamin.sieffert at metrigo.de (Benjamin Sieffert) Date: Wed, 2 Jul 2014 11:39:50 +0200 Subject: ArrayIndexOutOfBoundsException and NPE in regexp-Code Message-ID: Hello everyone, we are running jdk8u5 and seeing occasional errors in the nashorn-internal regexp classes. The regex in use is a very simple one that basically is just supposed to do several string matches in a readable manner like /some string|stringtotestfor|test for this string too/ Some sample stacktraces: 1) ArrayIndexOutOfBoundsException: 8 jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.opExactNIC(ByteCodeMachine.java:381):1 in "" jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt(ByteCodeMachine.java:129):1 in "" jdk.nashorn.internal.runtime.regexp.joni.Matcher.matchCheck(Matcher.java:272):1 in "" jdk.nashorn.internal.runtime.regexp.joni.Matcher.search(Matcher.java:405):1 in "" jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher.search(JoniRegExp.java:131):1 in "" jdk.nashorn.internal.objects.NativeRegExp.execInner(NativeRegExp.java:559):1 in "" jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:643):1 in "" jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:322):1 in "" jdk.nashorn.internal.scripts.Script$library$2._L356(library:460):1 in "" 2) NPE jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.opExactN(ByteCodeMachine.java:361):1 in "" jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt(ByteCodeMachine.java:126):1 in "" jdk.nashorn.internal.runtime.regexp.joni.Matcher.matchCheck(Matcher.java:272):1 in "" jdk.nashorn.internal.runtime.regexp.joni.Matcher.search(Matcher.java:405):1 in "" jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher.search(JoniRegExp.java:131):1 in "" jdk.nashorn.internal.objects.NativeRegExp.execInner(NativeRegExp.java:559):1 in "" jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:643):1 in "" jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:322):1 in "" jdk.nashorn.internal.scripts.Script$library$2._L356(library:460):1 in "" Would be nice to get some input on this. Sadly, there I don't have a reliable way to reproduce this right now. Script gets evaluated in a multithreaded environment, so it might have something to do with that. Regards -- Benjamin Sieffert metrigo GmbH Sternstr. 106 20357 Hamburg Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, Martin Rie? Die Gesellschaft ist eingetragen beim Registergericht Hamburg Nr. HRB 120447. From marcus.lagergren at oracle.com Wed Jul 2 10:18:13 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 2 Jul 2014 12:18:13 +0200 Subject: Extremely slow startup performance In-Reply-To: References: Message-ID: <7D0AB559-7A1C-4A97-9CE4-2720AA909C1B@oracle.com> Hi Lang! We are aware of there being a couple of warmup issues in Nashorn. My guess is that ?coffee-script.js? is a fairly large script, Nashorn currently compiles everything to byte code and therefore takes time. In JDK9, the follow changes have already been checked in, that may help you: * Lazy code generation policy on by default - less byte code generation * Class caching - reuse of compiled classes * Persistent code store on disk - basically identical code is never jitted more than once. If you compile identical source code, in these scripts, only the first run would be slow. This might help you out immensely. If you need the first run to go fast, we need to improve general warmup, and we are currently discussing how to do it. It?s on the table. And the following that might make it a little bit worse, until we?ve had more time to property attack the warmup issues. * Optimistic type optimization (may actually increase warmup) These will be backported to 8u40. What version of the JDK/nashorn are you using? Perhaps you could send us a Java Flight Recording of your recording of your slow startup, if you want us to look at it in detail. JFR files are always helpful. Regards Marcus On 02 Jul 2014, at 11:21, Sia Lang wrote: > I'm trying to use Nashorn as a plugin framework. > > However, code like: > > engine.eval(new BufferedReader(new FileReader("coffee-script.js"))); > > easily takes 10-15 seconds. V8 uses a few milliseconds (when using jav8 as > scriptengine) > > In my opinion, Nashorn is so slow on startup it's useless (I have tons of > plugin scripts, which accumulates to 2-3 minutes of application startup > time due to nashorn - with v8 i'm subsecond!) > > What's going on? Anything I can do to fix this? > > Lang From hannes.wallnoefer at oracle.com Wed Jul 2 10:40:19 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 02 Jul 2014 12:40:19 +0200 Subject: RFR 8043232: Index selection of overloaded java new constructors In-Reply-To: <53B399D5.6050609@oracle.com> References: <53B399D5.6050609@oracle.com> Message-ID: <53B3E193.9010201@oracle.com> Looks good. Hannes Am 2014-07-02 07:34, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8043232/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8043232 > > Thanks, > -Sundar From silverlanguage at gmail.com Wed Jul 2 11:00:57 2014 From: silverlanguage at gmail.com (Sia Lang) Date: Wed, 2 Jul 2014 13:00:57 +0200 Subject: Extremely slow startup performance In-Reply-To: <7D0AB559-7A1C-4A97-9CE4-2720AA909C1B@oracle.com> References: <7D0AB559-7A1C-4A97-9CE4-2720AA909C1B@oracle.com> Message-ID: I'm using u5. Note that while coffee-script.js is 204K, v8 swallows it subsecond. Nashorn is very slow on startup even for the smallest of scripts. The proposed caching would likely solve the problem - the initial load time (2-3 minutes), I can count as part of the application installation :) Followup questions: 1) By persistent code store, do you mean that the caching survive process restarts? That would be nice indeed. 2) What's the jit granularity? eval() ? 3) When will u40 be out? :) Lang On Wed, Jul 2, 2014 at 12:18 PM, Marcus Lagergren < marcus.lagergren at oracle.com> wrote: > Hi Lang! > > We are aware of there being a couple of warmup issues in Nashorn. My guess > is that ?coffee-script.js? is a fairly large script, Nashorn currently > compiles everything to byte code and therefore takes time. > > In JDK9, the follow changes have already been checked in, that may help > you: > > * Lazy code generation policy on by default - less byte code generation > * Class caching - reuse of compiled classes > * Persistent code store on disk - basically identical code is never jitted > more than once. If you compile identical source code, in these scripts, > only the first run would be slow. This might help you out immensely. If you > need the first run to go fast, we need to improve general warmup, and we > are currently discussing how to do it. It?s on the table. > > And the following that might make it a little bit worse, until we?ve had > more time to property attack the warmup issues. > > * Optimistic type optimization (may actually increase warmup) > > These will be backported to 8u40. > > What version of the JDK/nashorn are you using? Perhaps you could send us a > Java Flight Recording of your recording of your slow startup, if you want > us to look at it in detail. JFR files are always helpful. > > Regards > Marcus > > On 02 Jul 2014, at 11:21, Sia Lang wrote: > > > I'm trying to use Nashorn as a plugin framework. > > > > However, code like: > > > > engine.eval(new BufferedReader(new FileReader("coffee-script.js"))); > > > > easily takes 10-15 seconds. V8 uses a few milliseconds (when using jav8 > as > > scriptengine) > > > > In my opinion, Nashorn is so slow on startup it's useless (I have tons of > > plugin scripts, which accumulates to 2-3 minutes of application startup > > time due to nashorn - with v8 i'm subsecond!) > > > > What's going on? Anything I can do to fix this? > > > > Lang > > From james.laskey at oracle.com Wed Jul 2 11:05:45 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 2 Jul 2014 08:05:45 -0300 Subject: ArrayIndexOutOfBoundsException and NPE in regexp-Code In-Reply-To: References: Message-ID: Benjamin, We've run into a few cases where Joni (regex) is not safe across threads. This has been fixed in 8u20 http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/9ad26ed8cc97 . The workaround is to use new RegExp("...") so that the regexp is not shared. If you are iterating through a loop, hoist the expression outside the loop. Cheers, -- Jim On Jul 2, 2014, at 6:39 AM, Benjamin Sieffert wrote: > Hello everyone, > > we are running jdk8u5 and seeing occasional errors in the nashorn-internal > regexp classes. > The regex in use is a very simple one that basically is just supposed to do > several string matches in a readable manner like /some > string|stringtotestfor|test for this string too/ > > Some sample stacktraces: > > 1) ArrayIndexOutOfBoundsException: 8 > > jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.opExactNIC(ByteCodeMachine.java:381):1 > in "" > > jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt(ByteCodeMachine.java:129):1 > in "" > > jdk.nashorn.internal.runtime.regexp.joni.Matcher.matchCheck(Matcher.java:272):1 > in "" > > jdk.nashorn.internal.runtime.regexp.joni.Matcher.search(Matcher.java:405):1 > in "" > > jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher.search(JoniRegExp.java:131):1 > in "" > > jdk.nashorn.internal.objects.NativeRegExp.execInner(NativeRegExp.java:559):1 > in "" > > jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:643):1 in > "" > > jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:322):1 in > "" > > jdk.nashorn.internal.scripts.Script$library$2._L356(library:460):1 in "" > > 2) NPE > > jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.opExactN(ByteCodeMachine.java:361):1 > in "" > > jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt(ByteCodeMachine.java:126):1 > in "" > > jdk.nashorn.internal.runtime.regexp.joni.Matcher.matchCheck(Matcher.java:272):1 > in "" > > jdk.nashorn.internal.runtime.regexp.joni.Matcher.search(Matcher.java:405):1 > in "" > > jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher.search(JoniRegExp.java:131):1 > in "" > > jdk.nashorn.internal.objects.NativeRegExp.execInner(NativeRegExp.java:559):1 > in "" > > jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:643):1 in > "" > > jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:322):1 in > "" > > jdk.nashorn.internal.scripts.Script$library$2._L356(library:460):1 in "" > > Would be nice to get some input on this. Sadly, there I don't have a > reliable way to reproduce this > right now. Script gets evaluated in a multithreaded environment, so it > might have something to do with that. > > Regards > > -- > Benjamin Sieffert > metrigo GmbH > Sternstr. 106 > 20357 Hamburg > > Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, > Martin Rie? > Die Gesellschaft ist eingetragen beim Registergericht Hamburg > Nr. HRB 120447. From benjamin.sieffert at metrigo.de Wed Jul 2 11:12:01 2014 From: benjamin.sieffert at metrigo.de (Benjamin Sieffert) Date: Wed, 2 Jul 2014 13:12:01 +0200 Subject: ArrayIndexOutOfBoundsException and NPE in regexp-Code In-Reply-To: References: Message-ID: Thank you, glad to hear it had already been tracked down and fixed. We're gonna use the workaround until the release of update 20 then. 2014-07-02 13:05 GMT+02:00 Jim Laskey (Oracle) : > Benjamin, > > We've run into a few cases where Joni (regex) is not safe across threads. > This has been fixed in 8u20 > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/9ad26ed8cc97 . > The workaround is to use new RegExp("...") so that the regexp is not > shared. If you are iterating through a loop, hoist the expression outside > the loop. > > Cheers, > > -- Jim > > > > > > On Jul 2, 2014, at 6:39 AM, Benjamin Sieffert < > benjamin.sieffert at metrigo.de> wrote: > > > Hello everyone, > > > > we are running jdk8u5 and seeing occasional errors in the > nashorn-internal > > regexp classes. > > The regex in use is a very simple one that basically is just supposed to > do > > several string matches in a readable manner like /some > > string|stringtotestfor|test for this string too/ > > > > Some sample stacktraces: > > > > 1) ArrayIndexOutOfBoundsException: 8 > > > > > jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.opExactNIC(ByteCodeMachine.java:381):1 > > in "" > > > > > jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt(ByteCodeMachine.java:129):1 > > in "" > > > > > jdk.nashorn.internal.runtime.regexp.joni.Matcher.matchCheck(Matcher.java:272):1 > > in "" > > > > > jdk.nashorn.internal.runtime.regexp.joni.Matcher.search(Matcher.java:405):1 > > in "" > > > > > jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher.search(JoniRegExp.java:131):1 > > in "" > > > > > jdk.nashorn.internal.objects.NativeRegExp.execInner(NativeRegExp.java:559):1 > > in "" > > > > jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:643):1 > in > > "" > > > > jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:322):1 > in > > "" > > > > jdk.nashorn.internal.scripts.Script$library$2._L356(library:460):1 in "" > > > > 2) NPE > > > > > jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.opExactN(ByteCodeMachine.java:361):1 > > in "" > > > > > jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt(ByteCodeMachine.java:126):1 > > in "" > > > > > jdk.nashorn.internal.runtime.regexp.joni.Matcher.matchCheck(Matcher.java:272):1 > > in "" > > > > > jdk.nashorn.internal.runtime.regexp.joni.Matcher.search(Matcher.java:405):1 > > in "" > > > > > jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher.search(JoniRegExp.java:131):1 > > in "" > > > > > jdk.nashorn.internal.objects.NativeRegExp.execInner(NativeRegExp.java:559):1 > > in "" > > > > jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:643):1 > in > > "" > > > > jdk.nashorn.internal.objects.NativeRegExp.test(NativeRegExp.java:322):1 > in > > "" > > > > jdk.nashorn.internal.scripts.Script$library$2._L356(library:460):1 in "" > > > > Would be nice to get some input on this. Sadly, there I don't have a > > reliable way to reproduce this > > right now. Script gets evaluated in a multithreaded environment, so it > > might have something to do with that. > > > > Regards > > > > -- > > Benjamin Sieffert > > metrigo GmbH > > Sternstr. 106 > > 20357 Hamburg > > > > Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, > > Martin Rie? > > Die Gesellschaft ist eingetragen beim Registergericht Hamburg > > Nr. HRB 120447. > > -- Benjamin Sieffert metrigo GmbH Sternstr. 106 20357 Hamburg Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, Martin Rie? Die Gesellschaft ist eingetragen beim Registergericht Hamburg Nr. HRB 120447. From marcus.lagergren at oracle.com Wed Jul 2 12:01:50 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 2 Jul 2014 14:01:50 +0200 Subject: Extremely slow startup performance In-Reply-To: References: <7D0AB559-7A1C-4A97-9CE4-2720AA909C1B@oracle.com> Message-ID: > > 1) By persistent code store, do you mean that the caching survive process restarts? That would be nice indeed. > Yes I do. It will definitely survive restarts - including optimizations done and type assumptions (which will contribute to a warmup the first time too). These need not be done again. Attila - do you have anything to add here? Is it on be default. You can sync out the latest jdk9 repo and test it yourself. > 2) What's the jit granularity? eval() ? > We do read an entire script at once, but we don?t necessarily compile all of it (we do in 8u5 still, I think). With the lazy compilation policy we only compile the methods that we need in order to run the script when we encounter them. Sometimes it matters, sometimes it doesn?t. > 3) When will u40 be out? :) New years, I think. Check with the official lists. Poor man?s instrumentation; With 8u5 you can do -Dnashorn.time to get a system hook where the process spends its time. With 9 it?s ?log=time. Or send us a JFR recording. I would say that what you are looking at here is the pre-8u40 behavior of JITting the entire script. Likely you are going to see code generation. Besides all that, if you need speed on ?run 0? you?d need are further warmup improvements, which are not yet scheduled for a release. > > Lang > > > On Wed, Jul 2, 2014 at 12:18 PM, Marcus Lagergren wrote: > Hi Lang! > > We are aware of there being a couple of warmup issues in Nashorn. My guess is that ?coffee-script.js? is a fairly large script, Nashorn currently compiles everything to byte code and therefore takes time. > > In JDK9, the follow changes have already been checked in, that may help you: > > * Lazy code generation policy on by default - less byte code generation > * Class caching - reuse of compiled classes > * Persistent code store on disk - basically identical code is never jitted more than once. If you compile identical source code, in these scripts, only the first run would be slow. This might help you out immensely. If you need the first run to go fast, we need to improve general warmup, and we are currently discussing how to do it. It?s on the table. > > And the following that might make it a little bit worse, until we?ve had more time to property attack the warmup issues. > > * Optimistic type optimization (may actually increase warmup) > > These will be backported to 8u40. > > What version of the JDK/nashorn are you using? Perhaps you could send us a Java Flight Recording of your recording of your slow startup, if you want us to look at it in detail. JFR files are always helpful. > > Regards > Marcus > > On 02 Jul 2014, at 11:21, Sia Lang wrote: > > > I'm trying to use Nashorn as a plugin framework. > > > > However, code like: > > > > engine.eval(new BufferedReader(new FileReader("coffee-script.js"))); > > > > easily takes 10-15 seconds. V8 uses a few milliseconds (when using jav8 as > > scriptengine) > > > > In my opinion, Nashorn is so slow on startup it's useless (I have tons of > > plugin scripts, which accumulates to 2-3 minutes of application startup > > time due to nashorn - with v8 i'm subsecond!) > > > > What's going on? Anything I can do to fix this? > > > > Lang > > From sundararajan.athijegannathan at oracle.com Wed Jul 2 12:16:20 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 02 Jul 2014 17:46:20 +0530 Subject: RFR 8043232: Index selection of overloaded java new constructors In-Reply-To: <345D1189-A54A-451D-A009-45863FD385FE@oracle.com> References: <53B399D5.6050609@oracle.com> <345D1189-A54A-451D-A009-45863FD385FE@oracle.com> Message-ID: <53B3F814.8010700@oracle.com> Updated review at http://cr.openjdk.java.net/~sundar/8043232/webrev.01/ Please review Thanks -Sundar On Wednesday 02 July 2014 02:04 PM, Attila Szegedi wrote: > Two remarks: > > 1. in DynamicMethodLinker.java, you could factor out the > > return new GuardedInvocation(MethodHandles.dropArguments(invocation, 0, > desc.getMethodType().parameterType(0)), Guards.getIdentityGuard(receiver)); > > part that is appearing in both if and else branch to be outside of the if, guarded with if(invocation == null) (maybe adding an assert invocation != null in the constructor (else) branch if it must not be null in that case (as you aren't testing for it being null there). > > 2. OverloadedDynamicMethod could save the boolean flag by returning methods.getFirst().isConstructor(). Maybe assert in the OverloadedDynamicMethod constructor that all elements of "methods" return the same value for isConstructor(). > > Other than these, +1. > > Attila. > > On Jul 2, 2014, at 7:34 AM, A. Sundararajan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8043232/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8043232 >> >> Thanks, >> -Sundar From james.laskey at oracle.com Wed Jul 2 14:10:22 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 2 Jul 2014 11:10:22 -0300 Subject: RFR 8043232: Index selection of overloaded java new constructors In-Reply-To: <53B3F814.8010700@oracle.com> References: <53B399D5.6050609@oracle.com> <345D1189-A54A-451D-A009-45863FD385FE@oracle.com> <53B3F814.8010700@oracle.com> Message-ID: <61F92704-6F5B-4E85-92C5-6678ED52E7DC@oracle.com> +1 On Jul 2, 2014, at 9:16 AM, A. Sundararajan wrote: > Updated review at http://cr.openjdk.java.net/~sundar/8043232/webrev.01/ > > Please review > > Thanks > -Sundar > > On Wednesday 02 July 2014 02:04 PM, Attila Szegedi wrote: >> Two remarks: >> >> 1. in DynamicMethodLinker.java, you could factor out the >> >> return new GuardedInvocation(MethodHandles.dropArguments(invocation, 0, >> desc.getMethodType().parameterType(0)), Guards.getIdentityGuard(receiver)); >> >> part that is appearing in both if and else branch to be outside of the if, guarded with if(invocation == null) (maybe adding an assert invocation != null in the constructor (else) branch if it must not be null in that case (as you aren't testing for it being null there). >> >> 2. OverloadedDynamicMethod could save the boolean flag by returning methods.getFirst().isConstructor(). Maybe assert in the OverloadedDynamicMethod constructor that all elements of "methods" return the same value for isConstructor(). >> >> Other than these, +1. >> >> Attila. >> >> On Jul 2, 2014, at 7:34 AM, A. Sundararajan wrote: >> >>> Please review http://cr.openjdk.java.net/~sundar/8043232/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8043232 >>> >>> Thanks, >>> -Sundar > From silverlanguage at gmail.com Wed Jul 2 18:48:50 2014 From: silverlanguage at gmail.com (Sia Lang) Date: Wed, 2 Jul 2014 20:48:50 +0200 Subject: Extremely slow startup performance In-Reply-To: References: <7D0AB559-7A1C-4A97-9CE4-2720AA909C1B@oracle.com> Message-ID: I'm reluctant to try building jdk9 on my Windows machine :) When will an early access build with class caching reach https://jdk9.java.net/download/ ? Thanks! On Wed, Jul 2, 2014 at 2:01 PM, Marcus Lagergren < marcus.lagergren at oracle.com> wrote: > > 1) By persistent code store, do you mean that the caching survive process > restarts? That would be nice indeed. > > Yes I do. It will definitely survive restarts - including optimizations > done and type assumptions (which will contribute to a warmup the first time > too). These need not be done again. Attila - do you have anything to add > here? Is it on be default. You can sync out the latest jdk9 repo and test > it yourself. > > 2) What's the jit granularity? eval() ? > > We do read an entire script at once, but we don?t necessarily compile all > of it (we do in 8u5 still, I think). With the lazy compilation policy we > only compile the methods that we need in order to run the script when we > encounter them. Sometimes it matters, sometimes it doesn?t. > > 3) When will u40 be out? :) > > > New years, I think. Check with the official lists. > > Poor man?s instrumentation; With 8u5 you can do -Dnashorn.time to get a > system hook where the process spends its time. With 9 it?s ?log=time. > Or send us a JFR recording. I would say that what you are looking at here > is the pre-8u40 behavior of JITting the entire script. Likely you are going > to > see code generation. > > Besides all that, if you need speed on ?run 0? you?d need are further > warmup improvements, which are not yet scheduled for a release. > > > Lang > > > On Wed, Jul 2, 2014 at 12:18 PM, Marcus Lagergren < > marcus.lagergren at oracle.com> wrote: > >> Hi Lang! >> >> We are aware of there being a couple of warmup issues in Nashorn. My >> guess is that ?coffee-script.js? is a fairly large script, Nashorn >> currently compiles everything to byte code and therefore takes time. >> >> In JDK9, the follow changes have already been checked in, that may help >> you: >> >> * Lazy code generation policy on by default - less byte code generation >> * Class caching - reuse of compiled classes >> * Persistent code store on disk - basically identical code is never >> jitted more than once. If you compile identical source code, in these >> scripts, only the first run would be slow. This might help you out >> immensely. If you need the first run to go fast, we need to improve general >> warmup, and we are currently discussing how to do it. It?s on the table. >> >> And the following that might make it a little bit worse, until we?ve had >> more time to property attack the warmup issues. >> >> * Optimistic type optimization (may actually increase warmup) >> >> These will be backported to 8u40. >> >> What version of the JDK/nashorn are you using? Perhaps you could send us >> a Java Flight Recording of your recording of your slow startup, if you want >> us to look at it in detail. JFR files are always helpful. >> >> Regards >> Marcus >> >> On 02 Jul 2014, at 11:21, Sia Lang wrote: >> >> > I'm trying to use Nashorn as a plugin framework. >> > >> > However, code like: >> > >> > engine.eval(new BufferedReader(new FileReader("coffee-script.js"))); >> > >> > easily takes 10-15 seconds. V8 uses a few milliseconds (when using jav8 >> as >> > scriptengine) >> > >> > In my opinion, Nashorn is so slow on startup it's useless (I have tons >> of >> > plugin scripts, which accumulates to 2-3 minutes of application startup >> > time due to nashorn - with v8 i'm subsecond!) >> > >> > What's going on? Anything I can do to fix this? >> > >> > Lang >> >> > > From ecki at zusammenkunft.net Wed Jul 2 21:24:41 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 2 Jul 2014 23:24:41 +0200 Subject: Extremely slow startup performance In-Reply-To: References: Message-ID: <20140702232441.00005aa2.ecki@zusammenkunft.net> I am curious, is this time with or without starting the JVM? (as V8 is a native engine which especially for startup time is unbeatable. Gruss Bernd Am Wed, 2 Jul 2014 11:21:10 +0200 schrieb Sia Lang : > I'm trying to use Nashorn as a plugin framework. > > However, code like: > > engine.eval(new BufferedReader(new > FileReader("coffee-script.js"))); > > easily takes 10-15 seconds. V8 uses a few milliseconds (when using > jav8 as scriptengine) > > In my opinion, Nashorn is so slow on startup it's useless (I have > tons of plugin scripts, which accumulates to 2-3 minutes of > application startup time due to nashorn - with v8 i'm subsecond!) > > What's going on? Anything I can do to fix this? > > Lang From attila.szegedi at oracle.com Thu Jul 3 09:03:35 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 3 Jul 2014 11:03:35 +0200 Subject: Review request for JDK-8048858 Message-ID: Please review JDK-8048858 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Thu Jul 3 09:16:25 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 03 Jul 2014 11:16:25 +0200 Subject: Review request for JDK-8048858 In-Reply-To: References: Message-ID: <53B51F69.9010908@oracle.com> +1 Am 2014-07-03 11:03, schrieb Attila Szegedi: > Please review JDK-8048858 at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Jul 3 09:17:06 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 03 Jul 2014 14:47:06 +0530 Subject: Review request for JDK-8048858 In-Reply-To: References: Message-ID: <53B51F92.1000301@oracle.com> +1 On Thursday 03 July 2014 02:33 PM, Attila Szegedi wrote: > Please review JDK-8048858 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Thu Jul 3 09:50:30 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 3 Jul 2014 11:50:30 +0200 Subject: Review request for JDK-8048858 In-Reply-To: References: Message-ID: <4D8AB84A-B898-48B6-A4E5-2DED5FCA2FC0@oracle.com> +1 On 03 Jul 2014, at 11:03, Attila Szegedi wrote: > Please review JDK-8048858 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Thu Jul 3 12:51:05 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 3 Jul 2014 14:51:05 +0200 Subject: Review request for JDK-8047331 Message-ID: <064528E1-A79B-4520-9C10-6B4D719ACF90@oracle.com> Please review JDK-8047331 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Thu Jul 3 13:53:11 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 03 Jul 2014 15:53:11 +0200 Subject: Review request for JDK-8047331 In-Reply-To: <064528E1-A79B-4520-9C10-6B4D719ACF90@oracle.com> References: <064528E1-A79B-4520-9C10-6B4D719ACF90@oracle.com> Message-ID: <53B56047.8050705@oracle.com> I find the lOptimismInfo and effOptimismInfo variable names to be not very self-explanatory. Apart from that +1. Hannes Am 2014-07-03 14:51, schrieb Attila Szegedi: > Please review JDK-8047331 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Thu Jul 3 14:06:30 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 3 Jul 2014 16:06:30 +0200 Subject: Review request for JDK-8047166 Message-ID: <98B697A9-25FB-40E5-9D86-889512B2996E@oracle.com> Please review JDK-8047166 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Thu Jul 3 14:18:34 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 03 Jul 2014 16:18:34 +0200 Subject: Review request for JDK-8047166 In-Reply-To: <98B697A9-25FB-40E5-9D86-889512B2996E@oracle.com> References: <98B697A9-25FB-40E5-9D86-889512B2996E@oracle.com> Message-ID: <53B5663A.3000800@oracle.com> +1 Am 2014-07-03 16:06, schrieb Attila Szegedi: > Please review JDK-8047166 at for > > Thanks, > Attila. From james.laskey at oracle.com Thu Jul 3 14:32:36 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 3 Jul 2014 11:32:36 -0300 Subject: Review request for JDK-8047166 In-Reply-To: <98B697A9-25FB-40E5-9D86-889512B2996E@oracle.com> References: <98B697A9-25FB-40E5-9D86-889512B2996E@oracle.com> Message-ID: +1 On Jul 3, 2014, at 11:06 AM, Attila Szegedi wrote: > Please review JDK-8047166 at for > > Thanks, > Attila. From james.laskey at oracle.com Thu Jul 3 15:11:15 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 3 Jul 2014 12:11:15 -0300 Subject: Review request for JDK-8047331 In-Reply-To: <064528E1-A79B-4520-9C10-6B4D719ACF90@oracle.com> References: <064528E1-A79B-4520-9C10-6B4D719ACF90@oracle.com> Message-ID: <5D823BF3-C9F9-4323-B433-CD1EA99FDA42@oracle.com> +1 On Jul 3, 2014, at 9:51 AM, Attila Szegedi wrote: > Please review JDK-8047331 at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Jul 3 16:25:10 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 03 Jul 2014 21:55:10 +0530 Subject: RFR 8049242: Explicit constructor overload selection should work with StaticClass as well Message-ID: <53B583E6.4080204@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8049242/ for https://bugs.openjdk.java.net/browse/JDK-8049242 Thanks -Sundar From james.laskey at oracle.com Thu Jul 3 16:59:21 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 3 Jul 2014 13:59:21 -0300 Subject: RFR 8049242: Explicit constructor overload selection should work with StaticClass as well In-Reply-To: <53B583E6.4080204@oracle.com> References: <53B583E6.4080204@oracle.com> Message-ID: <5B5ABEF9-7519-4D32-971B-35D0300858E5@oracle.com> +1 On Jul 3, 2014, at 1:25 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8049242/ for https://bugs.openjdk.java.net/browse/JDK-8049242 > > Thanks > -Sundar From attila.szegedi at oracle.com Thu Jul 3 17:03:31 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 3 Jul 2014 19:03:31 +0200 Subject: RFR 8049242: Explicit constructor overload selection should work with StaticClass as well In-Reply-To: <53B583E6.4080204@oracle.com> References: <53B583E6.4080204@oracle.com> Message-ID: <2E8C2455-0346-49B3-9C46-618820E8DFC7@oracle.com> +1 On Jul 3, 2014, at 6:25 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8049242/ for https://bugs.openjdk.java.net/browse/JDK-8049242 > > Thanks > -Sundar From sundararajan.athijegannathan at oracle.com Fri Jul 4 05:04:27 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 04 Jul 2014 10:34:27 +0530 Subject: RFR 8049086: Minor API convenience functions on "Java" object Message-ID: <53B635DB.6090205@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8049086/ for https://bugs.openjdk.java.net/browse/JDK-8049086 Thanks, -Sundar From attila.szegedi at oracle.com Fri Jul 4 07:02:42 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 4 Jul 2014 09:02:42 +0200 Subject: Review request for JDK-8047067 Message-ID: <254A7A4C-82A5-46F6-8B6E-336A9911E93B@oracle.com> Please review JDK-8047067 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Fri Jul 4 07:53:01 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 04 Jul 2014 09:53:01 +0200 Subject: RFR 8049086: Minor API convenience functions on "Java" object In-Reply-To: <53B635DB.6090205@oracle.com> References: <53B635DB.6090205@oracle.com> Message-ID: <53B65D5D.9090007@oracle.com> +1 Am 2014-07-04 07:04, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8049086/ for > https://bugs.openjdk.java.net/browse/JDK-8049086 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Fri Jul 4 12:09:35 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 04 Jul 2014 17:39:35 +0530 Subject: RFR 8044760: Avoid PropertyMap duplicate for global instances Message-ID: <53B6997F.8040005@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8044760/ for https://bugs.openjdk.java.net/browse/JDK-8044760 Thanks -Sundar From sundararajan.athijegannathan at oracle.com Fri Jul 4 12:28:21 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 04 Jul 2014 17:58:21 +0530 Subject: Review request for JDK-8047067 In-Reply-To: <254A7A4C-82A5-46F6-8B6E-336A9911E93B@oracle.com> References: <254A7A4C-82A5-46F6-8B6E-336A9911E93B@oracle.com> Message-ID: <53B69DE5.9080207@oracle.com> Please uncomment test line(s) in JDK-8047057.js as well (regression test for umbrella bug) +1 -Sundar On Friday 04 July 2014 12:32 PM, Attila Szegedi wrote: > Please review JDK-8047067 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Fri Jul 4 13:04:37 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 4 Jul 2014 15:04:37 +0200 Subject: Review request for JDK-8047067 In-Reply-To: <254A7A4C-82A5-46F6-8B6E-336A9911E93B@oracle.com> References: <254A7A4C-82A5-46F6-8B6E-336A9911E93B@oracle.com> Message-ID: <2EBD4AEC-E8AC-422A-A1BC-2F26A448BD52@oracle.com> +1. This actually got easier to read and make less architectural noise. I think we can integrate the eval diamonds into the upcoming optimistic native method framework later, but this will do very nicely for now. /M On 04 Jul 2014, at 09:02, Attila Szegedi wrote: > Please review JDK-8047067 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Fri Jul 4 13:05:48 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 4 Jul 2014 15:05:48 +0200 Subject: RFR 8049086: Minor API convenience functions on "Java" object In-Reply-To: <53B635DB.6090205@oracle.com> References: <53B635DB.6090205@oracle.com> Message-ID: +1 On 04 Jul 2014, at 07:04, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8049086/ for https://bugs.openjdk.java.net/browse/JDK-8049086 > > Thanks, > -Sundar From rajmahendra at gmail.com Fri Jul 4 16:28:42 2014 From: rajmahendra at gmail.com (rajmahendra at gmail.com) Date: Fri, 4 Jul 2014 21:58:42 +0530 Subject: NashornFX framework Message-ID: Hi i and some of my friends from JUG Chennai/Hyderabad India plan to start a project codename Gainda (Hindi name for Rhino) https://github.com/rajmahendra/gainda the prototype look like this load('./dist/gainda.js'); Gainda.run([ 'base', 'graphics', 'controls' ], function (stage) { var button = new Button(); var root = new StackPane(); stage.title = "Hello World!"; button.text = "Say 'Hello World'"; button.onAction = function() print("Hello World!"); root.children.add(button); stage.scene = new Scene(root, 300, 250); stage.show(); }); Still miles to go.... -- Thank you and regards, Rajmahendra (*Raj*) JUG Chennai Founder JUG Hyderabad Lead http://about.me/rajonjava/ http://www.twitter.com/rajonjava ---------------------------------------------------------------------------------------------- "DREAM is not what you see in sleep; is the thing which does not let you sleep" - APJ Abdul Kalam Do the difficult things while they are easy and do the great things while they are small. A journey of a thousand miles must begin with a single step. - Lao Tzu From sundararajan.athijegannathan at oracle.com Tue Jul 8 08:51:08 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Jul 2014 14:21:08 +0530 Subject: RFR 8049524: Global object initialization via javax.script API should be minimal Message-ID: <53BBB0FC.7060007@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8049524/ for https://bugs.openjdk.java.net/browse/JDK-8049524 Thanks -Sundar From rieberandreas at gmail.com Tue Jul 8 09:22:21 2014 From: rieberandreas at gmail.com (Andreas Rieber) Date: Tue, 08 Jul 2014 11:22:21 +0200 Subject: RFR 8049524: Global object initialization via javax.script API should be minimal In-Reply-To: <53BBB0FC.7060007@oracle.com> References: <53BBB0FC.7060007@oracle.com> Message-ID: <53BBB84D.6080705@gmail.com> Hi Sundar, this change would break jrunscript and so on as you removed printf and sprintf. So looks like something is missing. Andreas On 08.07.2014 10:51, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8049524/ for > https://bugs.openjdk.java.net/browse/JDK-8049524 > > Thanks > -Sundar From timvolpe at gmail.com Wed Jul 9 15:02:59 2014 From: timvolpe at gmail.com (Tim Fox) Date: Wed, 09 Jul 2014 16:02:59 +0100 Subject: Providing "script name" to eval Message-ID: <53BD59A3.2060107@gmail.com> Hi folks, I am using Nashorn to execute a piece of JavaScript using eval: String str = loadFileFromClasspath(scriptName); engine.eval(str); If there's an error in the script, I get an error message something like this: ReferenceError: "blah" is not defined in at line number 1245242 Is there any way informing the engine of the "script name" when running the eval so it provides nicer error messages like this: ReferenceError: "blah" is not defined in myscript.js at line number 1245242 Which is much nicer for the user. (As a last resort I can catch any exceptions and replace with scriptName then rethrow them, but it would be nice if the engine could do this for me) From timvolpe at gmail.com Wed Jul 9 16:15:38 2014 From: timvolpe at gmail.com (Tim Fox) Date: Wed, 09 Jul 2014 17:15:38 +0100 Subject: Automatic type conversions: Passing char from Java to JS Message-ID: <53BD6AAA.70700@gmail.com> Hi, I've noticed that if I pass a java.lang.Character from Java to JS (e.g. via a JavaScript callback handler that is called from Java), then it is converted to a JavaScript object not a string. I.e. someJavaObject.setHandler(function(char) { console.log(typeof char); }); Then in the Java object: class MyJavaClass { public void setHandler(Consumer handler) { handler.accept('X'); } } The following is logged: object If I instead pass a java.lang.String from Java to JS, it is converted to JS string as I would expect. Intuitively I would expect a java.lang.Character to be converted to a JS string too. Is the current Nashorn behaviour as expected? Cheers From james.laskey at oracle.com Thu Jul 10 00:14:43 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 9 Jul 2014 21:14:43 -0300 Subject: Automatic type conversions: Passing char from Java to JS In-Reply-To: <53BD6AAA.70700@gmail.com> References: <53BD6AAA.70700@gmail.com> Message-ID: It is. There is no char type in JS, so it is treated like other POJOs. You have to explicitly char.toString(); or String(char). Auto conversion would be simple to implement but you would lose the functionality of Character; jjs> var c = new java.lang.Character('z'); jjs> c.compareTo(c); 0 Cheers, -- Jim On Jul 9, 2014, at 1:15 PM, Tim Fox wrote: > Hi, > > I've noticed that if I pass a java.lang.Character from Java to JS (e.g. via a JavaScript callback handler that is called from Java), then it is converted to a JavaScript object not a string. > > I.e. > > someJavaObject.setHandler(function(char) { > console.log(typeof char); > }); > > Then in the Java object: > > class MyJavaClass { > > public void setHandler(Consumer handler) { > handler.accept('X'); > } > > } > > The following is logged: > > object > > If I instead pass a java.lang.String from Java to JS, it is converted to JS string as I would expect. > > Intuitively I would expect a java.lang.Character to be converted to a JS string too. > > Is the current Nashorn behaviour as expected? > > Cheers > > From sundararajan.athijegannathan at oracle.com Thu Jul 10 03:16:06 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Jul 2014 08:46:06 +0530 Subject: Providing "script name" to eval In-Reply-To: <53BD59A3.2060107@gmail.com> References: <53BD59A3.2060107@gmail.com> Message-ID: <53BE0576.7080002@oracle.com> Hi, You can file name using ScriptEngine.FILENAME (http://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngine.html) property to associate script "file" name with a eval-ed script. import javax.script.*; public class Main { public static void main(String[] args) throws Exception { ScriptEngineManager m = new ScriptEngineManager(); ScriptEngine e = m.getEngineByName("nashorn"); e.put(ScriptEngine.FILENAME, "file.js"); e.eval("foo"); } } With that Nashorn will associate provided scriptName for that script. You can use "load" function as well to load a named script from a script object. import javax.script.*; public class Main { public static void main(String[] args) throws Exception { ScriptEngineManager m = new ScriptEngineManager(); ScriptEngine e = m.getEngineByName("nashorn"); e.put("scriptName", "file.js"); e.put("script", "foo"); e.eval("load({ script: script, name: scriptName })"); } } You can also use "eval naming" (See http://bugs.java.com/view_bug.do?bug_id=8032068) with jdk8u20+ and the example below: import javax.script.*; public class Main { public static void main(String[] args) throws Exception { ScriptEngineManager m = new ScriptEngineManager(); ScriptEngine e = m.getEngineByName("nashorn"); // older form of the directive //@ sourceURL works too. e.eval("//# sourceURL=myscript.js\nfoo"); } } Hope this helps. -Sundar On Wednesday 09 July 2014 08:32 PM, Tim Fox wrote: > Hi folks, > > I am using Nashorn to execute a piece of JavaScript using eval: > > String str = loadFileFromClasspath(scriptName); > > engine.eval(str); > > If there's an error in the script, I get an error message something > like this: > > ReferenceError: "blah" is not defined in at line number 1245242 > > Is there any way informing the engine of the "script name" when > running the eval so it provides nicer error messages like this: > > ReferenceError: "blah" is not defined in myscript.js at line number > 1245242 > > Which is much nicer for the user. > > (As a last resort I can catch any exceptions and replace with > scriptName then rethrow them, but it would be nice if the engine could > do this for me) > > From rod.nim at outlook.com Fri Jul 11 07:10:51 2014 From: rod.nim at outlook.com (Rod Nim) Date: Fri, 11 Jul 2014 07:10:51 +0000 Subject: ScriptObjectMirror Message-ID: Dear Nashorn devs; I'm wanting to invoke a JS function that looks like this: function myFunc(context) { with(context) { return a + b; } } Where a and b are values my Java "context" object supplies. I've tried passing in "context" from Java (via Invocable) as a Map; and am getting: javax.script.ScriptException: TypeError: Cannot apply "with" to non script object in Fair enough. So I tried my own instance of JSObject but Nasorn isn't happy with that either, same exception. So myArg needs to be an instance of ScriptObjectMirror. But ScriptObjectMirror is final! Any way to get me out of his corner? Thank you in advance for your help. I know you're a very busy team and answering "user" questions like this is not a core priority, in fact I almost feel embarrassed to ask. Thanks again. Rod From rod.nim at outlook.com Fri Jul 11 07:19:30 2014 From: rod.nim at outlook.com (Rod Nim) Date: Fri, 11 Jul 2014 07:19:30 +0000 Subject: ScriptObjectMirror - reformatted for plain text Message-ID: Dear Nashorn devs; I'm wanting to invoke a JS function that looks like this: function myFunc(context) {? ? ?with(context) {? ? ? ? return a + b;? ? ?}? }? Where a and b are values my Java "context" object supplies. I've tried passing in "context" from Java (via Invocable) as a Map; and am getting: ? ?javax.script.ScriptException: TypeError: Cannot apply "with" to non script object in Fair enough. So I tried my own instance of JSObject but Nasorn isn't happy with that either, same exception. So myArg needs to be an instance of ScriptObjectMirror. But ScriptObjectMirror is final! Any way to get me out of his corner? Thank you in advance for your help. I know you're a very busy team and answering "user" questions like this is not a core priority, in fact I almost feel embarrassed to ask. Thanks again. Rod? From timvolpe at gmail.com Mon Jul 14 09:18:23 2014 From: timvolpe at gmail.com (Tim Fox) Date: Mon, 14 Jul 2014 10:18:23 +0100 Subject: Providing "script name" to eval In-Reply-To: <53BE0576.7080002@oracle.com> References: <53BD59A3.2060107@gmail.com> <53BE0576.7080002@oracle.com> Message-ID: <53C3A05F.8000804@gmail.com> On 10/07/14 04:16, A. Sundararajan wrote: > > > You can also use "eval naming" (See > http://bugs.java.com/view_bug.do?bug_id=8032068) with jdk8u20+ Thanks Sundar, do you know when u20 will be available? Latest release seems to be jdk8u5 http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html From sundararajan.athijegannathan at oracle.com Mon Jul 14 10:56:44 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 14 Jul 2014 16:26:44 +0530 Subject: ScriptObjectMirror - reformatted for plain text In-Reply-To: References: Message-ID: <53C3B76C.50109@oracle.com> Hi Rod, Nashorn allows only script objects (i.e., objects created by a JS constructor or JS object literal expression) as scope expression for "with" statement. Arbitrary objects like "context" (which is an instance of javax.script.ScriptContext) can not be used as 'scope' expression for 'with'. In jdk9, support has been added to support script objects mirror other script engines or other globals (which are instances of ScriptObjectMirror). What is ScriptObjectMirror? it is java API for an underlying JS object (which is an instance of ScriptObject). For eg. you can a ScriptObjectMirror like this: ScriptObjectMirror sobj = (ScriptObjectMirror) engine.eval("({ foo: 233 })"); More info here: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes Hope this helps, -Sundar On Friday 11 July 2014 12:49 PM, Rod Nim wrote: > Dear Nashorn devs; > > I'm wanting to invoke a JS function that looks like this: > > function myFunc(context) { > with(context) { > return a + b; > } > } > > Where a and b are values my Java "context" object supplies. > > I've tried passing in "context" from Java (via Invocable) as a Map; and am getting: > > javax.script.ScriptException: TypeError: Cannot apply "with" to non script object in > > Fair enough. So I tried my own instance of JSObject but Nasorn isn't happy with that either, same exception. > > So myArg needs to be an instance of ScriptObjectMirror. But ScriptObjectMirror is final! > > Any way to get me out of his corner? > > Thank you in advance for your help. I know you're a very busy team and answering "user" questions like this is not a core priority, in fact I almost feel embarrassed to ask. > > Thanks again. > > Rod From sundararajan.athijegannathan at oracle.com Mon Jul 14 11:01:42 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 14 Jul 2014 16:31:42 +0530 Subject: Providing "script name" to eval In-Reply-To: <53C3A05F.8000804@gmail.com> References: <53BD59A3.2060107@gmail.com> <53BE0576.7080002@oracle.com> <53C3A05F.8000804@gmail.com> Message-ID: <53C3B896.5090402@oracle.com> Hi, Please find http://openjdk.java.net/projects/jdk8u/releases/8u20.html Thanks, -Sundar On Monday 14 July 2014 02:48 PM, Tim Fox wrote: > On 10/07/14 04:16, A. Sundararajan wrote: >> >> >> You can also use "eval naming" (See >> http://bugs.java.com/view_bug.do?bug_id=8032068) with jdk8u20+ > > Thanks Sundar, do you know when u20 will be available? Latest release > seems to be jdk8u5 > http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html > From sundararajan.athijegannathan at oracle.com Tue Jul 15 04:38:10 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 15 Jul 2014 10:08:10 +0530 Subject: RFR 8050432: javax.script.filename variable should not be enumerable with nashorn engine's ENGINE_SCOPE bindings Message-ID: <53C4B032.9060009@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8050432/ Thanks -Sundar From james.laskey at oracle.com Tue Jul 15 14:28:56 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 15 Jul 2014 11:28:56 -0300 Subject: RFR 8050432: javax.script.filename variable should not be enumerable with nashorn engine's ENGINE_SCOPE bindings In-Reply-To: <53C4B032.9060009@oracle.com> References: <53C4B032.9060009@oracle.com> Message-ID: <2B138E39-A67E-4E9B-A706-1A718B229D4E@oracle.com> +1 On Jul 15, 2014, at 1:38 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8050432/ > > Thanks > -Sundar > From sundararajan.athijegannathan at oracle.com Thu Jul 17 06:41:26 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 17 Jul 2014 12:11:26 +0530 Subject: RFR 8050964: OptimisticTypesPersistence.java should use java.util.Date instead of java.sql.Date Message-ID: <53C77016.1090001@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8050964/ Added test (using jdeps) to assert that we don't use non-Compact1 classes in nashorn. PS. Piggybacking three recent sample scripts. Thanks -Sundar From mark.reinhold at oracle.com Thu Jul 17 22:03:17 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 17 Jul 2014 15:03:17 -0700 (PDT) Subject: JEP 196: Nashorn Optimistic Typing Message-ID: <20140717220317.30D3028BB9@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/196 - Mark From andrebargull at googlemail.com Fri Jul 18 07:45:03 2014 From: andrebargull at googlemail.com (=?ISO-8859-15?Q?Andr=E9_Bargull?=) Date: Fri, 18 Jul 2014 09:45:03 +0200 Subject: Test262 tests for ECMAScript 5 now in branch "es5-tests" Message-ID: <53C8D07F.3050108@googlemail.com> From https://github.com/tc39/test262/issues/39 > Created branch "es5-tests" based off of the last commit before I pulled in > ES6 tests (and after I pulled in bug fixes). Cherry-picked deletion of > external folder to save everyone some HDD space :) make/build.xml should probably be updated accordingly. - Andr? From sundararajan.athijegannathan at oracle.com Fri Jul 18 10:57:43 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 18 Jul 2014 16:27:43 +0530 Subject: RFR 8051019: Separate src and test execution sandbox directories Message-ID: <53C8FDA7.4090803@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8051019/ With this change, build and dist directory can be outside nashorn repo directory (and already testng.jar can be kept elsewhere). These changes are by Lev Ppriima. Thanks -Sundar From sundararajan.athijegannathan at oracle.com Fri Jul 18 11:05:36 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 18 Jul 2014 16:35:36 +0530 Subject: Test262 tests for ECMAScript 5 now in branch "es5-tests" In-Reply-To: <53C8D07F.3050108@googlemail.com> References: <53C8D07F.3050108@googlemail.com> Message-ID: <53C8FF80.2020507@oracle.com> Thanks Andr? ! Filed a new bug against nashorn : https://bugs.openjdk.java.net/browse/JDK-8051346 Thanks -Sundar On Friday 18 July 2014 01:15 PM, Andr? Bargull wrote: > From https://github.com/tc39/test262/issues/39 > > > Created branch "es5-tests" based off of the last commit before I > pulled in > > ES6 tests (and after I pulled in bug fixes). Cherry-picked deletion of > > external folder to save everyone some HDD space :) > > > make/build.xml should probably be updated accordingly. > > > - Andr? From james.laskey at oracle.com Fri Jul 18 11:06:45 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 18 Jul 2014 08:06:45 -0300 Subject: RFR 8051019: Separate src and test execution sandbox directories In-Reply-To: <53C8FDA7.4090803@oracle.com> References: <53C8FDA7.4090803@oracle.com> Message-ID: <2ACFF3DE-7777-4AAB-B36D-F2246E245E3D@oracle.com> +1 On Jul 18, 2014, at 7:57 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8051019/ > > With this change, build and dist directory can be outside nashorn repo directory (and already testng.jar can be kept elsewhere). > > These changes are by Lev Ppriima. > > Thanks > -Sundar From marc at openendedgroup.com Sun Jul 20 15:39:53 2014 From: marc at openendedgroup.com (Marc Downie) Date: Sun, 20 Jul 2014 10:39:53 -0500 Subject: JSObject and delegation to other java classes Message-ID: Dear Nashorn-dev, I'm building a JSObject-implementation-based to a fairly complex Java class --- in order to present a more JavaScript-flavored fa?ade to some Java and I'm finding that I have to build a tremendous amount of boilerplate to call existing Java methods in a JSObject. You can see where this is heading in your own example code ( https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions): ... public Object getMember(String name) { switch (name) { case "length": return buf.capacity(); case "buf": // return a 'function' value for this property return new AbstractJSObject() { @Override public Object call(Object thiz, Object... args) { return BufferArray.this.buf; } // yes, I'm a function ! @Override public boolean isFunction() { return true; } }; } return null; } ... Imagine this code copied and pasted out to 50-odd methods & fields. Question 1: have I missed something? My main use case is actually less general: public class ClassWithBigAPI { .... many methods and fields ... } public class JSMassageLayer extends ClassWithBigAPI implements JSObject { ... public void getMember(String n) { // how to lookup and return all methods and fields in super? } } Question 2: is there something better that I can return than a whole new AbstractJSObject? I've gotten some distance by returning (SomeFunctionalInterface)this::someMethod, but I can't build those automatically. In my case all I want is the standard method / field lookup that I would have gotten before I implemented JSObject if that would succeed. As far as I can tell, not only is this cumbersome to write and maintain (even building these AbstractJSObject's based on reflection of the class I'm delegating too), but it seems non-performant and loses functionality that's hard to restore (for example magic SAM conversion on calling). For example, is there a sane (and api-legal) way of building SimpleDynamicMethod/OverloadedDynamicMethod instances? Question 3: is this a real design problem? In other languages / interfaces to languages there's a distinction made between a "getMember" that's called for all member lookup and a "getMember" that's called when other, standard member lookups fail (for example __getattr__ / __getattribute__ in python/jython, groovy invokeMethod / methodMissing). Other languages / runtimes privilege the second case (Ruby methodMissing, Scala's selectDynamic). I've found Jython's functionality here, in particular, vital to creating Pythonic interfaces to already-existing Java things, but I was hoping to move my whole operation over to Nashorn. Finally, I've also tried, in JS, new JSAdaptor(new ClassWithBigAPI()){ ... }, but that doesn't seem to get me anywhere --- unexpectedly, __get__ is still called for things that are in ClassWithBigAPI. Of course, being in JS gives me more options, so I'm pursuing that route for now. many thanks, Marc From marc at openendedgroup.com Sun Jul 20 16:58:28 2014 From: marc at openendedgroup.com (Marc Downie) Date: Sun, 20 Jul 2014 11:58:28 -0500 Subject: Monkey patching a Java class? In-Reply-To: <53631DC4.9020902@oracle.com> References: <53631DC4.9020902@oracle.com> Message-ID: Does adding new methods to Java.extend based subclasses actually work? Currently I have (staying close to the example code): var ArrayList = Java.type("java.util.ArrayList") var ArrayListExtender = Java.extend(ArrayList) var printSizeInvokedArrayList = new ArrayListExtender() { size: function() { print("size invoked!"); }, banana: function() { print("Banana"); } // this doesn't override anything in ArrayList } printSizeInvokedArrayList.size() // WORKS printSizeInvokedArrayList.banana() // TYPE ERROR ([] has no such function "banana") // and even: printSizeInvokedArrayList.peach = function(){print("Peach");} // no error, but.... printSizeInvokedArrayList.peach() // TYPE ERROR ([] has no such function "peach") (1.9.0-ea-b23 and 1.8.0_20-ea-b23) Marc. On Thu, May 1, 2014 at 11:23 PM, A. Sundararajan < sundararajan.athijegannathan at oracle.com> wrote: > No, you can't add/remove a method (or public field) of a Java class to use > within the script. You could subclass and expose that subclass as > "java.io.File" by > > var oldFile = java.io.File; > java.io.File = Java.extend(oldFile, ...) > > But, I'd not recommend it - besides user can still get original > java.io.File via Java.type (unless you do similar hack on Java.type as > well!!) > > Cleaner approach is to expose a script API wrapping java.io.File. > > -Sundar > > > On Thursday 17 April 2014 12:03 AM, HRJet wrote: > >> Is it possible to monkey patch a Java class for use within Javascript? >> >> For example, I want to add a convenience method to java.io.File class, say >> "readAsString()". >> >> Then, in javascript I want to call file.readAsString() where file is an >> instance of java.io.File. Note that the file instance may be created by >> some third-party code, over which I have no control. >> >> In Java land, this seems to be usually done with CGLib or AspectJ, etc. >> >> I was wondering if nashorn had some trick up its sleeve for doing this in >> script land, since this sort of thing is common in Javascript. >> >> thanks, >> HRJ >> > > From sundararajan.athijegannathan at oracle.com Mon Jul 21 11:07:10 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 21 Jul 2014 16:37:10 +0530 Subject: Monkey patching a Java class? In-Reply-To: References: <53631DC4.9020902@oracle.com> Message-ID: <53CCF45E.3030106@oracle.com> No, you can't add new methods to extended class (no facility to declare types and so on) - only overrides of super class methods. -Sundar On Sunday 20 July 2014 10:28 PM, Marc Downie wrote: > Does adding new methods to Java.extend based subclasses actually work? > Currently I have (staying close to the example code): > > var ArrayList = Java.type("java.util.ArrayList") > var ArrayListExtender = Java.extend(ArrayList) > var printSizeInvokedArrayList = new ArrayListExtender() { > size: function() { print("size invoked!"); }, > banana: function() { print("Banana"); } // this doesn't override anything > in ArrayList > } > > printSizeInvokedArrayList.size() // WORKS > printSizeInvokedArrayList.banana() // TYPE ERROR ([] has no such function > "banana") > > // and even: > > printSizeInvokedArrayList.peach = function(){print("Peach");} // no error, > but.... > printSizeInvokedArrayList.peach() // TYPE ERROR ([] has no such function > "peach") > > (1.9.0-ea-b23 and 1.8.0_20-ea-b23) > > Marc. > > > > On Thu, May 1, 2014 at 11:23 PM, A. Sundararajan < > sundararajan.athijegannathan at oracle.com> wrote: > >> No, you can't add/remove a method (or public field) of a Java class to use >> within the script. You could subclass and expose that subclass as >> "java.io.File" by >> >> var oldFile = java.io.File; >> java.io.File = Java.extend(oldFile, ...) >> >> But, I'd not recommend it - besides user can still get original >> java.io.File via Java.type (unless you do similar hack on Java.type as >> well!!) >> >> Cleaner approach is to expose a script API wrapping java.io.File. >> >> -Sundar >> >> >> On Thursday 17 April 2014 12:03 AM, HRJet wrote: >> >>> Is it possible to monkey patch a Java class for use within Javascript? >>> >>> For example, I want to add a convenience method to java.io.File class, say >>> "readAsString()". >>> >>> Then, in javascript I want to call file.readAsString() where file is an >>> instance of java.io.File. Note that the file instance may be created by >>> some third-party code, over which I have no control. >>> >>> In Java land, this seems to be usually done with CGLib or AspectJ, etc. >>> >>> I was wondering if nashorn had some trick up its sleeve for doing this in >>> script land, since this sort of thing is common in Javascript. >>> >>> thanks, >>> HRJ >>> >> From sundararajan.athijegannathan at oracle.com Mon Jul 21 11:11:48 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 21 Jul 2014 16:41:48 +0530 Subject: JSObject and delegation to other java classes In-Reply-To: References: Message-ID: <53CCF574.7000501@oracle.com> Will this sample of any help to you? http://hg.openjdk.java.net/jdk9/dev/nashorn/file/34a783929a67/samples/jsobj_example.js PS. JSObject is meant for very lightweight script-like objects - says remote objects (where net latency is much more than proxying calls etc.) or expose database records as script-friendly objects and so on. If you want to mix-n-match Java objects + JSObjects, doing it scripts is better. Thanks, -Sundar On Sunday 20 July 2014 09:09 PM, Marc Downie wrote: > Dear Nashorn-dev, > > I'm building a JSObject-implementation-based to a fairly complex Java class > --- in order to present a more JavaScript-flavored fa?ade to some Java and > I'm finding that I have to build a tremendous amount of boilerplate to call > existing Java methods in a JSObject. You can see where this is heading in > your own example code ( > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions): > > ... > public Object getMember(String name) { > switch (name) { > case "length": > return buf.capacity(); > case "buf": > // return a 'function' value for this property > return new AbstractJSObject() { > @Override > public Object call(Object thiz, Object... args) { > return BufferArray.this.buf; > } > // yes, I'm a function ! > @Override > public boolean isFunction() { > return true; > } > }; > } > return null; > } > ... > Imagine this code copied and pasted out to 50-odd methods & fields. > > Question 1: have I missed something? > > My main use case is actually less general: > > public class ClassWithBigAPI > { > .... many methods and fields ... > } > > public class JSMassageLayer extends ClassWithBigAPI implements JSObject > { > ... > public void getMember(String n) > { > // how to lookup and return all methods and fields in super? > } > } > > Question 2: is there something better that I can return than a whole new > AbstractJSObject? I've gotten some distance by returning > (SomeFunctionalInterface)this::someMethod, but I can't build those > automatically. In my case all I want is the standard method / field lookup > that I would have gotten before I implemented JSObject if that would > succeed. As far as I can tell, not only is this cumbersome to write and > maintain (even building these AbstractJSObject's based on reflection of the > class I'm delegating too), but it seems non-performant and loses > functionality that's hard to restore (for example magic SAM conversion on > calling). For example, is there a sane (and api-legal) way of building > SimpleDynamicMethod/OverloadedDynamicMethod instances? > > Question 3: is this a real design problem? In other languages / interfaces > to languages there's a distinction made between a "getMember" that's called > for all member lookup and a "getMember" that's called when other, standard > member lookups fail (for example __getattr__ / __getattribute__ in > python/jython, groovy invokeMethod / methodMissing). Other languages / > runtimes privilege the second case (Ruby methodMissing, Scala's > selectDynamic). I've found Jython's functionality here, in particular, > vital to creating Pythonic interfaces to already-existing Java things, but > I was hoping to move my whole operation over to Nashorn. > > Finally, I've also tried, in JS, new JSAdaptor(new ClassWithBigAPI()){ ... > }, but that doesn't seem to get me anywhere --- unexpectedly, __get__ is > still called for things that are in ClassWithBigAPI. Of course, being in JS > gives me more options, so I'm pursuing that route for now. > > many thanks, > > Marc From marc at openendedgroup.com Mon Jul 21 12:47:53 2014 From: marc at openendedgroup.com (Marc Downie) Date: Mon, 21 Jul 2014 07:47:53 -0500 Subject: Monkey patching a Java class? In-Reply-To: <53CCF45E.3030106@oracle.com> References: <53631DC4.9020902@oracle.com> <53CCF45E.3030106@oracle.com> Message-ID: Got it, thanks. I'd consider adding a sentence to the "Java.extend" docs ( https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions) to that end. My outside perspective is that it's unexpected that a) you can't, b) trying to fails silently, and c) setting arbitrary members on Java.extend classes work but they simply disappear never to return. best, Marc On Mon, Jul 21, 2014 at 6:07 AM, A. Sundararajan < sundararajan.athijegannathan at oracle.com> wrote: > No, you can't add new methods to extended class (no facility to declare > types and so on) - only overrides of super class methods. > > -Sundar > > > On Sunday 20 July 2014 10:28 PM, Marc Downie wrote: > >> Does adding new methods to Java.extend based subclasses actually work? >> Currently I have (staying close to the example code): >> >> var ArrayList = Java.type("java.util.ArrayList") >> var ArrayListExtender = Java.extend(ArrayList) >> var printSizeInvokedArrayList = new ArrayListExtender() { >> size: function() { print("size invoked!"); }, >> banana: function() { print("Banana"); } // this doesn't override >> anything >> in ArrayList >> } >> >> printSizeInvokedArrayList.size() // WORKS >> printSizeInvokedArrayList.banana() // TYPE ERROR ([] has no such function >> "banana") >> >> // and even: >> >> printSizeInvokedArrayList.peach = function(){print("Peach");} // no >> error, >> but.... >> printSizeInvokedArrayList.peach() // TYPE ERROR ([] has no such function >> "peach") >> >> (1.9.0-ea-b23 and 1.8.0_20-ea-b23) >> >> Marc. >> >> >> >> On Thu, May 1, 2014 at 11:23 PM, A. Sundararajan < >> sundararajan.athijegannathan at oracle.com> wrote: >> >> No, you can't add/remove a method (or public field) of a Java class to >>> use >>> within the script. You could subclass and expose that subclass as >>> "java.io.File" by >>> >>> var oldFile = java.io.File; >>> java.io.File = Java.extend(oldFile, ...) >>> >>> But, I'd not recommend it - besides user can still get original >>> java.io.File via Java.type (unless you do similar hack on Java.type as >>> well!!) >>> >>> Cleaner approach is to expose a script API wrapping java.io.File. >>> >>> -Sundar >>> >>> >>> On Thursday 17 April 2014 12:03 AM, HRJet wrote: >>> >>> Is it possible to monkey patch a Java class for use within Javascript? >>>> >>>> For example, I want to add a convenience method to java.io.File class, >>>> say >>>> "readAsString()". >>>> >>>> Then, in javascript I want to call file.readAsString() where file is an >>>> instance of java.io.File. Note that the file instance may be created by >>>> some third-party code, over which I have no control. >>>> >>>> In Java land, this seems to be usually done with CGLib or AspectJ, etc. >>>> >>>> I was wondering if nashorn had some trick up its sleeve for doing this >>>> in >>>> script land, since this sort of thing is common in Javascript. >>>> >>>> thanks, >>>> HRJ >>>> >>>> >>> > From sundararajan.athijegannathan at oracle.com Mon Jul 21 12:49:47 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 21 Jul 2014 18:19:47 +0530 Subject: Monkey patching a Java class? In-Reply-To: References: <53631DC4.9020902@oracle.com> <53CCF45E.3030106@oracle.com> Message-ID: <53CD0C6B.6030506@oracle.com> Agree. I'll fix the wiki. Thanks -Sundar On Monday 21 July 2014 06:17 PM, Marc Downie wrote: > Got it, thanks. I'd consider adding a sentence to the "Java.extend" docs ( > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions) to that > end. > > My outside perspective is that it's unexpected that a) you can't, b) trying > to fails silently, and c) setting arbitrary members on Java.extend classes > work but they simply disappear never to return. > > best, > > Marc > > > On Mon, Jul 21, 2014 at 6:07 AM, A. Sundararajan < > sundararajan.athijegannathan at oracle.com> wrote: > >> No, you can't add new methods to extended class (no facility to declare >> types and so on) - only overrides of super class methods. >> >> -Sundar >> >> >> On Sunday 20 July 2014 10:28 PM, Marc Downie wrote: >> >>> Does adding new methods to Java.extend based subclasses actually work? >>> Currently I have (staying close to the example code): >>> >>> var ArrayList = Java.type("java.util.ArrayList") >>> var ArrayListExtender = Java.extend(ArrayList) >>> var printSizeInvokedArrayList = new ArrayListExtender() { >>> size: function() { print("size invoked!"); }, >>> banana: function() { print("Banana"); } // this doesn't override >>> anything >>> in ArrayList >>> } >>> >>> printSizeInvokedArrayList.size() // WORKS >>> printSizeInvokedArrayList.banana() // TYPE ERROR ([] has no such function >>> "banana") >>> >>> // and even: >>> >>> printSizeInvokedArrayList.peach = function(){print("Peach");} // no >>> error, >>> but.... >>> printSizeInvokedArrayList.peach() // TYPE ERROR ([] has no such function >>> "peach") >>> >>> (1.9.0-ea-b23 and 1.8.0_20-ea-b23) >>> >>> Marc. >>> >>> >>> >>> On Thu, May 1, 2014 at 11:23 PM, A. Sundararajan < >>> sundararajan.athijegannathan at oracle.com> wrote: >>> >>> No, you can't add/remove a method (or public field) of a Java class to >>>> use >>>> within the script. You could subclass and expose that subclass as >>>> "java.io.File" by >>>> >>>> var oldFile = java.io.File; >>>> java.io.File = Java.extend(oldFile, ...) >>>> >>>> But, I'd not recommend it - besides user can still get original >>>> java.io.File via Java.type (unless you do similar hack on Java.type as >>>> well!!) >>>> >>>> Cleaner approach is to expose a script API wrapping java.io.File. >>>> >>>> -Sundar >>>> >>>> >>>> On Thursday 17 April 2014 12:03 AM, HRJet wrote: >>>> >>>> Is it possible to monkey patch a Java class for use within Javascript? >>>>> For example, I want to add a convenience method to java.io.File class, >>>>> say >>>>> "readAsString()". >>>>> >>>>> Then, in javascript I want to call file.readAsString() where file is an >>>>> instance of java.io.File. Note that the file instance may be created by >>>>> some third-party code, over which I have no control. >>>>> >>>>> In Java land, this seems to be usually done with CGLib or AspectJ, etc. >>>>> >>>>> I was wondering if nashorn had some trick up its sleeve for doing this >>>>> in >>>>> script land, since this sort of thing is common in Javascript. >>>>> >>>>> thanks, >>>>> HRJ >>>>> >>>>> From marc at openendedgroup.com Mon Jul 21 15:34:47 2014 From: marc at openendedgroup.com (Marc Downie) Date: Mon, 21 Jul 2014 10:34:47 -0500 Subject: JSObject and delegation to other java classes In-Reply-To: <53CCF574.7000501@oracle.com> References: <53CCF574.7000501@oracle.com> Message-ID: On Mon, Jul 21, 2014 at 6:11 AM, A. Sundararajan< sundararajan.athijegannathan at oracle.com> wrote: > Will this sample of any help to you? > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ > 34a783929a67/samples/jsobj_example.js > > It is! Many thanks. What stopped me getting there myself? Well I fell into this trap: assigned methods from the fallback class to temporary variables doesn't work var ArrayList = Java.type('java.util.ArrayList') var al = new ArrayList() al.size() // WORKS, returns zero var sz = al.size // works, sz is not undefined or null sz() // throws ClassCastException Obviously in your code you just do the lookup multiple times, but out of interest: is there anything I can do with sz to call the underlying method? What's it even for? best, Marc From sundararajan.athijegannathan at oracle.com Mon Jul 21 15:52:04 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 21 Jul 2014 21:22:04 +0530 Subject: JSObject and delegation to other java classes In-Reply-To: References: <53CCF574.7000501@oracle.com> Message-ID: <53CD3724.5020807@oracle.com> You can't "take" java method away from object and then "apply" it later (like you do with Java reflection). Also, there is not "Function" like "apply" for Java methods. If you switch on method names and have multiple call sites, i.e., one each for each "hot" methods and have default for the rest, that should help. -Sundar On Monday 21 July 2014 09:04 PM, Marc Downie wrote: > On Mon, Jul 21, 2014 at 6:11 AM, A. Sundararajan< > sundararajan.athijegannathan at oracle.com> wrote: > >> Will this sample of any help to you? >> >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ >> 34a783929a67/samples/jsobj_example.js >> >> > It is! Many thanks. > > What stopped me getting there myself? Well I fell into this trap: assigned > methods from the fallback class to temporary variables doesn't work > > var ArrayList = Java.type('java.util.ArrayList') > var al = new ArrayList() > > al.size() // WORKS, returns zero > var sz = al.size // works, sz is not undefined or null > sz() // throws ClassCastException > > Obviously in your code you just do the lookup multiple times, but out of > interest: is there anything I can do with sz to call the underlying method? > What's it even for? > > best, > > Marc From marc at openendedgroup.com Mon Jul 21 17:05:44 2014 From: marc at openendedgroup.com (Marc Downie) Date: Mon, 21 Jul 2014 12:05:44 -0500 Subject: JSObject and delegation to other java classes [further adventures in building JS interfaces to Java] Message-ID: So the solution posed here: > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ >> 34a783929a67/samples/jsobj_example.js > > suffers from one flaw (for my case and taste): the factory produces objects that delegate to a Java instance but are not actual subclasses, and thus cannot be passed to Java methods that expect those classes. This was the reason JSObject as an interface looked so appetizing. So here's a hybrid that works: public class BigBaseClass { // many methods, all written by some 3rd party } public class MyJSShim extends BigBaseClass implements JSObject { // much lovely JSObject customization // a getMember and setMember that makes this feel like a map, and a call that does interesting things } -- and in JavaScript -- function makeBigBaseClass() { var Shim = Java.extend(Java.type('somepackage.MyJSShim')) var shim = new Shim() { getMember: function(name) { var q = shim_super["getMember"](name) if (q) return q; if (typeof shim_super[name] == 'function') { return function() { var a = arguments; switch (a.length) { case 0: return shim_super[name](); case 1: return shim_super[name](a[0]); case 2: return shim_super[name](a[0], a[1]); // ... etc ... } } } } } var shim_super = Java.super(shim) return shim } --- I should also note that Java.extend(Java.type('somepackage.BigBaseClass'), Java.type('jdk.nashorn.api.scripting.JSObject')) also appears to work if you don't need any Java-side JSObject glue. This handy multi-arg version of Java.extend seems a little buried in docs. But this gets me the best of all three worlds: makeBigBaseClass returns an actual subclass of BigBaseClass, I can customize JS access to my inviolate, 3rd-party BigBaseClass to my heart's content in MyJSShim, but I can skip over the difficult/impossible to write parts of getMember in the Java implementation and write them in JS instead (still yielding method calls that have automatic SAM conversion and the like). Many thanks, (I'm still surprised I can't simply return shim_super[name] when it's typeof 'function', or use what's returned from Java.super(this)inside getMember, to eliminate the var shim_super altogether, but I'm getting over it. Also: a pony). Marc. From marcus.lagergren at oracle.com Mon Jul 21 17:22:22 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 21 Jul 2014 19:22:22 +0200 Subject: Oracle Nashorn Question In-Reply-To: References: Message-ID: <95857CB2-D788-4952-95E0-5F0CBDAEC642@oracle.com> The best place to post a query like this is nashorn-dev. In fact, we were actually looking at this today and we think we have ways to fix this. Partial remedy might be to use ?global-per-engine=true, setting, which will limit the creation to one global shared between engines. Right, Sundar? /M On 21 Jul 2014, at 17:49, Julien Ponge wrote: > Hi Frank, > > I'm not part of Oracle or the team working on Nashorn, so this question is best for Marcus who is part of it at Oracle. > > Cheers > > - Julien > > Begin forwarded message: > >> From: Timo Frank >> Subject: Oracle Nashorn Question >> Date: 21 Jul 2014 14:05:59 GMT+2 >> To: "julien.ponge at insa-lyon.fr" >> >> Dear Sir, >> >> lately I found your article on http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html about Java?s new JavaScript Engine Nashorn. >> At the moment I?m doing some research about integrating different scripting languages in the JVM via javax.script. >> After profiling some script executions with Mozilla Rhino and Nashorn I noticed, that nashorn?s initialization lasts much more longer than rhino?s. >> For curiosity I checked the CPU cycles: >> >> >> It appears that the creation of a global object takes a long time in nashorn. In Rhino for example, this step doesn?t seem to exist. >> Since I found no detailed information about this object I hope that I may ask you about this initialization step, which appears to be a huge disadvantage for Nashorn against Rhino. >> >> Best Regards, >> Timo Frank > From marc at openendedgroup.com Mon Jul 21 18:27:10 2014 From: marc at openendedgroup.com (Marc Downie) Date: Mon, 21 Jul 2014 13:27:10 -0500 Subject: JSObject and delegation to other java classes In-Reply-To: <53CD3724.5020807@oracle.com> References: <53CCF574.7000501@oracle.com> <53CD3724.5020807@oracle.com> Message-ID: On Mon, Jul 21, 2014 at 10:52 AM, A. Sundararajan < sundararajan.athijegannathan at oracle.com> wrote: > You can't "take" java method away from object and then "apply" it later > (like you do with Java reflection). Understood. But this statement is only half true ? you *can* take a java method away from an object. It's just that once you have it the only thing you can do with it (that I've found) is check that it's typeof 'function', upon which it lies to you. Anyway, confusions and expectations I'm all set now with what I need from the Nashorn/Java interface for now. Many thanks for all of your help. Marc. From sergey.lugovoy at oracle.com Wed Jul 23 13:42:22 2014 From: sergey.lugovoy at oracle.com (Sergey Lugovoy) Date: Wed, 23 Jul 2014 17:42:22 +0400 Subject: RFR 8049318: Test hideLocationProperties.js fails on Window due to backslash in path Message-ID: <53CFBBBE.5080002@oracle.com> Please review http://cr.openjdk.java.net/~avstepan/slugovoy/8049318/ for https://bugs.openjdk.java.net/browse/JDK-8049318 -- Thanks, Sergey From attila.szegedi at oracle.com Fri Jul 25 07:50:05 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 25 Jul 2014 09:50:05 +0200 Subject: Review request for JDK-8051839 Message-ID: <7C8511A1-0FBD-4AD9-9E2D-B5CB546B917A@oracle.com> Please review JDK-8051839 at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Fri Jul 25 08:29:05 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 25 Jul 2014 13:59:05 +0530 Subject: Review request for JDK-8051839 In-Reply-To: <7C8511A1-0FBD-4AD9-9E2D-B5CB546B917A@oracle.com> References: <7C8511A1-0FBD-4AD9-9E2D-B5CB546B917A@oracle.com> Message-ID: <53D21551.1000709@oracle.com> +1 On Friday 25 July 2014 01:20 PM, Attila Szegedi wrote: > Please review JDK-8051839 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Fri Jul 25 09:14:30 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 25 Jul 2014 11:14:30 +0200 Subject: Review request for JDK-8051839 In-Reply-To: <7C8511A1-0FBD-4AD9-9E2D-B5CB546B917A@oracle.com> References: <7C8511A1-0FBD-4AD9-9E2D-B5CB546B917A@oracle.com> Message-ID: <53D21FF6.7000903@oracle.com> +1 Am 2014-07-25 um 09:50 schrieb Attila Szegedi: > Please review JDK-8051839 at for > > Thanks, > Attila. From marc at openendedgroup.com Fri Jul 25 22:48:05 2014 From: marc at openendedgroup.com (Marc Downie) Date: Fri, 25 Jul 2014 17:48:05 -0500 Subject: Anonymous classes mess with field access from JS in unexpected ways Message-ID: Accessing to fields (but not methods) of anonymous classes and their superclasses seems broken, to me (1.9.0-ea-b23 & 1.8.0_20-ea-b23). Example: package somepackage; public class ScratchClass { public class ClassOne { public String peach = "pear"; public String banana() { return "banana"; } } public ClassOne c2 = new ClassOne() { public String yetMoreMember = "yet more"; public String banana() { return "banana, overridden in c2"; } public String pear() { return "pear"; } }; public ClassOne c1 = new ClassOne(); } --- jjs> var sc = new (Java.type("somepackage.ScratchClass"))() jjs> sc somepackage.ScratchClass at 418e7838 *// expected* jjs> sc.c1 somepackage.ScratchClass$ClassOne at 4f209819 *// expected* jjs> sc.c2 somepackage.ScratchClass$1 at 7193666c *// expected* jjs> sc.c1.peach pear *// expected* jjs> sc.c1.banana() banana *// expected* jjs> print(sc.c2.banana()) banana, overridden in c2 *// expected --- refers to overridden method* So far so good. But: jjs> print(sc.c2.peach) undefined *// unexpected --- should refer to field in superclass ClassOne?* jjs> print(sc.c2.yetMoreMember) undefined *// unexpected --- should refer to field in anon class?* jjs> print(sc.c2.pear()) :1 TypeError: somepackage.ScratchClass$1 at 7193666c has no such function "pear" *// unexpected --- should refer to method in anon class?* If I give that anonymous subclass of ClassOne an actual name and instantiate that instead all is well. Bug or misunderstanding about the Java/JavaScript interface? many thanks, Marc. From asotobu at gmail.com Sat Jul 26 12:02:23 2014 From: asotobu at gmail.com (Alex Soto) Date: Sat, 26 Jul 2014 14:02:23 +0200 Subject: Nashorn and AsciidoctorJs Message-ID: Hi guys, currently I am working on integrating Asciidoctor to Java using Nashorn and Opal. Nowadays we have got an asciidoctor java running above JRuby. Apart from Asciidoctor java we also have an asciidoctorjs which is created using Opal (a gem to convert Ruby programs to JavaScript). So next step is to integrate this js to java using nashorn. But we are having one problem. I have created a project with a test so you can take a look as well: https://github.com/lordofthejars/asciidoctorjs The test is located at https://github.com/lordofthejars/asciidoctorjs/blob/master/src/test/java/rhino/RenderDocumentWithRhino.java (although it is called Rhino currently we are using Nashorn). If I create an script engine an I use the eval method everywhere it works perfectly but because I would like to use some more typesafe approach I decided to create an interface mirroring some asciidoctor operations so I call invocable.getInterface(AsciidoctorJs.class) to create the proxied instance and then I call defined methods. This interface mimics the js asciidoctorjava.js which internally calls asciidoctor.js operations. This is done because I only want some operations available from Java part, not the whole operations that asciidoctor.js offers. asciidoctorjava.js looks like: var render = function(content, optionsHash2) { return Opal.Asciidoctor.$render(content, optionsHash2); }; The problem is that when I run the test an exception is thrown notifying that Opal.Asciidoctor.$render is not found. If I change that line to: var render = function(content, optionsHash2) { return "Hello World"; }; then it works so it seems that Nashorn don't load the asciidoctor.js but this is not exactly true because if I execute the same operation but using eval method it works. Probably I am missing something in the creation of proxied interface, but currently I cannot see what. Any idea on why this happens? Thank you so much for your help in advance. Alex. -- +----------------------------------------------------------+ Alex Soto Bueno - Computer Engineer www.lordofthejars.com +----------------------------------------------------------+ From sundararajan.athijegannathan at oracle.com Mon Jul 28 07:54:27 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 28 Jul 2014 13:24:27 +0530 Subject: Nashorn and AsciidoctorJs In-Reply-To: References: Message-ID: <53D601B3.70200@oracle.com> Hi, Each unique ENGINE_SCOPE Bindings either (a) wraps a Nashorn/ECMAScript 'global' instance or (b) is associated with a Nashorn/ECMAScript 'global' instance. There is also a default ScriptContext with it's own ENGINE_SCOPE bindings - which is a wrapper over a (default) nashorn/ecmascript 'global' instance. ECMAScript global instance is where all your function and variable definitions ("function func() {...} and var c =... ") go. Invocable's invokeFunction, invokeMethod and getInterface methods look for backing scripting functions in ENGINE_SCOPE of script engine's own Script Context (you can get/set that by ScriptEngine.getContext, ScriptEngine.setContext methods). In your test, you seem to evaluate code in a (non-default) ScriptContext and then set that as engine's default context - which is right. The following simple example works for me: import javax.script.*; public class Test { public static void main(String[] args) throws Exception { ScriptEngineManager m = new ScriptEngineManager(); ScriptEngine e = m.getEngineByName("nashorn"); SimpleScriptContext sctxt = new SimpleScriptContext(); Bindings b = new SimpleBindings(); sctxt.setBindings(b, ScriptContext.ENGINE_SCOPE); e.eval("function run() { print('hello') }", sctxt); e.setContext(sctxt); Runnable r = ((Invocable)e).getInterface(Runnable.class); r.run(); } } Please check the following: * you've corresponding global function definitions to implement AsciidoctorJs (in that SimpleScriptContext). Per spec. getInterface may return null if method definitions are missing. * What is the version of Java you use? Is there a default method in AsciidoctorJs interface? There was a bug regarding interfaces with default methods ( 8031359: Invocable.getInterface() works incorrectly if interface has default methods - http://bugs.java.com/view_bug.do?bug_id=8031359). This was fixed in 8u20. If everything fails, please file a bug with all info. needed to reproduce the bug + stack trace + JDK/OS version information. Hope this helps, -Sundar On Saturday 26 July 2014 05:32 PM, Alex Soto wrote: > Hi guys, > > currently I am working on integrating Asciidoctor to Java using Nashorn and > Opal. Nowadays we have got an asciidoctor java running above JRuby. > > Apart from Asciidoctor java we also have an asciidoctorjs which is created > using Opal (a gem to convert Ruby programs to JavaScript). > > So next step is to integrate this js to java using nashorn. But we are > having one problem. > > I have created a project with a test so you can take a look as well: > https://github.com/lordofthejars/asciidoctorjs > > The test is located at > https://github.com/lordofthejars/asciidoctorjs/blob/master/src/test/java/rhino/RenderDocumentWithRhino.java > (although it is called Rhino currently we are using Nashorn). > > If I create an script engine an I use the eval method everywhere it works > perfectly but because I would like to use some more typesafe approach I > decided to create an interface mirroring some asciidoctor operations so I > call invocable.getInterface(AsciidoctorJs.class) to create the proxied > instance and then I call defined methods. > > This interface mimics the js asciidoctorjava.js which internally calls > asciidoctor.js operations. This is done because I only want some operations > available from Java part, not the whole operations that asciidoctor.js > offers. > > asciidoctorjava.js looks like: > > var render = function(content, optionsHash2) { > return Opal.Asciidoctor.$render(content, optionsHash2); > }; > > The problem is that when I run the test an exception is thrown notifying > that Opal.Asciidoctor.$render is not found. If I change that line to: > > var render = function(content, optionsHash2) { > return "Hello World"; > }; > > then it works so it seems that Nashorn don't load the asciidoctor.js but > this is not exactly true because if I execute the same operation but using > eval method it works. > > Probably I am missing something in the creation of proxied interface, but > currently I cannot see what. > > Any idea on why this happens? > > Thank you so much for your help in advance. > > Alex. > From sergey.lugovoy at oracle.com Mon Jul 28 10:40:42 2014 From: sergey.lugovoy at oracle.com (Sergey Lugovoy) Date: Mon, 28 Jul 2014 14:40:42 +0400 Subject: RFR 8049318: Test hideLocationProperties.js fails on Window due to backslash in path In-Reply-To: <53CFBBBE.5080002@oracle.com> References: <53CFBBBE.5080002@oracle.com> Message-ID: <53D628AA.4010901@oracle.com> Hi all, please, review this simple fix. On 23.07.2014 17:42, Sergey Lugovoy wrote: > Please review http://cr.openjdk.java.net/~avstepan/slugovoy/8049318/ > for https://bugs.openjdk.java.net/browse/JDK-8049318 > -- Thanks, Sergey From sundararajan.athijegannathan at oracle.com Mon Jul 28 11:25:42 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 28 Jul 2014 16:55:42 +0530 Subject: RFR 8049318: Test hideLocationProperties.js fails on Window due to backslash in path In-Reply-To: <53D628AA.4010901@oracle.com> References: <53CFBBBE.5080002@oracle.com> <53D628AA.4010901@oracle.com> Message-ID: <53D63336.60407@oracle.com> +1 -Sundar On Monday 28 July 2014 04:10 PM, Sergey Lugovoy wrote: > Hi all, > please, review this simple fix. > > On 23.07.2014 17:42, Sergey Lugovoy wrote: >> Please review http://cr.openjdk.java.net/~avstepan/slugovoy/8049318/ >> for https://bugs.openjdk.java.net/browse/JDK-8049318 >> From marcus.lagergren at oracle.com Tue Jul 29 01:39:10 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 28 Jul 2014 18:39:10 -0700 Subject: RFR 8049318: Test hideLocationProperties.js fails on Window due to backslash in path In-Reply-To: <53CFBBBE.5080002@oracle.com> References: <53CFBBBE.5080002@oracle.com> Message-ID: <2EA106C6-A30E-4E29-A29D-4EC322BB166A@oracle.com> +1 On 23 Jul 2014, at 06:42, Sergey Lugovoy wrote: > Please review http://cr.openjdk.java.net/~avstepan/slugovoy/8049318/ > for https://bugs.openjdk.java.net/browse/JDK-8049318 > > -- > Thanks, > Sergey > From james.laskey at oracle.com Tue Jul 29 13:08:23 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 29 Jul 2014 10:08:23 -0300 Subject: Nashorn and AsciidoctorJs In-Reply-To: References: Message-ID: <6FEAA1A3-FD0A-48D1-9439-EA483C11DDF2@oracle.com> [Just getting back] Granted I tweaked the main to simplify the testing outside an IDE, but when I ran it it seems to work up to a point (asciidoctor.js:12234 timings.$start is undefined.): >> java -cp ../java nashorn.RenderDocumentWithNashorn Working Directory = /Projects/asciidoctorjs/src/test/resources Untitled

Hello World

*Hello World* [object Object] nashorn.AsciidoctorJs$$NashornJavaAdapter at 4a70d302 undefined Exception in thread "main" :12235 TypeError: Cannot call undefined at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:56) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:212) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:184) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:171) at jdk.nashorn.internal.runtime.Undefined.lookupTypeError(Undefined.java:128) at jdk.nashorn.internal.runtime.Undefined.lookup(Undefined.java:100) at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:98) at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:144) at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) at jdk.nashorn.internal.scripts.Script$\^eval\_$32._L11888$_L11906$_L12223$_L12226(:12235) at jdk.nashorn.internal.scripts.Script$\^eval\_$34._L11888$_L11906$_L12223$_L12310(:12336) at jdk.nashorn.internal.scripts.Script$\^eval\_._L1(:2) at nashorn.AsciidoctorJs$$NashornJavaAdapter.render(Unknown Source) at nashorn.RenderDocumentWithNashorn.main(RenderDocumentWithNashorn.java:66) package nashorn; import java.io.*; import java.util.HashMap; import java.util.Map; import java.util.Scanner; import javax.script.*; public class RenderDocumentWithNashorn { static void evalFile(String filename, ScriptEngine engine, SimpleScriptContext context) throws ScriptException, FileNotFoundException { engine.eval(new java.io.FileReader(filename), context); } public static void main(String[] args) throws ScriptException, NoSuchMethodException, FileNotFoundException { System.out.println("Working Directory = " + System.getProperty("user.dir")); ScriptEngineManager engineManager = new ScriptEngineManager(); ScriptEngine engine = engineManager.getEngineByName("nashorn"); SimpleScriptContext simpleScriptContext = new SimpleScriptContext(); Bindings bindings = new SimpleBindings(); simpleScriptContext.setBindings(bindings, ScriptContext.ENGINE_SCOPE); try { evalFile("opal.js", engine, simpleScriptContext); evalFile("asciidoctor.js", engine, simpleScriptContext); evalFile("asciidoctor_extensions.js", engine, simpleScriptContext); evalFile("asciidoctorjava.js", engine, simpleScriptContext); } catch (ScriptException e) { throw new IllegalArgumentException(e); } String content = "*Hello World*"; Map options = new HashMap<>(); options.put("header_footer", true); simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("listOptions", options.keySet().toArray()); simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("options", options); simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("content", content); Invocable invocable = (Invocable) engine; Object eval = engine.eval("Opal.hash2(listOptions, options)", simpleScriptContext); simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("hash2", eval); engine.setContext(simpleScriptContext); System.out.println(engine.eval("Opal.Asciidoctor.$render(content, hash2);", simpleScriptContext)); AsciidoctorJs asciidoctorJs = invocable.getInterface( AsciidoctorJs.class); System.out.println(content); System.out.println(eval); System.out.println(asciidoctorJs); System.out.println( asciidoctorJs.render(content, eval)); } } On Jul 26, 2014, at 9:02 AM, Alex Soto wrote: > Hi guys, > > currently I am working on integrating Asciidoctor to Java using Nashorn and > Opal. Nowadays we have got an asciidoctor java running above JRuby. > > Apart from Asciidoctor java we also have an asciidoctorjs which is created > using Opal (a gem to convert Ruby programs to JavaScript). > > So next step is to integrate this js to java using nashorn. But we are > having one problem. > > I have created a project with a test so you can take a look as well: > https://github.com/lordofthejars/asciidoctorjs > > The test is located at > https://github.com/lordofthejars/asciidoctorjs/blob/master/src/test/java/rhino/RenderDocumentWithRhino.java > (although it is called Rhino currently we are using Nashorn). > > If I create an script engine an I use the eval method everywhere it works > perfectly but because I would like to use some more typesafe approach I > decided to create an interface mirroring some asciidoctor operations so I > call invocable.getInterface(AsciidoctorJs.class) to create the proxied > instance and then I call defined methods. > > This interface mimics the js asciidoctorjava.js which internally calls > asciidoctor.js operations. This is done because I only want some operations > available from Java part, not the whole operations that asciidoctor.js > offers. > > asciidoctorjava.js looks like: > > var render = function(content, optionsHash2) { > return Opal.Asciidoctor.$render(content, optionsHash2); > }; > > The problem is that when I run the test an exception is thrown notifying > that Opal.Asciidoctor.$render is not found. If I change that line to: > > var render = function(content, optionsHash2) { > return "Hello World"; > }; > > then it works so it seems that Nashorn don't load the asciidoctor.js but > this is not exactly true because if I execute the same operation but using > eval method it works. > > Probably I am missing something in the creation of proxied interface, but > currently I cannot see what. > > Any idea on why this happens? > > Thank you so much for your help in advance. > > Alex. > > -- > +----------------------------------------------------------+ > Alex Soto Bueno - Computer Engineer > www.lordofthejars.com > +----------------------------------------------------------+ From james.laskey at oracle.com Tue Jul 29 13:21:09 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 29 Jul 2014 10:21:09 -0300 Subject: Nashorn and AsciidoctorJs In-Reply-To: <6FEAA1A3-FD0A-48D1-9439-EA483C11DDF2@oracle.com> References: <6FEAA1A3-FD0A-48D1-9439-EA483C11DDF2@oracle.com> Message-ID: <79C84535-26BA-47DE-BECE-F899F52EF26C@oracle.com> I just remembered I'm running with 8u20 preview - likely has some affect. -- Jim On Jul 29, 2014, at 10:08 AM, Jim Laskey (Oracle) wrote: > [Just getting back] > Granted I tweaked the main to simplify the testing outside an IDE, but when I ran it it seems to work up to a point (asciidoctor.js:12234 timings.$start is undefined.): > >>> java -cp ../java nashorn.RenderDocumentWithNashorn > Working Directory = /Projects/asciidoctorjs/src/test/resources > > > > > > > > Untitled > > > > >
>
>

Hello World

>
>
> > > > *Hello World* > [object Object] > nashorn.AsciidoctorJs$$NashornJavaAdapter at 4a70d302 > undefined > Exception in thread "main" :12235 TypeError: Cannot call undefined > at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:56) > at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:212) > at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:184) > at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:171) > at jdk.nashorn.internal.runtime.Undefined.lookupTypeError(Undefined.java:128) > at jdk.nashorn.internal.runtime.Undefined.lookup(Undefined.java:100) > at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:98) > at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) > at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) > at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:144) > at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) > at jdk.nashorn.internal.scripts.Script$\^eval\_$32._L11888$_L11906$_L12223$_L12226(:12235) > at jdk.nashorn.internal.scripts.Script$\^eval\_$34._L11888$_L11906$_L12223$_L12310(:12336) > at jdk.nashorn.internal.scripts.Script$\^eval\_._L1(:2) > at nashorn.AsciidoctorJs$$NashornJavaAdapter.render(Unknown Source) > at nashorn.RenderDocumentWithNashorn.main(RenderDocumentWithNashorn.java:66) > > package nashorn; > > import java.io.*; > import java.util.HashMap; > import java.util.Map; > import java.util.Scanner; > > import javax.script.*; > > public class RenderDocumentWithNashorn { > static void evalFile(String filename, ScriptEngine engine, SimpleScriptContext context) throws ScriptException, FileNotFoundException { > engine.eval(new java.io.FileReader(filename), context); > } > > public static void main(String[] args) throws ScriptException, NoSuchMethodException, FileNotFoundException { > System.out.println("Working Directory = " + System.getProperty("user.dir")); > > ScriptEngineManager engineManager = > new ScriptEngineManager(); > ScriptEngine engine = > engineManager.getEngineByName("nashorn"); > > > SimpleScriptContext simpleScriptContext = new SimpleScriptContext(); > Bindings bindings = new SimpleBindings(); > > simpleScriptContext.setBindings(bindings, ScriptContext.ENGINE_SCOPE); > > try { > evalFile("opal.js", engine, simpleScriptContext); > evalFile("asciidoctor.js", engine, simpleScriptContext); > evalFile("asciidoctor_extensions.js", engine, simpleScriptContext); > evalFile("asciidoctorjava.js", engine, simpleScriptContext); > } catch (ScriptException e) { > throw new IllegalArgumentException(e); > } > > String content = "*Hello World*"; > Map options = new HashMap<>(); > options.put("header_footer", true); > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("listOptions", options.keySet().toArray()); > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("options", options); > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("content", content); > > > Invocable invocable = (Invocable) engine; > > Object eval = engine.eval("Opal.hash2(listOptions, options)", simpleScriptContext); > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("hash2", eval); > > > > engine.setContext(simpleScriptContext); > > System.out.println(engine.eval("Opal.Asciidoctor.$render(content, hash2);", simpleScriptContext)); > > AsciidoctorJs asciidoctorJs = > invocable.getInterface( > AsciidoctorJs.class); > System.out.println(content); > System.out.println(eval); > System.out.println(asciidoctorJs); > System.out.println( > asciidoctorJs.render(content, eval)); > > > } > > } > > > > > > On Jul 26, 2014, at 9:02 AM, Alex Soto wrote: > >> Hi guys, >> >> currently I am working on integrating Asciidoctor to Java using Nashorn and >> Opal. Nowadays we have got an asciidoctor java running above JRuby. >> >> Apart from Asciidoctor java we also have an asciidoctorjs which is created >> using Opal (a gem to convert Ruby programs to JavaScript). >> >> So next step is to integrate this js to java using nashorn. But we are >> having one problem. >> >> I have created a project with a test so you can take a look as well: >> https://github.com/lordofthejars/asciidoctorjs >> >> The test is located at >> https://github.com/lordofthejars/asciidoctorjs/blob/master/src/test/java/rhino/RenderDocumentWithRhino.java >> (although it is called Rhino currently we are using Nashorn). >> >> If I create an script engine an I use the eval method everywhere it works >> perfectly but because I would like to use some more typesafe approach I >> decided to create an interface mirroring some asciidoctor operations so I >> call invocable.getInterface(AsciidoctorJs.class) to create the proxied >> instance and then I call defined methods. >> >> This interface mimics the js asciidoctorjava.js which internally calls >> asciidoctor.js operations. This is done because I only want some operations >> available from Java part, not the whole operations that asciidoctor.js >> offers. >> >> asciidoctorjava.js looks like: >> >> var render = function(content, optionsHash2) { >> return Opal.Asciidoctor.$render(content, optionsHash2); >> }; >> >> The problem is that when I run the test an exception is thrown notifying >> that Opal.Asciidoctor.$render is not found. If I change that line to: >> >> var render = function(content, optionsHash2) { >> return "Hello World"; >> }; >> >> then it works so it seems that Nashorn don't load the asciidoctor.js but >> this is not exactly true because if I execute the same operation but using >> eval method it works. >> >> Probably I am missing something in the creation of proxied interface, but >> currently I cannot see what. >> >> Any idea on why this happens? >> >> Thank you so much for your help in advance. >> >> Alex. >> >> -- >> +----------------------------------------------------------+ >> Alex Soto Bueno - Computer Engineer >> www.lordofthejars.com >> +----------------------------------------------------------+ > From asotobu at gmail.com Tue Jul 29 13:38:54 2014 From: asotobu at gmail.com (Alex Soto) Date: Tue, 29 Jul 2014 15:38:54 +0200 Subject: Nashorn and AsciidoctorJs In-Reply-To: <79C84535-26BA-47DE-BECE-F899F52EF26C@oracle.com> References: <6FEAA1A3-FD0A-48D1-9439-EA483C11DDF2@oracle.com> <79C84535-26BA-47DE-BECE-F899F52EF26C@oracle.com> Message-ID: Yes it works when I run eval but not when I use the interface approach. Note that the eval code is the same as asciidoctorjava.js (which is used to declare methods of interface) , in both cases it should work but it only works when eval is called (calling the code directly). 2014-07-29 15:21 GMT+02:00 Jim Laskey (Oracle) : > I just remembered I'm running with 8u20 preview - likely has some affect. > > -- Jim > > > > On Jul 29, 2014, at 10:08 AM, Jim Laskey (Oracle) > wrote: > > > [Just getting back] > > Granted I tweaked the main to simplify the testing outside an IDE, but > when I ran it it seems to work up to a point (asciidoctor.js:12234 > timings.$start is undefined.): > > > >>> java -cp ../java nashorn.RenderDocumentWithNashorn > > Working Directory = /Projects/asciidoctorjs/src/test/resources > > > > > > > > > > > > > > > > Untitled > > > > > > > > > >
> >
> >

Hello World

> >
> >
> > > > > > > > *Hello World* > > [object Object] > > nashorn.AsciidoctorJs$$NashornJavaAdapter at 4a70d302 > > undefined > > Exception in thread "main" :12235 TypeError: Cannot call undefined > > at > jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:56) > > at > jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:212) > > at > jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:184) > > at > jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:171) > > at > jdk.nashorn.internal.runtime.Undefined.lookupTypeError(Undefined.java:128) > > at > jdk.nashorn.internal.runtime.Undefined.lookup(Undefined.java:100) > > at > jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:98) > > at > jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) > > at > jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) > > at > jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:144) > > at > jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) > > at > jdk.nashorn.internal.scripts.Script$\^eval\_$32._L11888$_L11906$_L12223$_L12226(:12235) > > at > jdk.nashorn.internal.scripts.Script$\^eval\_$34._L11888$_L11906$_L12223$_L12310(:12336) > > at jdk.nashorn.internal.scripts.Script$\^eval\_._L1(:2) > > at nashorn.AsciidoctorJs$$NashornJavaAdapter.render(Unknown Source) > > at > nashorn.RenderDocumentWithNashorn.main(RenderDocumentWithNashorn.java:66) > > > > package nashorn; > > > > import java.io.*; > > import java.util.HashMap; > > import java.util.Map; > > import java.util.Scanner; > > > > import javax.script.*; > > > > public class RenderDocumentWithNashorn { > > static void evalFile(String filename, ScriptEngine engine, > SimpleScriptContext context) throws ScriptException, FileNotFoundException { > > engine.eval(new java.io.FileReader(filename), context); > > } > > > > public static void main(String[] args) throws ScriptException, > NoSuchMethodException, FileNotFoundException { > > System.out.println("Working Directory = " + > System.getProperty("user.dir")); > > > > ScriptEngineManager engineManager = > > new ScriptEngineManager(); > > ScriptEngine engine = > > engineManager.getEngineByName("nashorn"); > > > > > > SimpleScriptContext simpleScriptContext = new > SimpleScriptContext(); > > Bindings bindings = new SimpleBindings(); > > > > simpleScriptContext.setBindings(bindings, > ScriptContext.ENGINE_SCOPE); > > > > try { > > evalFile("opal.js", engine, simpleScriptContext); > > evalFile("asciidoctor.js", engine, simpleScriptContext); > > evalFile("asciidoctor_extensions.js", engine, > simpleScriptContext); > > evalFile("asciidoctorjava.js", engine, simpleScriptContext); > > } catch (ScriptException e) { > > throw new IllegalArgumentException(e); > > } > > > > String content = "*Hello World*"; > > Map options = new HashMap<>(); > > options.put("header_footer", true); > > > > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("listOptions", > options.keySet().toArray()); > > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("options", > options); > > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("content", > content); > > > > > > Invocable invocable = (Invocable) engine; > > > > Object eval = engine.eval("Opal.hash2(listOptions, options)", > simpleScriptContext); > > > > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("hash2", > eval); > > > > > > > > engine.setContext(simpleScriptContext); > > > > System.out.println(engine.eval("Opal.Asciidoctor.$render(content, > hash2);", simpleScriptContext)); > > > > AsciidoctorJs asciidoctorJs = > > invocable.getInterface( > > AsciidoctorJs.class); > > System.out.println(content); > > System.out.println(eval); > > System.out.println(asciidoctorJs); > > System.out.println( > > asciidoctorJs.render(content, eval)); > > > > > > } > > > > } > > > > > > > > > > > > On Jul 26, 2014, at 9:02 AM, Alex Soto wrote: > > > >> Hi guys, > >> > >> currently I am working on integrating Asciidoctor to Java using Nashorn > and > >> Opal. Nowadays we have got an asciidoctor java running above JRuby. > >> > >> Apart from Asciidoctor java we also have an asciidoctorjs which is > created > >> using Opal (a gem to convert Ruby programs to JavaScript). > >> > >> So next step is to integrate this js to java using nashorn. But we are > >> having one problem. > >> > >> I have created a project with a test so you can take a look as well: > >> https://github.com/lordofthejars/asciidoctorjs > >> > >> The test is located at > >> > https://github.com/lordofthejars/asciidoctorjs/blob/master/src/test/java/rhino/RenderDocumentWithRhino.java > >> (although it is called Rhino currently we are using Nashorn). > >> > >> If I create an script engine an I use the eval method everywhere it > works > >> perfectly but because I would like to use some more typesafe approach I > >> decided to create an interface mirroring some asciidoctor operations so > I > >> call invocable.getInterface(AsciidoctorJs.class) to create the proxied > >> instance and then I call defined methods. > >> > >> This interface mimics the js asciidoctorjava.js which internally calls > >> asciidoctor.js operations. This is done because I only want some > operations > >> available from Java part, not the whole operations that asciidoctor.js > >> offers. > >> > >> asciidoctorjava.js looks like: > >> > >> var render = function(content, optionsHash2) { > >> return Opal.Asciidoctor.$render(content, optionsHash2); > >> }; > >> > >> The problem is that when I run the test an exception is thrown notifying > >> that Opal.Asciidoctor.$render is not found. If I change that line to: > >> > >> var render = function(content, optionsHash2) { > >> return "Hello World"; > >> }; > >> > >> then it works so it seems that Nashorn don't load the asciidoctor.js but > >> this is not exactly true because if I execute the same operation but > using > >> eval method it works. > >> > >> Probably I am missing something in the creation of proxied interface, > but > >> currently I cannot see what. > >> > >> Any idea on why this happens? > >> > >> Thank you so much for your help in advance. > >> > >> Alex. > >> > >> -- > >> +----------------------------------------------------------+ > >> Alex Soto Bueno - Computer Engineer > >> www.lordofthejars.com > >> +----------------------------------------------------------+ > > > > -- +----------------------------------------------------------+ Alex Soto Bueno - Computer Engineer www.lordofthejars.com +----------------------------------------------------------+ From james.laskey at oracle.com Tue Jul 29 13:47:51 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 29 Jul 2014 10:47:51 -0300 Subject: Nashorn and AsciidoctorJs In-Reply-To: References: <6FEAA1A3-FD0A-48D1-9439-EA483C11DDF2@oracle.com> <79C84535-26BA-47DE-BECE-F899F52EF26C@oracle.com> Message-ID: <0C39EEE6-978D-4E6B-B5E4-D506BD7959A5@oracle.com> I'm confused - what do I need to do to make it fail? -- Jim On Jul 29, 2014, at 10:38 AM, Alex Soto wrote: > Yes it works when I run eval but not when I use the interface approach. Note that the eval code is the same as asciidoctorjava.js (which is used to declare methods of interface) , in both cases it should work but it only works when eval is called (calling the code directly). > > > 2014-07-29 15:21 GMT+02:00 Jim Laskey (Oracle) : > I just remembered I'm running with 8u20 preview - likely has some affect. > > -- Jim > > > > On Jul 29, 2014, at 10:08 AM, Jim Laskey (Oracle) wrote: > > > [Just getting back] > > Granted I tweaked the main to simplify the testing outside an IDE, but when I ran it it seems to work up to a point (asciidoctor.js:12234 timings.$start is undefined.): > > > >>> java -cp ../java nashorn.RenderDocumentWithNashorn > > Working Directory = /Projects/asciidoctorjs/src/test/resources > > > > > > > > > > > > > > > > Untitled > > > > > > > > > >
> >
> >

Hello World

> >
> >
> > > > > > > > *Hello World* > > [object Object] > > nashorn.AsciidoctorJs$$NashornJavaAdapter at 4a70d302 > > undefined > > Exception in thread "main" :12235 TypeError: Cannot call undefined > > at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:56) > > at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:212) > > at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:184) > > at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:171) > > at jdk.nashorn.internal.runtime.Undefined.lookupTypeError(Undefined.java:128) > > at jdk.nashorn.internal.runtime.Undefined.lookup(Undefined.java:100) > > at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:98) > > at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) > > at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) > > at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:144) > > at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) > > at jdk.nashorn.internal.scripts.Script$\^eval\_$32._L11888$_L11906$_L12223$_L12226(:12235) > > at jdk.nashorn.internal.scripts.Script$\^eval\_$34._L11888$_L11906$_L12223$_L12310(:12336) > > at jdk.nashorn.internal.scripts.Script$\^eval\_._L1(:2) > > at nashorn.AsciidoctorJs$$NashornJavaAdapter.render(Unknown Source) > > at nashorn.RenderDocumentWithNashorn.main(RenderDocumentWithNashorn.java:66) > > > > package nashorn; > > > > import java.io.*; > > import java.util.HashMap; > > import java.util.Map; > > import java.util.Scanner; > > > > import javax.script.*; > > > > public class RenderDocumentWithNashorn { > > static void evalFile(String filename, ScriptEngine engine, SimpleScriptContext context) throws ScriptException, FileNotFoundException { > > engine.eval(new java.io.FileReader(filename), context); > > } > > > > public static void main(String[] args) throws ScriptException, NoSuchMethodException, FileNotFoundException { > > System.out.println("Working Directory = " + System.getProperty("user.dir")); > > > > ScriptEngineManager engineManager = > > new ScriptEngineManager(); > > ScriptEngine engine = > > engineManager.getEngineByName("nashorn"); > > > > > > SimpleScriptContext simpleScriptContext = new SimpleScriptContext(); > > Bindings bindings = new SimpleBindings(); > > > > simpleScriptContext.setBindings(bindings, ScriptContext.ENGINE_SCOPE); > > > > try { > > evalFile("opal.js", engine, simpleScriptContext); > > evalFile("asciidoctor.js", engine, simpleScriptContext); > > evalFile("asciidoctor_extensions.js", engine, simpleScriptContext); > > evalFile("asciidoctorjava.js", engine, simpleScriptContext); > > } catch (ScriptException e) { > > throw new IllegalArgumentException(e); > > } > > > > String content = "*Hello World*"; > > Map options = new HashMap<>(); > > options.put("header_footer", true); > > > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("listOptions", options.keySet().toArray()); > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("options", options); > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("content", content); > > > > > > Invocable invocable = (Invocable) engine; > > > > Object eval = engine.eval("Opal.hash2(listOptions, options)", simpleScriptContext); > > > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("hash2", eval); > > > > > > > > engine.setContext(simpleScriptContext); > > > > System.out.println(engine.eval("Opal.Asciidoctor.$render(content, hash2);", simpleScriptContext)); > > > > AsciidoctorJs asciidoctorJs = > > invocable.getInterface( > > AsciidoctorJs.class); > > System.out.println(content); > > System.out.println(eval); > > System.out.println(asciidoctorJs); > > System.out.println( > > asciidoctorJs.render(content, eval)); > > > > > > } > > > > } > > > > > > > > > > > > On Jul 26, 2014, at 9:02 AM, Alex Soto wrote: > > > >> Hi guys, > >> > >> currently I am working on integrating Asciidoctor to Java using Nashorn and > >> Opal. Nowadays we have got an asciidoctor java running above JRuby. > >> > >> Apart from Asciidoctor java we also have an asciidoctorjs which is created > >> using Opal (a gem to convert Ruby programs to JavaScript). > >> > >> So next step is to integrate this js to java using nashorn. But we are > >> having one problem. > >> > >> I have created a project with a test so you can take a look as well: > >> https://github.com/lordofthejars/asciidoctorjs > >> > >> The test is located at > >> https://github.com/lordofthejars/asciidoctorjs/blob/master/src/test/java/rhino/RenderDocumentWithRhino.java > >> (although it is called Rhino currently we are using Nashorn). > >> > >> If I create an script engine an I use the eval method everywhere it works > >> perfectly but because I would like to use some more typesafe approach I > >> decided to create an interface mirroring some asciidoctor operations so I > >> call invocable.getInterface(AsciidoctorJs.class) to create the proxied > >> instance and then I call defined methods. > >> > >> This interface mimics the js asciidoctorjava.js which internally calls > >> asciidoctor.js operations. This is done because I only want some operations > >> available from Java part, not the whole operations that asciidoctor.js > >> offers. > >> > >> asciidoctorjava.js looks like: > >> > >> var render = function(content, optionsHash2) { > >> return Opal.Asciidoctor.$render(content, optionsHash2); > >> }; > >> > >> The problem is that when I run the test an exception is thrown notifying > >> that Opal.Asciidoctor.$render is not found. If I change that line to: > >> > >> var render = function(content, optionsHash2) { > >> return "Hello World"; > >> }; > >> > >> then it works so it seems that Nashorn don't load the asciidoctor.js but > >> this is not exactly true because if I execute the same operation but using > >> eval method it works. > >> > >> Probably I am missing something in the creation of proxied interface, but > >> currently I cannot see what. > >> > >> Any idea on why this happens? > >> > >> Thank you so much for your help in advance. > >> > >> Alex. > >> > >> -- > >> +----------------------------------------------------------+ > >> Alex Soto Bueno - Computer Engineer > >> www.lordofthejars.com > >> +----------------------------------------------------------+ > > > > > > > -- > +----------------------------------------------------------+ > Alex Soto Bueno - Computer Engineer > www.lordofthejars.com > +----------------------------------------------------------+ From james.laskey at oracle.com Tue Jul 29 18:36:17 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 29 Jul 2014 15:36:17 -0300 Subject: Nashorn and AsciidoctorJs In-Reply-To: References: <6FEAA1A3-FD0A-48D1-9439-EA483C11DDF2@oracle.com> <79C84535-26BA-47DE-BECE-F899F52EF26C@oracle.com> Message-ID: Alex, It appears that Nashorn is converting the contents of the second argument (eval) to Script Mirrors when using getInterface. This is causing some strange interactions later on. The work around is to use invocable.invokeFunction("render", content, eval), (not using interfaces) until we can establish the why and what. I'll file a bug when I get the details. Cheers, -- Jim On Jul 29, 2014, at 10:38 AM, Alex Soto wrote: > Yes it works when I run eval but not when I use the interface approach. Note that the eval code is the same as asciidoctorjava.js (which is used to declare methods of interface) , in both cases it should work but it only works when eval is called (calling the code directly). > > > 2014-07-29 15:21 GMT+02:00 Jim Laskey (Oracle) : > I just remembered I'm running with 8u20 preview - likely has some affect. > > -- Jim > > > > On Jul 29, 2014, at 10:08 AM, Jim Laskey (Oracle) wrote: > > > [Just getting back] > > Granted I tweaked the main to simplify the testing outside an IDE, but when I ran it it seems to work up to a point (asciidoctor.js:12234 timings.$start is undefined.): > > > >>> java -cp ../java nashorn.RenderDocumentWithNashorn > > Working Directory = /Projects/asciidoctorjs/src/test/resources > > > > > > > > > > > > > > > > Untitled > > > > > > > > > >
> >
> >

Hello World

> >
> >
> > > > > > > > *Hello World* > > [object Object] > > nashorn.AsciidoctorJs$$NashornJavaAdapter at 4a70d302 > > undefined > > Exception in thread "main" :12235 TypeError: Cannot call undefined > > at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:56) > > at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:212) > > at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:184) > > at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:171) > > at jdk.nashorn.internal.runtime.Undefined.lookupTypeError(Undefined.java:128) > > at jdk.nashorn.internal.runtime.Undefined.lookup(Undefined.java:100) > > at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:98) > > at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) > > at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) > > at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:144) > > at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) > > at jdk.nashorn.internal.scripts.Script$\^eval\_$32._L11888$_L11906$_L12223$_L12226(:12235) > > at jdk.nashorn.internal.scripts.Script$\^eval\_$34._L11888$_L11906$_L12223$_L12310(:12336) > > at jdk.nashorn.internal.scripts.Script$\^eval\_._L1(:2) > > at nashorn.AsciidoctorJs$$NashornJavaAdapter.render(Unknown Source) > > at nashorn.RenderDocumentWithNashorn.main(RenderDocumentWithNashorn.java:66) > > > > package nashorn; > > > > import java.io.*; > > import java.util.HashMap; > > import java.util.Map; > > import java.util.Scanner; > > > > import javax.script.*; > > > > public class RenderDocumentWithNashorn { > > static void evalFile(String filename, ScriptEngine engine, SimpleScriptContext context) throws ScriptException, FileNotFoundException { > > engine.eval(new java.io.FileReader(filename), context); > > } > > > > public static void main(String[] args) throws ScriptException, NoSuchMethodException, FileNotFoundException { > > System.out.println("Working Directory = " + System.getProperty("user.dir")); > > > > ScriptEngineManager engineManager = > > new ScriptEngineManager(); > > ScriptEngine engine = > > engineManager.getEngineByName("nashorn"); > > > > > > SimpleScriptContext simpleScriptContext = new SimpleScriptContext(); > > Bindings bindings = new SimpleBindings(); > > > > simpleScriptContext.setBindings(bindings, ScriptContext.ENGINE_SCOPE); > > > > try { > > evalFile("opal.js", engine, simpleScriptContext); > > evalFile("asciidoctor.js", engine, simpleScriptContext); > > evalFile("asciidoctor_extensions.js", engine, simpleScriptContext); > > evalFile("asciidoctorjava.js", engine, simpleScriptContext); > > } catch (ScriptException e) { > > throw new IllegalArgumentException(e); > > } > > > > String content = "*Hello World*"; > > Map options = new HashMap<>(); > > options.put("header_footer", true); > > > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("listOptions", options.keySet().toArray()); > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("options", options); > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("content", content); > > > > > > Invocable invocable = (Invocable) engine; > > > > Object eval = engine.eval("Opal.hash2(listOptions, options)", simpleScriptContext); > > > > simpleScriptContext.getBindings(ScriptContext.ENGINE_SCOPE).put("hash2", eval); > > > > > > > > engine.setContext(simpleScriptContext); > > > > System.out.println(engine.eval("Opal.Asciidoctor.$render(content, hash2);", simpleScriptContext)); > > > > AsciidoctorJs asciidoctorJs = > > invocable.getInterface( > > AsciidoctorJs.class); > > System.out.println(content); > > System.out.println(eval); > > System.out.println(asciidoctorJs); > > System.out.println( > > asciidoctorJs.render(content, eval)); > > > > > > } > > > > } > > > > > > > > > > > > On Jul 26, 2014, at 9:02 AM, Alex Soto wrote: > > > >> Hi guys, > >> > >> currently I am working on integrating Asciidoctor to Java using Nashorn and > >> Opal. Nowadays we have got an asciidoctor java running above JRuby. > >> > >> Apart from Asciidoctor java we also have an asciidoctorjs which is created > >> using Opal (a gem to convert Ruby programs to JavaScript). > >> > >> So next step is to integrate this js to java using nashorn. But we are > >> having one problem. > >> > >> I have created a project with a test so you can take a look as well: > >> https://github.com/lordofthejars/asciidoctorjs > >> > >> The test is located at > >> https://github.com/lordofthejars/asciidoctorjs/blob/master/src/test/java/rhino/RenderDocumentWithRhino.java > >> (although it is called Rhino currently we are using Nashorn). > >> > >> If I create an script engine an I use the eval method everywhere it works > >> perfectly but because I would like to use some more typesafe approach I > >> decided to create an interface mirroring some asciidoctor operations so I > >> call invocable.getInterface(AsciidoctorJs.class) to create the proxied > >> instance and then I call defined methods. > >> > >> This interface mimics the js asciidoctorjava.js which internally calls > >> asciidoctor.js operations. This is done because I only want some operations > >> available from Java part, not the whole operations that asciidoctor.js > >> offers. > >> > >> asciidoctorjava.js looks like: > >> > >> var render = function(content, optionsHash2) { > >> return Opal.Asciidoctor.$render(content, optionsHash2); > >> }; > >> > >> The problem is that when I run the test an exception is thrown notifying > >> that Opal.Asciidoctor.$render is not found. If I change that line to: > >> > >> var render = function(content, optionsHash2) { > >> return "Hello World"; > >> }; > >> > >> then it works so it seems that Nashorn don't load the asciidoctor.js but > >> this is not exactly true because if I execute the same operation but using > >> eval method it works. > >> > >> Probably I am missing something in the creation of proxied interface, but > >> currently I cannot see what. > >> > >> Any idea on why this happens? > >> > >> Thank you so much for your help in advance. > >> > >> Alex. > >> > >> -- > >> +----------------------------------------------------------+ > >> Alex Soto Bueno - Computer Engineer > >> www.lordofthejars.com > >> +----------------------------------------------------------+ > > > > > > > -- > +----------------------------------------------------------+ > Alex Soto Bueno - Computer Engineer > www.lordofthejars.com > +----------------------------------------------------------+ From marcus.lagergren at oracle.com Tue Jul 29 20:10:48 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 29 Jul 2014 13:10:48 -0700 Subject: Please review JDK-8048869 Message-ID: Please review http://cr.openjdk.java.net/~lagergren/8048869/webrev/ - sped up compile time about 5% all over the line from removing native casts from the IR nodes. Turned compile-octane into a more generic benchmark so that it can run an arbitrary number of compiles in the same process, to create a compile time profile for Nashorn. https://bugs.openjdk.java.net/browse/JDK-8048869 /M From james.laskey at oracle.com Tue Jul 29 21:21:06 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 29 Jul 2014 18:21:06 -0300 Subject: Please review JDK-8048869 In-Reply-To: References: Message-ID: +1 On Jul 29, 2014, at 5:10 PM, Marcus Lagergren wrote: > Please review http://cr.openjdk.java.net/~lagergren/8048869/webrev/ - sped up compile time about 5% all over the line from removing native casts from the IR nodes. Turned compile-octane into a more generic benchmark so that it can run an arbitrary number of compiles in the same process, to create a compile time profile for Nashorn. > > https://bugs.openjdk.java.net/browse/JDK-8048869 > > /M > From sundararajan.athijegannathan at oracle.com Thu Jul 31 12:28:53 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 31 Jul 2014 17:58:53 +0530 Subject: RFR 8053908: jdeps is not PATH on Mac, results in ant clean test failure on Mac Message-ID: <53DA3685.3010903@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8053908/ Thanks -Sundar From james.laskey at oracle.com Thu Jul 31 12:36:15 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 31 Jul 2014 09:36:15 -0300 Subject: RFR 8053908: jdeps is not PATH on Mac, results in ant clean test failure on Mac In-Reply-To: <53DA3685.3010903@oracle.com> References: <53DA3685.3010903@oracle.com> Message-ID: <3C62A363-50F0-4938-8AD8-BBFF9699E029@oracle.com> +1 On Jul 31, 2014, at 9:28 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8053908/ > > Thanks > -Sundar From hannes.wallnoefer at oracle.com Thu Jul 31 12:48:31 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 31 Jul 2014 14:48:31 +0200 Subject: RFR 8053908: jdeps is not PATH on Mac, results in ant clean test failure on Mac In-Reply-To: <53DA3685.3010903@oracle.com> References: <53DA3685.3010903@oracle.com> Message-ID: <53DA3B1F.5030702@oracle.com> Looks good. Hannes Am 2014-07-31 um 14:28 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8053908/ > > Thanks > -Sundar From pgbakker at gmail.com Thu Jul 31 19:43:00 2014 From: pgbakker at gmail.com (Paul Bakker) Date: Thu, 31 Jul 2014 21:43:00 +0200 Subject: Nashorn Roadmap & Rhino migration question Message-ID: <53DA9C44.7080008@gmail.com> Hi, Maybe not the right place to ask these questions, but I could not find another place to ask them. 1: What is the roadmap of Nashorn when it comes to EcmaScript 6. The spec if quite final, mostly bugfixing. Assuming that at some point EcmaScript 6 will be supported in Nashorn, what is the policy to porting support back to existing Java versions? Can we expect to see EcmaScript 6 support in Nashorn in Java 8, or would such features only become available in new Java versions (so 9 or even 10)? 2: We currently integrate with Rhino directly (not the version what was shipped with Java). One of the features we use is being able to load instantiate Java classes from JavaScript using a custom classloader, using the new Packages(classLoader) syntax (see http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html). Is this supported in Nashorn so way or the other? TIA, Paul