From sundararajan.athijegannathan at oracle.com Tue Oct 1 01:12:05 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 01 Oct 2013 13:42:05 +0530 Subject: Please review 8025488: Error.captureStackTrace should not format error stack Message-ID: <524A83D5.1070708@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8025448/ Thanks -Sundar From sundararajan.athijegannathan at oracle.com Tue Oct 1 01:23:31 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 01 Oct 2013 13:53:31 +0530 Subject: Review request for 8025488: Error.captureStackTrace should not format error stack Message-ID: <524A8683.7020901@oracle.com> Webrev: http://cr.openjdk.java.net/~sundar/8025488/ Bug: https://bugs.openjdk.java.net/browse/JDK-8025488 PS. My last email on this had wrong directory name "448" instead of "488". Please ignore that. -Sundar From hannes.wallnoefer at oracle.com Tue Oct 1 01:37:31 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 01 Oct 2013 10:37:31 +0200 Subject: Review request for 8025488: Error.captureStackTrace should not format error stack In-Reply-To: <524A8683.7020901@oracle.com> References: <524A8683.7020901@oracle.com> Message-ID: <524A89CB.8010305@oracle.com> +1 Am 2013-10-01 10:23, schrieb A. Sundararajan: > Webrev: http://cr.openjdk.java.net/~sundar/8025488/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8025488 > > PS. My last email on this had wrong directory name "448" instead of > "488". Please ignore that. > > -Sundar From sundararajan.athijegannathan at oracle.com Tue Oct 1 02:09:34 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 01 Oct 2013 09:09:34 +0000 Subject: hg: nashorn/jdk8/nashorn: 8025488: Error.captureStackTrace should not format error stack Message-ID: <20131001090938.0D10162C2B@hg.openjdk.java.net> Changeset: cd7fb58043cb Author: sundar Date: 2013-10-01 14:38 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/cd7fb58043cb 8025488: Error.captureStackTrace should not format error stack Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/objects/NativeError.java + test/script/basic/JDK-8025488.js + test/script/basic/JDK-8025488.js.EXPECTED From marcus.lagergren at oracle.com Tue Oct 1 02:17:47 2013 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 1 Oct 2013 11:17:47 +0200 Subject: Review request for 8025488: Error.captureStackTrace should not format error stack In-Reply-To: <524A8683.7020901@oracle.com> References: <524A8683.7020901@oracle.com> Message-ID: +1 On Oct 1, 2013, at 10:23 AM, A. Sundararajan wrote: > Webrev: http://cr.openjdk.java.net/~sundar/8025488/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8025488 > > PS. My last email on this had wrong directory name "448" instead of "488". Please ignore that. > > -Sundar From sundararajan.athijegannathan at oracle.com Fri Oct 4 03:52:48 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 04 Oct 2013 10:52:48 +0000 Subject: hg: nashorn/jdk8/nashorn: 8025771: Enhance Nashorn Contexts Message-ID: <20131004105255.9906062D6A@hg.openjdk.java.net> Changeset: 3470bc26128f Author: sundar Date: 2013-10-04 16:21 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/3470bc26128f 8025771: Enhance Nashorn Contexts Reviewed-by: jlaskey, hannesw - make/java.security.override ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! test/script/basic/JDK-8023026.js + test/script/sandbox/arrayclass.js + test/script/sandbox/arrayclass.js.EXPECTED From andrebargull at googlemail.com Tue Oct 8 00:10:42 2013 From: andrebargull at googlemail.com (=?ISO-8859-15?Q?Andr=E9_Bargull?=) Date: Tue, 08 Oct 2013 09:10:42 +0200 Subject: Constant folding removes array literal in boolean context Message-ID: <5253AFF2.8050603@googlemail.com> Just a quick one this time: FoldConstants#leaveIfNode() and FoldConstants#leaveTernaryNode() need to guard against ArrayLiteralNode: jjs> (function(){if([a]);})() Expected: throws ReferenceError Actual: no error jjs> [a] ? 1 : 2 Expected: throws ReferenceError Actual: no error - Andr? From hannes.wallnoefer at oracle.com Tue Oct 8 02:30:37 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 08 Oct 2013 11:30:37 +0200 Subject: Review request for JDK-8025213 Message-ID: <5253D0BD.9060906@oracle.com> Please review JDK-8025213: Assignment marks variable as defined too early http://cr.openjdk.java.net/~hannesw/8025213/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Tue Oct 8 02:45:08 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Oct 2013 11:45:08 +0200 Subject: Review request for JDK-8025213 In-Reply-To: <5253D0BD.9060906@oracle.com> References: <5253D0BD.9060906@oracle.com> Message-ID: <5253D424.1050802@oracle.com> +1 -Sundar On Tuesday 08 October 2013 11:30 AM, Hannes Wallnoefer wrote: > Please review JDK-8025213: Assignment marks variable as defined too early > > http://cr.openjdk.java.net/~hannesw/8025213/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Tue Oct 8 02:56:29 2013 From: hannes.wallnoefer at oracle.com (hannes.wallnoefer at oracle.com) Date: Tue, 08 Oct 2013 09:56:29 +0000 Subject: hg: nashorn/jdk8/nashorn: 8025213: Assignment marks variable as defined too early Message-ID: <20131008095641.B459C62E25@hg.openjdk.java.net> Changeset: 6345d08fd5de Author: hannesw Date: 2013-10-08 11:55 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/6345d08fd5de 8025213: Assignment marks variable as defined too early Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8025213.js + test/script/basic/JDK-8025213.js.EXPECTED From james.laskey at oracle.com Tue Oct 8 03:09:05 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 12:09:05 +0200 Subject: Review request for JDK-8025213 In-Reply-To: <5253D0BD.9060906@oracle.com> References: <5253D0BD.9060906@oracle.com> Message-ID: <32E70D7E-D226-48FD-BD26-6AC68462FC56@oracle.com> +1 On 2013-10-08, at 11:30 AM, Hannes Wallnoefer wrote: > Please review JDK-8025213: Assignment marks variable as defined too early > > http://cr.openjdk.java.net/~hannesw/8025213/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Tue Oct 8 03:20:20 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Oct 2013 12:20:20 +0200 Subject: Review request for 8026033: Switch should load expression even when there are no cases in it Message-ID: <5253DC64.4080802@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026033 Thanks -Sundar From tal.liron at threecrickets.com Tue Oct 8 03:22:07 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 08 Oct 2013 18:22:07 +0800 Subject: importClass Message-ID: <5253DCCF.8090500@threecrickets.com> What is the equivalent of Rhino's importClass in Nashorn? From sundararajan.athijegannathan at oracle.com Tue Oct 8 03:26:01 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Oct 2013 12:26:01 +0200 Subject: importClass In-Reply-To: <5253DCCF.8090500@threecrickets.com> References: <5253DCCF.8090500@threecrickets.com> Message-ID: <5253DDB9.4020009@oracle.com> var List = Java.type("java.util.List"); is the recommended way. But if you've to use importClass, you can do the following: load("nashorn:mozilla_compat.js") importClass(java.util.List); -Sundar On Tuesday 08 October 2013 12:22 PM, Tal Liron wrote: > What is the equivalent of Rhino's importClass in Nashorn? From hannes.wallnoefer at oracle.com Tue Oct 8 03:46:12 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 08 Oct 2013 12:46:12 +0200 Subject: Review request for 8026033: Switch should load expression even when there are no cases in it In-Reply-To: <5253DC64.4080802@oracle.com> References: <5253DC64.4080802@oracle.com> Message-ID: <5253E274.5010602@oracle.com> +1 Am 2013-10-08 12:20, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8026033 > > Thanks > -Sundar From tal.liron at threecrickets.com Tue Oct 8 03:55:02 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 08 Oct 2013 18:55:02 +0800 Subject: From JS to Java objects? Message-ID: <5253E486.3060304@threecrickets.com> Is there a utility API in Nashorn to coerce JS objects into Java equivalents? For example, from NativeArray to a Java array. From james.laskey at oracle.com Tue Oct 8 03:58:30 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 12:58:30 +0200 Subject: Review request for 8026033: Switch should load expression even when there are no cases in it In-Reply-To: <5253DC64.4080802@oracle.com> References: <5253DC64.4080802@oracle.com> Message-ID: <6B036AEE-2E17-4482-A40C-7D4F70B3EA1B@oracle.com> +1 On 2013-10-08, at 12:20 PM, "A. Sundararajan" wrote: > Please review http://cr.openjdk.java.net/~sundar/8026033 > > Thanks > -Sundar From hannes.wallnoefer at oracle.com Tue Oct 8 04:01:08 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 08 Oct 2013 13:01:08 +0200 Subject: Review request for JDK-8025965 Message-ID: <5253E5F4.2080402@oracle.com> Please review JDK-8025965: Specialized functions with same weight replace each other in TreeSet http://cr.openjdk.java.net/~hannesw/8025965/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Tue Oct 8 04:05:00 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 08 Oct 2013 11:05:00 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026033: Switch should load expression even when there are no cases in it Message-ID: <20131008110509.BD6A962E2B@hg.openjdk.java.net> Changeset: 8c326f8c6799 Author: sundar Date: 2013-10-08 13:02 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/8c326f8c6799 8026033: Switch should load expression even when there are no cases in it Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026033.js + test/script/basic/JDK-8026033.js.EXPECTED From sundararajan.athijegannathan at oracle.com Tue Oct 8 04:06:08 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Oct 2013 13:06:08 +0200 Subject: Review request for JDK-8025965 In-Reply-To: <5253E5F4.2080402@oracle.com> References: <5253E5F4.2080402@oracle.com> Message-ID: <5253E720.2050307@oracle.com> +1 On Tuesday 08 October 2013 01:01 PM, Hannes Wallnoefer wrote: > Please review JDK-8025965: Specialized functions with same weight > replace each other in TreeSet > > http://cr.openjdk.java.net/~hannesw/8025965/ > > Thanks, > Hannes From james.laskey at oracle.com Tue Oct 8 04:06:17 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 13:06:17 +0200 Subject: From JS to Java objects? In-Reply-To: <5253E486.3060304@threecrickets.com> References: <5253E486.3060304@threecrickets.com> Message-ID: <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> Var StringArray = Java.type("java,lang.String[]"); var arr = Java.to(["a", "b", "c"], StringArray); Or just var arr = Java.to(["a", "b", "c"], "java,lang.String[]"); Nashorn documentation can be found at: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation Cheers, -- Jim On 2013-10-08, at 12:55 PM, Tal Liron wrote: > Is there a utility API in Nashorn to coerce JS objects into Java equivalents? For example, from NativeArray to a Java array. From james.laskey at oracle.com Tue Oct 8 04:06:27 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 13:06:27 +0200 Subject: Review request for JDK-8025965 In-Reply-To: <5253E5F4.2080402@oracle.com> References: <5253E5F4.2080402@oracle.com> Message-ID: <9920A00B-6BD4-4D84-A6C6-14E2C298D907@oracle.com> +1 On 2013-10-08, at 1:01 PM, Hannes Wallnoefer wrote: > Please review JDK-8025965: Specialized functions with same weight replace each other in TreeSet > > http://cr.openjdk.java.net/~hannesw/8025965/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Tue Oct 8 04:14:35 2013 From: hannes.wallnoefer at oracle.com (hannes.wallnoefer at oracle.com) Date: Tue, 08 Oct 2013 11:14:35 +0000 Subject: hg: nashorn/jdk8/nashorn: 8025965: Specialized functions with same weight replace each other in TreeSet Message-ID: <20131008111436.35DF262E2E@hg.openjdk.java.net> Changeset: 025e2ff9e91b Author: hannesw Date: 2013-10-08 13:11 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/025e2ff9e91b 8025965: Specialized functions with same weight replace each other in TreeSet Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/CompiledFunction.java From tal.liron at threecrickets.com Tue Oct 8 04:21:03 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 08 Oct 2013 19:21:03 +0800 Subject: From JS to Java objects? In-Reply-To: <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> Message-ID: <5253EA9F.60007@threecrickets.com> Oh, I meant a Java API. (I'm calling Nashorn programatically and getting native objects back.) On 10/08/2013 07:06 PM, Jim Laskey (Oracle) wrote: > Var StringArray = Java.type("java,lang.String[]"); > > var arr = Java.to(["a", "b", "c"], StringArray); > > Or just > > var arr = Java.to(["a", "b", "c"], "java,lang.String[]"); > > Nashorn documentation can be found at: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation > > Cheers, > > -- Jim > > > > On 2013-10-08, at 12:55 PM, Tal Liron wrote: > >> Is there a utility API in Nashorn to coerce JS objects into Java equivalents? For example, from NativeArray to a Java array. From tal.liron at threecrickets.com Tue Oct 8 04:54:14 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 08 Oct 2013 19:54:14 +0800 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays Message-ID: <5253F266.1050708@threecrickets.com> Lets say we have a Java class with this method: class MyClass { void myMethod(String[] arguments) {} } And in Nashorn we call it like so: myInstance.myMethod(['a', 'b', 'c']) The JavaScript array seems to be converted into a string (as "a,b,c"), and then wrapped in a Java string array as its single element before sending to Java. In Rhino, the above works as expected. From james.laskey at oracle.com Tue Oct 8 05:12:59 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 14:12:59 +0200 Subject: From JS to Java objects? In-Reply-To: <5253EA9F.60007@threecrickets.com> References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> Message-ID: <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> Please be more specific with an example. I assume you want to extend a Java class or some such requirement, On 2013-10-08, at 1:21 PM, Tal Liron wrote: > Oh, I meant a Java API. (I'm calling Nashorn programatically and getting native objects back.) > > On 10/08/2013 07:06 PM, Jim Laskey (Oracle) wrote: >> Var StringArray = Java.type("java,lang.String[]"); >> >> var arr = Java.to(["a", "b", "c"], StringArray); >> >> Or just >> >> var arr = Java.to(["a", "b", "c"], "java,lang.String[]"); >> >> Nashorn documentation can be found at: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation >> >> Cheers, >> >> -- Jim >> >> >> >> On 2013-10-08, at 12:55 PM, Tal Liron wrote: >> >>> Is there a utility API in Nashorn to coerce JS objects into Java equivalents? For example, from NativeArray to a Java array. > From james.laskey at oracle.com Tue Oct 8 05:23:31 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 14:23:31 +0200 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <5253F266.1050708@threecrickets.com> References: <5253F266.1050708@threecrickets.com> Message-ID: <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> Nashorn does not coerce JS arrays implicitly. There were too many ambiguous cases to do a complete implementation (nested conversions.) In Nashorn you have to; myInstance.myMethod(Java.to(['a', 'b', 'c'], "java.lang.String[]")); or; var StringArray = Java.type("java.lang.String[]"); function args(array) { return Java.to(array, StringArray); } myInstance.myMethod(args(['a', 'b', 'c'])); Cheers, -- Jim On 2013-10-08, at 1:54 PM, Tal Liron wrote: > Lets say we have a Java class with this method: > > class MyClass { > void myMethod(String[] arguments) {} > } > > And in Nashorn we call it like so: > > myInstance.myMethod(['a', 'b', 'c']) > > The JavaScript array seems to be converted into a string (as "a,b,c"), and then wrapped in a Java string array as its single element before sending to Java. > > In Rhino, the above works as expected. From tal.liron at threecrickets.com Tue Oct 8 05:26:19 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 08 Oct 2013 20:26:19 +0800 Subject: From JS to Java objects? In-Reply-To: <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> Message-ID: <5253F9EB.2000507@threecrickets.com> Sorry about that, was trying to be succinct. In detail: I'm creating Nashorn scripts programmatically from Java (using Context.compileScript and ScriptRuntime.apply), and receiving native results that need some massaging in order to be usable in Java. (Specifically I'm working on creating a Nashorn adapter for Scripturian.) However, I mostly found the answers myself: 1. It's possible to call NativeJava.to (equivalent to Java.to in JavaScript) 2. More efficient is to test specifically for NativeArray results and wrap them in a ListAdapter, which makes them conform to the List interface. This is what NativeJava.to does internally. On 10/08/2013 08:12 PM, Jim Laskey (Oracle) wrote: > Please be more specific with an example. I assume you want to extend a Java class or some such requirement, > From rick.bullotta at thingworx.com Tue Oct 8 05:32:29 2013 From: rick.bullotta at thingworx.com (Rick Bullotta) Date: Tue, 8 Oct 2013 12:32:29 +0000 Subject: From JS to Java objects? In-Reply-To: <5253F9EB.2000507@threecrickets.com> References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> <5253F9EB.2000507@threecrickets.com> Message-ID: On a related topic, I'm particularly interested in better understanding the *Adapter model in Nashorn and how it compares to Rhino, particularly in terms of custom adapters. In Rhino, we use custom adapters to intercept get/set/delete/put and other methods to allow dynamic access to a variety of data structures and objects (we can virtualize properties and functions this way, versus automatic reflection and type munging), and it isn't at all clear how to do this with Nashorn. -----Original Message----- From: nashorn-dev-bounces at openjdk.java.net [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of Tal Liron Sent: Tuesday, October 08, 2013 8:26 AM To: nashorn-dev at openjdk.java.net Subject: Re: From JS to Java objects? Sorry about that, was trying to be succinct. In detail: I'm creating Nashorn scripts programmatically from Java (using Context.compileScript and ScriptRuntime.apply), and receiving native results that need some massaging in order to be usable in Java. (Specifically I'm working on creating a Nashorn adapter for Scripturian.) However, I mostly found the answers myself: 1. It's possible to call NativeJava.to (equivalent to Java.to in JavaScript) 2. More efficient is to test specifically for NativeArray results and wrap them in a ListAdapter, which makes them conform to the List interface. This is what NativeJava.to does internally. On 10/08/2013 08:12 PM, Jim Laskey (Oracle) wrote: > Please be more specific with an example. I assume you want to extend > a Java class or some such requirement, > From sundararajan.athijegannathan at oracle.com Tue Oct 8 05:34:40 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Oct 2013 14:34:40 +0200 Subject: Review request for 8026039: future strict names are allowed as function name and argument name of a strict function Message-ID: <5253FBE0.9080605@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026039/ -Sundar From tal.liron at threecrickets.com Tue Oct 8 05:35:28 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 08 Oct 2013 20:35:28 +0800 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> References: <5253F266.1050708@threecrickets.com> <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> Message-ID: <5253FC10.10400@threecrickets.com> In my mind, it's acceptible if nested conversion doesn't happen: Rhino doesn't support it, either. But one would expect that at least the first-level of arguments would be coerced. By the way, this also works as expected in other JVM dynamic languages: Jython, JRuby, Quercus, LuaJ, Groovy and Clojure (though the latter both use Java arrays, so coercion is easier: just to the array element type). Would it be possible to support this intrinsically in mozilla_compat.js? Or possibly add an optional flag for it in Nashorn? This is a big deal. I have a very large application that works in Rhino but won't work in Nashorn because of this. On 10/08/2013 08:23 PM, Jim Laskey (Oracle) wrote: > Nashorn does not coerce JS arrays implicitly. There were too many ambiguous cases to do a complete implementation (nested conversions.) In Nashorn you have to; > > myInstance.myMethod(Java.to(['a', 'b', 'c'], "java.lang.String[]")); > > or; > > var StringArray = Java.type("java.lang.String[]"); > function args(array) { > return Java.to(array, StringArray); > } > > myInstance.myMethod(args(['a', 'b', 'c'])); > > Cheers, > > -- Jim > From james.laskey at oracle.com Tue Oct 8 05:38:07 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 14:38:07 +0200 Subject: From JS to Java objects? In-Reply-To: <5253F9EB.2000507@threecrickets.com> References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> <5253F9EB.2000507@threecrickets.com> Message-ID: You really shouldn't be using internal classes. We can and will be changing them over time. Use JSObject instead. On 2013-10-08, at 2:26 PM, Tal Liron wrote: > Sorry about that, was trying to be succinct. > > In detail: I'm creating Nashorn scripts programmatically from Java (using Context.compileScript and ScriptRuntime.apply), and receiving native results that need some massaging in order to be usable in Java. (Specifically I'm working on creating a Nashorn adapter for Scripturian.) > > However, I mostly found the answers myself: > > 1. It's possible to call NativeJava.to (equivalent to Java.to in JavaScript) > 2. More efficient is to test specifically for NativeArray results and wrap them in a ListAdapter, which makes them conform to the List interface. This is what NativeJava.to does internally. > > On 10/08/2013 08:12 PM, Jim Laskey (Oracle) wrote: >> Please be more specific with an example. I assume you want to extend a Java class or some such requirement, >> > From tal.liron at threecrickets.com Tue Oct 8 05:41:00 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 08 Oct 2013 20:41:00 +0800 Subject: From JS to Java objects? In-Reply-To: References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> <5253F9EB.2000507@threecrickets.com> Message-ID: <5253FD5C.4080702@threecrickets.com> How? It doesn't seem to support the java.util interfaces, whereas ListAdapter does. Also, it seems that the only implementation of JSObject is ScriptObjectMirror, which is specific to the JSR-223. On 10/08/2013 08:38 PM, Jim Laskey (Oracle) wrote: > You really shouldn't be using internal classes. We can and will be changing them over time. Use JSObject instead. > From hannes.wallnoefer at oracle.com Tue Oct 8 05:42:54 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 08 Oct 2013 14:42:54 +0200 Subject: Constant folding removes array literal in boolean context In-Reply-To: <5253AFF2.8050603@googlemail.com> References: <5253AFF2.8050603@googlemail.com> Message-ID: <5253FDCE.6000504@oracle.com> Thanks Andr?. https://bugs.openjdk.java.net/browse/JDK-8026042 Wondering if our very limited constant folding for if and ternary nodes is worth it at all. Hannes Am 2013-10-08 09:10, schrieb Andr? Bargull: > Just a quick one this time: > FoldConstants#leaveIfNode() and FoldConstants#leaveTernaryNode() need > to guard against ArrayLiteralNode: > > jjs> (function(){if([a]);})() > > Expected: throws ReferenceError > Actual: no error > > jjs> [a] ? 1 : 2 > > Expected: throws ReferenceError > Actual: no error > > > - Andr? From rick.bullotta at thingworx.com Tue Oct 8 05:45:12 2013 From: rick.bullotta at thingworx.com (Rick Bullotta) Date: Tue, 8 Oct 2013 12:45:12 +0000 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> References: <5253F266.1050708@threecrickets.com> <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> Message-ID: <46a519bba07a46748cf7a8720311653d@BLUPR06MB001.namprd06.prod.outlook.com> This is actually a great reason to support custom wrap factories/adapters, so that application specific type conversion and name resolution can be done without burdening the script developer of this type of syntax, which, to be honest, would be a bit intimidating. I certainly wouldn't want to ask someone used to writing general purpose JavaScript to have to understand which objects were Java objects and which objects were JS objects. The power can be in the abstraction. I think a focus on a clean syntax is essential if we want Nashorn to empower higher level developers to use scripting (which we have been able to readily achieve with Rhino). Just my $0.02, before taxes. -----Original Message----- From: nashorn-dev-bounces at openjdk.java.net [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of Jim Laskey (Oracle) Sent: Tuesday, October 08, 2013 8:24 AM To: Tal Liron Cc: nashorn-dev at openjdk.java.net Subject: Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays Nashorn does not coerce JS arrays implicitly. There were too many ambiguous cases to do a complete implementation (nested conversions.) In Nashorn you have to; myInstance.myMethod(Java.to(['a', 'b', 'c'], "java.lang.String[]")); or; var StringArray = Java.type("java.lang.String[]"); function args(array) { return Java.to(array, StringArray); } myInstance.myMethod(args(['a', 'b', 'c'])); Cheers, -- Jim On 2013-10-08, at 1:54 PM, Tal Liron wrote: > Lets say we have a Java class with this method: > > class MyClass { > void myMethod(String[] arguments) {} > } > > And in Nashorn we call it like so: > > myInstance.myMethod(['a', 'b', 'c']) > > The JavaScript array seems to be converted into a string (as "a,b,c"), and then wrapped in a Java string array as its single element before sending to Java. > > In Rhino, the above works as expected. From sundararajan.athijegannathan at oracle.com Tue Oct 8 05:47:37 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Oct 2013 14:47:37 +0200 Subject: From JS to Java objects? In-Reply-To: <5253FD5C.4080702@threecrickets.com> References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> <5253F9EB.2000507@threecrickets.com> <5253FD5C.4080702@threecrickets.com> Message-ID: <5253FEE9.8080907@oracle.com> It is recommended that you please stick to jsr223 API on nashorn and use jdk.nashorn.api.scripting.* classes (which provide missing stuff in jsr223). Anything in jdk.internal and jdk.nashorn.internal is ... really internal implementation detail. Thanks -Sundar On Tuesday 08 October 2013 02:41 PM, Tal Liron wrote: > How? It doesn't seem to support the java.util interfaces, whereas > ListAdapter does. > > Also, it seems that the only implementation of JSObject is > ScriptObjectMirror, which is specific to the JSR-223. > > On 10/08/2013 08:38 PM, Jim Laskey (Oracle) wrote: >> You really shouldn't be using internal classes. We can and will be >> changing them over time. Use JSObject instead. >> > From sundararajan.athijegannathan at oracle.com Tue Oct 8 05:49:57 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Oct 2013 14:49:57 +0200 Subject: From JS to Java objects? In-Reply-To: References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> <5253F9EB.2000507@threecrickets.com> Message-ID: <5253FF75.8020909@oracle.com> There is JSAdapter support in nashorn (like jdk6/7 Rhino supported). JSAdapter is used within script to intercept get/put/call etc. Also it is possible to supply your own impl of jdk.nashorn.api.scripting.JSObject -- which can be used with natural script syntax from script. You can intercept calls, property access in your code. Hope this helps -Sundar On Tuesday 08 October 2013 02:32 PM, Rick Bullotta wrote: > On a related topic, I'm particularly interested in better understanding the *Adapter model in Nashorn and how it compares to Rhino, particularly in terms of custom adapters. > > In Rhino, we use custom adapters to intercept get/set/delete/put and other methods to allow dynamic access to a variety of data structures and objects (we can virtualize properties and functions this way, versus automatic reflection and type munging), and it isn't at all clear how to do this with Nashorn. > > -----Original Message----- > From: nashorn-dev-bounces at openjdk.java.net [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of Tal Liron > Sent: Tuesday, October 08, 2013 8:26 AM > To: nashorn-dev at openjdk.java.net > Subject: Re: From JS to Java objects? > > Sorry about that, was trying to be succinct. > > In detail: I'm creating Nashorn scripts programmatically from Java (using Context.compileScript and ScriptRuntime.apply), and receiving native results that need some massaging in order to be usable in Java. > (Specifically I'm working on creating a Nashorn adapter for Scripturian.) > > However, I mostly found the answers myself: > > 1. It's possible to call NativeJava.to (equivalent to Java.to in JavaScript) 2. More efficient is to test specifically for NativeArray results and wrap them in a ListAdapter, which makes them conform to the List interface. This is what NativeJava.to does internally. > > On 10/08/2013 08:12 PM, Jim Laskey (Oracle) wrote: >> Please be more specific with an example. I assume you want to extend >> a Java class or some such requirement, >> From rick.bullotta at thingworx.com Tue Oct 8 05:51:57 2013 From: rick.bullotta at thingworx.com (Rick Bullotta) Date: Tue, 8 Oct 2013 12:51:57 +0000 Subject: From JS to Java objects? In-Reply-To: <5253FF75.8020909@oracle.com> References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> <5253F9EB.2000507@threecrickets.com> <5253FF75.8020909@oracle.com> Message-ID: Awesome. Any examples out there in the ether? -----Original Message----- From: nashorn-dev-bounces at openjdk.java.net [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of A. Sundararajan Sent: Tuesday, October 08, 2013 8:50 AM To: nashorn-dev at openjdk.java.net Subject: Re: From JS to Java objects? There is JSAdapter support in nashorn (like jdk6/7 Rhino supported). JSAdapter is used within script to intercept get/put/call etc. Also it is possible to supply your own impl of jdk.nashorn.api.scripting.JSObject -- which can be used with natural script syntax from script. You can intercept calls, property access in your code. Hope this helps -Sundar On Tuesday 08 October 2013 02:32 PM, Rick Bullotta wrote: > On a related topic, I'm particularly interested in better understanding the *Adapter model in Nashorn and how it compares to Rhino, particularly in terms of custom adapters. > > In Rhino, we use custom adapters to intercept get/set/delete/put and other methods to allow dynamic access to a variety of data structures and objects (we can virtualize properties and functions this way, versus automatic reflection and type munging), and it isn't at all clear how to do this with Nashorn. > > -----Original Message----- > From: nashorn-dev-bounces at openjdk.java.net > [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of Tal Liron > Sent: Tuesday, October 08, 2013 8:26 AM > To: nashorn-dev at openjdk.java.net > Subject: Re: From JS to Java objects? > > Sorry about that, was trying to be succinct. > > In detail: I'm creating Nashorn scripts programmatically from Java (using Context.compileScript and ScriptRuntime.apply), and receiving native results that need some massaging in order to be usable in Java. > (Specifically I'm working on creating a Nashorn adapter for > Scripturian.) > > However, I mostly found the answers myself: > > 1. It's possible to call NativeJava.to (equivalent to Java.to in JavaScript) 2. More efficient is to test specifically for NativeArray results and wrap them in a ListAdapter, which makes them conform to the List interface. This is what NativeJava.to does internally. > > On 10/08/2013 08:12 PM, Jim Laskey (Oracle) wrote: >> Please be more specific with an example. I assume you want to extend >> a Java class or some such requirement, >> From james.laskey at oracle.com Tue Oct 8 05:55:02 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 14:55:02 +0200 Subject: Review request for 8026039: future strict names are allowed as function name and argument name of a strict function In-Reply-To: <5253FBE0.9080605@oracle.com> References: <5253FBE0.9080605@oracle.com> Message-ID: +1 On 2013-10-08, at 2:34 PM, "A. Sundararajan" wrote: > Please review http://cr.openjdk.java.net/~sundar/8026039/ > > -Sundar From sundararajan.athijegannathan at oracle.com Tue Oct 8 05:58:07 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 08 Oct 2013 12:58:07 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026039: future strict names are allowed as function name and argument name of a strict function Message-ID: <20131008125811.2D65662E37@hg.openjdk.java.net> Changeset: 19dba6637f20 Author: sundar Date: 2013-10-08 14:57 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/19dba6637f20 8026039: future strict names are allowed as function name and argument name of a strict function Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/error/JDK-8026039.js + test/script/error/JDK-8026039.js.EXPECTED From james.laskey at oracle.com Tue Oct 8 06:04:25 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 15:04:25 +0200 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <46a519bba07a46748cf7a8720311653d@BLUPR06MB001.namprd06.prod.outlook.com> References: <5253F266.1050708@threecrickets.com> <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> <46a519bba07a46748cf7a8720311653d@BLUPR06MB001.namprd06.prod.outlook.com> Message-ID: <2608CBF1-3377-4726-A96B-6814E0F31129@oracle.com> You could always create your own Dynalink linker plug in to do the wrappers you need. Sundar will follow up. On 2013-10-08, at 2:45 PM, Rick Bullotta wrote: > This is actually a great reason to support custom wrap factories/adapters, so that application specific type conversion and name resolution can be done without burdening the script developer of this type of syntax, which, to be honest, would be a bit intimidating. I certainly wouldn't want to ask someone used to writing general purpose JavaScript to have to understand which objects were Java objects and which objects were JS objects. The power can be in the abstraction. I think a focus on a clean syntax is essential if we want Nashorn to empower higher level developers to use scripting (which we have been able to readily achieve with Rhino). > > Just my $0.02, before taxes. > > -----Original Message----- > From: nashorn-dev-bounces at openjdk.java.net [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of Jim Laskey (Oracle) > Sent: Tuesday, October 08, 2013 8:24 AM > To: Tal Liron > Cc: nashorn-dev at openjdk.java.net > Subject: Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays > > Nashorn does not coerce JS arrays implicitly. There were too many ambiguous cases to do a complete implementation (nested conversions.) In Nashorn you have to; > > myInstance.myMethod(Java.to(['a', 'b', 'c'], "java.lang.String[]")); > > or; > > var StringArray = Java.type("java.lang.String[]"); function args(array) { > return Java.to(array, StringArray); > } > > myInstance.myMethod(args(['a', 'b', 'c'])); > > Cheers, > > -- Jim > > > On 2013-10-08, at 1:54 PM, Tal Liron wrote: > >> Lets say we have a Java class with this method: >> >> class MyClass { >> void myMethod(String[] arguments) {} >> } >> >> And in Nashorn we call it like so: >> >> myInstance.myMethod(['a', 'b', 'c']) >> >> The JavaScript array seems to be converted into a string (as "a,b,c"), and then wrapped in a Java string array as its single element before sending to Java. >> >> In Rhino, the above works as expected. > From rick.bullotta at thingworx.com Tue Oct 8 06:05:35 2013 From: rick.bullotta at thingworx.com (Rick Bullotta) Date: Tue, 8 Oct 2013 13:05:35 +0000 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <2608CBF1-3377-4726-A96B-6814E0F31129@oracle.com> References: <5253F266.1050708@threecrickets.com> <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> <46a519bba07a46748cf7a8720311653d@BLUPR06MB001.namprd06.prod.outlook.com> <2608CBF1-3377-4726-A96B-6814E0F31129@oracle.com> Message-ID: <8506748dff3c4e9c90b618bfc5a60a2c@BLUPR06MB001.namprd06.prod.outlook.com> Excellent. Looking forward to learning more and getting a prototype up and running. -----Original Message----- From: Jim Laskey (Oracle) [mailto:james.laskey at oracle.com] Sent: Tuesday, October 08, 2013 9:04 AM To: Rick Bullotta Cc: Tal Liron; nashorn-dev at openjdk.java.net Subject: Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays You could always create your own Dynalink linker plug in to do the wrappers you need. Sundar will follow up. On 2013-10-08, at 2:45 PM, Rick Bullotta wrote: > This is actually a great reason to support custom wrap factories/adapters, so that application specific type conversion and name resolution can be done without burdening the script developer of this type of syntax, which, to be honest, would be a bit intimidating. I certainly wouldn't want to ask someone used to writing general purpose JavaScript to have to understand which objects were Java objects and which objects were JS objects. The power can be in the abstraction. I think a focus on a clean syntax is essential if we want Nashorn to empower higher level developers to use scripting (which we have been able to readily achieve with Rhino). > > Just my $0.02, before taxes. > > -----Original Message----- > From: nashorn-dev-bounces at openjdk.java.net [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of Jim Laskey (Oracle) > Sent: Tuesday, October 08, 2013 8:24 AM > To: Tal Liron > Cc: nashorn-dev at openjdk.java.net > Subject: Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays > > Nashorn does not coerce JS arrays implicitly. There were too many ambiguous cases to do a complete implementation (nested conversions.) In Nashorn you have to; > > myInstance.myMethod(Java.to(['a', 'b', 'c'], "java.lang.String[]")); > > or; > > var StringArray = Java.type("java.lang.String[]"); function args(array) { > return Java.to(array, StringArray); > } > > myInstance.myMethod(args(['a', 'b', 'c'])); > > Cheers, > > -- Jim > > > On 2013-10-08, at 1:54 PM, Tal Liron wrote: > >> Lets say we have a Java class with this method: >> >> class MyClass { >> void myMethod(String[] arguments) {} >> } >> >> And in Nashorn we call it like so: >> >> myInstance.myMethod(['a', 'b', 'c']) >> >> The JavaScript array seems to be converted into a string (as "a,b,c"), and then wrapped in a Java string array as its single element before sending to Java. >> >> In Rhino, the above works as expected. > From sundararajan.athijegannathan at oracle.com Tue Oct 8 06:05:57 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Oct 2013 15:05:57 +0200 Subject: From JS to Java objects? In-Reply-To: References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> <5253F9EB.2000507@threecrickets.com> <5253FF75.8020909@oracle.com> Message-ID: <52540335.2050102@oracle.com> There are tests under $nashorn/test/ directory has tests that demonstrate the use of JSAdapter and JSObject (from outside). I am not sure if "Java Scripting Programmer's Guide" has JSAdapter or not. Pluggable JSObject is a more recent thing. -Sundar On Tuesday 08 October 2013 02:51 PM, Rick Bullotta wrote: > Awesome. Any examples out there in the ether? > > -----Original Message----- > From: nashorn-dev-bounces at openjdk.java.net [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of A. Sundararajan > Sent: Tuesday, October 08, 2013 8:50 AM > To: nashorn-dev at openjdk.java.net > Subject: Re: From JS to Java objects? > > There is JSAdapter support in nashorn (like jdk6/7 Rhino supported). > JSAdapter is used within script to intercept get/put/call etc. Also it is possible to supply your own impl of jdk.nashorn.api.scripting.JSObject -- which can be used with natural script syntax from script. You can intercept calls, property access in your code. > > Hope this helps > -Sundar > > On Tuesday 08 October 2013 02:32 PM, Rick Bullotta wrote: >> On a related topic, I'm particularly interested in better understanding the *Adapter model in Nashorn and how it compares to Rhino, particularly in terms of custom adapters. >> >> In Rhino, we use custom adapters to intercept get/set/delete/put and other methods to allow dynamic access to a variety of data structures and objects (we can virtualize properties and functions this way, versus automatic reflection and type munging), and it isn't at all clear how to do this with Nashorn. >> >> -----Original Message----- >> From: nashorn-dev-bounces at openjdk.java.net >> [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of Tal Liron >> Sent: Tuesday, October 08, 2013 8:26 AM >> To: nashorn-dev at openjdk.java.net >> Subject: Re: From JS to Java objects? >> >> Sorry about that, was trying to be succinct. >> >> In detail: I'm creating Nashorn scripts programmatically from Java (using Context.compileScript and ScriptRuntime.apply), and receiving native results that need some massaging in order to be usable in Java. >> (Specifically I'm working on creating a Nashorn adapter for >> Scripturian.) >> >> However, I mostly found the answers myself: >> >> 1. It's possible to call NativeJava.to (equivalent to Java.to in JavaScript) 2. More efficient is to test specifically for NativeArray results and wrap them in a ListAdapter, which makes them conform to the List interface. This is what NativeJava.to does internally. >> >> On 10/08/2013 08:12 PM, Jim Laskey (Oracle) wrote: >>> Please be more specific with an example. I assume you want to extend >>> a Java class or some such requirement, >>> From rick.bullotta at thingworx.com Tue Oct 8 06:08:11 2013 From: rick.bullotta at thingworx.com (Rick Bullotta) Date: Tue, 8 Oct 2013 13:08:11 +0000 Subject: From JS to Java objects? In-Reply-To: <52540335.2050102@oracle.com> References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> <5253F9EB.2000507@threecrickets.com> <5253FF75.8020909@oracle.com> <52540335.2050102@oracle.com> Message-ID: Just checked. No info yet on JSAdapter or JSObject in the Java Scripting Programmer's Guide. -----Original Message----- From: A. Sundararajan [mailto:sundararajan.athijegannathan at oracle.com] Sent: Tuesday, October 08, 2013 9:06 AM To: Rick Bullotta; nashorn-dev at openjdk.java.net Subject: Re: From JS to Java objects? There are tests under $nashorn/test/ directory has tests that demonstrate the use of JSAdapter and JSObject (from outside). I am not sure if "Java Scripting Programmer's Guide" has JSAdapter or not. Pluggable JSObject is a more recent thing. -Sundar On Tuesday 08 October 2013 02:51 PM, Rick Bullotta wrote: > Awesome. Any examples out there in the ether? > > -----Original Message----- > From: nashorn-dev-bounces at openjdk.java.net > [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of A. > Sundararajan > Sent: Tuesday, October 08, 2013 8:50 AM > To: nashorn-dev at openjdk.java.net > Subject: Re: From JS to Java objects? > > There is JSAdapter support in nashorn (like jdk6/7 Rhino supported). > JSAdapter is used within script to intercept get/put/call etc. Also it is possible to supply your own impl of jdk.nashorn.api.scripting.JSObject -- which can be used with natural script syntax from script. You can intercept calls, property access in your code. > > Hope this helps > -Sundar > > On Tuesday 08 October 2013 02:32 PM, Rick Bullotta wrote: >> On a related topic, I'm particularly interested in better understanding the *Adapter model in Nashorn and how it compares to Rhino, particularly in terms of custom adapters. >> >> In Rhino, we use custom adapters to intercept get/set/delete/put and other methods to allow dynamic access to a variety of data structures and objects (we can virtualize properties and functions this way, versus automatic reflection and type munging), and it isn't at all clear how to do this with Nashorn. >> >> -----Original Message----- >> From: nashorn-dev-bounces at openjdk.java.net >> [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of Tal Liron >> Sent: Tuesday, October 08, 2013 8:26 AM >> To: nashorn-dev at openjdk.java.net >> Subject: Re: From JS to Java objects? >> >> Sorry about that, was trying to be succinct. >> >> In detail: I'm creating Nashorn scripts programmatically from Java (using Context.compileScript and ScriptRuntime.apply), and receiving native results that need some massaging in order to be usable in Java. >> (Specifically I'm working on creating a Nashorn adapter for >> Scripturian.) >> >> However, I mostly found the answers myself: >> >> 1. It's possible to call NativeJava.to (equivalent to Java.to in JavaScript) 2. More efficient is to test specifically for NativeArray results and wrap them in a ListAdapter, which makes them conform to the List interface. This is what NativeJava.to does internally. >> >> On 10/08/2013 08:12 PM, Jim Laskey (Oracle) wrote: >>> Please be more specific with an example. I assume you want to >>> extend a Java class or some such requirement, >>> From hannes.wallnoefer at oracle.com Tue Oct 8 06:46:14 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 08 Oct 2013 15:46:14 +0200 Subject: Review request for JDK-8026042 Message-ID: <52540CA6.5090301@oracle.com> Please review JDK-8026042: FoldConstants need to guard against ArrayLiteralNode: http://cr.openjdk.java.net/~hannesw/8026042/ Thanks, Hannes From hannes.wallnoefer at oracle.com Tue Oct 8 06:54:34 2013 From: hannes.wallnoefer at oracle.com (hannes.wallnoefer at oracle.com) Date: Tue, 08 Oct 2013 13:54:34 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026042: FoldConstants need to guard against ArrayLiteralNode Message-ID: <20131008135436.E75E762E3C@hg.openjdk.java.net> Changeset: c9921761903b Author: hannesw Date: 2013-10-08 15:53 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/c9921761903b 8026042: FoldConstants need to guard against ArrayLiteralNode Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + test/script/basic/JDK-8026042.js + test/script/basic/JDK-8026042.js.EXPECTED From james.laskey at oracle.com Tue Oct 8 07:03:18 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 16:03:18 +0200 Subject: Review request for JDK-8026042 In-Reply-To: <52540CA6.5090301@oracle.com> References: <52540CA6.5090301@oracle.com> Message-ID: <2E0DD57C-82A9-4E1C-8477-F2CC975FF5C6@oracle.com> +1 On 2013-10-08, at 3:46 PM, Hannes Wallnoefer wrote: > Please review JDK-8026042: FoldConstants need to guard against ArrayLiteralNode: > > http://cr.openjdk.java.net/~hannesw/8026042/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Tue Oct 8 07:17:07 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 08 Oct 2013 16:17:07 +0200 Subject: Review request for 8026048: Function constructor should convert arguments to String before performing any syntax checks Message-ID: <525413E3.3040908@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026048/ -Sundar From james.laskey at oracle.com Tue Oct 8 07:20:07 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 8 Oct 2013 16:20:07 +0200 Subject: Review request for 8026048: Function constructor should convert arguments to String before performing any syntax checks In-Reply-To: <525413E3.3040908@oracle.com> References: <525413E3.3040908@oracle.com> Message-ID: <0B8FE764-161C-406F-91F0-88A85136A3DB@oracle.com> +1 On 2013-10-08, at 4:17 PM, "A. Sundararajan" wrote: > Please review http://cr.openjdk.java.net/~sundar/8026048/ > > -Sundar From sundararajan.athijegannathan at oracle.com Tue Oct 8 07:46:25 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 08 Oct 2013 14:46:25 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026048: Function constructor should convert arguments to String before performing any syntax checks Message-ID: <20131008144627.B173F62E41@hg.openjdk.java.net> Changeset: 346ba5b8a488 Author: sundar Date: 2013-10-08 16:46 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/346ba5b8a488 8026048: Function constructor should convert arguments to String before performing any syntax checks Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeFunction.java + test/script/basic/JDK-8026048.js From tal.liron at threecrickets.com Tue Oct 8 07:49:27 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 8 Oct 2013 22:49:27 +0800 Subject: From JS to Java objects? In-Reply-To: <5253FEE9.8080907@oracle.com> References: <5253E486.3060304@threecrickets.com> <20F32AE8-1989-4D64-99F5-B1A2BB0C0F99@oracle.com> <5253EA9F.60007@threecrickets.com> <890E6C61-A864-4851-9337-63F43C24B583@oracle.com> <5253F9EB.2000507@threecrickets.com> <5253FD5C.4080702@threecrickets.com> <5253FEE9.8080907@oracle.com> Message-ID: I appreciate this recommendation, but as the main developer on Scripturian, which is a scalable alternative to JSR-223 with a well-defined threading model, I really do have to bypass JSR-223 and call the internal classes. I know it means that breakage can happen with future versions, which is why Scripturian support states clearly which versions it works for. I'm hoping for better collaboration in standardizing these things, which is why I'm asking questions on this mailing list... On Tue, Oct 8, 2013 at 8:47 PM, A. Sundararajan wrote: > It is recommended that you please stick to jsr223 API on nashorn and use > jdk.nashorn.api.scripting.* classes (which provide missing stuff in jsr223). > Anything in jdk.internal and jdk.nashorn.internal is ... really internal > implementation detail. > > Thanks > -Sundar > > > On Tuesday 08 October 2013 02:41 PM, Tal Liron wrote: >> >> How? It doesn't seem to support the java.util interfaces, whereas >> ListAdapter does. >> >> Also, it seems that the only implementation of JSObject is >> ScriptObjectMirror, which is specific to the JSR-223. >> >> On 10/08/2013 08:38 PM, Jim Laskey (Oracle) wrote: >>> >>> You really shouldn't be using internal classes. We can and will be >>> changing them over time. Use JSObject instead. >>> >> > From tal.liron at threecrickets.com Tue Oct 8 12:02:57 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 03:02:57 +0800 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <2608CBF1-3377-4726-A96B-6814E0F31129@oracle.com> References: <5253F266.1050708@threecrickets.com> <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> <46a519bba07a46748cf7a8720311653d@BLUPR06MB001.namprd06.prod.outlook.com> <2608CBF1-3377-4726-A96B-6814E0F31129@oracle.com> Message-ID: <525456E1.5050702@threecrickets.com> Until he follows up, here's how I *think* it works from looking at the code: Argument conversion is handled by GuardingTypeConverterFactory instances. In Nashorn, these are NashornLinker and NashornPrimitiveLinker. Custom converters are loaded with a ServiceLoader, and thus can be defined in META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker. If any of those instances also implement GuardingTypeConverterFactory, then they are added to the converter chain. But I have to say that beyond that the code is hard to follow... conversion is actually handled with dynamic links so it's somewhat "meta" programming at that stage. I'm also unclear as to which converter is selected if multiple are available... Any tips towards helping me find a solution to my issue would be appreciated. Indeed, a simple skeleton for a custom linker would be great! On 10/08/2013 09:04 PM, Jim Laskey (Oracle) wrote: > You could always create your own Dynalink linker plug in to do the wrappers you need. Sundar will follow up. > From tal.liron at threecrickets.com Tue Oct 8 23:43:35 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 14:43:35 +0800 Subject: Bug report: NPE in DebugLogger.levelAbove Message-ID: <5254FB17.3050500@threecrickets.com> The code uses Logger.getLevel(), but doesn't take into account that the value could be null. Exception trace: java.lang.NullPointerException at jdk.nashorn.internal.runtime.DebugLogger.levelAbove(DebugLogger.java:129) at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:352) at jdk.nashorn.internal.runtime.Context.compile(Context.java:887) at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:844) at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:387) From james.laskey at oracle.com Wed Oct 9 00:53:04 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 9 Oct 2013 09:53:04 +0200 Subject: Bug report: NPE in DebugLogger.levelAbove In-Reply-To: <5254FB17.3050500@threecrickets.com> References: <5254FB17.3050500@threecrickets.com> Message-ID: <5B6FF9D7-1552-4552-960F-288FCABB8DD3@oracle.com> Are you multi-threading? On 2013-10-09, at 8:43 AM, Tal Liron wrote: > The code uses Logger.getLevel(), but doesn't take into account that the value could be null. Exception trace: > > java.lang.NullPointerException > at jdk.nashorn.internal.runtime.DebugLogger.levelAbove(DebugLogger.java:129) > at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:352) > at jdk.nashorn.internal.runtime.Context.compile(Context.java:887) > at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:844) > at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:387) > From james.laskey at oracle.com Wed Oct 9 01:15:59 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 9 Oct 2013 10:15:59 +0200 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <525456E1.5050702@threecrickets.com> References: <5253F266.1050708@threecrickets.com> <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> <46a519bba07a46748cf7a8720311653d@BLUPR06MB001.namprd06.prod.outlook.com> <2608CBF1-3377-4726-A96B-6814E0F31129@oracle.com> <525456E1.5050702@threecrickets.com> Message-ID: After consideration and from my own experiences, I'm going to add as a feature request. However, code freeze is next week, so it's extremely likely this will not show up until first non-security update. JDK-8026113 Cheers, -- Jim On 2013-10-08, at 9:02 PM, Tal Liron wrote: > Until he follows up, here's how I *think* it works from looking at the code: > > Argument conversion is handled by GuardingTypeConverterFactory instances. In Nashorn, these are NashornLinker and NashornPrimitiveLinker. > > Custom converters are loaded with a ServiceLoader, and thus can be defined in META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker. If any of those instances also implement GuardingTypeConverterFactory, then they are added to the converter chain. > > But I have to say that beyond that the code is hard to follow... conversion is actually handled with dynamic links so it's somewhat "meta" programming at that stage. I'm also unclear as to which converter is selected if multiple are available... > > Any tips towards helping me find a solution to my issue would be appreciated. Indeed, a simple skeleton for a custom linker would be great! > > On 10/08/2013 09:04 PM, Jim Laskey (Oracle) wrote: >> You could always create your own Dynalink linker plug in to do the wrappers you need. Sundar will follow up. >> > From sundararajan.athijegannathan at oracle.com Wed Oct 9 01:34:07 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 09 Oct 2013 10:34:07 +0200 Subject: Review request for 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object Message-ID: <525514FF.6040209@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026112/ -Sundar From hannes.wallnoefer at oracle.com Wed Oct 9 01:47:31 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 09 Oct 2013 10:47:31 +0200 Subject: Review request for JDK-8026008: Constant folding removes var statement Message-ID: <52551823.3020401@oracle.com> Please review JDK-8026008: Constant folding removes var statement: http://cr.openjdk.java.net/~hannesw/8026008/ Thanks, Hannes From hannes.wallnoefer at oracle.com Wed Oct 9 01:48:12 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 09 Oct 2013 10:48:12 +0200 Subject: Review request for 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object In-Reply-To: <525514FF.6040209@oracle.com> References: <525514FF.6040209@oracle.com> Message-ID: <5255184C.2020906@oracle.com> Looks good to me. Hannes Am 2013-10-09 10:34, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8026112/ > > -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 9 01:48:17 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 09 Oct 2013 08:48:17 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object Message-ID: <20131009084820.D6C7A62E77@hg.openjdk.java.net> Changeset: 8d29733ad609 Author: sundar Date: 2013-10-09 10:47 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/8d29733ad609 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026112.js From attila.szegedi at oracle.com Wed Oct 9 01:50:45 2013 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 9 Oct 2013 10:50:45 +0200 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <525456E1.5050702@threecrickets.com> References: <5253F266.1050708@threecrickets.com> <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> <46a519bba07a46748cf7a8720311653d@BLUPR06MB001.namprd06.prod.outlook.com> <2608CBF1-3377-4726-A96B-6814E0F31129@oracle.com> <525456E1.5050702@threecrickets.com> Message-ID: <85BC5B5D-5D2E-441C-B352-D5FE0F5F5737@oracle.com> Well, the API of GuardingTypeConverterFactory should be fairly straightforward: you're asked for a conversion from a type to a type, you're supposed to return a conditional invocation (invocation with a guard). What you'd do is react to any calls where to.isArray() == false with null, and to.isArray() == true with a newly created GuardedInvocation where the guard is a method handle for "object instance of ScriptObject", and invocation is basically a method handle to NativeJava.to() with the appropriate type parameter bound. Note that this'll also incidentally work for conversion to multidimensional array types (e.g. int[][] parameter target passed a [[1,2][3,4]]) as in the Java.to() implementation elements are converted elementwise to the target component type using the full type conversion machinery of Dynalink, consulting all the discovered type converter factories. The reason I was uncomfortable providing this conversion as an implicit conversion is that I still think there's no single correct way to do it, as there's many strategies with multiple valid choices in the conversion: 1. Do you generally recursively convert elements, or only to the depth indicated by the number of dimensions on the target array type? Given a target of Object[], and a value of [ [ [1, 2], [3, 4] ], [5, 6] ], do you also convert nested arrays or not? If yes, to what type? Object[]? List? (Proving all elements in every nested array can be represented as int[] would be an O(n) time additional operation). An obvious choice is not converting beyond the depth indicated by the target type dimension. By implication, automatic conversion to java.util.List will never have nested conversions, as they're one dimensional. 2. If you do nested conversions, can you guarantee that none of the arrays contains itself as an element? If not, you need to maintain a stack of currently converted elements to detect a cycle otherwise you end up with a StackOverflowError. If you can guarantee no array contains itself as an element, then maintaining a stack is a waste of time and memory. (Note: java.util.Arrays.deepHashCode, and deepEquals explicitly have undefined behavior for directly or indirecrly self-referencing arrays, either design choice is valid under different requirements). 3. When you detect a cycle, do you throw an error (like JSON.stringify() does), or do you short-circuit and use the already existing, half-converted object in its place? True, none of these affect conversion of single-dimensional arrays, or conversion of arrays to target primitive types. But then we also don't like providing half-solutions, and a general complete solution needs to address the above questions too. Then there are other strategy choices too, although we made a design decision on them already with Java.to(), but I'm including them for sake of completeness: 1. If you have repeated elements in an Object[] array, do you convert them to objects of different identities, or do you canonicalize them? (Java.to() doesn't canonicalize, as it might require another O(n) or more memory). 2. What do you do with undefined elements in a sparse array? (We fill out with JS equivalent of Undefined for the array element type.) 3. Back to automatic conversion to List vs. Object[]: is it okay to always have a List being live-backed by the JS array, but Object[] being a copy? Shouldn't the List then also always be a copy? (Java.to does a live-backed List and obviously must have a copy array). Anyway, my general feeling was that it's better to give people an explicit API for array conversion than to hide a lot of implicit behavior in an automatic conversion, especially behavior that can have size and time requirements linear to the size of the input array. Attila. On Oct 8, 2013, at 9:02 PM, Tal Liron wrote: > Until he follows up, here's how I *think* it works from looking at the code: > > Argument conversion is handled by GuardingTypeConverterFactory instances. In Nashorn, these are NashornLinker and NashornPrimitiveLinker. > > Custom converters are loaded with a ServiceLoader, and thus can be defined in META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker. If any of those instances also implement GuardingTypeConverterFactory, then they are added to the converter chain. > > But I have to say that beyond that the code is hard to follow... conversion is actually handled with dynamic links so it's somewhat "meta" programming at that stage. I'm also unclear as to which converter is selected if multiple are available... > > Any tips towards helping me find a solution to my issue would be appreciated. Indeed, a simple skeleton for a custom linker would be great! > > On 10/08/2013 09:04 PM, Jim Laskey (Oracle) wrote: >> You could always create your own Dynalink linker plug in to do the wrappers you need. Sundar will follow up. >> > From sundararajan.athijegannathan at oracle.com Wed Oct 9 02:00:50 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 09 Oct 2013 11:00:50 +0200 Subject: Review request for JDK-8026008: Constant folding removes var statement In-Reply-To: <52551823.3020401@oracle.com> References: <52551823.3020401@oracle.com> Message-ID: <52551B42.7050508@oracle.com> +1 On Wednesday 09 October 2013 10:47 AM, Hannes Wallnoefer wrote: > Please review JDK-8026008: Constant folding removes var statement: > > http://cr.openjdk.java.net/~hannesw/8026008/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Wed Oct 9 03:15:56 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 09 Oct 2013 12:15:56 +0200 Subject: Review request for 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime.ScriptObject Message-ID: <52552CDC.9070806@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026125/ -Sundar From hannes.wallnoefer at oracle.com Wed Oct 9 04:26:45 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 09 Oct 2013 13:26:45 +0200 Subject: Review request for 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime.ScriptObject In-Reply-To: <52552CDC.9070806@oracle.com> References: <52552CDC.9070806@oracle.com> Message-ID: <52553D75.6040106@oracle.com> +1 Am 2013-10-09 12:15, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8026125/ > > -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 9 04:26:48 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 09 Oct 2013 11:26:48 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime.ScriptObject Message-ID: <20131009112651.198E862E82@hg.openjdk.java.net> Changeset: 1e03d7caa68b Author: sundar Date: 2013-10-09 13:26 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/1e03d7caa68b 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime.ScriptObject Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8026125.js From hannes.wallnoefer at oracle.com Wed Oct 9 05:51:57 2013 From: hannes.wallnoefer at oracle.com (hannes.wallnoefer at oracle.com) Date: Wed, 09 Oct 2013 12:51:57 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026008: Constant folding removes var statement Message-ID: <20131009125200.A5E7D62E85@hg.openjdk.java.net> Changeset: ec3094d9d5d5 Author: hannesw Date: 2013-10-09 14:50 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/ec3094d9d5d5 8026008: Constant folding removes var statement Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/FoldConstants.java + test/script/basic/JDK-8026008.js + test/script/basic/JDK-8026008.js.EXPECTED From tal.liron at threecrickets.com Wed Oct 9 06:12:39 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 21:12:39 +0800 Subject: Bug report: NPE in DebugLogger.levelAbove In-Reply-To: <5B6FF9D7-1552-4552-960F-288FCABB8DD3@oracle.com> References: <5254FB17.3050500@threecrickets.com> <5B6FF9D7-1552-4552-960F-288FCABB8DD3@oracle.com> Message-ID: <52555647.4000008@threecrickets.com> Not in this case. But in any case, Logger.getLevel may very well return null by its implementation and documentation. On 10/09/2013 03:53 PM, Jim Laskey (Oracle) wrote: > Are you multi-threading? > > > On 2013-10-09, at 8:43 AM, Tal Liron wrote: > >> The code uses Logger.getLevel(), but doesn't take into account that the value could be null. Exception trace: >> From tal.liron at threecrickets.com Wed Oct 9 06:20:12 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 21:20:12 +0800 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <85BC5B5D-5D2E-441C-B352-D5FE0F5F5737@oracle.com> References: <5253F266.1050708@threecrickets.com> <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> <46a519bba07a46748cf7a8720311653d@BLUPR06MB001.namprd06.prod.outlook.com> <2608CBF1-3377-4726-A96B-6814E0F31129@oracle.com> <525456E1.5050702@threecrickets.com> <85BC5B5D-5D2E-441C-B352-D5FE0F5F5737@oracle.com> Message-ID: <5255580C.1040307@threecrickets.com> Thank you for this, it's still a bit hard to follow but I will give it a try. I should state that I entirely agree with you regarding the ambiguity of coercion, but I think the problem is minimized when you document the limitations. You can't support everything--by definition--but you can allow for some common shortcuts. And recall Rick's comment: it's behavior that users simply expect. Worse still, the current behavior would not only seem "broken" for some, but it's also very hard to debug: a concatenated string instead of an array of arguments? It took me an hour of poking around to understand what was going wrong. Furthermore, a more general point: It's crucial for the Nashorn project not to forget the vast amount of Rhino code out there. Even when Rhino might seem quirky, it would still be very good to support these quirks, even with an optional flag. I have tens of thousands of lines of code for Rhino, and it's daunting to have to find and catch all these calls, especially when often these arrays are constructed dynamically. Nashorn has an a huge legacy in Rhino: but you should treat it as a benefit, not a problem! On 10/09/2013 04:50 PM, Attila Szegedi wrote: > Well, the API of GuardingTypeConverterFactory should be fairly straightforward: you're asked for a conversion from a type to a type, you're supposed to return a conditional invocation (invocation with a guard). What you'd do is react to any calls where to.isArray() == false with null, and to.isArray() == true with a newly created GuardedInvocation where the guard is a method handle for "object instance of ScriptObject", and invocation is basically a method handle to NativeJava.to() with the appropriate type parameter bound. > > Note that this'll also incidentally work for conversion to multidimensional array types (e.g. int[][] parameter target passed a [[1,2][3,4]]) as in the Java.to() implementation elements are converted elementwise to the target component type using the full type conversion machinery of Dynalink, consulting all the discovered type converter factories. > > The reason I was uncomfortable providing this conversion as an implicit conversion is that I still think there's no single correct way to do it, as there's many strategies with multiple valid choices in the conversion: > > 1. Do you generally recursively convert elements, or only to the depth indicated by the number of dimensions on the target array type? Given a target of Object[], and a value of [ [ [1, 2], [3, 4] ], [5, 6] ], do you also convert nested arrays or not? If yes, to what type? Object[]? List? (Proving all elements in every nested array can be represented as int[] would be an O(n) time additional operation). An obvious choice is not converting beyond the depth indicated by the target type dimension. By implication, automatic conversion to java.util.List will never have nested conversions, as they're one dimensional. > 2. If you do nested conversions, can you guarantee that none of the arrays contains itself as an element? If not, you need to maintain a stack of currently converted elements to detect a cycle otherwise you end up with a StackOverflowError. If you can guarantee no array contains itself as an element, then maintaining a stack is a waste of time and memory. (Note: java.util.Arrays.deepHashCode, and deepEquals explicitly have undefined behavior for directly or indirecrly self-referencing arrays, either design choice is valid under different requirements). > 3. When you detect a cycle, do you throw an error (like JSON.stringify() does), or do you short-circuit and use the already existing, half-converted object in its place? > > True, none of these affect conversion of single-dimensional arrays, or conversion of arrays to target primitive types. But then we also don't like providing half-solutions, and a general complete solution needs to address the above questions too. > > Then there are other strategy choices too, although we made a design decision on them already with Java.to(), but I'm including them for sake of completeness: > > 1. If you have repeated elements in an Object[] array, do you convert them to objects of different identities, or do you canonicalize them? (Java.to() doesn't canonicalize, as it might require another O(n) or more memory). > 2. What do you do with undefined elements in a sparse array? (We fill out with JS equivalent of Undefined for the array element type.) > 3. Back to automatic conversion to List vs. Object[]: is it okay to always have a List being live-backed by the JS array, but Object[] being a copy? Shouldn't the List then also always be a copy? (Java.to does a live-backed List and obviously must have a copy array). > > Anyway, my general feeling was that it's better to give people an explicit API for array conversion than to hide a lot of implicit behavior in an automatic conversion, especially behavior that can have size and time requirements linear to the size of the input array. > > Attila. > > On Oct 8, 2013, at 9:02 PM, Tal Liron wrote: > >> Until he follows up, here's how I *think* it works from looking at the code: >> >> Argument conversion is handled by GuardingTypeConverterFactory instances. In Nashorn, these are NashornLinker and NashornPrimitiveLinker. >> >> Custom converters are loaded with a ServiceLoader, and thus can be defined in META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker. If any of those instances also implement GuardingTypeConverterFactory, then they are added to the converter chain. >> >> But I have to say that beyond that the code is hard to follow... conversion is actually handled with dynamic links so it's somewhat "meta" programming at that stage. I'm also unclear as to which converter is selected if multiple are available... >> >> Any tips towards helping me find a solution to my issue would be appreciated. Indeed, a simple skeleton for a custom linker would be great! >> >> On 10/08/2013 09:04 PM, Jim Laskey (Oracle) wrote: >>> You could always create your own Dynalink linker plug in to do the wrappers you need. Sundar will follow up. >>> From tal.liron at threecrickets.com Wed Oct 9 06:42:20 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 21:42:20 +0800 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: References: <5253F266.1050708@threecrickets.com> <3AA3B23D-A4A3-4C53-AE66-E99E1904F54B@oracle.com> <46a519bba07a46748cf7a8720311653d@BLUPR06MB001.namprd06.prod.outlook.com> <2608CBF1-3377-4726-A96B-6814E0F31129@oracle.com> <525456E1.5050702@threecrickets.com> Message-ID: <52555D3C.50901@threecrickets.com> I deem this feature important for Nashorn's adoption: if I could submit a patch soon, would it be possible to make it in time for release? On 10/09/2013 04:15 PM, Jim Laskey (Oracle) wrote: > After consideration and from my own experiences, I'm going to add as a > feature request. However, code freeze is next week, so it's extremely > likely this will not show up until first non-security update. > > JDK-8026113 > From tal.liron at threecrickets.com Wed Oct 9 07:13:24 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 22:13:24 +0800 Subject: Bug report: can't call static methods on a Java class instance Message-ID: <52556484.4050107@threecrickets.com> If we have a Java class: class MyClass { public static void myMethod(); } And in JavaScript try: myInstance.myMethod() Then we would get an exception that looks something like this: myscript.js:... TypeError: MyClass at ... has no such function "myMethod" 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.linker.NashornBottomLinker.linkBean(NashornBottomLinker.java:113) at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:68) at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:138) at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) at jdk.nashorn.internal.scripts.Script$default.runScript(component/services/sincerity/version/default.js:6) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) From tal.liron at threecrickets.com Wed Oct 9 07:18:31 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 22:18:31 +0800 Subject: Bug report: can't overcome Java method ambiguity in some clear cases Message-ID: <525565B7.1010605@threecrickets.com> Here's a particular exception I got: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.lang.String, java.lang.String), (int, java.lang.Object)] of the method org.restlet.util.Series.set for argument types [java.lang.String, java.lang.Integer] at jdk.internal.dynalink.beans.OverloadedMethod.throwAmbiguousMethod(OverloadedMethod.java:222) at jdk.nashorn.internal.scripts.Script$http.runScript(component/clients/http.js:12) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) at com.threecrickets.scripturian.adapter.NashornProgram.execute(NashornProgram.java:83) at com.threecrickets.scripturian.Executable.execute(Executable.java:838) at com.threecrickets.scripturian.service.DocumentService.execute(DocumentService.java:154) at jdk.nashorn.internal.scripts.Script$container._L28$_L63(sincerity/container.js:72) at jdk.nashorn.internal.scripts.Script$container._L28$_L82(sincerity/container.js:108) at jdk.nashorn.internal.scripts.Script$default.runScript(component/default.js:57) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) However, it seems rather clear that the first signature is suitable, with the second argument to be coerced into a string. (This works correctly in Rhino.) From james.laskey at oracle.com Wed Oct 9 07:28:34 2013 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 9 Oct 2013 07:28:34 -0700 (PDT) Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays Message-ID: If you can get the changes to me by Tuesday Oct 15th, I'll take a look. No guarantees, but if the changes are small, are correct, and do not restrict future enhancements in this area then I'll run the changes up the approval chain. Cheers, -- Jim ----- Original Message ----- From: tal.liron at threecrickets.com To: nashorn-dev at openjdk.java.net Sent: Wednesday, October 9, 2013 3:51:10 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays I deem this feature important for Nashorn's adoption: if I could submit a patch soon, would it be possible to make it in time for release? On 10/09/2013 04:15 PM, Jim Laskey (Oracle) wrote: > After consideration and from my own experiences, I'm going to add as a > feature request. However, code freeze is next week, so it's extremely > likely this will not show up until first non-security update. > > JDK-8026113 > From tal.liron at threecrickets.com Wed Oct 9 07:28:45 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 22:28:45 +0800 Subject: Bug Report: importClass in mozilla_compat.js only supports a single arguments Message-ID: <5255681D.6030709@threecrickets.com> In Rhino this works: importClass(java.util.LinkedList, java.util.HashMap) But Nashorn will only import the first class. From andreas.woess at jku.at Wed Oct 9 07:43:06 2013 From: andreas.woess at jku.at (Andreas Woess) Date: Wed, 09 Oct 2013 16:43:06 +0200 Subject: Bug report: can't overcome Java method ambiguity in some clear cases In-Reply-To: <525565B7.1010605@threecrickets.com> References: <525565B7.1010605@threecrickets.com> Message-ID: <52556B7A.1060607@jku.at> I'd like to add to this bug report: jjs> new java.awt.Color(0.5,0.5,0.5) java.awt.Color[r=128,g=128,b=128] jjs> new java.awt.Color(1.0,0.5,0.5) java.lang.RuntimeException: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(float, float, float), (int, int, int)] of the method java.awt.Color. for argument types [java.lang.Integer, java.lang.Double, java.lang.Double] I would have expected an automatic int->float conversion here. interestingly enough, this works in Nashorn (but not in Rhino): jjs> new java.awt.Color(1.0,0.5) java.awt.Color[r=0,g=0,b=1] - andreas On 09.10.2013 16:18, Tal Liron wrote: > Here's a particular exception I got: > > java.lang.NoSuchMethodException: Can't unambiguously select between > fixed arity signatures [(java.lang.String, java.lang.String), (int, > java.lang.Object)] of the method org.restlet.util.Series.set for > argument types [java.lang.String, java.lang.Integer] > at > jdk.internal.dynalink.beans.OverloadedMethod.throwAmbiguousMethod(OverloadedMethod.java:222) > at > jdk.nashorn.internal.scripts.Script$http.runScript(component/clients/http.js:12) > at > jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) > at > jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) > at > jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) > at > com.threecrickets.scripturian.adapter.NashornProgram.execute(NashornProgram.java:83) > at > com.threecrickets.scripturian.Executable.execute(Executable.java:838) > at > com.threecrickets.scripturian.service.DocumentService.execute(DocumentService.java:154) > at > jdk.nashorn.internal.scripts.Script$container._L28$_L63(sincerity/container.js:72) > at > jdk.nashorn.internal.scripts.Script$container._L28$_L82(sincerity/container.js:108) > at > jdk.nashorn.internal.scripts.Script$default.runScript(component/default.js:57) > at > jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) > at > jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) > at > jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) > > However, it seems rather clear that the first signature is suitable, > with the second argument to be coerced into a string. (This works > correctly in Rhino.) > From attila.szegedi at oracle.com Wed Oct 9 07:45:04 2013 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 9 Oct 2013 16:45:04 +0200 Subject: Bug report: can't overcome Java method ambiguity in some clear cases In-Reply-To: <525565B7.1010605@threecrickets.com> References: <525565B7.1010605@threecrickets.com> Message-ID: <72FE0910-D3FB-4073-BEC8-9E80B198AE69@oracle.com> Well, as I stare at it, I think this should be ambiguous. Based on JS conversion rules, both methods are applicable, and neither method is more specific than the other. I'd say this worked incidentally in Rhino, because it probably just picked the first signature that matched. Just convert your Integer argument to String explicitly here, e.g. series.methodName(someString, String(someInt)) Alternatively, you can use manual overload resolution: series["methodName(String, String)"](someString, someInt) (It'll actually be faster that way, as it won't have to choose an overload on every invocation) Attila. On Oct 9, 2013, at 4:18 PM, Tal Liron wrote: > Here's a particular exception I got: > > java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.lang.String, java.lang.String), (int, java.lang.Object)] of the method org.restlet.util.Series.set for argument types [java.lang.String, java.lang.Integer] > at jdk.internal.dynalink.beans.OverloadedMethod.throwAmbiguousMethod(OverloadedMethod.java:222) > at jdk.nashorn.internal.scripts.Script$http.runScript(component/clients/http.js:12) > at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) > at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) > at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) > at com.threecrickets.scripturian.adapter.NashornProgram.execute(NashornProgram.java:83) > at com.threecrickets.scripturian.Executable.execute(Executable.java:838) > at com.threecrickets.scripturian.service.DocumentService.execute(DocumentService.java:154) > at jdk.nashorn.internal.scripts.Script$container._L28$_L63(sincerity/container.js:72) > at jdk.nashorn.internal.scripts.Script$container._L28$_L82(sincerity/container.js:108) > at jdk.nashorn.internal.scripts.Script$default.runScript(component/default.js:57) > at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) > at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) > at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) > > However, it seems rather clear that the first signature is suitable, with the second argument to be coerced into a string. (This works correctly in Rhino.) From tal.liron at threecrickets.com Wed Oct 9 07:50:40 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 22:50:40 +0800 Subject: Bug report: can't overcome Java method ambiguity in some clear cases In-Reply-To: <72FE0910-D3FB-4073-BEC8-9E80B198AE69@oracle.com> References: <525565B7.1010605@threecrickets.com> <72FE0910-D3FB-4073-BEC8-9E80B198AE69@oracle.com> Message-ID: <52556D40.6010908@threecrickets.com> I see your point, but once again I'm very worried about: 1) How much Nashorn diverges from not only Rhino, but also many other JVM languages. 2) How much Nashorn diverges, in my humble opinion, from the spirit of dynamic languages, which generally prefer to plough through ambiguities rather than totally fail. I guess Nashorn is turning out to be something quite different from what some of us have envisioned. I'm confident I'm not the only user who will be surprised. On 10/09/2013 10:45 PM, Attila Szegedi wrote: > Well, as I stare at it, I think this should be ambiguous. Based on JS conversion rules, both methods are applicable, and neither method is more specific than the other. I'd say this worked incidentally in Rhino, because it probably just picked the first signature that matched. > > Just convert your Integer argument to String explicitly here, e.g. > > series.methodName(someString, String(someInt)) > > Alternatively, you can use manual overload resolution: > > series["methodName(String, String)"](someString, someInt) > > (It'll actually be faster that way, as it won't have to choose an overload on every invocation) > > Attila. > > On Oct 9, 2013, at 4:18 PM, Tal Liron wrote: > >> Here's a particular exception I got: >> >> java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.lang.String, java.lang.String), (int, java.lang.Object)] of the method org.restlet.util.Series.set for argument types [java.lang.String, java.lang.Integer] >> at jdk.internal.dynalink.beans.OverloadedMethod.throwAmbiguousMethod(OverloadedMethod.java:222) >> at jdk.nashorn.internal.scripts.Script$http.runScript(component/clients/http.js:12) >> at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) >> at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) >> at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) >> at com.threecrickets.scripturian.adapter.NashornProgram.execute(NashornProgram.java:83) >> at com.threecrickets.scripturian.Executable.execute(Executable.java:838) >> at com.threecrickets.scripturian.service.DocumentService.execute(DocumentService.java:154) >> at jdk.nashorn.internal.scripts.Script$container._L28$_L63(sincerity/container.js:72) >> at jdk.nashorn.internal.scripts.Script$container._L28$_L82(sincerity/container.js:108) >> at jdk.nashorn.internal.scripts.Script$default.runScript(component/default.js:57) >> at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) >> at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) >> at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) >> >> However, it seems rather clear that the first signature is suitable, with the second argument to be coerced into a string. (This works correctly in Rhino.) From attila.szegedi at oracle.com Wed Oct 9 07:55:10 2013 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 9 Oct 2013 16:55:10 +0200 Subject: Bug report: can't call static methods on a Java class instance In-Reply-To: <52556484.4050107@threecrickets.com> References: <52556484.4050107@threecrickets.com> Message-ID: <774896D2-A5B3-4D61-A001-9026FACACF12@oracle.com> Yup. Static methods can't be invoked on instances. This is by design. The following will work: Java.type("MyClass").myMethod() of course, you can reuse it as: var MyClass = Java.type("MyClass") ... MyClass.myMethod() As a matter of fact, you can even get the method and invoke it later: var myMethod = Java.type("MyClass").myMethod ... myMethod() This will also work: myInstance.class.static.myMethod() as "static" is a synthetic property on java.lang.Class objects that returns the object representing their static facet (basically, containing static members and acting as a constructor - the same object Java.type() returns). Attila. On Oct 9, 2013, at 4:13 PM, Tal Liron wrote: > If we have a Java class: > > class MyClass { > public static void myMethod(); > } > > And in JavaScript try: > > myInstance.myMethod() > > Then we would get an exception that looks something like this: > > myscript.js:... TypeError: MyClass at ... has no such function "myMethod" > 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.linker.NashornBottomLinker.linkBean(NashornBottomLinker.java:113) > at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:68) > at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) > at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:138) > at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) > at jdk.nashorn.internal.scripts.Script$default.runScript(component/services/sincerity/version/default.js:6) > at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) > at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) > at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) > From tal.liron at threecrickets.com Wed Oct 9 07:58:14 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 22:58:14 +0800 Subject: Bug report: can't call static methods on a Java class instance In-Reply-To: <774896D2-A5B3-4D61-A001-9026FACACF12@oracle.com> References: <52556484.4050107@threecrickets.com> <774896D2-A5B3-4D61-A001-9026FACACF12@oracle.com> Message-ID: <52556F06.9030809@threecrickets.com> I understand the workaround, but again I fail to see the rationale behind Nashorn's overly-strict interface to Java. What's wrong with supporting the shorthand in Nashorn, especially when Rhino behaves as JavaScript programmers would expect? On 10/09/2013 10:55 PM, Attila Szegedi wrote: > Yup. Static methods can't be invoked on instances. This is by design. The following will work: > > Java.type("MyClass").myMethod() > > of course, you can reuse it as: > > var MyClass = Java.type("MyClass") > ... > MyClass.myMethod() > > As a matter of fact, you can even get the method and invoke it later: > > var myMethod = Java.type("MyClass").myMethod > ... > myMethod() > > This will also work: > > myInstance.class.static.myMethod() > > as "static" is a synthetic property on java.lang.Class objects that returns the object representing their static facet (basically, containing static members and acting as a constructor - the same object Java.type() returns). > > Attila. > > On Oct 9, 2013, at 4:13 PM, Tal Liron wrote: > >> If we have a Java class: >> >> class MyClass { >> public static void myMethod(); >> } >> >> And in JavaScript try: >> >> myInstance.myMethod() >> >> Then we would get an exception that looks something like this: >> >> myscript.js:... TypeError: MyClass at ... has no such function "myMethod" >> 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.linker.NashornBottomLinker.linkBean(NashornBottomLinker.java:113) >> at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:68) >> at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) >> at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:138) >> at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) >> at jdk.nashorn.internal.scripts.Script$default.runScript(component/services/sincerity/version/default.js:6) >> at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) >> at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) >> at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) >> From attila.szegedi at oracle.com Wed Oct 9 08:08:14 2013 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 9 Oct 2013 17:08:14 +0200 Subject: Bug report: can't overcome Java method ambiguity in some clear cases In-Reply-To: <52556B7A.1060607@jku.at> References: <525565B7.1010605@threecrickets.com> <52556B7A.1060607@jku.at> Message-ID: Fair enough. If someone writes "1.0", it's reasonable to expect they had a floating point in mind. We are probably prematurely "optimizing" the constant 1.0 to an int. I opened to track this. Attila. On Oct 9, 2013, at 4:43 PM, Andreas Woess wrote: > I'd like to add to this bug report: > > jjs> new java.awt.Color(0.5,0.5,0.5) > java.awt.Color[r=128,g=128,b=128] > jjs> new java.awt.Color(1.0,0.5,0.5) > java.lang.RuntimeException: java.lang.NoSuchMethodException: Can't > unambiguously select between fixed arity signatures [(float, float, > float), (int, int, int)] of the method java.awt.Color. for > argument types [java.lang.Integer, java.lang.Double, java.lang.Double] > I would have expected an automatic int->float conversion here. > > interestingly enough, this works in Nashorn (but not in Rhino): > jjs> new java.awt.Color(1.0,0.5) > java.awt.Color[r=0,g=0,b=1] > > - andreas > > On 09.10.2013 16:18, Tal Liron wrote: >> Here's a particular exception I got: >> >> java.lang.NoSuchMethodException: Can't unambiguously select between >> fixed arity signatures [(java.lang.String, java.lang.String), (int, >> java.lang.Object)] of the method org.restlet.util.Series.set for >> argument types [java.lang.String, java.lang.Integer] >> at >> jdk.internal.dynalink.beans.OverloadedMethod.throwAmbiguousMethod(OverloadedMethod.java:222) >> at >> jdk.nashorn.internal.scripts.Script$http.runScript(component/clients/http.js:12) >> at >> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) >> at >> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) >> at >> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) >> at >> com.threecrickets.scripturian.adapter.NashornProgram.execute(NashornProgram.java:83) >> at >> com.threecrickets.scripturian.Executable.execute(Executable.java:838) >> at >> com.threecrickets.scripturian.service.DocumentService.execute(DocumentService.java:154) >> at >> jdk.nashorn.internal.scripts.Script$container._L28$_L63(sincerity/container.js:72) >> at >> jdk.nashorn.internal.scripts.Script$container._L28$_L82(sincerity/container.js:108) >> at >> jdk.nashorn.internal.scripts.Script$default.runScript(component/default.js:57) >> at >> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) >> at >> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) >> at >> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) >> >> However, it seems rather clear that the first signature is suitable, >> with the second argument to be coerced into a string. (This works >> correctly in Rhino.) >> > From attila.szegedi at oracle.com Wed Oct 9 08:25:26 2013 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 9 Oct 2013 17:25:26 +0200 Subject: Bug report: can't call static methods on a Java class instance In-Reply-To: <52556F06.9030809@threecrickets.com> References: <52556484.4050107@threecrickets.com> <774896D2-A5B3-4D61-A001-9026FACACF12@oracle.com> <52556F06.9030809@threecrickets.com> Message-ID: <5BFDAF3C-AF0E-45DB-AAA4-4C6A6F2C8550@oracle.com> On Oct 9, 2013, at 4:58 PM, Tal Liron wrote: > I understand the workaround, but again I fail to see the rationale behind Nashorn's overly-strict interface to Java. What's wrong with supporting the shorthand in Nashorn, especially when Rhino behaves as JavaScript programmers would expect? I'm not sure what expectation a JavaScript programmer could intrinsically have with regard to the functionality of the Java platform. (E.g. a concept of instance vs. static members not sharing a namespace on an object). Java platform and JavaScript are independent, so a theoretical "JavaScript programmer" should have no a priori expectations with regard to how platform integration features work. A "JavaScript programmer used to work with Rhino" is a different kind of creature, of course. Implementing functionality on the border of a language and its host platform will always be a tradeoff between leaning more towards one side or more towards the other. Where decisions need to be made, they will always reflect the convictions of its designers. My conviction is that exposing static members through instances is a sloppy mashing together of otherwise separate namespaces, hence I chose not to enable it. (Using instances to invoke static methods is also a discouraged practice in Java, where it additionally carries an unnecessary null dereference risk). I actually frowned upon Rhino supporting that. I believe that where I had to make design decisions, I made them in the direction of helping people write more maintainable and clear code in the long run, even if it means not having some, as you'd say "convenient shortcuts". At the end of the day, Nashorn isn't Rhino. It's quite similar in lots of regards, but when needed, we deliberated and went with different choices when we felt we need to. It's a different runtime. (Notwithstanding, I think we'll do something about the array conversions?) Attila. > > On 10/09/2013 10:55 PM, Attila Szegedi wrote: >> Yup. Static methods can't be invoked on instances. This is by design. The following will work: >> >> Java.type("MyClass").myMethod() >> >> of course, you can reuse it as: >> >> var MyClass = Java.type("MyClass") >> ... >> MyClass.myMethod() >> >> As a matter of fact, you can even get the method and invoke it later: >> >> var myMethod = Java.type("MyClass").myMethod >> ... >> myMethod() >> >> This will also work: >> >> myInstance.class.static.myMethod() >> >> as "static" is a synthetic property on java.lang.Class objects that returns the object representing their static facet (basically, containing static members and acting as a constructor - the same object Java.type() returns). >> >> Attila. >> >> On Oct 9, 2013, at 4:13 PM, Tal Liron wrote: >> >>> If we have a Java class: >>> >>> class MyClass { >>> public static void myMethod(); >>> } >>> >>> And in JavaScript try: >>> >>> myInstance.myMethod() >>> >>> Then we would get an exception that looks something like this: >>> >>> myscript.js:... TypeError: MyClass at ... has no such function "myMethod" >>> 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.linker.NashornBottomLinker.linkBean(NashornBottomLinker.java:113) >>> at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:68) >>> at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) >>> at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:138) >>> at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) >>> at jdk.nashorn.internal.scripts.Script$default.runScript(component/services/sincerity/version/default.js:6) >>> at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) >>> at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) >>> at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) >>> > From attila.szegedi at oracle.com Wed Oct 9 08:27:02 2013 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 9 Oct 2013 17:27:02 +0200 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: References: Message-ID: You'll also need to sign and send us an Oracle Contributor Agreement: On Oct 9, 2013, at 4:28 PM, Jim Laskey wrote: > If you can get the changes to me by Tuesday Oct 15th, I'll take a look. No guarantees, but if the changes are small, are correct, and do not restrict future enhancements in this area then I'll run the changes up the approval chain. > > Cheers, > > -- Jim > > ----- Original Message ----- > From: tal.liron at threecrickets.com > To: nashorn-dev at openjdk.java.net > Sent: Wednesday, October 9, 2013 3:51:10 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays > > I deem this feature important for Nashorn's adoption: if I could submit > a patch soon, would it be possible to make it in time for release? > > On 10/09/2013 04:15 PM, Jim Laskey (Oracle) wrote: >> After consideration and from my own experiences, I'm going to add as a >> feature request. However, code freeze is next week, so it's extremely >> likely this will not show up until first non-security update. >> >> JDK-8026113 >> > From tal.liron at threecrickets.com Wed Oct 9 08:42:29 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 09 Oct 2013 23:42:29 +0800 Subject: Bug report: can't call static methods on a Java class instance In-Reply-To: <5BFDAF3C-AF0E-45DB-AAA4-4C6A6F2C8550@oracle.com> References: <52556484.4050107@threecrickets.com> <774896D2-A5B3-4D61-A001-9026FACACF12@oracle.com> <52556F06.9030809@threecrickets.com> <5BFDAF3C-AF0E-45DB-AAA4-4C6A6F2C8550@oracle.com> Message-ID: <52557965.2050304@threecrickets.com> Again, I do understand your conviction, but "sloppy" (or "simple"?) is exactly what most dynamic languages are all about. If a programmer wanted to use Java, they would. But when working in JavaScript, expectations are quite different. Unfortunately, in my opinion, Nashorn right now requires JavaScript programmers to understand Java paradigms when using Java classes, objects and even method calls. Almost all other JVM dynamic languages treat Java classes and objects as natively as possible, some more opaquely than others (JRuby does a truly marvelous job at allowing you duck-type Java instances). I also think you're thinking more of clean-room JavaScript programs in your design. But actually Nashorn will be used more widely, I think, in specialized embedded environments which set up bindings for domain-specific APIs, and invariably these APIs will be written in Java. Nashorn unfortunately will not "just work" with these Java-made APIs, but would require an additional layer of JavaScript wrappers to do the coercsions and other "shortcuts" that Nashorn is not doing for us. Using Nashorn's special Java.* APIs would be clumsy if not unacceptable in such environments, even if well-documented. Would it not be possible to allow for your generally reasonable conviction via something like a "strict_java" flag? When this flag is off, Nashorn could work in a "sloppy" mode. I'm 100% sure you'll be getting these kinds of confused questions again and again from JavaScript programmers. On 10/09/2013 11:25 PM, Attila Szegedi wrote: > On Oct 9, 2013, at 4:58 PM, Tal Liron wrote: > >> I understand the workaround, but again I fail to see the rationale behind Nashorn's overly-strict interface to Java. What's wrong with supporting the shorthand in Nashorn, especially when Rhino behaves as JavaScript programmers would expect? > I'm not sure what expectation a JavaScript programmer could intrinsically have with regard to the functionality of the Java platform. (E.g. a concept of instance vs. static members not sharing a namespace on an object). Java platform and JavaScript are independent, so a theoretical "JavaScript programmer" should have no a priori expectations with regard to how platform integration features work. A "JavaScript programmer used to work with Rhino" is a different kind of creature, of course. > > Implementing functionality on the border of a language and its host platform will always be a tradeoff between leaning more towards one side or more towards the other. Where decisions need to be made, they will always reflect the convictions of its designers. My conviction is that exposing static members through instances is a sloppy mashing together of otherwise separate namespaces, hence I chose not to enable it. (Using instances to invoke static methods is also a discouraged practice in Java, where it additionally carries an unnecessary null dereference risk). I actually frowned upon Rhino supporting that. > > I believe that where I had to make design decisions, I made them in the direction of helping people write more maintainable and clear code in the long run, even if it means not having some, as you'd say "convenient shortcuts". At the end of the day, Nashorn isn't Rhino. It's quite similar in lots of regards, but when needed, we deliberated and went with different choices when we felt we need to. It's a different runtime. (Notwithstanding, I think we'll do something about the array conversions?) > > Attila. > >> On 10/09/2013 10:55 PM, Attila Szegedi wrote: >>> Yup. Static methods can't be invoked on instances. This is by design. The following will work: >>> >>> Java.type("MyClass").myMethod() >>> >>> of course, you can reuse it as: >>> >>> var MyClass = Java.type("MyClass") >>> ... >>> MyClass.myMethod() >>> >>> As a matter of fact, you can even get the method and invoke it later: >>> >>> var myMethod = Java.type("MyClass").myMethod >>> ... >>> myMethod() >>> >>> This will also work: >>> >>> myInstance.class.static.myMethod() >>> >>> as "static" is a synthetic property on java.lang.Class objects that returns the object representing their static facet (basically, containing static members and acting as a constructor - the same object Java.type() returns). >>> >>> Attila. >>> >>> On Oct 9, 2013, at 4:13 PM, Tal Liron wrote: >>> >>>> If we have a Java class: >>>> >>>> class MyClass { >>>> public static void myMethod(); >>>> } >>>> >>>> And in JavaScript try: >>>> >>>> myInstance.myMethod() >>>> >>>> Then we would get an exception that looks something like this: >>>> >>>> myscript.js:... TypeError: MyClass at ... has no such function "myMethod" >>>> 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.linker.NashornBottomLinker.linkBean(NashornBottomLinker.java:113) >>>> at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:68) >>>> at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) >>>> at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:138) >>>> at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) >>>> at jdk.nashorn.internal.scripts.Script$default.runScript(component/services/sincerity/version/default.js:6) >>>> at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) >>>> at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) >>>> at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) >>>> From marcus.lagergren at oracle.com Wed Oct 9 08:55:19 2013 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Wed, 09 Oct 2013 15:55:19 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026137: Fix Issues with Binary Evaluation Order Message-ID: <20131009155522.C88D462E97@hg.openjdk.java.net> Changeset: 03a68e7ca1d5 Author: lagergren Date: 2013-10-09 17:53 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/03a68e7ca1d5 8026137: Fix Issues with Binary Evaluation Order Reviewed-by: hannesw, jlaskey Contributed-by: marcus.lagergren at oracle.com, attila.szegedi at oracle.com ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java - src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/script/basic/JDK-8026137.js + test/script/basic/JDK-8026137.js.EXPECTED From andrebargull at googlemail.com Wed Oct 9 09:44:13 2013 From: andrebargull at googlemail.com (=?ISO-8859-15?Q?Andr=E9_Bargull?=) Date: Wed, 09 Oct 2013 18:44:13 +0200 Subject: hg: nashorn/jdk8/nashorn: 8026137: Fix Issues with Binary Evaluation Order Message-ID: <525587DD.3020100@googlemail.com> Quick question for this change set: Why does CodeGenerator#safeLiteral(...) need to test for literal nodes instead of using type information? When the right-hand-side is a primitive type, side effects cannot occur, so the additional swap/dup/pop instructions can be omitted safely. For example `function f(a){var c = 1; return a - c }` now emits: ALOAD 1 ILOAD 4 SWAP INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber (Ljava/lang/Object;)D DUP2_X1 POP2 I2D DSUB Using type info it's possible to change the bytecode to: ALOAD 1 INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber (Ljava/lang/Object;)D ILOAD 4 I2D DSUB (Also: That was one of the bug reports which worried me a bit, because I expected the changes to be non-trivial. :-( - Andr? > Changeset: 03a68e7ca1d5 > Author: lagergren > Date: 2013-10-09 17:53 +0200 > URL:http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/03a68e7ca1d5 > > 8026137: Fix Issues with Binary Evaluation Order > Reviewed-by: hannesw, jlaskey > Contributed-by:marcus.lagergren at oracle.com ,attila.szegedi at oracle.com > > ! src/jdk/nashorn/internal/codegen/Attr.java > ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java > ! src/jdk/nashorn/internal/codegen/CodeGenerator.java > ! src/jdk/nashorn/internal/codegen/CompileUnit.java > ! src/jdk/nashorn/internal/codegen/Compiler.java > ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java > ! src/jdk/nashorn/internal/codegen/MethodEmitter.java > ! src/jdk/nashorn/internal/codegen/WeighNodes.java > ! src/jdk/nashorn/internal/codegen/types/BooleanType.java > ! src/jdk/nashorn/internal/codegen/types/ObjectType.java > ! src/jdk/nashorn/internal/codegen/types/Type.java > ! src/jdk/nashorn/internal/ir/AccessNode.java > ! src/jdk/nashorn/internal/ir/BaseNode.java > ! src/jdk/nashorn/internal/ir/CallNode.java > ! src/jdk/nashorn/internal/ir/IdentNode.java > ! src/jdk/nashorn/internal/ir/IndexNode.java > ! src/jdk/nashorn/internal/ir/LiteralNode.java > ! src/jdk/nashorn/internal/ir/RuntimeNode.java > - src/jdk/nashorn/internal/ir/TypeOverride.java > ! src/jdk/nashorn/internal/ir/UnaryNode.java > ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java > ! src/jdk/nashorn/internal/parser/TokenType.java > ! src/jdk/nashorn/internal/runtime/Context.java > ! src/jdk/nashorn/internal/runtime/JSType.java > ! src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java > ! src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java > ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java > + test/script/basic/JDK-8026137.js > + test/script/basic/JDK-8026137.js.EXPECTED From tal.liron at threecrickets.com Wed Oct 9 10:33:01 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 10 Oct 2013 01:33:01 +0800 Subject: Nashorn works in real life Message-ID: <5255934D.3070802@threecrickets.com> After reporting various bugs and complaints on the list, I have some good news for a change. :) The complete Prudence stack, which includes a *lot* of JavaScript code developed for years to work in Rhino, now runs perfectly fine on Nashorn. (The exact same code base also works in Rhino.) Prudence is a powerful REST and web platform. With it, you can use JavaScript (as well as many other JVM languages) to write RESTful resources and dynamically generated, cached web pages. I hope this will allow you to test Nashorn performance in server-side environments, and to compare it with Rhino in this respect, too. Nashorn is now a fully supported language in Scripturian (an alternative to JSR-223), so any other applications that use Scripturian can also now leverage Nashorn. I should point out that Scripturian also works with the nashorn-backport project, so the whole stack can work on JVM 7. I did need some hacks: 1. I patched Nashorn for the "NPE in DebugLogger.levelAbove" bug I reported. 2. I patched mozilla_compat to support multiple arguments in importClass (again, as with the bug I reported). 3. I had to implement a rather ugly hack in Sincerity to deal with Nashorn's current inability to coerce string arrays (I actually do a string.split(",")...), and also moved a static method to become non-static for the sake of Nashorn's strictness. Sigh. (And also some other small JavaScript changes that work fine in Rhino, too.) I would also love for Diligence to run on Nashorn: Diligence is a full-blown server-side JavaScript web framework built on Prudence and MongoDB. However, this would require more work, because the JVM/JavaScript MongoDB driver I wrote is currently Rhino-specific. I will update you in the future on this progress, as it would allow for even more avenues for testing. Keep up the good work! And hopefully listen to my advice on how to move Nashorn forward: I speak from quite a bit of experience with dynamic languages on the JVM, and JavaScript especially. -Tal From tal.liron at threecrickets.com Wed Oct 9 11:40:24 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 10 Oct 2013 02:40:24 +0800 Subject: Bug report: instanceof incompatible with mozilla_compat's importClass Message-ID: <5255A318.8080405@threecrickets.com> Example: importClass(java.io.File) x instanceof File Will throw an exception: nashorn:mozilla_compat.js:65:20 ReferenceError: File is not defined at jdk.nashorn.internal.scripts.Script$\=nashorn\!mozilla_compat._L47$_L51(nashorn:mozilla_compat.js:65) However, this works: x instanceof java.io.File From sundararajan.athijegannathan at oracle.com Wed Oct 9 11:46:08 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 09 Oct 2013 20:46:08 +0200 Subject: Review request for 8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases. Message-ID: <5255A470.3000104@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026167/ -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 9 12:06:44 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 09 Oct 2013 21:06:44 +0200 Subject: Bug report: instanceof incompatible with mozilla_compat's importClass In-Reply-To: <5255A318.8080405@threecrickets.com> References: <5255A318.8080405@threecrickets.com> Message-ID: <5255A944.5060604@oracle.com> var x = {} load('nashorn:mozilla_compat.js') importClass(java.io.File) print(x instanceof File) var y = new File("foo"); print(y instanceof File) works fine for me. Tried with latest nashorn tip: changeset: 596:03a68e7ca1d5 tag: tip user: lagergren date: Wed Oct 09 17:53:22 2013 +0200 summary: 8026137: Fix Issues with Binary Evaluation Order PS. I am sure this should work with early access jdk8 snapshot too -- as I don't recall any bugfix in this area in the recent past. -Sundar On Wednesday 09 October 2013 08:40 PM, Tal Liron wrote: > Example: > > importClass(java.io.File) > x instanceof File > > Will throw an exception: > > nashorn:mozilla_compat.js:65:20 ReferenceError: File is not defined > at > jdk.nashorn.internal.scripts.Script$\=nashorn\!mozilla_compat._L47$_L51(nashorn:mozilla_compat.js:65) > > However, this works: > > x instanceof java.io.File > From tal.liron at threecrickets.com Wed Oct 9 20:56:23 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 10 Oct 2013 11:56:23 +0800 Subject: Bug report: instanceof incompatible with mozilla_compat's importClass In-Reply-To: <5255A944.5060604@oracle.com> References: <5255A318.8080405@threecrickets.com> <5255A944.5060604@oracle.com> Message-ID: <52562567.5010301@threecrickets.com> Hm, something very strange is happening, because I'm also unable to isolate this exception. Moreover, the exception is coming from importPackage in mozilla_compat, not importClass. However, nowhere am I calling importPackage. Do you have any idea what could be causing this oddity? On 10/10/2013 03:06 AM, A. Sundararajan wrote: > var x = {} > load('nashorn:mozilla_compat.js') > > importClass(java.io.File) > print(x instanceof File) > > var y = new File("foo"); > print(y instanceof File) > > works fine for me. Tried with latest nashorn tip: > > changeset: 596:03a68e7ca1d5 > tag: tip > user: lagergren > date: Wed Oct 09 17:53:22 2013 +0200 > summary: 8026137: Fix Issues with Binary Evaluation Order > > > PS. I am sure this should work with early access jdk8 snapshot too -- > as I don't recall any bugfix in this area in the recent past. > > -Sundar > > On Wednesday 09 October 2013 08:40 PM, Tal Liron wrote: >> Example: >> >> importClass(java.io.File) >> x instanceof File >> >> Will throw an exception: >> >> nashorn:mozilla_compat.js:65:20 ReferenceError: File is not defined >> at >> jdk.nashorn.internal.scripts.Script$\=nashorn\!mozilla_compat._L47$_L51(nashorn:mozilla_compat.js:65) >> >> However, this works: >> >> x instanceof java.io.File >> > From sundararajan.athijegannathan at oracle.com Wed Oct 9 22:08:54 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Oct 2013 07:08:54 +0200 Subject: Bug report: instanceof incompatible with mozilla_compat's importClass In-Reply-To: <52562567.5010301@threecrickets.com> References: <5255A318.8080405@threecrickets.com> <5255A944.5060604@oracle.com> <52562567.5010301@threecrickets.com> Message-ID: <52563666.9030307@oracle.com> I hope you call load('nashorn:mozilla_compat.js') as a top-level expression -- and not within a function. Because mozilla_compat.js assumes it is being evaluated with 'this' as global scope. ReferenceError may be from importPackage -- because importPackage is the one that installs __noSuchProperty__ hook to the global scope. That is to make sure unresolved globals are checked for possible imports. Other than that I can't think of anything else ... (without more context to the script that fails) -Sundar On Thursday 10 October 2013 05:56 AM, Tal Liron wrote: > Hm, something very strange is happening, because I'm also unable to > isolate this exception. > > Moreover, the exception is coming from importPackage in > mozilla_compat, not importClass. However, nowhere am I calling > importPackage. Do you have any idea what could be causing this oddity? > > On 10/10/2013 03:06 AM, A. Sundararajan wrote: >> var x = {} >> load('nashorn:mozilla_compat.js') >> >> importClass(java.io.File) >> print(x instanceof File) >> >> var y = new File("foo"); >> print(y instanceof File) >> >> works fine for me. Tried with latest nashorn tip: >> >> changeset: 596:03a68e7ca1d5 >> tag: tip >> user: lagergren >> date: Wed Oct 09 17:53:22 2013 +0200 >> summary: 8026137: Fix Issues with Binary Evaluation Order >> >> >> PS. I am sure this should work with early access jdk8 snapshot too -- >> as I don't recall any bugfix in this area in the recent past. >> >> -Sundar >> >> On Wednesday 09 October 2013 08:40 PM, Tal Liron wrote: >>> Example: >>> >>> importClass(java.io.File) >>> x instanceof File >>> >>> Will throw an exception: >>> >>> nashorn:mozilla_compat.js:65:20 ReferenceError: File is not defined >>> at >>> jdk.nashorn.internal.scripts.Script$\=nashorn\!mozilla_compat._L47$_L51(nashorn:mozilla_compat.js:65) >>> >>> However, this works: >>> >>> x instanceof java.io.File >>> >> > From tal.liron at threecrickets.com Wed Oct 9 22:33:22 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 10 Oct 2013 13:33:22 +0800 Subject: Bug report: instanceof incompatible with mozilla_compat's importClass In-Reply-To: <52563666.9030307@oracle.com> References: <5255A318.8080405@threecrickets.com> <5255A944.5060604@oracle.com> <52562567.5010301@threecrickets.com> <52563666.9030307@oracle.com> Message-ID: <52563C22.4040002@threecrickets.com> Hm, would there be any bad consequences to calling load('nashorn:mozilla_compat.js') twice? On 10/10/2013 01:08 PM, A. Sundararajan wrote: > I hope you call load('nashorn:mozilla_compat.js') as a top-level > expression -- and not within a function. Because mozilla_compat.js > assumes it is being evaluated with 'this' as global scope. > > ReferenceError may be from importPackage -- because importPackage is > the one that installs __noSuchProperty__ hook to the global scope. > That is to make sure unresolved globals are checked for possible imports. From andrebargull at googlemail.com Thu Oct 10 00:06:17 2013 From: andrebargull at googlemail.com (=?ISO-8859-15?Q?Andr=E9_Bargull?=) Date: Thu, 10 Oct 2013 09:06:17 +0200 Subject: Fuzzing results 10/10/2013 (hg tip 03a68e7ca1d5) Message-ID: <525651E9.3090406@googlemail.com> Re-ran jsfunfuzz with the latest patches applied, results below. - Andr? function f() { if(x3, y) x; } Exception in thread "main" java.lang.AssertionError: DISCARD(x3) has no type at jdk.nashorn.internal.ir.Expression.getType(Expression.java:96) at jdk.nashorn.internal.codegen.BranchOptimizer.branchOptimizer(BranchOptimizer.java:87) at jdk.nashorn.internal.codegen.BranchOptimizer.branchOptimizer(BranchOptimizer.java:163) at jdk.nashorn.internal.codegen.BranchOptimizer.execute(BranchOptimizer.java:56) at jdk.nashorn.internal.codegen.CodeGenerator.enterIfNode(CodeGenerator.java:1158) at jdk.nashorn.internal.ir.IfNode.accept(IfNode.java:76) at jdk.nashorn.internal.ir.Node.accept(Node.java:291) at jdk.nashorn.internal.ir.Block.accept(Block.java:143) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:361) ... function f(x) { return y, x } Exception in thread "main" java.lang.AssertionError: Illegal conversion object -> false false at jdk.nashorn.internal.codegen.types.ObjectType.convert(ObjectType.java:158) at jdk.nashorn.internal.codegen.MethodEmitter.convert(MethodEmitter.java:1560) at jdk.nashorn.internal.codegen.CodeGenerator$1.enterDefault(CodeGenerator.java:500) at jdk.nashorn.internal.ir.visitor.NodeVisitor.enterBinaryNode(NodeVisitor.java:178) at jdk.nashorn.internal.ir.BinaryNode.accept(BinaryNode.java:165) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:447) at jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:359) at jdk.nashorn.internal.codegen.CodeGenerator.enterReturnNode(CodeGenerator.java:1556) at jdk.nashorn.internal.ir.ReturnNode.accept(ReturnNode.java:91) at jdk.nashorn.internal.ir.Node.accept(Node.java:291) ... function f() { L: {{break L; } return; } } function f() { L: {if(x2) {break L; } throw x; } } Exception in thread "main" java.lang.VerifyError: StackMapTable error: bad offset Exception Details: Location: jdk/nashorn/internal/scripts/Script$\^shell\_.f(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; @0: aload_0 Reason: Invalid stackmap specification. Current Frame: bci: @12 flags: { } locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject' } stack: { } Bytecode: 0000000: 2ab6 0018 4da7 0007 0000 00bf Stackmap Table: full_frame(@8,{},{Object[#53]}) append_frame(@12,Object[#20],Object[#55],Object[#57]) function f() { switch(x) { default: if(true) break; return; } } function f() { switch(x) { default: L: break; return; } } java.lang.NullPointerException at jdk.internal.org.objectweb.asm.Frame.merge(Frame.java:1321) at jdk.internal.org.objectweb.asm.MethodWriter.visitMaxs(MethodWriter.java:1499) at jdk.nashorn.internal.codegen.MethodEmitter.end(MethodEmitter.java:200) at jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1125) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:297) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:49) at jdk.nashorn.internal.codegen.CodeGenerator$1.enterFunctionNode(CodeGenerator.java:478) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:296) ... function f() { Function.call.call(function x() { eval("x") }); eval("x") } try { f() } catch(e) { e.printStackTrace() } java.lang.ClassCastException: Cannot cast jdk.nashorn.internal.scripts.JO1P0 to jdk.nashorn.internal.scripts.JO2P0 at sun.invoke.util.ValueConversions.newClassCastException(ValueConversions.java:461) at sun.invoke.util.ValueConversions.castReference(ValueConversions.java:456) at jdk.nashorn.internal.scripts.Script$\^shell\_#1\^eval\_.runScript(#1:1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) at jdk.nashorn.internal.runtime.Context.eval(Context.java:465) at jdk.nashorn.internal.objects.Global.directEval(Global.java:811) at jdk.nashorn.internal.scripts.Script$\^shell\_.f(:1) at jdk.nashorn.internal.scripts.Script$\^shell\_.runScript(:1) ... function f() { with({}) return eval("arguments", 3/0); } try { f() } catch(e) { e.printStackTrace() } java.lang.NullPointerException at java.lang.invoke.MethodHandles.guardWithTest(MethodHandles.java:2131) at jdk.nashorn.internal.lookup.MethodHandleFactory$StandardMethodHandleFunctionality.guardWithTest(MethodHandleFactory.java:287) at jdk.nashorn.internal.runtime.WithObject.fixScopeCallSite(WithObject.java:258) at jdk.nashorn.internal.runtime.WithObject.lookup(WithObject.java:126) at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:75) 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:138) at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) at jdk.nashorn.internal.scripts.Script$\^shell\_#1\^eval\_.runScript(#1:1) ... From sundararajan.athijegannathan at oracle.com Thu Oct 10 02:08:02 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Oct 2013 11:08:02 +0200 Subject: Fuzzing results 10/10/2013 (hg tip 03a68e7ca1d5) In-Reply-To: <525651E9.3090406@googlemail.com> References: <525651E9.3090406@googlemail.com> Message-ID: <52566E72.4010507@oracle.com> Thanks for reporting. I filed https://bugs.openjdk.java.net/browse/JDK-8026249 -Sundar On Thursday 10 October 2013 09:06 AM, Andr? Bargull wrote: > Re-ran jsfunfuzz with the latest patches applied, results below. > > - Andr? > > > > > function f() { if(x3, y) x; } > > Exception in thread "main" java.lang.AssertionError: DISCARD(x3) has > no type > at jdk.nashorn.internal.ir.Expression.getType(Expression.java:96) > at > jdk.nashorn.internal.codegen.BranchOptimizer.branchOptimizer(BranchOptimizer.java:87) > at > jdk.nashorn.internal.codegen.BranchOptimizer.branchOptimizer(BranchOptimizer.java:163) > at > jdk.nashorn.internal.codegen.BranchOptimizer.execute(BranchOptimizer.java:56) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterIfNode(CodeGenerator.java:1158) > at jdk.nashorn.internal.ir.IfNode.accept(IfNode.java:76) > at jdk.nashorn.internal.ir.Node.accept(Node.java:291) > at jdk.nashorn.internal.ir.Block.accept(Block.java:143) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at jdk.nashorn.internal.ir.Block.accept(Block.java:361) > ... > > > > function f(x) { return y, x } > > Exception in thread "main" java.lang.AssertionError: Illegal > conversion object -> false false > at > jdk.nashorn.internal.codegen.types.ObjectType.convert(ObjectType.java:158) > at > jdk.nashorn.internal.codegen.MethodEmitter.convert(MethodEmitter.java:1560) > at > jdk.nashorn.internal.codegen.CodeGenerator$1.enterDefault(CodeGenerator.java:500) > at > jdk.nashorn.internal.ir.visitor.NodeVisitor.enterBinaryNode(NodeVisitor.java:178) > at jdk.nashorn.internal.ir.BinaryNode.accept(BinaryNode.java:165) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:447) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:359) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterReturnNode(CodeGenerator.java:1556) > at jdk.nashorn.internal.ir.ReturnNode.accept(ReturnNode.java:91) > at jdk.nashorn.internal.ir.Node.accept(Node.java:291) > ... > > > > function f() { L: {{break L; } return; } } > function f() { L: {if(x2) {break L; } throw x; } } > > Exception in thread "main" java.lang.VerifyError: StackMapTable error: > bad offset > Exception Details: > Location: > jdk/nashorn/internal/scripts/Script$\^shell\_.f(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; > @0: aload_0 > Reason: > Invalid stackmap specification. > Current Frame: > bci: @12 > flags: { } > locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', > 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject' } > stack: { } > Bytecode: > 0000000: 2ab6 0018 4da7 0007 0000 00bf > Stackmap Table: > full_frame(@8,{},{Object[#53]}) > append_frame(@12,Object[#20],Object[#55],Object[#57]) > > > > function f() { switch(x) { default: if(true) break; return; } } > function f() { switch(x) { default: L: break; return; } } > > java.lang.NullPointerException > at jdk.internal.org.objectweb.asm.Frame.merge(Frame.java:1321) > at > jdk.internal.org.objectweb.asm.MethodWriter.visitMaxs(MethodWriter.java:1499) > at > jdk.nashorn.internal.codegen.MethodEmitter.end(MethodEmitter.java:200) > at > jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1125) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:297) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at > jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:49) > at > jdk.nashorn.internal.codegen.CodeGenerator$1.enterFunctionNode(CodeGenerator.java:478) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:296) > ... > > > > function f() { Function.call.call(function x() { eval("x") }); > eval("x") } try { f() } catch(e) { e.printStackTrace() } > > java.lang.ClassCastException: Cannot cast > jdk.nashorn.internal.scripts.JO1P0 to jdk.nashorn.internal.scripts.JO2P0 > at > sun.invoke.util.ValueConversions.newClassCastException(ValueConversions.java:461) > at > sun.invoke.util.ValueConversions.castReference(ValueConversions.java:456) > at > jdk.nashorn.internal.scripts.Script$\^shell\_#1\^eval\_.runScript(#1:1) > at > jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:527) > at > jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:204) > at > jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:367) > at jdk.nashorn.internal.runtime.Context.eval(Context.java:465) > at jdk.nashorn.internal.objects.Global.directEval(Global.java:811) > at jdk.nashorn.internal.scripts.Script$\^shell\_.f(:1) > at jdk.nashorn.internal.scripts.Script$\^shell\_.runScript(:1) > ... > > > > function f() { with({}) return eval("arguments", 3/0); } try { f() } > catch(e) { e.printStackTrace() } > > java.lang.NullPointerException > at > java.lang.invoke.MethodHandles.guardWithTest(MethodHandles.java:2131) > at > jdk.nashorn.internal.lookup.MethodHandleFactory$StandardMethodHandleFunctionality.guardWithTest(MethodHandleFactory.java:287) > at > jdk.nashorn.internal.runtime.WithObject.fixScopeCallSite(WithObject.java:258) > at > jdk.nashorn.internal.runtime.WithObject.lookup(WithObject.java:126) > at > jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:75) > 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:138) > at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232) > at > jdk.nashorn.internal.scripts.Script$\^shell\_#1\^eval\_.runScript(#1:1) > ... From sundararajan.athijegannathan at oracle.com Thu Oct 10 02:26:48 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Oct 2013 11:26:48 +0200 Subject: Review request for 8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases. Message-ID: <525672D8.906@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026167/webrev.01/ PS. I changed to use unique eval id instead of caller Class (as in webrev.00) and adjusted .EXPECTED to avoid full URL of evals Thanks -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 10 02:47:27 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Oct 2013 11:47:27 +0200 Subject: Bug report: instanceof incompatible with mozilla_compat's importClass In-Reply-To: <52563C22.4040002@threecrickets.com> References: <5255A318.8080405@threecrickets.com> <5255A944.5060604@oracle.com> <52562567.5010301@threecrickets.com> <52563666.9030307@oracle.com> <52563C22.4040002@threecrickets.com> Message-ID: <525677AF.6060505@oracle.com> Hmm.. does not seem to be the case.. I tried this: load('nashorn:mozilla_compat.js') load('nashorn:mozilla_compat.js') importClass(java.io.File) var x = {} print(x instanceof File) - seems fine as well. prints false as expected. May be something else.. PS. importPackage would chain it's own __noSuchProperty__ again - aside from inefficiency, I don't see how that would result in error that you cited. -Sundar On Thursday 10 October 2013 07:33 AM, Tal Liron wrote: > Hm, would there be any bad consequences to calling > load('nashorn:mozilla_compat.js') twice? > > On 10/10/2013 01:08 PM, A. Sundararajan wrote: >> I hope you call load('nashorn:mozilla_compat.js') as a top-level >> expression -- and not within a function. Because mozilla_compat.js >> assumes it is being evaluated with 'this' as global scope. >> >> ReferenceError may be from importPackage -- because importPackage is >> the one that installs __noSuchProperty__ hook to the global scope. >> That is to make sure unresolved globals are checked for possible >> imports. > From sundararajan.athijegannathan at oracle.com Thu Oct 10 02:49:18 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 10 Oct 2013 09:49:18 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases. Message-ID: <20131010094922.D823462ED9@hg.openjdk.java.net> Changeset: 7cc5ff16380f Author: sundar Date: 2013-10-10 11:48 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/7cc5ff16380f 8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases. Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! test/script/assert.js ! test/script/basic/JDK-8019508.js ! test/script/basic/JDK-8019508.js.EXPECTED ! test/script/basic/JDK-8019553.js ! test/script/basic/JDK-8019553.js.EXPECTED ! test/script/basic/JDK-8019791.js ! test/script/basic/JDK-8019791.js.EXPECTED ! test/script/basic/JDK-8019805.js ! test/script/basic/JDK-8019805.js.EXPECTED + test/script/basic/JDK-8026167.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-100.js.EXPECTED ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-293.js.EXPECTED ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-40.js.EXPECTED ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-51.js.EXPECTED ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-98.js.EXPECTED ! test/script/basic/eval.js ! test/script/basic/eval.js.EXPECTED From sundararajan.athijegannathan at oracle.com Thu Oct 10 04:13:46 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Oct 2013 13:13:46 +0200 Subject: Review request for 8026248: importClass has to be a varargs function Message-ID: <52568BEA.4030700@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026248/ -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 10 04:18:26 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 10 Oct 2013 11:18:26 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026248: importClass has to be a varargs function Message-ID: <20131010111829.7038062EE9@hg.openjdk.java.net> Changeset: e60bbcf2f6b6 Author: sundar Date: 2013-10-10 13:17 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/e60bbcf2f6b6 8026248: importClass has to be a varargs function Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8026248.js + test/script/basic/JDK-8026248.js.EXPECTED From hannes.wallnoefer at oracle.com Thu Oct 10 04:30:29 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 10 Oct 2013 13:30:29 +0200 Subject: Review request for 8026248: importClass has to be a varargs function In-Reply-To: <52568BEA.4030700@oracle.com> References: <52568BEA.4030700@oracle.com> Message-ID: <52568FD5.6060502@oracle.com> +1 Am 2013-10-10 13:13, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8026248/ > > -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 10 04:56:58 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Oct 2013 13:56:58 +0200 Subject: Review request for 8026162: "this" in SAM adapter functions is wrong Message-ID: <5256960A.4020305@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026162/ -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 10 05:44:14 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 10 Oct 2013 12:44:14 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026162: "this" in SAM adapter functions is wrong Message-ID: <20131010124416.3D5DD62EF1@hg.openjdk.java.net> Changeset: 34f7a699cdef Author: sundar Date: 2013-10-10 14:43 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/34f7a699cdef 8026162: "this" in SAM adapter functions is wrong Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java + test/script/basic/JDK-8026162.js From tal.liron at threecrickets.com Thu Oct 10 06:16:44 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 10 Oct 2013 21:16:44 +0800 Subject: Synchronized functions Message-ID: <5256A8BC.5050804@threecrickets.com> How does one create synchronized functions in Nashorn? Rhino has this facility: function myFunction() { ... } myFunction = new org.mozilla.javascript.Synchronizer(myFunction) From tal.liron at threecrickets.com Thu Oct 10 06:53:07 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 10 Oct 2013 21:53:07 +0800 Subject: How to distribute a patched nashorn.jar? Message-ID: <5256B143.7040304@threecrickets.com> Currently, jre/lib/ext/nashorn.jar is loaded first. Is there a way to prefer a nashorn.jar distributed separately? From sundararajan.athijegannathan at oracle.com Thu Oct 10 07:12:35 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Oct 2013 16:12:35 +0200 Subject: How to distribute a patched nashorn.jar? In-Reply-To: <5256B143.7040304@threecrickets.com> References: <5256B143.7040304@threecrickets.com> Message-ID: <5256B5D3.2010105@oracle.com> java -Djava.ext.dirs= MainClass On Thursday 10 October 2013 03:53 PM, Tal Liron wrote: > Currently, jre/lib/ext/nashorn.jar is loaded first. Is there a way to > prefer a nashorn.jar distributed separately? From marcus.lagergren at oracle.com Thu Oct 10 07:17:00 2013 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Thu, 10 Oct 2013 14:17:00 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026250: Logging nullpointer bugfix and javadoc warnings Message-ID: <20131010141703.0D64062EF9@hg.openjdk.java.net> Changeset: ed3da7a574a0 Author: lagergren Date: 2013-10-10 16:16 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/ed3da7a574a0 8026250: Logging nullpointer bugfix and javadoc warnings Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java From tal.liron at threecrickets.com Thu Oct 10 09:50:52 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Fri, 11 Oct 2013 00:50:52 +0800 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: References: Message-ID: <5256DAEC.4060201@threecrickets.com> I've created a patch that I think meets the requirements. I haven't done a lot of testing, but it seems to work. I currently support conversion to String[] and Object[] arrays, but it would be trivial to add conversions to other primitive array types (boolean[], Number[], int[], etc.) Specifically, the changes are to TypeUtilities, JavaArgumenConverters, and Guards. It took quite a bit of research to find the right place to add the converter, but it's actually very little code and it seems basically correct to me. I do have some questions about specifics, but you would need to see the code first. I'm especially concerned about how I handled the warning log check in Guards. Where do I send the contributer agreement, and what is the best way to send my code to the team? On 10/09/2013 11:27 PM, Attila Szegedi wrote: > You'll also need to sign and send us an Oracle Contributor Agreement: > > > On Oct 9, 2013, at 4:28 PM, Jim Laskey > wrote: > >> If you can get the changes to me by Tuesday Oct 15th, I'll take a >> look. No guarantees, but if the changes are small, are correct, and >> do not restrict future enhancements in this area then I'll run the >> changes up the approval chain. >> >> Cheers, >> >> -- Jim From tal.liron at threecrickets.com Thu Oct 10 12:03:02 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Fri, 11 Oct 2013 03:03:02 +0800 Subject: Bug report: instanceof incompatible with mozilla_compat's importClass In-Reply-To: <525677AF.6060505@oracle.com> References: <5255A318.8080405@threecrickets.com> <5255A944.5060604@oracle.com> <52562567.5010301@threecrickets.com> <52563666.9030307@oracle.com> <52563C22.4040002@threecrickets.com> <525677AF.6060505@oracle.com> Message-ID: <5256F9E6.8010903@threecrickets.com> Thanks for your efforts, Sundar. This bug is proving very hard to isolate... all my attempts at a simple example don't reproduce the bug. (It occurs in a rather complex program in a Scripturian environment.) I have a question, though, on my current line of inquiry: Why does the definition of importClass in mozilla_compat use Object.defineProperty on "this"? This approach seems to limit portability. Is there no way to access the global scope from JavaScript? Or, perhaps, would it be possible to use the Object prototype instead? On 10/10/2013 05:47 PM, A. Sundararajan wrote: > Hmm.. does not seem to be the case.. From sundararajan.athijegannathan at oracle.com Thu Oct 10 12:07:19 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 10 Oct 2013 21:07:19 +0200 Subject: Review request for 8026264: Getter, setter function name mangling issues Message-ID: <5256FAE7.7040403@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026264/ -Sundar From james.laskey at oracle.com Thu Oct 10 12:09:49 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 10 Oct 2013 21:09:49 +0200 Subject: Review request for 8026264: Getter, setter function name mangling issues In-Reply-To: <5256FAE7.7040403@oracle.com> References: <5256FAE7.7040403@oracle.com> Message-ID: <4149A589-AB32-40A7-9231-0E9D9A936E52@oracle.com> +1 On 2013-10-10, at 9:07 PM, "A. Sundararajan" wrote: > Please review http://cr.openjdk.java.net/~sundar/8026264/ > > -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 10 12:44:15 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 10 Oct 2013 19:44:15 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026264: Getter, setter function name mangling issues Message-ID: <20131010194423.6038862F3D@hg.openjdk.java.net> Changeset: a781ea074521 Author: sundar Date: 2013-10-10 21:43 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/a781ea074521 8026264: Getter, setter function name mangling issues Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java + test/script/basic/JDK-8026264.js From sundararajan.athijegannathan at oracle.com Thu Oct 10 21:29:51 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 11 Oct 2013 06:29:51 +0200 Subject: Bug report: instanceof incompatible with mozilla_compat's importClass In-Reply-To: <5256F9E6.8010903@threecrickets.com> References: <5255A318.8080405@threecrickets.com> <5255A944.5060604@oracle.com> <52562567.5010301@threecrickets.com> <52563666.9030307@oracle.com> <52563C22.4040002@threecrickets.com> <525677AF.6060505@oracle.com> <5256F9E6.8010903@threecrickets.com> Message-ID: <52577EBF.2060305@oracle.com> Hi, FWIW, I fixed repeated __noSuchProperty__ chaining in importPackage as part of changeset: 598:e60bbcf2f6b6 user: sundar date: Thu Oct 10 13:17:57 2013 +0200 summary: 8026248: importClass has to be a varargs function If it reproduces with smaller test case, we'll revisit again. On Object.defineProperty: this is to use have correct "enumerability" for additional global properties. i.e., don't want to start enumerating more properties -- and be on par with the other builit-in globals. -Sundar On Thursday 10 October 2013 09:03 PM, Tal Liron wrote: > Thanks for your efforts, Sundar. This bug is proving very hard to > isolate... all my attempts at a simple example don't reproduce the > bug. (It occurs in a rather complex program in a Scripturian > environment.) > > I have a question, though, on my current line of inquiry: Why does the > definition of importClass in mozilla_compat use Object.defineProperty > on "this"? This approach seems to limit portability. Is there no way > to access the global scope from JavaScript? Or, perhaps, would it be > possible to use the Object prototype instead? > > On 10/10/2013 05:47 PM, A. Sundararajan wrote: >> Hmm.. does not seem to be the case.. > From sundararajan.athijegannathan at oracle.com Thu Oct 10 21:31:44 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 11 Oct 2013 06:31:44 +0200 Subject: Review request for 8026263: [NASHORN] Test test/script/basic/JDK-8025488.js fails in nightly builds Message-ID: <52577F30.6030003@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026263/ -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 10 21:50:17 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 11 Oct 2013 04:50:17 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026263: [NASHORN] Test test/script/basic/JDK-8025488.js fails in nightly builds Message-ID: <20131011045028.9B26462F59@hg.openjdk.java.net> Changeset: 375c2f2d41c8 Author: sundar Date: 2013-10-11 06:50 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/375c2f2d41c8 8026263: [NASHORN] Test test/script/basic/JDK-8025488.js fails in nightly builds Reviewed-by: jlaskey ! test/script/basic/JDK-8025488.js From james.laskey at oracle.com Thu Oct 10 23:15:06 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 11 Oct 2013 08:15:06 +0200 Subject: Review request for 8026263: [NASHORN] Test test/script/basic/JDK-8025488.js fails in nightly builds In-Reply-To: <52577F30.6030003@oracle.com> References: <52577F30.6030003@oracle.com> Message-ID: <13A5065C-BB36-4A48-ABB9-24A8376A016B@oracle.com> +1 On 2013-10-11, at 6:31 AM, "A. Sundararajan" wrote: > Please review http://cr.openjdk.java.net/~sundar/8026263/ > > -Sundar From sundararajan.athijegannathan at oracle.com Fri Oct 11 00:31:36 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 11 Oct 2013 09:31:36 +0200 Subject: Synchronized functions In-Reply-To: <5256A8BC.5050804@threecrickets.com> References: <5256A8BC.5050804@threecrickets.com> Message-ID: <5257A958.6080106@oracle.com> There is a 'sync' function in a demo application (jconsole script plugin). This may be of use. var sync = function(func, obj) { if (arguments.length < 1 || arguments.length > 2 ) { throw "sync(function [,object]) parameter count mismatch"; } var syncobj = (arguments.length == 2 ? obj : this); if (!syncobj._syncLock) { syncobj._syncLock = new Lock(); } return function() { syncobj._syncLock.lock(); try { func.apply(null, arguments); } finally { syncobj._syncLock.unlock(); } }; }; See also: https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt -Sundar On Thursday 10 October 2013 03:16 PM, Tal Liron wrote: > How does one create synchronized functions in Nashorn? > > Rhino has this facility: > > function myFunction() { ... } > myFunction = new org.mozilla.javascript.Synchronizer(myFunction) From hannes.wallnoefer at oracle.com Fri Oct 11 01:37:03 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 11 Oct 2013 10:37:03 +0200 Subject: Review request for JDK-8026016: too many relinks dominate avatar.js http benchmark Message-ID: <5257B8AF.10803@oracle.com> Please review JDK-8026016: too many relinks dominate avatar.js http benchmark. http://cr.openjdk.java.net/~hannesw/8026016/ Thanks, Hannes From tal.liron at threecrickets.com Fri Oct 11 01:45:57 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Fri, 11 Oct 2013 16:45:57 +0800 Subject: Synchronized functions In-Reply-To: <5257A958.6080106@oracle.com> References: <5256A8BC.5050804@threecrickets.com> <5257A958.6080106@oracle.com> Message-ID: <5257BAC5.5070503@threecrickets.com> Thanks! Would it be possible to add this to mozilla_compat.js so that "new org.mozilla.javascript.Synchronizer(myFunction)" would work? On 10/11/2013 03:31 PM, A. Sundararajan wrote: > There is a 'sync' function in a demo application (jconsole script > plugin). This may be of use. > > var sync = function(func, obj) { > if (arguments.length < 1 || arguments.length > 2 ) { > throw "sync(function [,object]) parameter count mismatch"; > } > > var syncobj = (arguments.length == 2 ? obj : this); > > if (!syncobj._syncLock) { > syncobj._syncLock = new Lock(); > } > > return function() { > syncobj._syncLock.lock(); > try { > func.apply(null, arguments); > } finally { > syncobj._syncLock.unlock(); > } > }; > }; > > See also: > https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt > > -Sundar > > On Thursday 10 October 2013 03:16 PM, Tal Liron wrote: >> How does one create synchronized functions in Nashorn? >> >> Rhino has this facility: >> >> function myFunction() { ... } >> myFunction = new org.mozilla.javascript.Synchronizer(myFunction) > From hannes.wallnoefer at oracle.com Fri Oct 11 01:54:00 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 11 Oct 2013 10:54:00 +0200 Subject: Review request for JDK-8026292: Megamorphic setter fails with boolean value Message-ID: <5257BCA8.7090303@oracle.com> Please review JDK-8026292: Megamorphic setter fails with boolean value: http://cr.openjdk.java.net/~hannesw/8026292/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Fri Oct 11 01:55:57 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 11 Oct 2013 10:55:57 +0200 Subject: Review request for 8026302: source representation of getter and setter methods is wrong Message-ID: <5257BD1D.5000008@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026302/ -Sundar From tal.liron at threecrickets.com Fri Oct 11 02:02:43 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Fri, 11 Oct 2013 17:02:43 +0800 Subject: Synchronized functions In-Reply-To: <5257BAC5.5070503@threecrickets.com> References: <5256A8BC.5050804@threecrickets.com> <5257A958.6080106@oracle.com> <5257BAC5.5070503@threecrickets.com> Message-ID: <5257BEB3.8000906@threecrickets.com> Also, wouldn't this shorter version work? function synchronize(fn) { var lock = new java.util.concurrent.locks.ReentrantLock() return function() { lock.lock() try { return fn.apply(this, arguments) } finally { lock.unlock() } } } On 10/11/2013 04:45 PM, Tal Liron wrote: > Thanks! > > Would it be possible to add this to mozilla_compat.js so that "new > org.mozilla.javascript.Synchronizer(myFunction)" would work? > > On 10/11/2013 03:31 PM, A. Sundararajan wrote: >> There is a 'sync' function in a demo application (jconsole script >> plugin). This may be of use. >> >> var sync = function(func, obj) { >> if (arguments.length < 1 || arguments.length > 2 ) { >> throw "sync(function [,object]) parameter count mismatch"; >> } >> >> var syncobj = (arguments.length == 2 ? obj : this); >> >> if (!syncobj._syncLock) { >> syncobj._syncLock = new Lock(); >> } >> >> return function() { >> syncobj._syncLock.lock(); >> try { >> func.apply(null, arguments); >> } finally { >> syncobj._syncLock.unlock(); >> } >> }; >> }; >> >> See also: >> https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt >> >> -Sundar >> >> On Thursday 10 October 2013 03:16 PM, Tal Liron wrote: >>> How does one create synchronized functions in Nashorn? >>> >>> Rhino has this facility: >>> >>> function myFunction() { ... } >>> myFunction = new org.mozilla.javascript.Synchronizer(myFunction) >> > From hannes.wallnoefer at oracle.com Fri Oct 11 02:05:01 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 11 Oct 2013 11:05:01 +0200 Subject: Review request for 8026302: source representation of getter and setter methods is wrong In-Reply-To: <5257BD1D.5000008@oracle.com> References: <5257BD1D.5000008@oracle.com> Message-ID: <5257BF3D.60406@oracle.com> +1 Am 2013-10-11 10:55, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8026302/ > > -Sundar From james.laskey at oracle.com Fri Oct 11 02:06:40 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 11 Oct 2013 11:06:40 +0200 Subject: Review request for 8026302: source representation of getter and setter methods is wrong In-Reply-To: <5257BD1D.5000008@oracle.com> References: <5257BD1D.5000008@oracle.com> Message-ID: <4C8DD723-6E6C-436D-A32D-9B728876CF98@oracle.com> +1 On 2013-10-11, at 10:55 AM, "A. Sundararajan" wrote: > Please review http://cr.openjdk.java.net/~sundar/8026302/ > > -Sundar From james.laskey at oracle.com Fri Oct 11 02:16:47 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 11 Oct 2013 11:16:47 +0200 Subject: Review request for JDK-8026292: Megamorphic setter fails with boolean value In-Reply-To: <5257BCA8.7090303@oracle.com> References: <5257BCA8.7090303@oracle.com> Message-ID: <82BDCA84-2FEE-425B-95AB-C37625458FCA@oracle.com> +1 On 2013-10-11, at 10:54 AM, Hannes Wallnoefer wrote: > Please review JDK-8026292: Megamorphic setter fails with boolean value: > > http://cr.openjdk.java.net/~hannesw/8026292/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Fri Oct 11 02:17:32 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 11 Oct 2013 11:17:32 +0200 Subject: Review request for JDK-8026292: Megamorphic setter fails with boolean value In-Reply-To: <5257BCA8.7090303@oracle.com> References: <5257BCA8.7090303@oracle.com> Message-ID: <5257C22C.4050206@oracle.com> +1 On Friday 11 October 2013 10:54 AM, Hannes Wallnoefer wrote: > Please review JDK-8026292: Megamorphic setter fails with boolean value: > > http://cr.openjdk.java.net/~hannesw/8026292/ > > Thanks, > Hannes From tal.liron at threecrickets.com Fri Oct 11 02:20:27 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Fri, 11 Oct 2013 17:20:27 +0800 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <5256DAEC.4060201@threecrickets.com> References: <5256DAEC.4060201@threecrickets.com> Message-ID: <5257C2DB.1040200@threecrickets.com> I hope someone can help me get my contribution in soon! The project is moving quickly... an hg pull last night broke my fix, but I re-fixed and improved it. The sooner it can be integrated, the better. Now only two files need to be changed: JavaArgumentConverters and NashornPrimitiveLinker. I've also added all the primitive array types and improved the logic a bit. On 10/11/2013 12:50 AM, Tal Liron wrote: > I've created a patch that I think meets the requirements. I haven't > done a lot of testing, but it seems to work. I currently support > conversion to String[] and Object[] arrays, but it would be trivial to > add conversions to other primitive array types (boolean[], Number[], > int[], etc.) > > Specifically, the changes are to TypeUtilities, JavaArgumenConverters, > and Guards. > > It took quite a bit of research to find the right place to add the > converter, but it's actually very little code and it seems basically > correct to me. I do have some questions about specifics, but you would > need to see the code first. I'm especially concerned about how I > handled the warning log check in Guards. > > Where do I send the contributer agreement, and what is the best way to > send my code to the team? > > On 10/09/2013 11:27 PM, Attila Szegedi wrote: >> You'll also need to sign and send us an Oracle Contributor Agreement: >> >> >> On Oct 9, 2013, at 4:28 PM, Jim Laskey > > wrote: >> >>> If you can get the changes to me by Tuesday Oct 15th, I'll take a >>> look. No guarantees, but if the changes are small, are correct, and >>> do not restrict future enhancements in this area then I'll run the >>> changes up the approval chain. >>> >>> Cheers, >>> >>> -- Jim > From hannes.wallnoefer at oracle.com Fri Oct 11 02:23:10 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 11 Oct 2013 11:23:10 +0200 Subject: Synchronized functions In-Reply-To: <5257BAC5.5070503@threecrickets.com> References: <5256A8BC.5050804@threecrickets.com> <5257A958.6080106@oracle.com> <5257BAC5.5070503@threecrickets.com> Message-ID: <5257C37E.1070803@oracle.com> Actually Rhino exposes a "sync" function for this purpose, org.mozilla.javascript.Synchronizer is just the class implementing this feature and not meant to be used directly by scripts. While you could do something like this in Nashorn I would advise against it. Thread-safety is not one of the primary design goals in Nashorn, and nowadays most people would agree that there are better and safer ways for working with threads. I suggest looking at Worker/Actor models where you have multiple script engines working together through message passing. Hannes Am 2013-10-11 10:45, schrieb Tal Liron: > Thanks! > > Would it be possible to add this to mozilla_compat.js so that "new > org.mozilla.javascript.Synchronizer(myFunction)" would work? > > On 10/11/2013 03:31 PM, A. Sundararajan wrote: >> There is a 'sync' function in a demo application (jconsole script >> plugin). This may be of use. >> >> var sync = function(func, obj) { >> if (arguments.length < 1 || arguments.length > 2 ) { >> throw "sync(function [,object]) parameter count mismatch"; >> } >> >> var syncobj = (arguments.length == 2 ? obj : this); >> >> if (!syncobj._syncLock) { >> syncobj._syncLock = new Lock(); >> } >> >> return function() { >> syncobj._syncLock.lock(); >> try { >> func.apply(null, arguments); >> } finally { >> syncobj._syncLock.unlock(); >> } >> }; >> }; >> >> See also: >> https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt >> >> -Sundar >> >> On Thursday 10 October 2013 03:16 PM, Tal Liron wrote: >>> How does one create synchronized functions in Nashorn? >>> >>> Rhino has this facility: >>> >>> function myFunction() { ... } >>> myFunction = new org.mozilla.javascript.Synchronizer(myFunction) >> > From james.laskey at oracle.com Fri Oct 11 02:24:07 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 11 Oct 2013 11:24:07 +0200 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: <5257C2DB.1040200@threecrickets.com> References: <5256DAEC.4060201@threecrickets.com> <5257C2DB.1040200@threecrickets.com> Message-ID: Once you sign the contributor agreement we can accept your changes. On 2013-10-11, at 11:20 AM, Tal Liron wrote: > I hope someone can help me get my contribution in soon! The project is moving quickly... an hg pull last night broke my fix, but I re-fixed and improved it. The sooner it can be integrated, the better. > > Now only two files need to be changed: JavaArgumentConverters and NashornPrimitiveLinker. I've also added all the primitive array types and improved the logic a bit. > > On 10/11/2013 12:50 AM, Tal Liron wrote: >> I've created a patch that I think meets the requirements. I haven't done a lot of testing, but it seems to work. I currently support conversion to String[] and Object[] arrays, but it would be trivial to add conversions to other primitive array types (boolean[], Number[], int[], etc.) >> >> Specifically, the changes are to TypeUtilities, JavaArgumenConverters, and Guards. >> >> It took quite a bit of research to find the right place to add the converter, but it's actually very little code and it seems basically correct to me. I do have some questions about specifics, but you would need to see the code first. I'm especially concerned about how I handled the warning log check in Guards. >> >> Where do I send the contributer agreement, and what is the best way to send my code to the team? >> >> On 10/09/2013 11:27 PM, Attila Szegedi wrote: >>> You'll also need to sign and send us an Oracle Contributor Agreement: >>> >>> On Oct 9, 2013, at 4:28 PM, Jim Laskey > wrote: >>> >>>> If you can get the changes to me by Tuesday Oct 15th, I'll take a look. No guarantees, but if the changes are small, are correct, and do not restrict future enhancements in this area then I'll run the changes up the approval chain. >>>> >>>> Cheers, >>>> >>>> -- Jim >> > From hannes.wallnoefer at oracle.com Fri Oct 11 01:57:18 2013 From: hannes.wallnoefer at oracle.com (hannes.wallnoefer at oracle.com) Date: Fri, 11 Oct 2013 08:57:18 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026292: Megamorphic setter fails with boolean value Message-ID: <20131011085723.3D72962F64@hg.openjdk.java.net> Changeset: 1c154cee43d9 Author: hannesw Date: 2013-10-11 10:56 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/1c154cee43d9 8026292: Megamorphic setter fails with boolean value Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8026292.js From tal.liron at threecrickets.com Fri Oct 11 02:28:58 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Fri, 11 Oct 2013 17:28:58 +0800 Subject: Synchronized functions In-Reply-To: <5257C37E.1070803@oracle.com> References: <5256A8BC.5050804@threecrickets.com> <5257A958.6080106@oracle.com> <5257BAC5.5070503@threecrickets.com> <5257C37E.1070803@oracle.com> Message-ID: <5257C4DA.90406@threecrickets.com> The Scripturian environment is designed for multi-threadedness and does the "right thing" in terms of Nashorn contexts/globals to ensure separation. In concurrent environments, using locks can be useful. Might not the best choice for high concurrency, but it sometimes it's necessary, especially when working with 3rd party libraries. It would be nice if "sync" were added to mozilla_compat. Isn't the whole point of it to support legacy code? On 10/11/2013 05:23 PM, Hannes Wallnoefer wrote: > Actually Rhino exposes a "sync" function for this purpose, > org.mozilla.javascript.Synchronizer is just the class implementing > this feature and not meant to be used directly by scripts. > > While you could do something like this in Nashorn I would advise > against it. Thread-safety is not one of the primary design goals in > Nashorn, and nowadays most people would agree that there are better > and safer ways for working with threads. I suggest looking at > Worker/Actor models where you have multiple script engines working > together through message passing. > > Hannes > > Am 2013-10-11 10:45, schrieb Tal Liron: >> Thanks! >> >> Would it be possible to add this to mozilla_compat.js so that "new >> org.mozilla.javascript.Synchronizer(myFunction)" would work? >> >> On 10/11/2013 03:31 PM, A. Sundararajan wrote: >>> There is a 'sync' function in a demo application (jconsole script >>> plugin). This may be of use. >>> >>> var sync = function(func, obj) { >>> if (arguments.length < 1 || arguments.length > 2 ) { >>> throw "sync(function [,object]) parameter count mismatch"; >>> } >>> >>> var syncobj = (arguments.length == 2 ? obj : this); >>> >>> if (!syncobj._syncLock) { >>> syncobj._syncLock = new Lock(); >>> } >>> >>> return function() { >>> syncobj._syncLock.lock(); >>> try { >>> func.apply(null, arguments); >>> } finally { >>> syncobj._syncLock.unlock(); >>> } >>> }; >>> }; >>> >>> See also: >>> https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt >>> >>> -Sundar >>> >>> On Thursday 10 October 2013 03:16 PM, Tal Liron wrote: >>>> How does one create synchronized functions in Nashorn? >>>> >>>> Rhino has this facility: >>>> >>>> function myFunction() { ... } >>>> myFunction = new org.mozilla.javascript.Synchronizer(myFunction) >>> >> > From james.laskey at oracle.com Fri Oct 11 03:00:25 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 11 Oct 2013 12:00:25 +0200 Subject: Review request: 8026309 - latest runsunspider.js tests contains several bugs Message-ID: <3F05C5E1-D4E0-46B0-9FAB-40A1CFF11A0B@oracle.com> http://cr.openjdk.java.net/~jlaskey/8026309/webrev.00 From sundararajan.athijegannathan at oracle.com Fri Oct 11 03:09:33 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 11 Oct 2013 12:09:33 +0200 Subject: Review request: 8026309 - latest runsunspider.js tests contains several bugs In-Reply-To: <3F05C5E1-D4E0-46B0-9FAB-40A1CFF11A0B@oracle.com> References: <3F05C5E1-D4E0-46B0-9FAB-40A1CFF11A0B@oracle.com> Message-ID: <5257CE5D.2050800@oracle.com> +1 On Friday 11 October 2013 12:00 PM, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8026309/webrev.00 From sundararajan.athijegannathan at oracle.com Fri Oct 11 02:16:52 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 11 Oct 2013 09:16:52 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026302: source representation of getter and setter methods is wrong Message-ID: <20131011091656.220D962F66@hg.openjdk.java.net> Changeset: fb091f9052a6 Author: sundar Date: 2013-10-11 11:15 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/fb091f9052a6 8026302: source representation of getter and setter methods is wrong Reviewed-by: lagergren, hannesw, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8026302.js + test/script/basic/JDK-8026302.js.EXPECTED ! test/script/basic/objects.js.EXPECTED From hannes.wallnoefer at oracle.com Fri Oct 11 03:45:07 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 11 Oct 2013 12:45:07 +0200 Subject: Synchronized functions In-Reply-To: <5257C4DA.90406@threecrickets.com> References: <5256A8BC.5050804@threecrickets.com> <5257A958.6080106@oracle.com> <5257BAC5.5070503@threecrickets.com> <5257C37E.1070803@oracle.com> <5257C4DA.90406@threecrickets.com> Message-ID: <5257D6B3.6050308@oracle.com> I guess addition to mozilla_compat would be ok. Can you please file a bug for this at https://bugs.openjdk.java.net/? Thanks, Hannes Am 2013-10-11 11:28, schrieb Tal Liron: > The Scripturian environment is designed for multi-threadedness and > does the "right thing" in terms of Nashorn contexts/globals to ensure > separation. In concurrent environments, using locks can be useful. > Might not the best choice for high concurrency, but it sometimes it's > necessary, especially when working with 3rd party libraries. > > It would be nice if "sync" were added to mozilla_compat. Isn't the > whole point of it to support legacy code? > > On 10/11/2013 05:23 PM, Hannes Wallnoefer wrote: >> Actually Rhino exposes a "sync" function for this purpose, >> org.mozilla.javascript.Synchronizer is just the class implementing >> this feature and not meant to be used directly by scripts. >> >> While you could do something like this in Nashorn I would advise >> against it. Thread-safety is not one of the primary design goals in >> Nashorn, and nowadays most people would agree that there are better >> and safer ways for working with threads. I suggest looking at >> Worker/Actor models where you have multiple script engines working >> together through message passing. >> >> Hannes >> >> Am 2013-10-11 10:45, schrieb Tal Liron: >>> Thanks! >>> >>> Would it be possible to add this to mozilla_compat.js so that "new >>> org.mozilla.javascript.Synchronizer(myFunction)" would work? >>> >>> On 10/11/2013 03:31 PM, A. Sundararajan wrote: >>>> There is a 'sync' function in a demo application (jconsole script >>>> plugin). This may be of use. >>>> >>>> var sync = function(func, obj) { >>>> if (arguments.length < 1 || arguments.length > 2 ) { >>>> throw "sync(function [,object]) parameter count mismatch"; >>>> } >>>> >>>> var syncobj = (arguments.length == 2 ? obj : this); >>>> >>>> if (!syncobj._syncLock) { >>>> syncobj._syncLock = new Lock(); >>>> } >>>> >>>> return function() { >>>> syncobj._syncLock.lock(); >>>> try { >>>> func.apply(null, arguments); >>>> } finally { >>>> syncobj._syncLock.unlock(); >>>> } >>>> }; >>>> }; >>>> >>>> See also: >>>> https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt >>>> >>>> -Sundar >>>> >>>> On Thursday 10 October 2013 03:16 PM, Tal Liron wrote: >>>>> How does one create synchronized functions in Nashorn? >>>>> >>>>> Rhino has this facility: >>>>> >>>>> function myFunction() { ... } >>>>> myFunction = new org.mozilla.javascript.Synchronizer(myFunction) >>>> >>> >> > From tal.liron at threecrickets.com Fri Oct 11 03:58:57 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Fri, 11 Oct 2013 18:58:57 +0800 Subject: Synchronized functions In-Reply-To: <5257D6B3.6050308@oracle.com> References: <5256A8BC.5050804@threecrickets.com> <5257A958.6080106@oracle.com> <5257BAC5.5070503@threecrickets.com> <5257C37E.1070803@oracle.com> <5257C4DA.90406@threecrickets.com> <5257D6B3.6050308@oracle.com> Message-ID: <5257D9F1.2030404@threecrickets.com> There doesn't seem to be a way for me to add Nashorn bugs there. Could you guys do it? On 10/11/2013 06:45 PM, Hannes Wallnoefer wrote: > I guess addition to mozilla_compat would be ok. Can you please file a > bug for this at https://bugs.openjdk.java.net/? From tal.liron at threecrickets.com Fri Oct 11 03:59:55 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Fri, 11 Oct 2013 18:59:55 +0800 Subject: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays In-Reply-To: References: Message-ID: <5257DA2B.3030409@threecrickets.com> Attached is my working patch. I've signed the developer agreement and sent it to the Oracle as required. I've marked all my changes with a "// TAL" comment so you can easily find them. Here is the explanation: JavaArgumentConverters.java: I've added new converters for all primitive array types, as well as Object[] and String[]. For NativeArrays, it would convert all the individual elements. For other object types, it would attempt to create a one-element array, assuming that element is convertible. I added a few utility methods, too, to help with this. I also took the liberty to make a change to toString: it will fallback to Object.toString. (I have a feeling some of you will not like this change, as it's not directly related to the feature, but I see no harm in it, and it much helped my testing. In fact, it's even Java's behavior when working with non-string objects. Without this change, JavaScript programmers would still have to work hard to set up arrays before sending them to Java.) NashornPrimitiveLinker.java: canLinkTypeStatic now recognizes all the supported primitive array types. In compareConversion, I've also added a check to prefer conversion to arrays over conversion to primitives. Without this, an ambiguous exception could be thrown in cases where two similar method signatures exist. (For example, java.lang.Runtime.execute has a version that accepts a string array and another that accepts a string.) I think this can be further improved to prefer Object[] over String[] if there is such ambiguity. What I need help with from you guys is in getGuardedInvocation: I currently return null for NativeArray, because I'm not sure how to get an appropriate guard. Currently primitiveLookup only supports non-array primitive types. I think what happens in this case is that a default guard is provided, but I'm not entirely sure. Guards.java: I've added extra checks to avoid the isInstanceGuardAlwaysFalse log warning for array conversions. On 10/09/2013 10:28 PM, Jim Laskey wrote: > If you can get the changes to me by Tuesday Oct 15th, I'll take a look. No guarantees, but if the changes are small, are correct, and do not restrict future enhancements in this area then I'll run the changes up the approval chain. > > -------------- next part -------------- diff --git a/src/jdk/internal/dynalink/support/Guards.java b/src/jdk/internal/dynalink/support/Guards.java --- a/src/jdk/internal/dynalink/support/Guards.java +++ b/src/jdk/internal/dynalink/support/Guards.java @@ -155,7 +155,18 @@ LOG.log(Level.WARNING, "isInstanceGuardAlwaysTrue", new Object[] { clazz.getName(), pos, type }); return constantTrue(type); } - if(!declaredType.isAssignableFrom(clazz)) { + if(!declaredType.isAssignableFrom(clazz) && + // TAL + clazz != Object[].class && + clazz != String[].class && + clazz != boolean[].class && + clazz != float[].class && + clazz != double[].class && + clazz != byte[].class && + clazz != short[].class && + clazz != int[].class && + clazz != long[].class && + clazz != char[].class) { LOG.log(Level.WARNING, "isInstanceGuardAlwaysFalse", new Object[] { clazz.getName(), pos, type }); return constantFalse(type); } diff --git a/src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java b/src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java --- a/src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java +++ b/src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java @@ -25,18 +25,21 @@ package jdk.nashorn.internal.runtime.linker; +import static jdk.nashorn.internal.lookup.Lookup.MH; import static jdk.nashorn.internal.runtime.ECMAErrors.typeError; import static jdk.nashorn.internal.runtime.ScriptRuntime.UNDEFINED; -import static jdk.nashorn.internal.lookup.Lookup.MH; import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.util.HashMap; import java.util.Map; + import jdk.internal.dynalink.support.TypeUtilities; +import jdk.nashorn.internal.objects.NativeArray; import jdk.nashorn.internal.runtime.ConsString; import jdk.nashorn.internal.runtime.JSType; import jdk.nashorn.internal.runtime.ScriptObject; +import jdk.nashorn.internal.runtime.arrays.ArrayData; /** * Utility class shared by {@code NashornLinker} and {@code NashornPrimitiveLinker} for converting JS values to Java @@ -53,6 +56,18 @@ private static final MethodHandle TO_CHAR = findOwnMH("toChar", Character.class, Object.class); private static final MethodHandle TO_CHAR_PRIMITIVE = findOwnMH("toCharPrimitive", char.class, Object.class); + // TAL + private static final MethodHandle TO_OBJECT_ARRAY = findOwnMH("toObjectArray", Object[].class, Object.class); + private static final MethodHandle TO_STRING_ARRAY = findOwnMH("toStringArray", String[].class, Object.class); + private static final MethodHandle TO_BOOLEAN_PRIMITIVE_ARRAY = findOwnMH("toBooleanPrimitiveArray", boolean[].class, Object.class); + private static final MethodHandle TO_FLOAT_PRIMITIVE_ARRAY = findOwnMH("toFloatPrimitiveArray", float[].class, Object.class); + private static final MethodHandle TO_DOUBLE_PRIMITIVE_ARRAY = findOwnMH("toDoublePrimitiveArray", double[].class, Object.class); + private static final MethodHandle TO_BYTE_PRIMITIVE_ARRAY = findOwnMH("toBytePrimitiveArray", byte[].class, Object.class); + private static final MethodHandle TO_SHORT_PRIMITIVE_ARRAY = findOwnMH("toShortPrimitiveArray", short[].class, Object.class); + private static final MethodHandle TO_INT_PRIMITIVE_ARRAY = findOwnMH("toIntPrimitiveArray", int[].class, Object.class); + private static final MethodHandle TO_LONG_PRIMITIVE_ARRAY = findOwnMH("toLongPrimitiveArray", long[].class, Object.class); + private static final MethodHandle TO_CHAR_PRIMITIVE_ARRAY = findOwnMH("toCharPrimitiveArray", char[].class, Object.class); + private JavaArgumentConverters() { } @@ -60,7 +75,6 @@ return CONVERTERS.get(targetType); } - @SuppressWarnings("unused") private static Boolean toBoolean(final Object obj) { if (obj instanceof Boolean) { return (Boolean) obj; @@ -98,6 +112,12 @@ throw assertUnexpectedType(obj); } + // TAL + private static boolean toBooleanPrimitive(final Object obj0) { + final Boolean b = toBoolean(obj0); + return b == null ? false : b; + } + private static Character toChar(final Object o) { if (o == null) { return null; @@ -124,7 +144,6 @@ return s.charAt(0); } - @SuppressWarnings("unused") private static char toCharPrimitive(final Object obj0) { final Character c = toChar(obj0); return c == null ? (char)0 : c; @@ -150,11 +169,12 @@ obj = JSType.toPrimitive(obj, String.class); continue; } - throw assertUnexpectedType(obj); + // TAL + return obj.toString(); + //throw assertUnexpectedType(obj); } } - @SuppressWarnings("unused") private static Double toDouble(final Object obj0) { // TODO - Order tests for performance. for (Object obj = obj0; ;) { @@ -180,6 +200,12 @@ } } + // TAL + private static double toDoublePrimitive(final Object obj0) { + final Double d = toDouble(obj0); + return d == null ? 0.0D : d; + } + @SuppressWarnings("unused") private static Number toNumber(final Object obj0) { // TODO - Order tests for performance. @@ -227,16 +253,194 @@ } } - private static AssertionError assertUnexpectedType(final Object obj) { - return new AssertionError("Unexpected type" + obj.getClass().getName() + ". Guards should have prevented this"); - } - - @SuppressWarnings("unused") private static long toLongPrimitive(final Object obj0) { final Long l = toLong(obj0); return l == null ? 0L : l; } + // TAL + @SuppressWarnings("unused") + private static Object[] toObjectArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + Object[] r = new Object[length]; + for (int i = 0; i < length; i++) { + r[i] = data.getObject(i); + } + return r; + } else { + return obj0 != null ? new Object[] { obj0 } : null; + } + } + + // TAL + @SuppressWarnings("unused") + private static String[] toStringArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + String[] r = new String[length]; + for (int i = 0; i < length; i++) { + r[i] = toString(data.getObject(i)); + } + return r; + } else { + String r = toString(obj0); + return r != null ? new String[] { r } : null; + } + } + + // TAL + @SuppressWarnings("unused") + private static boolean[] toBooleanPrimitiveArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + boolean[] r = new boolean[length]; + for (int i = 0; i < length; i++) { + r[i] = toBooleanPrimitive(data.getObject(i)); + } + return r; + } else { + Boolean r = toBoolean(obj0); + return r != null ? new boolean[] { r } : null; + } + } + + // TAL + @SuppressWarnings("unused") + private static float[] toFloatPrimitiveArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + float[] r = new float[length]; + for (int i = 0; i < length; i++) { + r[i] = (float) toDoublePrimitive(data.getObject(i)); + } + return r; + } else { + Double r = toDouble(obj0); + return r != null ? new float[] { r.floatValue() } : null; + } + } + + // TAL + @SuppressWarnings("unused") + private static double[] toDoublePrimitiveArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + double[] r = new double[length]; + for (int i = 0; i < length; i++) { + r[i] = toDoublePrimitive(data.getObject(i)); + } + return r; + } else { + Double r = toDouble(obj0); + return r != null ? new double[] { r } : null; + } + } + + // TAL + @SuppressWarnings("unused") + private static byte[] toBytePrimitiveArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + byte[] r = new byte[length]; + for (int i = 0; i < length; i++) { + r[i] = (byte) toLongPrimitive(data.getObject(i)); + } + return r; + } else { + Long r = toLong(obj0); + return r != null ? new byte[] { r.byteValue() } : null; + } + } + + // TAL + @SuppressWarnings("unused") + private static short[] toShortPrimitiveArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + short[] r = new short[length]; + for (int i = 0; i < length; i++) { + r[i] = (short) toLongPrimitive(data.getObject(i)); + } + return r; + } else { + Long r = toLong(obj0); + return r != null ? new short[] { r.shortValue() } : null; + } + } + + // TAL + @SuppressWarnings("unused") + private static int[] toIntPrimitiveArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + int[] r = new int[length]; + for (int i = 0; i < length; i++) { + r[i] = (int) toLongPrimitive(data.getObject(i)); + } + return r; + } else { + Long r = toLong(obj0); + return r != null ? new int[] { r.intValue() } : null; + } + } + + // TAL + @SuppressWarnings("unused") + private static long[] toLongPrimitiveArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + long[] r = new long[length]; + for (int i = 0; i < length; i++) { + r[i] = toLongPrimitive(data.getObject(i)); + } + return r; + } else { + Long r = toLong(obj0); + return r != null ? new long[] { r } : null; + } + } + + // TAL + @SuppressWarnings("unused") + private static char[] toCharPrimitiveArray(final Object obj0) + { + if (obj0 instanceof NativeArray) { + ArrayData data = ((NativeArray) obj0).getArray(); + int length = (int) data.length(); + char[] r = new char[length]; + for (int i = 0; i < length; i++) { + r[i] = toCharPrimitive(data.getObject(i)); + } + return r; + } else { + Character r = toChar(obj0); + return r != null ? new char[] { r } : null; + } + } + + private static AssertionError assertUnexpectedType(final Object obj) { + return new AssertionError("Unexpected type" + obj.getClass().getName() + ". Guards should have prevented this"); + } + private static MethodHandle findOwnMH(final String name, final Class rtype, final Class... types) { return MH.findStatic(MethodHandles.lookup(), JavaArgumentConverters.class, name, MH.type(rtype, types)); } @@ -259,6 +463,18 @@ CONVERTERS.put(long.class, TO_LONG_PRIMITIVE); CONVERTERS.put(Long.class, TO_LONG); + // TAL + CONVERTERS.put(Object[].class, TO_OBJECT_ARRAY); + CONVERTERS.put(String[].class, TO_STRING_ARRAY); + CONVERTERS.put(boolean[].class, TO_BOOLEAN_PRIMITIVE_ARRAY); + CONVERTERS.put(float[].class, TO_FLOAT_PRIMITIVE_ARRAY); + CONVERTERS.put(double[].class, TO_DOUBLE_PRIMITIVE_ARRAY); + CONVERTERS.put(byte[].class, TO_BYTE_PRIMITIVE_ARRAY); + CONVERTERS.put(short[].class, TO_SHORT_PRIMITIVE_ARRAY); + CONVERTERS.put(int[].class, TO_INT_PRIMITIVE_ARRAY); + CONVERTERS.put(long[].class, TO_LONG_PRIMITIVE_ARRAY); + CONVERTERS.put(char[].class, TO_CHAR_PRIMITIVE_ARRAY); + putLongConverter(Byte.class); putLongConverter(Short.class); putLongConverter(Integer.class); diff --git a/src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java b/src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java --- a/src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java +++ b/src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java @@ -29,6 +29,7 @@ import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; + import jdk.internal.dynalink.linker.ConversionComparator; import jdk.internal.dynalink.linker.GuardedInvocation; import jdk.internal.dynalink.linker.GuardingTypeConverterFactory; @@ -36,6 +37,7 @@ import jdk.internal.dynalink.linker.LinkerServices; import jdk.internal.dynalink.linker.TypeBasedGuardingDynamicLinker; import jdk.internal.dynalink.support.TypeUtilities; +import jdk.nashorn.internal.objects.NativeArray; import jdk.nashorn.internal.runtime.ConsString; import jdk.nashorn.internal.runtime.Context; import jdk.nashorn.internal.runtime.GlobalObject; @@ -52,7 +54,12 @@ } private static boolean canLinkTypeStatic(final Class type) { - return type == String.class || type == Boolean.class || type == ConsString.class || Number.class.isAssignableFrom(type); + return type == String.class || type == Boolean.class || type == ConsString.class || Number.class.isAssignableFrom(type) || + // TAL + type == String[].class || type == Object[].class || type == boolean[].class || + type == float[].class || type == double[].class || + type == byte[].class || type == short[].class || type == int[].class || type == long[].class || + type == char[].class; } @Override @@ -63,6 +70,12 @@ final Object self = request.getReceiver(); final GlobalObject global = (GlobalObject) Context.getGlobal(); final NashornCallSiteDescriptor desc = (NashornCallSiteDescriptor) request.getCallSiteDescriptor(); + + // TAL + if (self.getClass().isArray()) { + // TODO + return null; + } return Bootstrap.asType(global.primitiveLookup(request, self), linkerServices, desc); } @@ -148,6 +161,16 @@ return Comparison.TYPE_2_BETTER; } } + + // TAL + if (NativeArray.class.isAssignableFrom(sourceType)) { + if (targetType1.isArray() && !targetType2.isArray()) { + return Comparison.TYPE_1_BETTER; + } + if (targetType2.isArray() && !targetType1.isArray()) { + return Comparison.TYPE_2_BETTER; + } + } return Comparison.INDETERMINATE; } From sundararajan.athijegannathan at oracle.com Fri Oct 11 04:42:06 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 11 Oct 2013 13:42:06 +0200 Subject: Review request for 8026317: $ in the function name results in wrong function being invoked Message-ID: <5257E40E.7020100@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8026317/ -Sundar From sundararajan.athijegannathan at oracle.com Fri Oct 11 05:11:38 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 11 Oct 2013 12:11:38 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026317: $ in the function name results in wrong function being invoked Message-ID: <20131011121142.04E7662F6A@hg.openjdk.java.net> Changeset: 062579f50371 Author: sundar Date: 2013-10-11 14:11 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/062579f50371 8026317: $ in the function name results in wrong function being invoked Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/Namespace.java + test/script/basic/JDK-8026317.js + test/script/basic/JDK-8026317.js.EXPECTED From andrebargull at googlemail.com Fri Oct 11 05:17:17 2013 From: andrebargull at googlemail.com (=?ISO-8859-15?Q?Andr=E9_Bargull?=) Date: Fri, 11 Oct 2013 14:17:17 +0200 Subject: Review request for 8026317: $ in the function name results in wrong function being invoked Message-ID: <5257EC4D.8080800@googlemail.com> r- jjs> function f(){var o1 = {get "g"(){return 1}}, o2 = {get "g"(){return 2}}, o3 = {get "g-1"(){return 3}}; return o1["g"] + o2["g"] + o3["g-1"] } jjs> f() Returns 5 instead of 6. - Andr? > Please reviewhttp://cr.openjdk.java.net/~sundar/8026317/ > > -Sundar From sundararajan.athijegannathan at oracle.com Fri Oct 11 05:20:13 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 11 Oct 2013 14:20:13 +0200 Subject: Review request for 8026317: $ in the function name results in wrong function being invoked In-Reply-To: <5257EC4D.8080800@googlemail.com> References: <5257EC4D.8080800@googlemail.com> Message-ID: <5257ECFD.1060401@oracle.com> :-) Will file another bug later.. -Sundar On Friday 11 October 2013 02:17 PM, Andr? Bargull wrote: > r- > > jjs> function f(){var o1 = {get "g"(){return 1}}, o2 = {get > "g"(){return 2}}, o3 = {get "g-1"(){return 3}}; return o1["g"] + > o2["g"] + o3["g-1"] } > jjs> f() > > Returns 5 instead of 6. > > - Andr? > > >> Please reviewhttp://cr.openjdk.java.net/~sundar/8026317/ >> >> >> -Sundar > From james.laskey at oracle.com Fri Oct 11 06:01:48 2013 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Fri, 11 Oct 2013 13:01:48 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026309: latest runsunspider.js tests contains several bugs Message-ID: <20131011130156.749DF62F6D@hg.openjdk.java.net> Changeset: 6cb4f20d971f Author: jlaskey Date: 2013-10-11 14:54 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/6cb4f20d971f 8026309: latest runsunspider.js tests contains several bugs Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! test/script/basic/runsunspider.js From cay at horstmann.com Fri Oct 11 20:28:36 2013 From: cay at horstmann.com (Cay Horstmann) Date: Fri, 11 Oct 2013 20:28:36 -0700 Subject: Why -- when supplying jjs script arguments? Message-ID: <5258C1E4.8050902@horstmann.com> Hi, I am writing a chapter on Nashorn for "Java 8 for the Impatient", which will eventually find its way into one of the Core Java tomes. I am a bit baffled why one needs to supply -- when calling a script with arguments. I mean, when I put a #!/usr/bin/jjs in a script, why can't I just run it as myScript arg1 arg2 arg3 instead of myScript -- arg1 arg2 arg3 I know I can solve this with a second script, but it seems a hassle. And is this a new thing? The article http://benjiweber.co.uk/blog/2013/01/27/javascript-shell-scripting-with-nashorn/ doesn't mention it. Thanks, Cay -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From marcus.lagergren at oracle.com Sat Oct 12 08:59:02 2013 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sat, 12 Oct 2013 17:59:02 +0200 Subject: Synchronized functions In-Reply-To: <5257D9F1.2030404@threecrickets.com> References: <5256A8BC.5050804@threecrickets.com> <5257A958.6080106@oracle.com> <5257BAC5.5070503@threecrickets.com> <5257C37E.1070803@oracle.com> <5257C4DA.90406@threecrickets.com> <5257D6B3.6050308@oracle.com> <5257D9F1.2030404@threecrickets.com> Message-ID: That is correct - Hannes, I believe you have to be at least project author to be able to file stuff for a particular openjdk project, but with the speed Tal is working at I assume he will be that any day real soon now ;-) I have filed: https://bugs.openjdk.java.net/browse/JDK-8026367 /M On Oct 11, 2013, at 12:58 PM, Tal Liron wrote: > There doesn't seem to be a way for me to add Nashorn bugs there. Could you guys do it? > > On 10/11/2013 06:45 PM, Hannes Wallnoefer wrote: >> I guess addition to mozilla_compat would be ok. Can you please file a bug for this at https://bugs.openjdk.java.net/? > From james.laskey at oracle.com Sat Oct 12 12:26:03 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Sat, 12 Oct 2013 16:26:03 -0300 Subject: Why -- when supplying jjs script arguments? In-Reply-To: <5258C1E4.8050902@horstmann.com> References: <5258C1E4.8050902@horstmann.com> Message-ID: <3E6D06A7-E40F-4186-8954-B8967A4C4683@oracle.com> In general all arguments prior to -- are for the jjs command (see -help) and all the arguments on the script command line are just a continuation of the shebang line. At one point it was possible to #!/usr/bin/jjs -- to get all the script command line arguments as arguments, but this doesn't seem to work any more, will check with the launcher team about this. On 2013-10-12, at 12:28 AM, Cay Horstmann wrote: > Hi, I am writing a chapter on Nashorn for "Java 8 for the Impatient", which will eventually find its way into one of the Core Java tomes. > > I am a bit baffled why one needs to supply -- when calling a script with arguments. I mean, when I put a > > #!/usr/bin/jjs > > in a script, why can't I just run it as > > myScript arg1 arg2 arg3 > > instead of > > myScript -- arg1 arg2 arg3 > > I know I can solve this with a second script, but it seems a hassle. And is this a new thing? The article http://benjiweber.co.uk/blog/2013/01/27/javascript-shell-scripting-with-nashorn/ doesn't mention it. > > Thanks, > > Cay > > -- > > Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From cay at horstmann.com Sat Oct 12 14:28:24 2013 From: cay at horstmann.com (Cay Horstmann) Date: Sat, 12 Oct 2013 14:28:24 -0700 Subject: Why -- when supplying jjs script arguments? In-Reply-To: <3E6D06A7-E40F-4186-8954-B8967A4C4683@oracle.com> References: <5258C1E4.8050902@horstmann.com> <3E6D06A7-E40F-4186-8954-B8967A4C4683@oracle.com> Message-ID: <5259BEF8.1060108@horstmann.com> It's just a little awkward for scripting. I'd suggest to change the behavior of the arguments when in scripting mode, so that in scripting mode only one script is read, and the others are args. Cheers, Cay Le 12/10/2013 12:26, Jim Laskey (Oracle) a ?crit : > In general all arguments prior to -- are for the jjs command (see -help) and all the arguments on the script command line are just a continuation of the shebang line. At one point it was possible to #!/usr/bin/jjs -- to get all the script command line arguments as arguments, but this doesn't seem to work any more, will check with the launcher team about this. > > > > On 2013-10-12, at 12:28 AM, Cay Horstmann wrote: > >> Hi, I am writing a chapter on Nashorn for "Java 8 for the Impatient", which will eventually find its way into one of the Core Java tomes. >> >> I am a bit baffled why one needs to supply -- when calling a script with arguments. I mean, when I put a >> >> #!/usr/bin/jjs >> >> in a script, why can't I just run it as >> >> myScript arg1 arg2 arg3 >> >> instead of >> >> myScript -- arg1 arg2 arg3 >> >> I know I can solve this with a second script, but it seems a hassle. And is this a new thing? The article http://benjiweber.co.uk/blog/2013/01/27/javascript-shell-scripting-with-nashorn/ doesn't mention it. >> >> Thanks, >> >> Cay >> >> -- >> >> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com > -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From tal.liron at threecrickets.com Sun Oct 13 07:33:26 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Sun, 13 Oct 2013 22:33:26 +0800 Subject: A ConsString Gotcha Message-ID: <525AAF36.1050705@threecrickets.com> ConsString can cause some hard-to-find bugs when interacting with Java classes. Consider this code: var map = new java.util.HashMap var prefix = 'a' var key = prefix + 'b' map.put(key, 'hello') print(map.get(key) + '\n') print(map.get('ab') + '\n') It will output 'hello' and then 'null'. The reason is that key is a ConsString. See for yourself: for (var i = map.keySet().iterator(); i.hasNext(); ) { print(i.next().getClass() + '\n') } This can cause some very hard-to-find bugs. I know too well. :). I'm not sure how best to deal with it, but here are some suggestions. 1. Document it in the user guide, possibly with the simple example I gave above. I expect that many of these bugs will happen when dealing with generic classes, such as those in java.util. The workaround for the example above: var key = String(prefix + 'b') But that's hardly intuitively necessary. 2. It may be a good idea for Nashorn to always coerce ConsString into String when interacting with Java, even if the method signature expects an Object. The one downside I can think of is that it will make it impossible to offer special handling for ConsString in Java classes. This would seem, however, to be quite a rare usage and may not be worth the potential for awful bugs. What do you think? From james.laskey at oracle.com Sun Oct 13 09:28:56 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Sun, 13 Oct 2013 13:28:56 -0300 Subject: A ConsString Gotcha In-Reply-To: <525AAF36.1050705@threecrickets.com> References: <525AAF36.1050705@threecrickets.com> Message-ID: <332C3BB2-737A-4C19-8271-E79A63BA0406@oracle.com> The complication there is that every time you have an Object argument/field you would have to have an if instanceof ConsString cast String sequence, which is a huge performance hit. ConsString was introduced to significantly improve performance (high frequency operation), so it's a bit of a dilemma. The team has debated this several times. It might be better in the long run to be able to properly declare the HashMap with something like; var StringHashMap = Java.type("java.util.HashMap"); or even better var JObject = Java.type("java.lang.Object"); var JString = Java.type("java.lang.String"); var StringHashMap = Java.type("java.util.HashMap", JString, JObject); Just my 2 cents. Cheers, -- Jim On 2013-10-13, at 11:33 AM, Tal Liron wrote: > ConsString can cause some hard-to-find bugs when interacting with Java classes. > > Consider this code: > > var map = new java.util.HashMap > > var prefix = 'a' > var key = prefix + 'b' > > map.put(key, 'hello') > > print(map.get(key) + '\n') > print(map.get('ab') + '\n') > > It will output 'hello' and then 'null'. The reason is that key is a ConsString. See for yourself: > > for (var i = map.keySet().iterator(); i.hasNext(); ) { > print(i.next().getClass() + '\n') > } > > This can cause some very hard-to-find bugs. I know too well. :). I'm not sure how best to deal with it, but here are some suggestions. > > 1. Document it in the user guide, possibly with the simple example I gave above. I expect that many of these bugs will happen when dealing with generic classes, such as those in java.util. The workaround for the example above: > > var key = String(prefix + 'b') > > But that's hardly intuitively necessary. > > 2. It may be a good idea for Nashorn to always coerce ConsString into String when interacting with Java, even if the method signature expects an Object. > > The one downside I can think of is that it will make it impossible to offer special handling for ConsString in Java classes. This would seem, however, to be quite a rare usage and may not be worth the potential for awful bugs. > > What do you think? > > From tal.liron at threecrickets.com Sun Oct 13 09:41:46 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Mon, 14 Oct 2013 00:41:46 +0800 Subject: A ConsString Gotcha In-Reply-To: <332C3BB2-737A-4C19-8271-E79A63BA0406@oracle.com> References: <525AAF36.1050705@threecrickets.com> <332C3BB2-737A-4C19-8271-E79A63BA0406@oracle.com> Message-ID: <525ACD4A.7010402@threecrickets.com> Your proposal solves the generics problem nicely enough, but many 3rd party libraries out there have methods with Object argument signatures. I still think that blanket conversion is best, configurable with a flag. The performance issue might be fixable like so: if ever a ConsString needs to be converted to a String, it would happen once and only once, effectively internally replacing the ConsString with a String instance. The performance hit would be momentary. And again, can be disabled with a flag. On 10/14/2013 12:28 AM, Jim Laskey (Oracle) wrote: > The complication there is that every time you have an Object argument/field you would have to have an if instanceof ConsString cast String sequence, which is a huge performance hit. ConsString was introduced to significantly improve performance (high frequency operation), so it's a bit of a dilemma. The team has debated this several times. It might be better in the long run to be able to properly declare the HashMap with something like; > > var StringHashMap = Java.type("java.util.HashMap"); > > or even better > > var JObject = Java.type("java.lang.Object"); > var JString = Java.type("java.lang.String"); > var StringHashMap = Java.type("java.util.HashMap", JString, JObject); > From attila.szegedi at oracle.com Sun Oct 13 09:55:20 2013 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Sun, 13 Oct 2013 18:55:20 +0200 Subject: A ConsString Gotcha In-Reply-To: <525AAF36.1050705@threecrickets.com> References: <525AAF36.1050705@threecrickets.com> Message-ID: <6DBAD991-C2DB-48A4-BAF0-DA38B24EC5CD@oracle.com> On Oct 13, 2013, at 4:33 PM, Tal Liron wrote: > ConsString can cause some hard-to-find bugs when interacting with Java classes. > > [...] > > 1. Document it in the user guide, possibly with the simple example I gave above. I expect that many of these bugs will happen when dealing with generic classes, such as those in java.util. The workaround for the example above: > > var key = String(prefix + 'b') > > But that's hardly intuitively necessary. It is documented in > > 2. It may be a good idea for Nashorn to always coerce ConsString into String when interacting with Java, even if the method signature expects an Object. It's not really easy to do consistently, for subtle reasons having to do with not imposing conversions on method invocation parameters to which a JLS method invocation conversion applies; trivially, anything-to-Object always applies. Introducing an argument filter on every parameter of declared type Object is prohibitive with regard to performance. Attila. > The one downside I can think of is that it will make it impossible to offer special handling for ConsString in Java classes. This would seem, however, to be quite a rare usage and may not be worth the potential for awful bugs. > > What do you think? > > From tal.liron at threecrickets.com Sun Oct 13 09:57:35 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Mon, 14 Oct 2013 00:57:35 +0800 Subject: A ConsString Gotcha In-Reply-To: <6DBAD991-C2DB-48A4-BAF0-DA38B24EC5CD@oracle.com> References: <525AAF36.1050705@threecrickets.com> <6DBAD991-C2DB-48A4-BAF0-DA38B24EC5CD@oracle.com> Message-ID: <525AD0FF.6060207@threecrickets.com> Rhino also has ConsString, but doesn't exhibit this problem -- how is handled there? On 10/14/2013 12:55 AM, Attila Szegedi wrote: > It's not really easy to do consistently, for subtle reasons having to > do with not imposing conversions on method invocation parameters to > which a JLS method invocation conversion applies; trivially, > anything-to-Object always applies. Introducing an argument filter on > every parameter of declared type Object is prohibitive with regard to > performance. > > Attila. From rick.bullotta at thingworx.com Sun Oct 13 10:13:12 2013 From: rick.bullotta at thingworx.com (Rick Bullotta) Date: Sun, 13 Oct 2013 17:13:12 +0000 Subject: A ConsString Gotcha In-Reply-To: <525ACD4A.7010402@threecrickets.com> References: <525AAF36.1050705@threecrickets.com> <332C3BB2-737A-4C19-8271-E79A63BA0406@oracle.com> <525ACD4A.7010402@threecrickets.com> Message-ID: I do think it is a reasonable requirement when using any arbitrary library that in some cases a wrapper would be required. Having a method signature with "Object" is not exactly ideal for even weakly typed interaction...kinda like an XML schema with "xsd:any". I think the key is to avoid having to make the script developer do goofy stuff. If it requires a developer to wrap some 3rd party library to provide necessary typing or type munging in some edge cases, that certainly seems reasonable, doesn't it? -----Original Message----- From: nashorn-dev-bounces at openjdk.java.net [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf Of Tal Liron Sent: Sunday, October 13, 2013 12:42 PM To: nashorn-dev at openjdk.java.net Subject: Re: A ConsString Gotcha Your proposal solves the generics problem nicely enough, but many 3rd party libraries out there have methods with Object argument signatures. I still think that blanket conversion is best, configurable with a flag. The performance issue might be fixable like so: if ever a ConsString needs to be converted to a String, it would happen once and only once, effectively internally replacing the ConsString with a String instance. The performance hit would be momentary. And again, can be disabled with a flag. On 10/14/2013 12:28 AM, Jim Laskey (Oracle) wrote: > The complication there is that every time you have an Object > argument/field you would have to have an if instanceof ConsString cast > String sequence, which is a huge performance hit. ConsString was > introduced to significantly improve performance (high frequency > operation), so it's a bit of a dilemma. The team has debated this > several times. It might be better in the long run to be able to > properly declare the HashMap with something like; > > var StringHashMap = Java.type("java.util.HashMap java.lang.Object>"); > > or even better > > var JObject = Java.type("java.lang.Object"); > var JString = Java.type("java.lang.String"); > var StringHashMap = Java.type("java.util.HashMap", JString, JObject); > From tal.liron at threecrickets.com Sun Oct 13 10:29:59 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Mon, 14 Oct 2013 01:29:59 +0800 Subject: A ConsString Gotcha In-Reply-To: References: <525AAF36.1050705@threecrickets.com> <332C3BB2-737A-4C19-8271-E79A63BA0406@oracle.com> <525ACD4A.7010402@threecrickets.com> Message-ID: <525AD897.103@threecrickets.com> Reasonable, but only to an extent. :) I think JVM languages should integrate more naturally with Java libraries, without needing specialized wrappers. This is especially true for a language like JavaScript, which has almost no standard library of its own, and is thus very dependent on Java libraries. Part of the reason for choosing to develop with a dynamic language on the JVM (JRuby, Jython, Scala, etc.) is the ability to access the huge extant JVM ecosystem, and of course you don't expect developers of those 3rd party libraries to specifically target one specific dynamic language engine, especially when some of these language engines do not yet exist. Other JVM language engines seem to do a better job than Nashorn at this, at least currently. I'll continue to argue my case on specific issues, but it's clear to me now that the Nashorn team has a different set of convictions/priorities. The alternative for me, right now, is some weird Nashorn-specific hacks. Here's an example I just committed to the MongoDB driver: var status = application.globals.get(String('mongoDb.status.' + client.hashCode())) // workaround to avoid ConsString in Nashorn A JavaScript programmer would be confused. And, this is unnecessary with Rhino. On 10/14/2013 01:13 AM, Rick Bullotta wrote: > I do think it is a reasonable requirement when using any arbitrary library that in some cases a wrapper would be required. Having a method signature with "Object" is not exactly ideal for even weakly typed interaction...kinda like an XML schema with "xsd:any". I think the key is to avoid having to make the script developer do goofy stuff. If it requires a developer to wrap some 3rd party library to provide necessary typing or type munging in some edge cases, that certainly seems reasonable, doesn't it? > From tal.liron at threecrickets.com Sun Oct 13 22:22:47 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Mon, 14 Oct 2013 13:22:47 +0800 Subject: Nashorn works in real life In-Reply-To: <5255934D.3070802@threecrickets.com> References: <5255934D.3070802@threecrickets.com> Message-ID: <525B7FA7.9060902@threecrickets.com> More good news: Diligence now also works on Nashorn. It is a powerful, scalable MonogDB-driven web framework: http://threecrickets.com/diligence/ MongoVision, an Ext-JS-based front end for MongoDB, now also runs on Nashorn: http://code.google.com/p/mongo-vision/ To allow for this involved refactoring the MongoDB Rhino driver to now be a MongoDB "JVM" driver that can support various JVM languages, with the same for the extensible Rhino JSON dependency. It all works directly with Nashorn internal objects for high-performance BSON/JSON conversions. Here are the newly refactored projects, now with Nashorn support: http://code.google.com/p/mongodb-jvm/ http://code.google.com/p/json-jvm/ So, now the entire Three Crickets stack can be run on either Nashorn or Rhino. Phew! It's been a long week. And now March 2014 can't come soon enough. On 10/10/2013 01:33 AM, Tal Liron wrote: > After reporting various bugs and complaints on the list, I have some > good news for a change. :) > > The complete Prudence stack, which includes a *lot* of JavaScript code > developed for years to work in Rhino, now runs perfectly fine on > Nashorn. (The exact same code base also works in Rhino.) > > Prudence is a powerful REST and web platform. With it, you can use > JavaScript (as well as many other JVM languages) to write RESTful > resources and dynamically generated, cached web pages. > > I hope this will allow you to test Nashorn performance in server-side > environments, and to compare it with Rhino in this respect, too. > > Nashorn is now a fully supported language in Scripturian (an > alternative to JSR-223), so any other applications that use > Scripturian can also now leverage Nashorn. I should point out that > Scripturian also works with the nashorn-backport project, so the whole > stack can work on JVM 7. > > I did need some hacks: > > 1. I patched Nashorn for the "NPE in DebugLogger.levelAbove" bug I > reported. > 2. I patched mozilla_compat to support multiple arguments in > importClass (again, as with the bug I reported). > 3. I had to implement a rather ugly hack in Sincerity to deal with > Nashorn's current inability to coerce string arrays (I actually do a > string.split(",")...), and also moved a static method to become > non-static for the sake of Nashorn's strictness. Sigh. > > (And also some other small JavaScript changes that work fine in Rhino, > too.) > > I would also love for Diligence to run on Nashorn: Diligence is a > full-blown server-side JavaScript web framework built on Prudence and > MongoDB. However, this would require more work, because the > JVM/JavaScript MongoDB driver I wrote is currently Rhino-specific. I > will update you in the future on this progress, as it would allow for > even more avenues for testing. > > Keep up the good work! And hopefully listen to my advice on how to > move Nashorn forward: I speak from quite a bit of experience with > dynamic languages on the JVM, and JavaScript especially. > > -Tal From hannes.wallnoefer at oracle.com Mon Oct 14 01:16:10 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 14 Oct 2013 10:16:10 +0200 Subject: Review request for JDK-8026016: too many relinks dominate avatar.js http benchmark Message-ID: <525BA84A.304@oracle.com> Please review JDK-8026016: too many relinks dominate avatar.js http benchmark. http://cr.openjdk.java.net/~hannesw/8026016/webrev.02/ Apart from the fix to let callsites for non-existant properties go megamorphic (while preserving noSuchMethod functionality) this also removes some minor inefficiencies in ScriptObject. set() methods used to check key for array index twice, and has*() methods unnecessarily created an FindProperty object. Thanks, Hannes From hannes.wallnoefer at oracle.com Mon Oct 14 01:16:53 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 14 Oct 2013 10:16:53 +0200 Subject: Synchronized functions In-Reply-To: References: <5256A8BC.5050804@threecrickets.com> <5257A958.6080106@oracle.com> <5257BAC5.5070503@threecrickets.com> <5257C37E.1070803@oracle.com> <5257C4DA.90406@threecrickets.com> <5257D6B3.6050308@oracle.com> <5257D9F1.2030404@threecrickets.com> Message-ID: <525BA875.1060902@oracle.com> Sorry, I didn't know that. Looking at it now. Hannes Am 2013-10-12 17:59, schrieb Marcus Lagergren: > That is correct - Hannes, I believe you have to be at least project author to be able to file stuff for a particular openjdk project, but with the speed Tal is working at I assume he will be that any day real soon now ;-) > > I have filed: https://bugs.openjdk.java.net/browse/JDK-8026367 > > /M > > On Oct 11, 2013, at 12:58 PM, Tal Liron wrote: > >> There doesn't seem to be a way for me to add Nashorn bugs there. Could you guys do it? >> >> On 10/11/2013 06:45 PM, Hannes Wallnoefer wrote: >>> I guess addition to mozilla_compat would be ok. Can you please file a bug for this at https://bugs.openjdk.java.net/? From james.laskey at oracle.com Mon Oct 14 02:11:38 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 14 Oct 2013 06:11:38 -0300 Subject: Nashorn works in real life In-Reply-To: <525B7FA7.9060902@threecrickets.com> References: <5255934D.3070802@threecrickets.com> <525B7FA7.9060902@threecrickets.com> Message-ID: Three cheers. Sent from Jim's iPhone > On Oct 14, 2013, at 2:22 AM, Tal Liron wrote: > > More good news: Diligence now also works on Nashorn. It is a powerful, scalable MonogDB-driven web framework: > > http://threecrickets.com/diligence/ > > MongoVision, an Ext-JS-based front end for MongoDB, now also runs on Nashorn: > > http://code.google.com/p/mongo-vision/ > > To allow for this involved refactoring the MongoDB Rhino driver to now be a MongoDB "JVM" driver that can support various JVM languages, with the same for the extensible Rhino JSON dependency. It all works directly with Nashorn internal objects for high-performance BSON/JSON conversions. Here are the newly refactored projects, now with Nashorn support: > > http://code.google.com/p/mongodb-jvm/ > http://code.google.com/p/json-jvm/ > > So, now the entire Three Crickets stack can be run on either Nashorn or Rhino. > > Phew! It's been a long week. And now March 2014 can't come soon enough. > >> On 10/10/2013 01:33 AM, Tal Liron wrote: >> After reporting various bugs and complaints on the list, I have some good news for a change. :) >> >> The complete Prudence stack, which includes a *lot* of JavaScript code developed for years to work in Rhino, now runs perfectly fine on Nashorn. (The exact same code base also works in Rhino.) >> >> Prudence is a powerful REST and web platform. With it, you can use JavaScript (as well as many other JVM languages) to write RESTful resources and dynamically generated, cached web pages. >> >> I hope this will allow you to test Nashorn performance in server-side environments, and to compare it with Rhino in this respect, too. >> >> Nashorn is now a fully supported language in Scripturian (an alternative to JSR-223), so any other applications that use Scripturian can also now leverage Nashorn. I should point out that Scripturian also works with the nashorn-backport project, so the whole stack can work on JVM 7. >> >> I did need some hacks: >> >> 1. I patched Nashorn for the "NPE in DebugLogger.levelAbove" bug I reported. >> 2. I patched mozilla_compat to support multiple arguments in importClass (again, as with the bug I reported). >> 3. I had to implement a rather ugly hack in Sincerity to deal with Nashorn's current inability to coerce string arrays (I actually do a string.split(",")...), and also moved a static method to become non-static for the sake of Nashorn's strictness. Sigh. >> >> (And also some other small JavaScript changes that work fine in Rhino, too.) >> >> I would also love for Diligence to run on Nashorn: Diligence is a full-blown server-side JavaScript web framework built on Prudence and MongoDB. However, this would require more work, because the JVM/JavaScript MongoDB driver I wrote is currently Rhino-specific. I will update you in the future on this progress, as it would allow for even more avenues for testing. >> >> Keep up the good work! And hopefully listen to my advice on how to move Nashorn forward: I speak from quite a bit of experience with dynamic languages on the JVM, and JavaScript especially. >> >> -Tal > From sundararajan.athijegannathan at oracle.com Mon Oct 14 02:31:30 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 14 Oct 2013 15:01:30 +0530 Subject: Review request for JDK-8026016: too many relinks dominate avatar.js http benchmark In-Reply-To: <525BA84A.304@oracle.com> References: <525BA84A.304@oracle.com> Message-ID: <525BB9F2.2060604@oracle.com> Looks good to me -Sundar On Monday 14 October 2013 01:46 PM, Hannes Wallnoefer wrote: > Please review JDK-8026016: too many relinks dominate avatar.js http > benchmark. > > http://cr.openjdk.java.net/~hannesw/8026016/webrev.02/ > > Apart from the fix to let callsites for non-existant properties go > megamorphic (while preserving noSuchMethod functionality) this also > removes some minor inefficiencies in ScriptObject. set() methods used > to check key for array index twice, and has*() methods unnecessarily > created an FindProperty object. > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Mon Oct 14 02:49:20 2013 From: hannes.wallnoefer at oracle.com (hannes.wallnoefer at oracle.com) Date: Mon, 14 Oct 2013 09:49:20 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026016: too many relinks dominate avatar.js http benchmark Message-ID: <20131014094931.6ACFD62363@hg.openjdk.java.net> Changeset: 8c617a092d68 Author: hannesw Date: 2013-10-14 11:45 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/8c617a092d68 8026016: too many relinks dominate avatar.js http benchmark Reviewed-by: sundar, jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8026016.js + test/script/basic/JDK-8026016.js.EXPECTED From attila.szegedi at oracle.com Mon Oct 14 03:41:51 2013 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Mon, 14 Oct 2013 10:41:51 +0000 Subject: hg: nashorn/jdk8/nashorn: 8026113: Nashorn arrays should automatically convert to Java arrays Message-ID: <20131014104159.9271962371@hg.openjdk.java.net> Changeset: d155c4a7703c Author: attila Date: 2013-10-14 12:41 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/d155c4a7703c 8026113: Nashorn arrays should automatically convert to Java arrays Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java + test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java From marcus.lagergren at oracle.com Mon Oct 14 05:48:56 2013 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 14 Oct 2013 14:48:56 +0200 Subject: Nashorn works in real life In-Reply-To: <525B7FA7.9060902@threecrickets.com> References: <5255934D.3070802@threecrickets.com> <525B7FA7.9060902@threecrickets.com> Message-ID: <97DD94A3-370F-4FCA-A440-1E653A66C112@oracle.com> Nice one, Tal! Everything works and you are happy with behavior? Faster than Rhino? (we are doing some additional performance work right now) /M On Oct 14, 2013, at 7:22 AM, Tal Liron wrote: > From tal.liron at threecrickets.com Mon Oct 14 05:58:36 2013 From: tal.liron at threecrickets.com (Tal Liron) Date: Mon, 14 Oct 2013 20:58:36 +0800 Subject: Nashorn works in real life In-Reply-To: <97DD94A3-370F-4FCA-A440-1E653A66C112@oracle.com> References: <5255934D.3070802@threecrickets.com> <525B7FA7.9060902@threecrickets.com> <97DD94A3-370F-4FCA-A440-1E653A66C112@oracle.com> Message-ID: <525BEA7C.7050504@threecrickets.com> Performance per se is hard to test in data-driven web applications: the complete route uses the database, which is always orders of magnitude slower than that of the code execution. And in Prudence, the cache is handled entirely in Java code, so it won't even run any Nashorn when pulling pages from the cache. I may need to devise a different kind of test, more CPU-bound, specifically to benchmark Nashorn vs. Rhino. If you guys have any ideas (possibly that you are using in Avatar.js?) I'd be happy to try them. However, I do some have news for the bootstrapping process (based on Sincerity). And the news is not good: Nashorn takes significantly longer to compile than Rhino, resulting in a slower bootstrap overall. I believe this could be much alleviated by allowing us to cache compiled bytecode to disk (Scripturian does this for Rhino), but I've been told that this feature won't be available for Nashorn. So, every bootstrap involves compiling the JavaScript all over again, and it's not fast. So, actually for the one area in the software stack where I hoped Nashorn's performance would shine--bootstrapping--I'm not seeing the benefits yet. On 10/14/2013 08:48 PM, Marcus Lagergren wrote: > Nice one, Tal! Everything works and you are happy with behavior? > Faster than Rhino? (we are doing some additional performance work > right now) > > /M From marcus.lagergren at oracle.com Mon Oct 14 06:11:09 2013 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 14 Oct 2013 15:11:09 +0200 Subject: Nashorn works in real life In-Reply-To: <525BEA7C.7050504@threecrickets.com> References: <5255934D.3070802@threecrickets.com> <525B7FA7.9060902@threecrickets.com> <97DD94A3-370F-4FCA-A440-1E653A66C112@oracle.com> <525BEA7C.7050504@threecrickets.com> Message-ID: Part of the performance work requires us moving to a more lazy execution model, which should bring part of the bootstrapping problem away. At the time I can't say if this is 8.0 or the first service upgrade, though. /M On Oct 14, 2013, at 2:58 PM, Tal Liron wrote: > Performance per se is hard to test in data-driven web applications: the complete route uses the database, which is always orders of magnitude slower than that of the code execution. And in Prudence, the cache is handled entirely in Java code, so it won't even run any Nashorn when pulling pages from the cache. I may need to devise a different kind of test, more CPU-bound, specifically to benchmark Nashorn vs. Rhino. If you guys have any ideas (possibly that you are using in Avatar.js?) I'd be happy to try them. > > However, I do some have news for the bootstrapping process (based on Sincerity). And the news is not good: Nashorn takes significantly longer to compile than Rhino, resulting in a slower bootstrap overall. I believe this could be much alleviated by allowing us to cache compiled bytecode to disk (Scripturian does this for Rhino), but I've been told that this feature won't be available for Nashorn. So, every bootstrap involves compiling the JavaScript all over again, and it's not fast. > > So, actually for the one area in the software stack where I hoped Nashorn's performance would shine--bootstrapping--I'm not seeing the benefits yet. > > On 10/14/2013 08:48 PM, Marcus Lagergren wrote: >> Nice one, Tal! Everything works and you are happy with behavior? Faster than Rhino? (we are doing some additional performance work right now) >> >> /M > From hannes.wallnoefer at oracle.com Mon Oct 14 09:39:22 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 14 Oct 2013 18:39:22 +0200 Subject: Review request for JDK-8026367: Add a sync keyword to mozilla_compat Message-ID: <525C1E3A.3030702@oracle.com> Please review JDK-8026367: Add a sync keyword to mozilla_compat: http://cr.openjdk.java.net/~hannesw/8026367/ Thanks, Hannes From hannes.wallnoefer at oracle.com Mon Oct 14 12:28:08 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 14 Oct 2013 21:28:08 +0200 Subject: hg: nashorn/jdk8/nashorn: 8026137: Fix Issues with Binary Evaluation Order In-Reply-To: <525587DD.3020100@googlemail.com> References: <525587DD.3020100@googlemail.com> Message-ID: <525C45C8.2030408@oracle.com> Side effects can still occur with primitive types. As an example, this script from the test case as a numeric right hand side: ({valueOf: function(){throw 0}}) - ({valueOf: function(){throw 1}} - 1) But maybe something like this (pseudo-code) could work in CodeGenerator#safeLiteral: isPrimitiveLiteralNode || (isIdentNode && isPrimitiveType) An IdentNode can have side effects if it is a global with a getter, but if we know it's type that shouldn't be the case. Hannes Am 2013-10-09 18:44, schrieb Andr? Bargull: > Quick question for this change set: > > Why does CodeGenerator#safeLiteral(...) need to test for literal nodes > instead of using type information? When the right-hand-side is a > primitive type, side effects cannot occur, so the additional > swap/dup/pop instructions can be omitted safely. > > For example `function f(a){var c = 1; return a - c }` now emits: > ALOAD 1 > ILOAD 4 > SWAP > INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber > (Ljava/lang/Object;)D > DUP2_X1 > POP2 > I2D > DSUB > > Using type info it's possible to change the bytecode to: > ALOAD 1 > INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber > (Ljava/lang/Object;)D > ILOAD 4 > I2D > DSUB > > > (Also: That was one of the bug reports which worried me a bit, because > I expected the changes to be non-trivial. :-( > > > - Andr? > >> Changeset: 03a68e7ca1d5 >> Author: lagergren >> Date: 2013-10-09 17:53 +0200 >> URL:http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/03a68e7ca1d5 >> >> 8026137: Fix Issues with Binary Evaluation Order >> Reviewed-by: hannesw, jlaskey >> Contributed-by:marcus.lagergren at oracle.com >> ,attila.szegedi >> at oracle.com >> >> >> ! src/jdk/nashorn/internal/codegen/Attr.java >> ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java >> ! src/jdk/nashorn/internal/codegen/CodeGenerator.java >> ! src/jdk/nashorn/internal/codegen/CompileUnit.java >> ! src/jdk/nashorn/internal/codegen/Compiler.java >> ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java >> ! src/jdk/nashorn/internal/codegen/MethodEmitter.java >> ! src/jdk/nashorn/internal/codegen/WeighNodes.java >> ! src/jdk/nashorn/internal/codegen/types/BooleanType.java >> ! src/jdk/nashorn/internal/codegen/types/ObjectType.java >> ! src/jdk/nashorn/internal/codegen/types/Type.java >> ! src/jdk/nashorn/internal/ir/AccessNode.java >> ! src/jdk/nashorn/internal/ir/BaseNode.java >> ! src/jdk/nashorn/internal/ir/CallNode.java >> ! src/jdk/nashorn/internal/ir/IdentNode.java >> ! src/jdk/nashorn/internal/ir/IndexNode.java >> ! src/jdk/nashorn/internal/ir/LiteralNode.java >> ! src/jdk/nashorn/internal/ir/RuntimeNode.java >> - src/jdk/nashorn/internal/ir/TypeOverride.java >> ! src/jdk/nashorn/internal/ir/UnaryNode.java >> ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java >> ! src/jdk/nashorn/internal/parser/TokenType.java >> ! src/jdk/nashorn/internal/runtime/Context.java >> ! src/jdk/nashorn/internal/runtime/JSType.java >> ! src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java >> ! src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java >> ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java >> + test/script/basic/JDK-8026137.js >> + test/script/basic/JDK-8026137.js.EXPECTED From andrebargull at googlemail.com Mon Oct 14 12:59:31 2013 From: andrebargull at googlemail.com (=?ISO-8859-15?Q?Andr=E9_Bargull?=) Date: Mon, 14 Oct 2013 21:59:31 +0200 Subject: hg: nashorn/jdk8/nashorn: 8026137: Fix Issues with Binary Evaluation Order Message-ID: <525C4D23.2090702@googlemail.com> "primitive type" was a bad choice of words, I rather meant "side-effect-free". When all operands are primitives, most operations won't trigger side-effects. Only most operations because in `0 - (0 instanceof 1)` all operands are primitives, but `(0 instanceof 1)` still needs to be executed before the subtraction. So I was thinking of the following change for Codegen (incomplete -> `instanceof` etc. not handled!): private static boolean isSideEffectFree(final Expression rhs) { if (rhs instanceof LiteralNode.PrimitiveLiteralNode) { return true; } else if (rhs instanceof IdentNode) { return !rhs.getSymbol().isScope() && !rhs.getType().isObject(); } else if (rhs instanceof UnaryNode) { UnaryNode unary = (UnaryNode) rhs; return isSideEffectFree(unary.rhs()); } else if (rhs instanceof BinaryNode) { BinaryNode binary = (BinaryNode) rhs; return isSideEffectFree(binary.lhs()) && isSideEffectFree(binary.rhs()); } else if (rhs instanceof TernaryNode) { TernaryNode ternary = (TernaryNode) rhs; return isSideEffectFree(ternary.getTest()) && isSideEffectFree(ternary.getTrueExpression()) && isSideEffectFree(ternary.getFalseExpression()); } return false; } private static boolean safeLiteral(final Expression rhs) { // return isSideEffectFree(rhs); return rhs instanceof LiteralNode && !(rhs instanceof ArrayLiteralNode); } - Andr? > Side effects can still occur with primitive types. As an example, this > script from the test case as a numeric right hand side: > > ({valueOf: function(){throw 0}}) - ({valueOf: function(){throw 1}} - 1) > > But maybe something like this (pseudo-code) could work in > CodeGenerator#safeLiteral: > > isPrimitiveLiteralNode || (isIdentNode && isPrimitiveType) > > An IdentNode can have side effects if it is a global with a getter, but > if we know it's type that shouldn't be the case. > > Hannes > > Am 2013-10-09 18:44, schrieb Andr? Bargull: > >/ Quick question for this change set: > />/ > />/ Why does CodeGenerator#safeLiteral(...) need to test for literal nodes > />/ instead of using type information? When the right-hand-side is a > />/ primitive type, side effects cannot occur, so the additional > />/ swap/dup/pop instructions can be omitted safely. > />/ > />/ For example `function f(a){var c = 1; return a - c }` now emits: > />/ ALOAD 1 > />/ ILOAD 4 > />/ SWAP > />/ INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber > />/ (Ljava/lang/Object;)D > />/ DUP2_X1 > />/ POP2 > />/ I2D > />/ DSUB > />/ > />/ Using type info it's possible to change the bytecode to: > />/ ALOAD 1 > />/ INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber > />/ (Ljava/lang/Object;)D > />/ ILOAD 4 > />/ I2D > />/ DSUB > />/ > />/ > />/ (Also: That was one of the bug reports which worried me a bit, because > />/ I expected the changes to be non-trivial. :-( > />/ > />/ > />/ - Andr?/ From hannes.wallnoefer at oracle.com Mon Oct 14 13:32:30 2013 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 14 Oct 2013 22:32:30 +0200 Subject: hg: nashorn/jdk8/nashorn: 8026137: Fix Issues with Binary Evaluation Order In-Reply-To: <525C4D23.2090702@googlemail.com> References: <525C4D23.2090702@googlemail.com> Message-ID: <525C54DE.3080209@oracle.com> Looks good. One thing I'm noting is that String is currently handled as ObjectType (i.e. getType().isObject() will return true), which is true in Java terms, but in this context we should treat String as primitive, right? Hannes Am 2013-10-14 21:59, schrieb Andr? Bargull: > "primitive type" was a bad choice of words, I rather meant > "side-effect-free". > > When all operands are primitives, most operations won't trigger > side-effects. Only most operations because in `0 - (0 instanceof 1)` > all operands are primitives, but `(0 instanceof 1)` still needs to be > executed before the subtraction. So I was thinking of the following > change for Codegen (incomplete -> `instanceof` etc. not handled!): > > > private static boolean isSideEffectFree(final Expression rhs) { > if (rhs instanceof LiteralNode.PrimitiveLiteralNode) { > return true; > } else if (rhs instanceof IdentNode) { > return !rhs.getSymbol().isScope() && > !rhs.getType().isObject(); > } else if (rhs instanceof UnaryNode) { > UnaryNode unary = (UnaryNode) rhs; > return isSideEffectFree(unary.rhs()); > } else if (rhs instanceof BinaryNode) { > BinaryNode binary = (BinaryNode) rhs; > return isSideEffectFree(binary.lhs()) > && isSideEffectFree(binary.rhs()); > } else if (rhs instanceof TernaryNode) { > TernaryNode ternary = (TernaryNode) rhs; > return isSideEffectFree(ternary.getTest()) > && isSideEffectFree(ternary.getTrueExpression()) > && isSideEffectFree(ternary.getFalseExpression()); > } > return false; > } > > private static boolean safeLiteral(final Expression rhs) { > // return isSideEffectFree(rhs); > return rhs instanceof LiteralNode && !(rhs instanceof > ArrayLiteralNode); > } > > > - Andr? > > >> Side effects can still occur with primitive types. As an example, this >> script from the test case as a numeric right hand side: >> >> ({valueOf: function(){throw 0}}) - ({valueOf: function(){throw 1}} - 1) >> >> But maybe something like this (pseudo-code) could work in >> CodeGenerator#safeLiteral: >> >> isPrimitiveLiteralNode || (isIdentNode && isPrimitiveType) >> >> An IdentNode can have side effects if it is a global with a getter, but >> if we know it's type that shouldn't be the case. >> >> Hannes >> >> Am 2013-10-09 18:44, schrieb Andr? Bargull: >> >/ Quick question for this change set: >> />/ >> />/ Why does CodeGenerator#safeLiteral(...) need to test for literal nodes >> />/ instead of using type information? When the right-hand-side is a >> />/ primitive type, side effects cannot occur, so the additional >> />/ swap/dup/pop instructions can be omitted safely. >> />/ >> />/ For example `function f(a){var c = 1; return a - c }` now emits: >> />/ ALOAD 1 >> />/ ILOAD 4 >> />/ SWAP >> />/ INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber >> />/ (Ljava/lang/Object;)D >> />/ DUP2_X1 >> />/ POP2 >> />/ I2D >> />/ DSUB >> />/ >> />/ Using type info it's possible to change the bytecode to: >> />/ ALOAD 1 >> />/ INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber >> />/ (Ljava/lang/Object;)D >> />/ ILOAD 4 >> />/ I2D >> />/ DSUB >> />/ >> />/ >> />/ (Also: That was one of the bug reports which worried me a bit, because >> />/ I expected the changes to be non-trivial. :-( >> />/ >> />/ >> />/ - Andr?/ From andrebargull at googlemail.com Mon Oct 14 23:29:09 2013 From: andrebargull at googlemail.com (=?ISO-8859-15?Q?Andr=E9_Bargull?=) Date: Tue, 15 Oct 2013 08:29:09 +0200 Subject: hg: nashorn/jdk8/nashorn: 8026137: Fix Issues with Binary Evaluation Order In-Reply-To: <525C54DE.3080209@oracle.com> References: <525C4D23.2090702@googlemail.com> <525C54DE.3080209@oracle.com> Message-ID: <525CE0B5.6000403@googlemail.com> Yeah, sure strings need to be handled explicitly here. On 10/14/2013 10:32 PM, Hannes Wallnoefer wrote: > Looks good. One thing I'm noting is that String is currently handled > as ObjectType (i.e. getType().isObject() will return true), which is > true in Java terms, but in this context we should treat String as > primitive, right? > > Hannes > > Am 2013-10-14 21:59, schrieb Andr? Bargull: >> "primitive type" was a bad choice of words, I rather meant >> "side-effect-free". >> >> When all operands are primitives, most operations won't trigger >> side-effects. Only most operations because in `0 - (0 instanceof 1)` >> all operands are primitives, but `(0 instanceof 1)` still needs to be >> executed before the subtraction. So I was thinking of the following >> change for Codegen (incomplete -> `instanceof` etc. not handled!): >> >> >> private static boolean isSideEffectFree(final Expression rhs) { >> if (rhs instanceof LiteralNode.PrimitiveLiteralNode) { >> return true; >> } else if (rhs instanceof IdentNode) { >> return !rhs.getSymbol().isScope() && >> !rhs.getType().isObject(); >> } else if (rhs instanceof UnaryNode) { >> UnaryNode unary = (UnaryNode) rhs; >> return isSideEffectFree(unary.rhs()); >> } else if (rhs instanceof BinaryNode) { >> BinaryNode binary = (BinaryNode) rhs; >> return isSideEffectFree(binary.lhs()) >> && isSideEffectFree(binary.rhs()); >> } else if (rhs instanceof TernaryNode) { >> TernaryNode ternary = (TernaryNode) rhs; >> return isSideEffectFree(ternary.getTest()) >> && isSideEffectFree(ternary.getTrueExpression()) >> && isSideEffectFree(ternary.getFalseExpression()); >> } >> return false; >> } >> >> private static boolean safeLiteral(final Expression rhs) { >> // return isSideEffectFree(rhs); >> return rhs instanceof LiteralNode && !(rhs instanceof >> ArrayLiteralNode); >> } >> >> >> - Andr? >> >> >>> Side effects can still occur with primitive types. As an example, this >>> script from the test case as a numeric right hand side: >>> >>> ({valueOf: function(){throw 0}}) - ({valueOf: function(){throw 1}} - 1) >>> >>> But maybe something like this (pseudo-code) could work in >>> CodeGenerator#safeLiteral: >>> >>> isPrimitiveLiteralNode || (isIdentNode && isPrimitiveType) >>> >>> An IdentNode can have side effects if it is a global with a getter, but >>> if we know it's type that shouldn't be the case. >>> >>> Hannes >>> >>> Am 2013-10-09 18:44, schrieb Andr? Bargull: >>> >/ Quick question for this change set: >>> />/ >>> />/ Why does CodeGenerator#safeLiteral(...) need to test for >>> literal nodes >>> />/ instead of using type information? When the right-hand-side is a >>> />/ primitive type, side effects cannot occur, so the additional >>> />/ swap/dup/pop instructions can be omitted safely. >>> />/ >>> />/ For example `function f(a){var c = 1; return a - c }` now emits: >>> />/ ALOAD 1 >>> />/ ILOAD 4 >>> />/ SWAP >>> />/ INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber >>> />/ (Ljava/lang/Object;)D >>> />/ DUP2_X1 >>> />/ POP2 >>> />/ I2D >>> />/ DSUB >>> />/ >>> />/ Using type info it's possible to change the bytecode to: >>> />/ ALOAD 1 >>> />/ INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber >>> />/ (Ljava/lang/Object;)D >>> />/ ILOAD 4 >>> />/ I2D >>> />/ DSUB >>> />/ >>> />/ >>> />/ (Also: That was one of the bug reports which worried me a bit, >>> because >>> />/ I expected the changes to be non-trivial. :-( >>> />/ >>> />/ >>> />/ - Andr?/ > > From andrebargull at googlemail.com Tue Oct 15 01:45:52 2013 From: andrebargull at googlemail.com (=?ISO-8859-15?Q?Andr=E9_Bargull?=) Date: Tue, 15 Oct 2013 10:45:52 +0200 Subject: Code generation patches for fuzzer (feedback requested) Message-ID: <525D00C0.5020800@googlemail.com> I've needed to apply the following patches to continue fuzzing. If those changes look reasonable, can someone make sure they get into the upstream repo? - Andr? (1) IncompatibleAssignmentCoercion.patch: `Type.widest(Type, Type)` can promote boolean -> number, or number -> string. This is not wanted for (?:) - ConditionalExpressions or ReturnStatements. Added a new uncoercedWidest(Type, Type) method to Attr which makes sure only valid promotions are applied. test cases: /* no verify error */ function f1(c,x){ c (x ? [1] : 1); } function f2(c,x){ c = (x ? "123" : 1); return c } typeof f2(null,true) === "string" typeof f2(null,false) === "number" function f3(v){if (v) return 123; else return true} f3(true) === 123 f3(false) === true (2) JDK-8026249-WidenDISCARD.patch: The left-hand side of a BinaryNode does not have a Type if it is a Discard node, that means `lhs.getType()` may throw an assertion error. Moving the Type.widest() calls makes sure `lhs.getType()` is only called when it is safe to do. test case: /* no assertion */ function f() { if(x3, y) x; } (3) JDK-8026249-EnsureTypeDiscard.patch: The type for a CommaRight BinaryNode is based on the right-hand side's type, make sure the RHS always has a proper type attached. [I've also fixed this for CommaLeft, but that one isn't actually used, is it?] test case: /* no assertion */ function f(x) { return y, x } (4) JDK-8026249-ControlFlowEscape.patch: Control flow may escape from SwitchNode or LabelNode through `break` or `continue` statements. Simply moving the "controlFlowEscapes" logic from LoopNode to BreakableStatement solves the SwitchNode issue. And for LabelNode just clear the "terminal" on its body node. test cases: /* no verify error / NPE */ function f() { L: { try { return 1; } finally { break L; }} } /* no verify error / NPE */ function f() { L: { if (v) break L; return} } /* no verify error / NPE */ function f() { L: {{ break L; } return; } } /* no verify error / NPE */ function f() { L: { if (x2) { break L; } throw x; } } /* no verify error / NPE */ function f() { switch(v) { default: if(v) break; return; } } /* no verify error / NPE */ function f() { switch(x) { default: if(true) break; return; } } /* no verify error / NPE */ function f() { switch(x) { default: L: break; return; } } -------------- next part -------------- diff --git a/src/jdk/nashorn/internal/codegen/Attr.java b/src/jdk/nashorn/internal/codegen/Attr.java --- a/src/jdk/nashorn/internal/codegen/Attr.java +++ b/src/jdk/nashorn/internal/codegen/Attr.java @@ -1264,11 +1264,13 @@ @Override public Node leaveCOMMARIGHT(final BinaryNode binaryNode) { + ensureTypeNotUnknown(binaryNode.rhs()); return end(ensureSymbol(binaryNode.rhs().getType(), binaryNode)); } @Override public Node leaveCOMMALEFT(final BinaryNode binaryNode) { + ensureTypeNotUnknown(binaryNode.lhs()); return end(ensureSymbol(binaryNode.lhs().getType(), binaryNode)); } -------------- next part -------------- diff --git a/src/jdk/nashorn/internal/codegen/BranchOptimizer.java b/src/jdk/nashorn/internal/codegen/BranchOptimizer.java --- a/src/jdk/nashorn/internal/codegen/BranchOptimizer.java +++ b/src/jdk/nashorn/internal/codegen/BranchOptimizer.java @@ -84,7 +84,6 @@ private void branchOptimizer(final BinaryNode binaryNode, final Label label, final boolean state) { final Expression lhs = binaryNode.lhs(); final Expression rhs = binaryNode.rhs(); - Type widest = Type.widest(lhs.getType(), rhs.getType()); switch (binaryNode.tokenType()) { case AND: @@ -113,33 +112,33 @@ case EQ: case EQ_STRICT: - codegen.loadBinaryOperands(lhs, rhs, widest); + codegen.loadBinaryOperands(lhs, rhs, Type.widest(lhs.getType(), rhs.getType())); method.conditionalJump(state ? EQ : NE, true, label); return; case NE: case NE_STRICT: - codegen.loadBinaryOperands(lhs, rhs, widest); + codegen.loadBinaryOperands(lhs, rhs, Type.widest(lhs.getType(), rhs.getType())); method.conditionalJump(state ? NE : EQ, true, label); return; case GE: - codegen.loadBinaryOperands(lhs, rhs, widest); + codegen.loadBinaryOperands(lhs, rhs, Type.widest(lhs.getType(), rhs.getType())); method.conditionalJump(state ? GE : LT, !state, label); return; case GT: - codegen.loadBinaryOperands(lhs, rhs, widest); + codegen.loadBinaryOperands(lhs, rhs, Type.widest(lhs.getType(), rhs.getType())); method.conditionalJump(state ? GT : LE, !state, label); return; case LE: - codegen.loadBinaryOperands(lhs, rhs, widest); + codegen.loadBinaryOperands(lhs, rhs, Type.widest(lhs.getType(), rhs.getType())); method.conditionalJump(state ? LE : GT, state, label); return; case LT: - codegen.loadBinaryOperands(lhs, rhs, widest); + codegen.loadBinaryOperands(lhs, rhs, Type.widest(lhs.getType(), rhs.getType())); method.conditionalJump(state ? LT : GE, state, label); return; -------------- next part -------------- diff --git a/src/jdk/nashorn/internal/codegen/Attr.java b/src/jdk/nashorn/internal/codegen/Attr.java --- a/src/jdk/nashorn/internal/codegen/Attr.java +++ b/src/jdk/nashorn/internal/codegen/Attr.java @@ -765,7 +765,7 @@ symbol.setType(Type.OBJECT); } - returnType = Type.widest(returnTypes.pop(), symbol.getSymbolType()); + returnType = uncoercedWidest(returnTypes.pop(), symbol.getSymbolType()); } else { returnType = Type.OBJECT; //undefined } @@ -1427,7 +1427,7 @@ ensureTypeNotUnknown(trueExpr); ensureTypeNotUnknown(falseExpr); - final Type type = Type.widest(trueExpr.getType(), falseExpr.getType()); + final Type type = uncoercedWidest(trueExpr.getType(), falseExpr.getType()); return end(ensureSymbol(type, ternaryNode)); } @@ -1603,6 +1603,34 @@ } /** + * Returns the widest or most common of two types without applying type + * coercion, e.g. coercion from boolean -> int, or int -> string is not + * allowed. + * + * @param type0 type one + * @param type1 type two + * + * @return the widest type + */ + private static Type uncoercedWidest(final Type type0, final Type type1) { + final boolean canWiden; + if (type0.isUnknown() || type1.isUnknown()) { + canWiden = true; + } else if (type0.isNumeric() || type1.isNumeric()) { + canWiden = type0.isNumeric() && type1.isNumeric(); + } else if (type0.isBoolean() || type1.isBoolean()) { + canWiden = type0.isBoolean() && type1.isBoolean(); + } else { + assert type0.isObject() && type1.isObject(); + canWiden = true; + } + if (canWiden) { + return Type.widest(type0, type1); + } + return Type.OBJECT; + } + + /** * If types have changed, we can have failed to update vars. For example * * var x = 17; //x is int -------------- next part -------------- diff --git a/src/jdk/nashorn/internal/codegen/Lower.java b/src/jdk/nashorn/internal/codegen/Lower.java --- a/src/jdk/nashorn/internal/codegen/Lower.java +++ b/src/jdk/nashorn/internal/codegen/Lower.java @@ -48,6 +48,7 @@ import jdk.nashorn.internal.ir.ForNode; import jdk.nashorn.internal.ir.FunctionNode; import jdk.nashorn.internal.ir.FunctionNode.CompilationState; +import jdk.nashorn.internal.ir.CaseNode; import jdk.nashorn.internal.ir.IdentNode; import jdk.nashorn.internal.ir.IfNode; import jdk.nashorn.internal.ir.LabelNode; @@ -255,7 +256,7 @@ @Override public Node leaveLabelNode(final LabelNode labelNode) { - return addStatement(labelNode); + return addStatement(checkEscape(labelNode)); } @Override @@ -267,7 +268,7 @@ @Override public Node leaveSwitchNode(final SwitchNode switchNode) { - return addStatement(switchNode); + return addStatement(checkEscape(switchNode)); } @Override @@ -627,6 +628,24 @@ return loopNode; } + private SwitchNode checkEscape(final SwitchNode switchNode) { + for (final CaseNode caseNode : switchNode.getCases()) { + final boolean escapes = controlFlowEscapes(lc, caseNode.getBody()); + if (escapes) { + return switchNode.setControlFlowEscapes(lc, escapes); + } + } + return switchNode; + } + + private LabelNode checkEscape(final LabelNode labelNode) { + final boolean escapes = controlFlowEscapes(lc, labelNode.getBody()); + if (escapes) { + return labelNode. + setBody(lc, labelNode.getBody().setIsTerminal(lc, false)); + } + return labelNode; + } private Node addStatement(final Statement statement) { lc.appendStatement(statement); diff --git a/src/jdk/nashorn/internal/ir/BreakableStatement.java b/src/jdk/nashorn/internal/ir/BreakableStatement.java --- a/src/jdk/nashorn/internal/ir/BreakableStatement.java +++ b/src/jdk/nashorn/internal/ir/BreakableStatement.java @@ -36,6 +36,9 @@ /** break label. */ protected final Label breakLabel; + /** Can control flow escape from statement, e.g. through breaks or continues to outer loops? */ + protected final boolean controlFlowEscapes; + /** * Constructor * @@ -44,9 +47,10 @@ * @param finish finish * @param breakLabel break label */ - protected BreakableStatement(final int lineNumber, final long token, final int finish, final Label breakLabel) { + protected BreakableStatement(final int lineNumber, final long token, final int finish, final Label breakLabel, final boolean controlFlowEscapes) { super(lineNumber, token, finish); this.breakLabel = breakLabel; + this.controlFlowEscapes = controlFlowEscapes; } /** @@ -54,9 +58,10 @@ * * @param breakableNode source node */ - protected BreakableStatement(final BreakableStatement breakableNode) { + protected BreakableStatement(final BreakableStatement breakableNode, final boolean controlFlowEscapes) { super(breakableNode); this.breakLabel = new Label(breakableNode.getBreakLabel()); + this.controlFlowEscapes = controlFlowEscapes; } /** @@ -88,4 +93,23 @@ public List