From burakkoray at gmail.com Fri Jan 5 06:37:57 2018 From: burakkoray at gmail.com (Koray) Date: Fri, 5 Jan 2018 08:37:57 +0200 Subject: Loss of engine scope in a new Thread Message-ID: Hello, I have a structure which creates a new thread for each client that is connected and assigns a new ScriptContext to them along with a new SimpleBinding for engine scope and same binding for global scope. Each engine scope has a variable called "client", which is basically the javascript object that represents the client. This object has methods like tell, which uses that client's socket to send and receive data. My problem is I can't seem to create a new thread and run a code in it. Each time I do it, it seems to be running on a new scope hense losing the client variable, which leaves me unable to contact with the client. Here are my engine options: engine=(NashornScriptEngine) factory.getScriptEngine(new String[]{"-ot=true", "-doe", "--global-per-engine", "-strict"}); I thought global-per-engine might be the cause, but I can't get clients to have their own client variable without it. Is this a bug? How can I get my code to keep the engine scope in a new Thread which is created like "new java.lang.Thread(function run() { client.tell("hello"); });" Please let me know if this is not clear enough and I'll try to explain better along with code examples. Thank you From hannes.wallnoefer at oracle.com Mon Jan 8 15:44:35 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 8 Jan 2018 16:44:35 +0100 Subject: RFR: 8193567: Conversion of comparison nodes affects local slots in optimistic continuation In-Reply-To: <415D866D-73DF-4A2F-90F1-52EBC34D3759@gmail.com> References: <2A602DA1-A5E0-4292-81E0-92476101EC96@oracle.com> <415D866D-73DF-4A2F-90F1-52EBC34D3759@gmail.com> Message-ID: <3E65A046-441F-4790-BA61-CC64ADDC901F@oracle.com> Thanks for the review, Attila. I didn?t look at the contents of the local slots. I think the root of the problem is that the comparison is represented as RuntimeNode in some cases and as BinaryNode in others, and it can switch between the two between optimistic recompilations (see LocalVariableTypesCalculator.leaveBinaryNode on how comparison nodes are replaced with RuntimeNodes depending on the types of sub-expressions). I doubt it is possible to guarantee these representations use a compatible slot layout, and even if there is, I think for JDK 10 it?s best to take the safe path. Hannes > Am 25.12.2017 um 17:27 schrieb Attila Szegedi : > > A sad +1. I too wish this were easier to solve. Can you point me to the code parts that cause differences in local slot assignment? I guess I could try to figure it out myself from that terrible expression in the test, but if you have a quick explanation? > > Thanks, > Attila. > >> On Dec 21, 2017, at 4:36 PM, Hannes Walln?fer wrote: >> >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193567 >> Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/ >> >> I?ve tried finding a smaller fix like just tagging the child nodes of all comparisons as non-optimistic, but that didn't fix the problem as those nodes could still have optimistic children. >> >> Hannes > From michel.trudeau at oracle.com Mon Jan 8 16:15:39 2018 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Mon, 08 Jan 2018 08:15:39 -0800 Subject: JavaScript/Nashorn mailing list? In-Reply-To: <5f7def19-f29d-9f75-084f-1cbfd694e2e6@oracle.com> References: <5f7def19-f29d-9f75-084f-1cbfd694e2e6@oracle.com> Message-ID: <5A53992B.2070008@oracle.com> Olivier, Nashorn-dev is the best mailing list to ask questions. -- Thanks, Michel > Olivier > January 8, 2018 at 8:08 AM > Hello Michel, and happy 2018! > Quick question for you: I am trying to run some ES6 scripts from Java, > using Nashorn. > What would be a good mailing list (or Slack channel, or what not) for > me to ask some questions about that? > > I found the "nashorn.args" property, with the value "--language=es6", > but I am still facing some issues when I want to import modules... > > Any pointer would help, > Thank you! > - Olivier From szegedia at gmail.com Mon Jan 8 17:48:02 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 8 Jan 2018 18:48:02 +0100 Subject: RFR: 8193567: Conversion of comparison nodes affects local slots in optimistic continuation In-Reply-To: <3E65A046-441F-4790-BA61-CC64ADDC901F@oracle.com> References: <2A602DA1-A5E0-4292-81E0-92476101EC96@oracle.com> <415D866D-73DF-4A2F-90F1-52EBC34D3759@gmail.com> <3E65A046-441F-4790-BA61-CC64ADDC901F@oracle.com> Message-ID: <2E15C588-54F1-4A8D-AD77-77E427896389@gmail.com> I completely agree with taking the safe path in JDK 10. I still want to figure out what might be the root problem with this. Both RuntimeNode for comparisons and BinaryNode take two arguments in the same order. Even if there were some pushing/popping involved around them for UOE handlers, the continuation handler code did evolve over time (and all the corner cases we encountered earlier on) into a creature that can very well handle changes in local variable types across recompilations and slot numbering too (e.g. as an int evolves to double), so I doubt there?s a systemic problem here but rather another corner case to track down. This is in no way meant as a criticism of your work ? I totally agree it?s better to take this approach for JDK 10, it?s more a note to myself that I should dig into this next time I have some cycles and see if I can find a smaller-impact solution. Attila. > On 2018. Jan 8., at 16:44, Hannes Walln?fer wrote: > > Thanks for the review, Attila. > > I didn?t look at the contents of the local slots. I think the root of the problem is that the comparison is represented as RuntimeNode in some cases and as BinaryNode in others, and it can switch between the two between optimistic recompilations (see LocalVariableTypesCalculator.leaveBinaryNode on how comparison nodes are replaced with RuntimeNodes depending on the types of sub-expressions). I doubt it is possible to guarantee these representations use a compatible slot layout, and even if there is, I think for JDK 10 it?s best to take the safe path. > > Hannes > > >> Am 25.12.2017 um 17:27 schrieb Attila Szegedi : >> >> A sad +1. I too wish this were easier to solve. Can you point me to the code parts that cause differences in local slot assignment? I guess I could try to figure it out myself from that terrible expression in the test, but if you have a quick explanation? >> >> Thanks, >> Attila. >> >>> On Dec 21, 2017, at 4:36 PM, Hannes Walln?fer wrote: >>> >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193567 >>> Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/ >>> >>> I?ve tried finding a smaller fix like just tagging the child nodes of all comparisons as non-optimistic, but that didn't fix the problem as those nodes could still have optimistic children. >>> >>> Hannes >> > From sundararajan.athijegannathan at oracle.com Tue Jan 9 02:17:26 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 09 Jan 2018 07:47:26 +0530 Subject: JavaScript/Nashorn mailing list? In-Reply-To: <5A53992B.2070008@oracle.com> References: <5f7def19-f29d-9f75-084f-1cbfd694e2e6@oracle.com> <5A53992B.2070008@oracle.com> Message-ID: <5A542636.2010508@oracle.com> Not all ES6 features are implemented - only a small subset is in jdk 9. Please report with the exact issue... -Sundar On 08/01/18, 9:45 PM, Michel Trudeau wrote: > Olivier, > > Nashorn-dev is the best mailing list > to ask questions. From priya.lakshmi.muthuswamy at oracle.com Tue Jan 9 07:00:31 2018 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Tue, 9 Jan 2018 12:30:31 +0530 Subject: RFR:8157251:BeanLinker relinks array length operations for array types Message-ID: <6a146bc9-245d-3afe-905d-2f3f00f3c07f@oracle.com> Hi, Please review JDK-8157251 : BeanLinker relinks array length operations for array types JBS : https://bugs.openjdk.java.net/browse/JDK-8157251 webrev : http://cr.openjdk.java.net/~pmuthuswamy/8157251/webrev.00/ Thanks, Priya From james.laskey at oracle.com Tue Jan 9 13:23:28 2018 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 9 Jan 2018 09:23:28 -0400 Subject: RFR:8157251:BeanLinker relinks array length operations for array types In-Reply-To: <6a146bc9-245d-3afe-905d-2f3f00f3c07f@oracle.com> References: <6a146bc9-245d-3afe-905d-2f3f00f3c07f@oracle.com> Message-ID: +1 > On Jan 9, 2018, at 3:00 AM, Priya Lakshmi Muthuswamy wrote: > > Hi, > > Please review JDK-8157251 : BeanLinker relinks array length operations for array types > > JBS : https://bugs.openjdk.java.net/browse/JDK-8157251 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8157251/webrev.00/ > > Thanks, > Priya From hannes.wallnoefer at oracle.com Tue Jan 9 13:58:27 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 9 Jan 2018 14:58:27 +0100 Subject: RFR:8157251:BeanLinker relinks array length operations for array types In-Reply-To: References: <6a146bc9-245d-3afe-905d-2f3f00f3c07f@oracle.com> Message-ID: <2C247BDB-A98B-4B29-A0A4-6D934E9C5051@oracle.com> +1 Hannes > Am 09.01.2018 um 14:23 schrieb Jim Laskey (Oracle) : > > +1 > > >> On Jan 9, 2018, at 3:00 AM, Priya Lakshmi Muthuswamy wrote: >> >> Hi, >> >> Please review JDK-8157251 : BeanLinker relinks array length operations for array types >> >> JBS : https://bugs.openjdk.java.net/browse/JDK-8157251 >> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8157251/webrev.00/ >> >> Thanks, >> Priya > From szegedia at gmail.com Tue Jan 9 14:21:08 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 9 Jan 2018 15:21:08 +0100 Subject: RFR:8157251:BeanLinker relinks array length operations for array types In-Reply-To: <6a146bc9-245d-3afe-905d-2f3f00f3c07f@oracle.com> References: <6a146bc9-245d-3afe-905d-2f3f00f3c07f@oracle.com> Message-ID: This effectively reverts the combined and . That was not the intent of 8157251, though. The intent of 8157251 was to use MethodHandles.arrayLength(Object[].class) for all arrays with components of reference type (and use ValidationType.INSTANCE_OF for it, as all such arrays will be instance-of Object[] through instance-of semantics for array types) and leave the linking of arrays with primitive component types as they are today. So, basically, something like: if(clazz.isArray()) { // Some languages won't have a notion of manipulating collections. Exposing "length" on arrays as an // explicit property is beneficial for them. if (clazz.getComponentType().isPrimitive()) { setPropertyGetter("length", MethodHandles.arrayLength(clazz), ValidationType.EXACT_CLASS); } else { setPropertyGetter("length", MethodHandles.arrayLength(Object[].class), ValidationType.INSTANCE_OF); } Obviously, this is again a tradeoff between linkage stability and performance, except that with this solution we don?t sacrifice any performance and we still increase linkage stability. Going back to Array.getLength does further increase linkage stability, but *speculatively* it doesn?t intrinsify to as lean code as MethodHandles.arrayLength does (it certainly erases the type information of the argument); someone with time on their hands should probably run some PrintAssembly tests with -XX:-TieredCompilation to see whether this is true (if not, then 8157225 and 8157250 were done for nothing and this patch undoes them anyway). In any case, I don?t have a too strong opinion about this; I don?t mind even if this ends up being a reversal of 8157225; it?s just weird that we have arrayLength method handle intrinsics and not use them. Attila. > On Jan 9, 2018, at 8:00 AM, Priya Lakshmi Muthuswamy wrote: > > Hi, > > Please review JDK-8157251 : BeanLinker relinks array length operations for array types > > JBS : https://bugs.openjdk.java.net/browse/JDK-8157251 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8157251/webrev.00/ > > Thanks, > Priya From priya.lakshmi.muthuswamy at oracle.com Wed Jan 10 05:42:44 2018 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Wed, 10 Jan 2018 11:12:44 +0530 Subject: RFR:8157251:BeanLinker relinks array length operations for array types In-Reply-To: References: <6a146bc9-245d-3afe-905d-2f3f00f3c07f@oracle.com> Message-ID: <4f4431af-fa9d-63f2-83ed-3af2036af4e0@oracle.com> Hi Attila, Thanks for the review. I just felt in the case of primitive types there will be relinking. I tried with the below fix. In the case object types, I see relinking when we use Validation.INSTANCE_OF. But works fine without relinking when we use Validation.IS_ARRAY if(clazz.isArray()) { // Some languages won't have a notion of manipulating collections. Exposing "length" on arrays as an // explicit property is beneficial for them. if (clazz.getComponentType().isPrimitive()) { setPropertyGetter("length", MethodHandles.arrayLength(clazz), ValidationType.EXACT_CLASS); }else { setPropertyGetter("length", MethodHandles.arrayLength(Object[].class), ValidationType.IS_ARRAY); } Thanks, Priya On 1/9/2018 7:51 PM, Attila Szegedi wrote: > This effectively reverts the combined and . > > That was not the intent of 8157251, though. > > The intent of 8157251 was to use MethodHandles.arrayLength(Object[].class) for all arrays with components of reference type (and use ValidationType.INSTANCE_OF for it, as all such arrays will be instance-of Object[] through instance-of semantics for array types) and leave the linking of arrays with primitive component types as they are today. > > So, basically, something like: > > if(clazz.isArray()) { > // Some languages won't have a notion of manipulating collections. Exposing "length" on arrays as an > // explicit property is beneficial for them. > if (clazz.getComponentType().isPrimitive()) { > setPropertyGetter("length", MethodHandles.arrayLength(clazz), ValidationType.EXACT_CLASS); > } else { > setPropertyGetter("length", MethodHandles.arrayLength(Object[].class), ValidationType.INSTANCE_OF); > } > > Obviously, this is again a tradeoff between linkage stability and performance, except that with this solution we don?t sacrifice any performance and we still increase linkage stability. Going back to Array.getLength does further increase linkage stability, but *speculatively* it doesn?t intrinsify to as lean code as MethodHandles.arrayLength does (it certainly erases the type information of the argument); someone with time on their hands should probably run some PrintAssembly tests with -XX:-TieredCompilation to see whether this is true (if not, then 8157225 and 8157250 were done for nothing and this patch undoes them anyway). > > In any case, I don?t have a too strong opinion about this; I don?t mind even if this ends up being a reversal of 8157225; it?s just weird that we have arrayLength method handle intrinsics and not use them. > > Attila. > > >> On Jan 9, 2018, at 8:00 AM, Priya Lakshmi Muthuswamy wrote: >> >> Hi, >> >> Please review JDK-8157251 : BeanLinker relinks array length operations for array types >> >> JBS : https://bugs.openjdk.java.net/browse/JDK-8157251 >> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8157251/webrev.00/ >> >> Thanks, >> Priya From hannes.wallnoefer at oracle.com Wed Jan 10 13:32:28 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 10 Jan 2018 14:32:28 +0100 Subject: RFR:8157251:BeanLinker relinks array length operations for array types In-Reply-To: <4f4431af-fa9d-63f2-83ed-3af2036af4e0@oracle.com> References: <6a146bc9-245d-3afe-905d-2f3f00f3c07f@oracle.com> <4f4431af-fa9d-63f2-83ed-3af2036af4e0@oracle.com> Message-ID: Priya, The problem with your solution that using an object array invocation with a primitive array will throw a ClassCastException as it passes the isArray guard. On the other hand, the problem with instanceof validation in Attila?s snippet is that it uses the concrete callsite type (e.g. String[]) instead of Object[]. What we?d need is a guard with an instanceof Object[] check. However, I don?t think a callsite for array length will usually see so many different array classes to go megamorphic, so I think both your solutions (Priya?s webrev and Attila?s code snippet) are acceptable. Hannes > Am 10.01.2018 um 06:42 schrieb Priya Lakshmi Muthuswamy : > > Hi Attila, > > Thanks for the review. I just felt in the case of primitive types there will be relinking. > I tried with the below fix. > In the case object types, I see relinking when we use Validation.INSTANCE_OF. But works fine without relinking when we use Validation.IS_ARRAY > > if(clazz.isArray()) { > // Some languages won't have a notion of manipulating collections. Exposing "length" on arrays as an // explicit property is beneficial for them. if (clazz.getComponentType().isPrimitive()) { > setPropertyGetter("length", MethodHandles.arrayLength(clazz), ValidationType.EXACT_CLASS); > }else { > setPropertyGetter("length", MethodHandles.arrayLength(Object[].class), ValidationType.IS_ARRAY); > } > > Thanks, > Priya > > > On 1/9/2018 7:51 PM, Attila Szegedi wrote: >> This effectively reverts the combined and . >> >> That was not the intent of 8157251, though. >> >> The intent of 8157251 was to use MethodHandles.arrayLength(Object[].class) for all arrays with components of reference type (and use ValidationType.INSTANCE_OF for it, as all such arrays will be instance-of Object[] through instance-of semantics for array types) and leave the linking of arrays with primitive component types as they are today. >> >> So, basically, something like: >> >> if(clazz.isArray()) { >> // Some languages won't have a notion of manipulating collections. Exposing "length" on arrays as an >> // explicit property is beneficial for them. >> if (clazz.getComponentType().isPrimitive()) { >> setPropertyGetter("length", MethodHandles.arrayLength(clazz), ValidationType.EXACT_CLASS); >> } else { >> setPropertyGetter("length", MethodHandles.arrayLength(Object[].class), ValidationType.INSTANCE_OF); >> } >> >> Obviously, this is again a tradeoff between linkage stability and performance, except that with this solution we don?t sacrifice any performance and we still increase linkage stability. Going back to Array.getLength does further increase linkage stability, but *speculatively* it doesn?t intrinsify to as lean code as MethodHandles.arrayLength does (it certainly erases the type information of the argument); someone with time on their hands should probably run some PrintAssembly tests with -XX:-TieredCompilation to see whether this is true (if not, then 8157225 and 8157250 were done for nothing and this patch undoes them anyway). >> >> In any case, I don?t have a too strong opinion about this; I don?t mind even if this ends up being a reversal of 8157225; it?s just weird that we have arrayLength method handle intrinsics and not use them. >> >> Attila. >> >> >>> On Jan 9, 2018, at 8:00 AM, Priya Lakshmi Muthuswamy wrote: >>> >>> Hi, >>> >>> Please review JDK-8157251 : BeanLinker relinks array length operations for array types >>> >>> JBS : https://bugs.openjdk.java.net/browse/JDK-8157251 >>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8157251/webrev.00/ >>> >>> Thanks, >>> Priya > From szegedia at gmail.com Wed Jan 10 17:39:13 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 10 Jan 2018 18:39:13 +0100 Subject: RFR:8157251:BeanLinker relinks array length operations for array types In-Reply-To: References: <6a146bc9-245d-3afe-905d-2f3f00f3c07f@oracle.com> <4f4431af-fa9d-63f2-83ed-3af2036af4e0@oracle.com> Message-ID: <7FD21D14-69FC-4C41-A49D-1C06B1689270@gmail.com> On Jan 10, 2018, at 2:32 PM, Hannes Walln?fer wrote: > > Priya, > > The problem with your solution that using an object array invocation with a primitive array will throw a ClassCastException as it passes the isArray guard. > > On the other hand, the problem with instanceof validation in Attila?s snippet is that it uses the concrete callsite type (e.g. String[]) instead of Object[]. What we?d need is a guard with an instanceof Object[] check. Yeah, my solution wasn?t complete by any means, it just wanted to be a pointer in the right direction. Priya?s change to use IS_ARRAY *almost* worked, except for, as you noticed, primitive arrays. FWIW, since IS_ARRAY isn?t actually used for anything else (the JIRA ticket allures to it getting retired), we could replace it with a new IS_REFERENCE_ARRAY ValidationType (that basically describes an instanceof Object[] check) and then Priya and mine combined solution below would work with it. The only other place where a new ValidationType needs to be handled is in AbstractJavaLinker.getGuard and GuardedInvocationComponent.Validator.compose. Those would need some more adjustments (basically, replacing every "validatorClass.isArray()? expression with ?Object[].class.isAssignableFrom(validatorClass)?.) Of course, then on another look it seems to me that length properties for collections and maps will *also* have stricter linkage than necessary, since INSTANCE_OF validation type will always link an instanceof check for the linked class, and these properties could also have more lenient linkage, like how element getters and setters are stably linked for lists and maps in general. So I guess we might need to add an IS_COLLECTION and IS_MAP ValidationType too to use for these length getters :-) It?s not a big deal adding validation types, they?re just encapsulations of guard logic that also know how to compose (they need to compose in unnamed getter linking logic? welcome to the nontrivial world of bean linking :-) ). It might be tempting to just override getPropertyGetter() instead and add special code for linking ?length?, and that?d _mostly_ work; one advantage of using setPropertyGetter() is that those properties defined with setPropertyGetter() will be automatically found by call sites with unnamed access, e.g. Nashorn pseudocode: var propName = (function() { return ?length? })() arr[propName] > However, I don?t think a callsite for array length will usually see so many different array classes to go megamorphic, so I think both your solutions (Priya?s webrev and Attila?s code snippet) are acceptable. Yeah, I?m also fine with whichever solution. Committing the reversal to Array.getLength is fine too with me. It might be a nice exercise though to add IS_REFERENCE_ARRAY, IS_COLLECTION, and IS_MAP ValidationTypes, and define the length getters for arrays, collections, and maps using them, with requisite adjustments to both AbstractJavaLinker.getGuard and GuardedInvocationComponent.Validator.compose. Attila. > > Hannes > >> Am 10.01.2018 um 06:42 schrieb Priya Lakshmi Muthuswamy : >> >> Hi Attila, >> >> Thanks for the review. I just felt in the case of primitive types there will be relinking. >> I tried with the below fix. >> In the case object types, I see relinking when we use Validation.INSTANCE_OF. But works fine without relinking when we use Validation.IS_ARRAY >> >> if(clazz.isArray()) { >> // Some languages won't have a notion of manipulating collections. Exposing "length" on arrays as an // explicit property is beneficial for them. if (clazz.getComponentType().isPrimitive()) { >> setPropertyGetter("length", MethodHandles.arrayLength(clazz), ValidationType.EXACT_CLASS); >> }else { >> setPropertyGetter("length", MethodHandles.arrayLength(Object[].class), ValidationType.IS_ARRAY); >> } >> >> Thanks, >> Priya >> >> >> On 1/9/2018 7:51 PM, Attila Szegedi wrote: >>> This effectively reverts the combined and . >>> >>> That was not the intent of 8157251, though. >>> >>> The intent of 8157251 was to use MethodHandles.arrayLength(Object[].class) for all arrays with components of reference type (and use ValidationType.INSTANCE_OF for it, as all such arrays will be instance-of Object[] through instance-of semantics for array types) and leave the linking of arrays with primitive component types as they are today. >>> >>> So, basically, something like: >>> >>> if(clazz.isArray()) { >>> // Some languages won't have a notion of manipulating collections. Exposing "length" on arrays as an >>> // explicit property is beneficial for them. >>> if (clazz.getComponentType().isPrimitive()) { >>> setPropertyGetter("length", MethodHandles.arrayLength(clazz), ValidationType.EXACT_CLASS); >>> } else { >>> setPropertyGetter("length", MethodHandles.arrayLength(Object[].class), ValidationType.INSTANCE_OF); >>> } >>> >>> Obviously, this is again a tradeoff between linkage stability and performance, except that with this solution we don?t sacrifice any performance and we still increase linkage stability. Going back to Array.getLength does further increase linkage stability, but *speculatively* it doesn?t intrinsify to as lean code as MethodHandles.arrayLength does (it certainly erases the type information of the argument); someone with time on their hands should probably run some PrintAssembly tests with -XX:-TieredCompilation to see whether this is true (if not, then 8157225 and 8157250 were done for nothing and this patch undoes them anyway). >>> >>> In any case, I don?t have a too strong opinion about this; I don?t mind even if this ends up being a reversal of 8157225; it?s just weird that we have arrayLength method handle intrinsics and not use them. >>> >>> Attila. >>> >>> >>>> On Jan 9, 2018, at 8:00 AM, Priya Lakshmi Muthuswamy wrote: >>>> >>>> Hi, >>>> >>>> Please review JDK-8157251 : BeanLinker relinks array length operations for array types >>>> >>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8157251 >>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8157251/webrev.00/ >>>> >>>> Thanks, >>>> Priya >> > From sundararajan.athijegannathan at oracle.com Fri Jan 12 05:49:01 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 12 Jan 2018 11:19:01 +0530 Subject: Loss of engine scope in a new Thread In-Reply-To: References: Message-ID: <5A584C4D.1020307@oracle.com> can you use send us a simple compilable, runnable test case that can reproduce your issue? Thanks, -Sundar On 05/01/18, 12:07 PM, Koray wrote: > Hello, > > I have a structure which creates a new thread for each client that is > connected and assigns a new ScriptContext to them along with a new > SimpleBinding for engine scope and same binding for global scope. Each > engine scope has a variable called "client", which is basically the > javascript object that represents the client. This object has methods > like tell, which uses that client's socket to send and receive data. > My problem is I can't seem to create a new thread and run a code in > it. Each time I do it, it seems to be running on a new scope hense > losing the client variable, which leaves me unable to contact with the > client. Here are my engine options: > engine=(NashornScriptEngine) factory.getScriptEngine(new > String[]{"-ot=true", "-doe", "--global-per-engine", "-strict"}); > I thought global-per-engine might be the cause, but I can't get > clients to have their own client variable without it. Is this a bug? > How can I get my code to keep the engine scope in a new Thread which > is created like "new java.lang.Thread(function run() { > client.tell("hello"); });" > Please let me know if this is not clear enough and I'll try to explain > better along with code examples. > > Thank you From hannes.wallnoefer at oracle.com Fri Jan 12 09:26:25 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 12 Jan 2018 10:26:25 +0100 Subject: RFR [11]: 8194985: JavaAdapterBytecodeGenerator passes invalid type descriptor to ASM Message-ID: Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8194985 Webrev: http://cr.openjdk.java.net/~hannesw/8194985/webrev.00/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Fri Jan 12 10:08:17 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 12 Jan 2018 15:38:17 +0530 Subject: RFR [11]: 8194985: JavaAdapterBytecodeGenerator passes invalid type descriptor to ASM In-Reply-To: References: Message-ID: <5A588911.3040008@oracle.com> +1 -Sundar On 12/01/18, 2:56 PM, Hannes Walln?fer wrote: > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8194985 > Webrev: http://cr.openjdk.java.net/~hannesw/8194985/webrev.00/ > > Thanks, > Hannes From szegedia at gmail.com Fri Jan 12 12:00:55 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 12 Jan 2018 13:00:55 +0100 Subject: RFR [11]: 8194985: JavaAdapterBytecodeGenerator passes invalid type descriptor to ASM In-Reply-To: <5A588911.3040008@oracle.com> References: <5A588911.3040008@oracle.com> Message-ID: <28CA122F-7E2F-4BEC-87B1-0268032A31F1@gmail.com> +1 That?s a weird thing to make stricter. I guess in anticipation of value types which will use something other than L it can?t just substitute L anymore for anything that?s not a known primitive type name. Attila. > On 2018. Jan 12., at 11:08, Sundararajan Athijegannathan wrote: > > +1 > > -Sundar > > On 12/01/18, 2:56 PM, Hannes Walln?fer wrote: >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8194985 >> Webrev: http://cr.openjdk.java.net/~hannesw/8194985/webrev.00/ >> >> Thanks, >> Hannes From hannes.wallnoefer at oracle.com Fri Jan 12 12:59:17 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 12 Jan 2018 13:59:17 +0100 Subject: RFR [11]: 8194985: JavaAdapterBytecodeGenerator passes invalid type descriptor to ASM In-Reply-To: <28CA122F-7E2F-4BEC-87B1-0268032A31F1@gmail.com> References: <5A588911.3040008@oracle.com> <28CA122F-7E2F-4BEC-87B1-0268032A31F1@gmail.com> Message-ID: Actually the old implementation was a bit careless, checking just the first character in a switch statement for primitive and reference types, and then creating a *method* type in the default case, which just happened to work by chance for our checkcast operation. The way it is now is definitely an improvement. Thanks for the reviews! Hannes > Am 12.01.2018 um 13:00 schrieb Attila Szegedi : > > +1 > > That?s a weird thing to make stricter. I guess in anticipation of value types which will use something other than L it can?t just substitute L anymore for anything that?s not a known primitive type name. > > Attila. > >> On 2018. Jan 12., at 11:08, Sundararajan Athijegannathan wrote: >> >> +1 >> >> -Sundar >> >> On 12/01/18, 2:56 PM, Hannes Walln?fer wrote: >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194985 >>> Webrev: http://cr.openjdk.java.net/~hannesw/8194985/webrev.00/ >>> >>> Thanks, >>> Hannes > From szegedia at gmail.com Sat Jan 13 10:02:25 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Sat, 13 Jan 2018 11:02:25 +0100 Subject: Review request for JDK-8193295: Remove no longer used COMMALEFT In-Reply-To: References: <202BF530-2C4A-4EEC-9EC3-E1900CB6DC06@gmail.com> <4E6B3DD0-A3FF-4DD2-B18C-725F99FDE37C@oracle.com> Message-ID: <9F5DE847-65B1-40CA-9C86-BE89C76EAC99@gmail.com> Can I get another review? > On Dec 25, 2017, at 10:59 AM, Attila Szegedi wrote: > > Yeah, JDK 11. There?s no visible changes, so it doesn?t really make sense pushing it into JDK 10. > >> On Dec 21, 2017, at 9:37 PM, Hannes Walln?fer wrote: >> >> Interesting. I bet the answer is in the commits from before we went open source. >> >> +1 >> >> I assume this is for JDK 11? >> >> Hannes >> >>> Am 21.12.2017 um 19:20 schrieb Attila Szegedi : >>> >>> Please review JDK-8193295 "Remove no longer used COMMALEFT" at for >>> >>> I love deleting code :-) >>> >>> COMMALEFT was an odd duck, as there?s not really anything in the ES specification that?d require it, and we really don?t even use it for anything. I had a memory that we used to use it for some behavior around object literals, but I can?t find any traces of that? I run: >>> >>> hg log --template "{ifcontains('COMMALEFT', diff(), '{node} {desc}\n', '')}? >>> >>> and trawled through the diffs for all changesets it brought up, but I haven?t found a single use of COMMALEFT ever. >>> >>> Thanks, >>> Attila. >> > From openjdk at haupz.de Sun Jan 14 08:38:05 2018 From: openjdk at haupz.de (Michael Haupt) Date: Sun, 14 Jan 2018 09:38:05 +0100 Subject: Review request for JDK-8193295: Remove no longer used COMMALEFT In-Reply-To: <9F5DE847-65B1-40CA-9C86-BE89C76EAC99@gmail.com> References: <202BF530-2C4A-4EEC-9EC3-E1900CB6DC06@gmail.com> <4E6B3DD0-A3FF-4DD2-B18C-725F99FDE37C@oracle.com> <9F5DE847-65B1-40CA-9C86-BE89C76EAC99@gmail.com> Message-ID: <2745B074-D1E8-43F1-98BB-C9F6DB9F7AD4@haupz.de> Hi Attila, thumbs up. :-) Best, Michael > Am 13.01.2018 um 11:02 schrieb Attila Szegedi : > > Can I get another review? > >> On Dec 25, 2017, at 10:59 AM, Attila Szegedi wrote: >> >> Yeah, JDK 11. There?s no visible changes, so it doesn?t really make sense pushing it into JDK 10. >> >>> On Dec 21, 2017, at 9:37 PM, Hannes Walln?fer wrote: >>> >>> Interesting. I bet the answer is in the commits from before we went open source. >>> >>> +1 >>> >>> I assume this is for JDK 11? >>> >>> Hannes >>> >>>> Am 21.12.2017 um 19:20 schrieb Attila Szegedi : >>>> >>>> Please review JDK-8193295 "Remove no longer used COMMALEFT" at for >>>> >>>> I love deleting code :-) >>>> >>>> COMMALEFT was an odd duck, as there?s not really anything in the ES specification that?d require it, and we really don?t even use it for anything. I had a memory that we used to use it for some behavior around object literals, but I can?t find any traces of that? I run: >>>> >>>> hg log --template "{ifcontains('COMMALEFT', diff(), '{node} {desc}\n', '')}? >>>> >>>> and trawled through the diffs for all changesets it brought up, but I haven?t found a single use of COMMALEFT ever. >>>> >>>> Thanks, >>>> Attila. >>> >> > From hannes.wallnoefer at oracle.com Wed Jan 17 15:36:48 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 17 Jan 2018 16:36:48 +0100 Subject: RFR: 8195123: Very large regressions in Octane benchmarks using 10-b39 Message-ID: <5FCD03F4-FE2A-4910-9521-E743E8FCF792@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8195123 Webrev: http://cr.openjdk.java.net/~hannesw/8195123/webrev.00/ This undoes the recent fix for JDK-8193567 (Attila, in case you?re reading, I should have taken your doubts more serously) and replaces it with a different fix. Instead of disabling optimistic types within comparison nodes, the new fix avoids the shortcuts for null and undefined comparison if the compared expression contains an optimistic expression. Previously we only checked whether the expression itself was optimistic or contained the expression that triggered the current rest-of compilation. It?s easy to see why we must avoid it also for nested optimistic expressions, as they can trigger deoptimization as well. In my testing, this fixes the performance regression. Hannes From james.laskey at oracle.com Wed Jan 17 15:43:18 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 17 Jan 2018 11:43:18 -0400 Subject: RFR: 8195123: Very large regressions in Octane benchmarks using 10-b39 In-Reply-To: <5FCD03F4-FE2A-4910-9521-E743E8FCF792@oracle.com> References: <5FCD03F4-FE2A-4910-9521-E743E8FCF792@oracle.com> Message-ID: <92EF1439-0919-46EF-AAD1-1323CE09A992@oracle.com> +1 > On Jan 17, 2018, at 11:36 AM, Hannes Walln?fer wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195123 > Webrev: http://cr.openjdk.java.net/~hannesw/8195123/webrev.00/ > > This undoes the recent fix for JDK-8193567 (Attila, in case you?re reading, I should have taken your doubts more serously) and replaces it with a different fix. > > Instead of disabling optimistic types within comparison nodes, the new fix avoids the shortcuts for null and undefined comparison if the compared expression contains an optimistic expression. Previously we only checked whether the expression itself was optimistic or contained the expression that triggered the current rest-of compilation. It?s easy to see why we must avoid it also for nested optimistic expressions, as they can trigger deoptimization as well. > > In my testing, this fixes the performance regression. > > Hannes From szegedia at gmail.com Wed Jan 17 20:37:33 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 17 Jan 2018 21:37:33 +0100 Subject: RFR: 8195123: Very large regressions in Octane benchmarks using 10-b39 In-Reply-To: <92EF1439-0919-46EF-AAD1-1323CE09A992@oracle.com> References: <5FCD03F4-FE2A-4910-9521-E743E8FCF792@oracle.com> <92EF1439-0919-46EF-AAD1-1323CE09A992@oracle.com> Message-ID: <05B51721-5EB2-4E66-AE8B-58CB9E4DD2C1@gmail.com> +1 > On 2018. Jan 17., at 16:43, Jim Laskey wrote: > > +1 > > >> On Jan 17, 2018, at 11:36 AM, Hannes Walln?fer wrote: >> >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8195123 >> Webrev: http://cr.openjdk.java.net/~hannesw/8195123/webrev.00/ >> >> This undoes the recent fix for JDK-8193567 (Attila, in case you?re reading, I should have taken your doubts more serously) and replaces it with a different fix. >> >> Instead of disabling optimistic types within comparison nodes, the new fix avoids the shortcuts for null and undefined comparison if the compared expression contains an optimistic expression. Previously we only checked whether the expression itself was optimistic or contained the expression that triggered the current rest-of compilation. It?s easy to see why we must avoid it also for nested optimistic expressions, as they can trigger deoptimization as well. >> >> In my testing, this fixes the performance regression. >> >> Hannes > From olivier.lediouris at oracle.com Mon Jan 8 16:33:57 2018 From: olivier.lediouris at oracle.com (Olivier) Date: Mon, 8 Jan 2018 08:33:57 -0800 Subject: ES6 from Java, using Nashorn Message-ID: <9180c456-4e2e-4f27-cd27-a13a29c60e92@oracle.com> Hi experts, I want to run ES6 scripts from Java, using Nashorn. I have scripts involving 'let', 'const', my Java code is happy with it, I just need to use a property "nashorn.args" set to "--language=es6". Now, I'd like to move forward, use imports and modules. I have one script like this (modules.01.js): function displayMessage() { console.log("Hello JS World!"); }; export default displayMessage; I want to consume it from this (modules.consume.js): import displayMessagefrom './modules.01'; displayMessage(); But this is where I have a question: My engine.eval("load('./modules.consume.js');"); complains about the "import" statement. In the transpiled version, it complains about the "require" statement. I must be missing something... I attach my code, in case it's needed. Any idea, pointer, comment, help, etc, most welcome, Thank you! - Olivier -------------- next part -------------- package scripting; import javax.script.ScriptEngine; import javax.script.ScriptEngineFactory; import javax.script.ScriptEngineManager; import java.io.File; import java.io.FileReader; import java.util.List; import java.util.stream.Collectors; public class Executor { private final static String SCRIPT_TO_RUN = "es6" + File.separator + "out" + File.separator + "modules.consume.js"; // Transpiled //private final static String SCRIPT_TO_RUN = "es6" + File.separator + "modules.consume.js"; // Not transpiled private final static String NASHORN_ARGS = "nashorn.args"; private final static String ES_6 = "--language=es6"; public static void main(String... args) throws Exception { System.out.println(String.format("Running from [%s]", System.getProperty("user.dir"))); String script = SCRIPT_TO_RUN; if (args.length > 0) { script = args[0]; } System.setProperty(NASHORN_ARGS, ES_6); ScriptEngineManager factory = new ScriptEngineManager(); List engineFactories = factory.getEngineFactories(); System.out.println(String.format("%s factory(ies).", engineFactories.size())); engineFactories.stream().forEach(ef -> { System.out.println(String.format("%s (%s)", ef.getEngineName(), ef.getNames().stream().collect(Collectors.joining(", ")))); }); ScriptEngine engine = factory.getEngineByName("nashorn"); FileReader reader = new FileReader(script); try { engine.eval(reader); } catch (Exception ex) { System.err.println("Ooops:" + ex.toString()); } finally { reader.close(); } // Another approach try { String command = String.format("load('%s');", script); System.out.println(String.format("Executing [%s]", command)); engine.eval(command); } catch (Exception ex) { ex.printStackTrace(); } engine.eval("print('Bye now.');"); } } From bradgrier at cox.net Fri Jan 19 03:06:28 2018 From: bradgrier at cox.net (Brad Grier) Date: Thu, 18 Jan 2018 21:06:28 -0600 Subject: ES6 and JavaImporter Message-ID: Hello, I wanted to experiment with the Java 9 ES6 features in my software. Unfortunately I can't get far because of an issue involving JavaImporter. I created a simple jjs example that illustrates the problem. The script works under ES5 but fails under ES6 with: ./pg4.js:6 ReferenceError: "printIt" is not defined #!/usr/bin/jjs -J-Dnashorn.args=--language=es6 var imports = new JavaImporter(java.util); with(imports){ function printIt(a){ print("map: " + a); } function printAndClear(b){ printIt(b); b.clear(); } var map = new HashMap(); map.put('js', 'javascript'); map.put("java", "java"); printAndClear(map); } Thanks. I'm using build 9.0.1+11 on OS X. Brad From natedogith1 at gmail.com Fri Jan 19 09:31:58 2018 From: natedogith1 at gmail.com (Nathan Faulkner) Date: Fri, 19 Jan 2018 04:31:58 -0500 Subject: Field Method Conflicts Message-ID: Is there any way, other than reflection, to access a field that shares a name with a method? It seems that, with the Test class, instance.item returns the item() dynamic method (as does instance["item"]), and instance.item2 returns "b". public class Test { public String item = "1"; public String item2 = "2"; public String item() { return "a"; } public String getItem2() { return "b"; } } Thanks, Nathan Faulkner From hannes.wallnoefer at oracle.com Fri Jan 19 14:11:32 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 19 Jan 2018 15:11:32 +0100 Subject: ES6 from Java, using Nashorn In-Reply-To: <9180c456-4e2e-4f27-cd27-a13a29c60e92@oracle.com> References: <9180c456-4e2e-4f27-cd27-a13a29c60e92@oracle.com> Message-ID: Hi Olivier, Support for ECMAScript 6 is quite incomplete in Nashorn unfortunately. We only support a small set of ES6 features in JDK 9: ? Template strings ? let, const, and block scope ? Iterators and for..of loops ? Map, Set, WeakMap, and WeakSet ? Symbols ? Binary and octal literals ?require? on the other hand is not part of ES6. It was created as a way to implement modules in the pre-ES6 world. It can be implemented in script and there are implementations out there, so this is probably the most promising approach to use modules in Nashorn. Hannes > Am 08.01.2018 um 17:33 schrieb Olivier : > > Hi experts, > I want to run ES6 scripts from Java, using Nashorn. > I have scripts involving 'let', 'const', my Java code is happy with it, I just need to use a property "nashorn.args" set to "--language=es6". > > Now, I'd like to move forward, use imports and modules. > I have one script like this (modules.01.js): > > function displayMessage() { > console.log("Hello JS World!"); > }; > > export default displayMessage; > > I want to consume it from this (modules.consume.js): > > import displayMessagefrom './modules.01'; > > displayMessage(); > > But this is where I have a question: > My engine.eval("load('./modules.consume.js');"); complains about the "import" statement. > In the transpiled version, it complains about the "require" statement. > > I must be missing something... I attach my code, in case it's needed. > > Any idea, pointer, comment, help, etc, most welcome, > Thank you! > - Olivier > > > > From hannes.wallnoefer at oracle.com Fri Jan 19 14:24:02 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 19 Jan 2018 15:24:02 +0100 Subject: ES6 and JavaImporter In-Reply-To: References: Message-ID: <2B0F6DB8-4798-497C-B7E6-ED3E2EB26C3E@oracle.com> Brad, I as I wrote in my last reply to this list, ES6 support is quite incomplete in Nashorn. However, that doesn?t really explain this error. I?m looking into it and will file a bug. Hannes > Am 19.01.2018 um 04:06 schrieb Brad Grier : > > Hello, > > I wanted to experiment with the Java 9 ES6 features in my software. > Unfortunately I can't get far because of an issue involving JavaImporter. I > created a simple jjs example that illustrates the problem. The script works > under ES5 but fails under ES6 with: ./pg4.js:6 ReferenceError: "printIt" > is not defined > > #!/usr/bin/jjs -J-Dnashorn.args=--language=es6 > > var imports = new JavaImporter(java.util); > with(imports){ > > function printIt(a){ > print("map: " + a); > } > > function printAndClear(b){ > printIt(b); > b.clear(); > } > > var map = new HashMap(); > map.put('js', 'javascript'); > map.put("java", "java"); > printAndClear(map); > } > > Thanks. I'm using build 9.0.1+11 on OS X. > > Brad From szegedia at gmail.com Fri Jan 19 17:39:19 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 19 Jan 2018 18:39:19 +0100 Subject: Field Method Conflicts In-Reply-To: References: Message-ID: <10C3E16B-EBC6-44A3-8321-0DAC1FA4F0A6@gmail.com> No, there isn?t really. Nashorn (well, actually Dynalink that?s underlying Nashorn?s Java-binding functionality) gives preference to a method over a field as methods are more flexible, can include preconditions, can be overridden etc. There?s an assumption that whoever designs the class with both a field and a method sharing their name (or method name conforming to getter convention for the property) would consider the method to be more specific. Attila. > On 2018. Jan 19., at 10:31, Nathan Faulkner wrote: > > Is there any way, other than reflection, to access a field that shares a > name with a method? It seems that, with the Test class, instance.item > returns the item() dynamic method (as does instance["item"]), and > instance.item2 returns "b". > > public class Test { > public String item = "1"; > public String item2 = "2"; > > public String item() { > return "a"; > } > > public String getItem2() { > return "b"; > } > } > > > Thanks, > Nathan Faulkner From sundararajan.athijegannathan at oracle.com Mon Jan 22 14:44:34 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 22 Jan 2018 20:14:34 +0530 Subject: RFR 8195829 Parsing a nameless ES6 class results in a thrown NullPointerException. Message-ID: <5A65F8D2.2070002@oracle.com> Please review. Webrev: http://cr.openjdk.java.net/~sundar/8195829/webrev.00/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8195829 Thanks, -Sundar From james.laskey at oracle.com Mon Jan 22 14:38:21 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 22 Jan 2018 10:38:21 -0400 Subject: RFR 8195829 Parsing a nameless ES6 class results in a thrown NullPointerException. In-Reply-To: <5A65F8D2.2070002@oracle.com> References: <5A65F8D2.2070002@oracle.com> Message-ID: +1 > On Jan 22, 2018, at 10:44 AM, Sundararajan Athijegannathan wrote: > > Please review. > > Webrev: http://cr.openjdk.java.net/~sundar/8195829/webrev.00/index.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8195829 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Mon Jan 22 14:43:47 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 22 Jan 2018 15:43:47 +0100 Subject: RFR 8195829 Parsing a nameless ES6 class results in a thrown NullPointerException. In-Reply-To: <5A65F8D2.2070002@oracle.com> References: <5A65F8D2.2070002@oracle.com> Message-ID: +1 Hannes > Am 22.01.2018 um 15:44 schrieb Sundararajan Athijegannathan : > > Please review. > > Webrev: http://cr.openjdk.java.net/~sundar/8195829/webrev.00/index.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8195829 > > Thanks, > -Sundar From priya.lakshmi.muthuswamy at oracle.com Tue Jan 23 06:34:07 2018 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Tue, 23 Jan 2018 12:04:07 +0530 Subject: RFR: 8147614: add jjs test for -t option Message-ID: Hi, Kindly review JDK-8147614: add jjs test for -t option JBS: https://bugs.openjdk.java.net/browse/JDK-8147614 webrev: http://cr.openjdk.java.net/~pmuthuswamy/8147614/webrev.00/ Thanks, Priya From hannes.wallnoefer at oracle.com Tue Jan 23 11:46:09 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 23 Jan 2018 12:46:09 +0100 Subject: RFR: 8147614: add jjs test for -t option In-Reply-To: References: Message-ID: <76FBB1D7-A9A2-4F4A-B673-CFF357FDFD0D@oracle.com> +1 Hannes > Am 23.01.2018 um 07:34 schrieb Priya Lakshmi Muthuswamy : > > Hi, > > Kindly review JDK-8147614: add jjs test for -t option > > JBS: https://bugs.openjdk.java.net/browse/JDK-8147614 > webrev: http://cr.openjdk.java.net/~pmuthuswamy/8147614/webrev.00/ > > Thanks, > Priya From sundararajan.athijegannathan at oracle.com Tue Jan 23 12:39:08 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 23 Jan 2018 18:09:08 +0530 Subject: RFR: 8147614: add jjs test for -t option In-Reply-To: References: Message-ID: <5A672CEC.6040405@oracle.com> +1 -Sundar On 23/01/18, 12:04 PM, Priya Lakshmi Muthuswamy wrote: > Hi, > > Kindly review JDK-8147614: add jjs test for -t option > > JBS: https://bugs.openjdk.java.net/browse/JDK-8147614 > webrev: http://cr.openjdk.java.net/~pmuthuswamy/8147614/webrev.00/ > > Thanks, > Priya From james.laskey at oracle.com Tue Jan 23 12:54:55 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 23 Jan 2018 08:54:55 -0400 Subject: RFR: 8147614: add jjs test for -t option In-Reply-To: References: Message-ID: +1 > On Jan 23, 2018, at 2:34 AM, Priya Lakshmi Muthuswamy wrote: > > Hi, > > Kindly review JDK-8147614: add jjs test for -t option > > JBS: https://bugs.openjdk.java.net/browse/JDK-8147614 > webrev: http://cr.openjdk.java.net/~pmuthuswamy/8147614/webrev.00/ > > Thanks, > Priya From mani at moofwd.com Thu Jan 25 22:29:56 2018 From: mani at moofwd.com (Mani Govindarajulu) Date: Thu, 25 Jan 2018 17:29:56 -0500 Subject: subscribe Message-ID: -- *Thanks & Regards> M.* *+1-PEAL70-7077* From anders.rundgren.net at gmail.com Sun Jan 28 09:48:17 2018 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Sun, 28 Jan 2018 10:48:17 +0100 Subject: Da Capo: JSON "clear text" signatures Message-ID: The JSON "clear text" signature initiative seems to (finally) be headed for IETF standardization.? The plan is having a BOF session at the next IETF in London. This scheme builds on EcmaScript JSON processing rules for data normalization which only rely on JSON.parse() and JSON.stringify(). A thorny issue for implementers is though serializing the JSON "Number" type. An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely compatible...) solution is currently available in "Nashorn": http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java It would be great if such support could for example be included as a static method in java.lang.Double, making Java and EcmaScript/JavaScript 100% interoperable with respect to this feature, the rest is actually close to trivial. thanx, Anders https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 From hannes.wallnoefer at oracle.com Mon Jan 29 13:52:16 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 29 Jan 2018 14:52:16 +0100 Subject: Da Capo: JSON "clear text" signatures In-Reply-To: References: Message-ID: Hi Anders, I think I lack the context required to understand what you?re asking for. Can you explain how transmitting numbers/doubles in JSON should work and how the static method you?re asking for would enable this? Also, is there a document somewhere describing the IETF standardization work you?re talking about? Thanks, Hannes > Am 28.01.2018 um 10:48 schrieb Anders Rundgren : > > The JSON "clear text" signature initiative seems to (finally) be headed for IETF standardization. The plan is having a BOF session at the next IETF in London. > > This scheme builds on EcmaScript JSON processing rules for data normalization which only rely on JSON.parse() and JSON.stringify(). > > A thorny issue for implementers is though serializing the JSON "Number" type. > > An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely compatible...) solution is currently available in "Nashorn": > http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java > > It would be great if such support could for example be included as a static method in java.lang.Double, making Java and EcmaScript/JavaScript 100% interoperable with respect to this feature, the rest is actually close to trivial. > > thanx, > Anders > https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 From anders.rundgren.net at gmail.com Mon Jan 29 14:15:17 2018 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Mon, 29 Jan 2018 15:15:17 +0100 Subject: Da Capo: JSON "clear text" signatures In-Reply-To: References: Message-ID: <5e1cda3f-4baa-d2b2-c098-c1fd2e6663ea@gmail.com> On 2018-01-29 14:52, Hannes Walln?fer wrote: > Hi Anders, > > I think I lack the context required to understand what you?re asking for. Can you explain how transmitting numbers/doubles in JSON should work and how the static method you?re asking for would enable this? Sure. Signatures depend on that data appears identical on both sides (sender + receiver). If one side outputs the integer 10 as 10.0 (which is OK JSON-wise), the signature will break in an EcmaScript environment where it must be 10 and nothing else. JSON tools would call the proposed static method rather than building their own number serializer. Initially I thought number serialization was a simple problem but that was entirely wrong :-) Fortunately the ECMA folks have the expertize needed and their solution is already supported in billions of devices. Nashorn almost cuts it but only for JavaScript, not Java. > Also, is there a document somewhere describing the IETF standardization work you?re talking about? You will have to wait to next week (when it becomes public), but in the meantime you can take a look at the core "input specifications": https://cyberphone.github.io/doc/security/jose-jcs.html https://cyberphone.github.io/doc/security/jose-jef.html Thanx, Anders > > Thanks, > Hannes > >> Am 28.01.2018 um 10:48 schrieb Anders Rundgren : >> >> The JSON "clear text" signature initiative seems to (finally) be headed for IETF standardization. The plan is having a BOF session at the next IETF in London. >> >> This scheme builds on EcmaScript JSON processing rules for data normalization which only rely on JSON.parse() and JSON.stringify(). >> >> A thorny issue for implementers is though serializing the JSON "Number" type. >> >> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely compatible...) solution is currently available in "Nashorn": >> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java >> >> It would be great if such support could for example be included as a static method in java.lang.Double, making Java and EcmaScript/JavaScript 100% interoperable with respect to this feature, the rest is actually close to trivial. >> >> thanx, >> Anders >> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 > From sundararajan.athijegannathan at oracle.com Mon Jan 29 14:49:15 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 29 Jan 2018 20:19:15 +0530 Subject: Da Capo: JSON "clear text" signatures In-Reply-To: <5e1cda3f-4baa-d2b2-c098-c1fd2e6663ea@gmail.com> References: <5e1cda3f-4baa-d2b2-c098-c1fd2e6663ea@gmail.com> Message-ID: <5A6F346B.6080709@oracle.com> Just to be clear. so.. do you want a toString (static method?) variant in java.lang.Double class as per this specification? -Sundar On 29/01/18, 7:45 PM, Anders Rundgren wrote: > On 2018-01-29 14:52, Hannes Walln?fer wrote: >> Hi Anders, >> >> I think I lack the context required to understand what you?re asking >> for. Can you explain how transmitting numbers/doubles in JSON should >> work and how the static method you?re asking for would enable this? > > Sure. Signatures depend on that data appears identical on both sides > (sender + receiver). > If one side outputs the integer 10 as 10.0 (which is OK JSON-wise), > the signature will break in an EcmaScript environment where it must be > 10 and nothing else. > JSON tools would call the proposed static method rather than building > their own number serializer. > > Initially I thought number serialization was a simple problem but that > was entirely wrong :-) > Fortunately the ECMA folks have the expertize needed and their > solution is already supported in billions of devices. > Nashorn almost cuts it but only for JavaScript, not Java. > >> Also, is there a document somewhere describing the IETF >> standardization work you?re talking about? > > You will have to wait to next week (when it becomes public), but in > the meantime you can take a look at the core "input specifications": > https://cyberphone.github.io/doc/security/jose-jcs.html > https://cyberphone.github.io/doc/security/jose-jef.html > > Thanx, > Anders > >> >> Thanks, >> Hannes >> >>> Am 28.01.2018 um 10:48 schrieb Anders Rundgren >>> : >>> >>> The JSON "clear text" signature initiative seems to (finally) be >>> headed for IETF standardization. The plan is having a BOF session >>> at the next IETF in London. >>> >>> This scheme builds on EcmaScript JSON processing rules for data >>> normalization which only rely on JSON.parse() and JSON.stringify(). >>> >>> A thorny issue for implementers is though serializing the JSON >>> "Number" type. >>> >>> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely >>> compatible...) solution is currently available in "Nashorn": >>> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java >>> >>> >>> It would be great if such support could for example be included as a >>> static method in java.lang.Double, making Java and >>> EcmaScript/JavaScript 100% interoperable with respect to this >>> feature, the rest is actually close to trivial. >>> >>> thanx, >>> Anders >>> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 >>> >> > From anders.rundgren.net at gmail.com Mon Jan 29 14:46:33 2018 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Mon, 29 Jan 2018 15:46:33 +0100 Subject: Da Capo: JSON "clear text" signatures In-Reply-To: <5A6F346B.6080709@oracle.com> References: <5e1cda3f-4baa-d2b2-c098-c1fd2e6663ea@gmail.com> <5A6F346B.6080709@oracle.com> Message-ID: <6dfd33eb-66bd-a275-cd96-409e07cc558e@gmail.com> On 2018-01-29 15:49, Sundararajan Athijegannathan wrote: > Just to be clear. so.. do you want a toString (static method?) variant > in java.lang.Double class as per this specification? I don't think this is a major issue because all fundamental JSON types anyway needs be dealt with separately or through a super interface. The existing Nashorn method (after upgrade to match ES better) moved to the Java layer would probably be just fine. Anders > > -Sundar > > On 29/01/18, 7:45 PM, Anders Rundgren wrote: >> On 2018-01-29 14:52, Hannes Walln?fer wrote: >>> Hi Anders, >>> >>> I think I lack the context required to understand what you?re asking >>> for. Can you explain how transmitting numbers/doubles in JSON should >>> work and how the static method you?re asking for would enable this? >> >> Sure. Signatures depend on that data appears identical on both sides >> (sender + receiver). >> If one side outputs the integer 10 as 10.0 (which is OK JSON-wise), >> the signature will break in an EcmaScript environment where it must be >> 10 and nothing else. >> JSON tools would call the proposed static method rather than building >> their own number serializer. >> >> Initially I thought number serialization was a simple problem but that >> was entirely wrong :-) >> Fortunately the ECMA folks have the expertize needed and their >> solution is already supported in billions of devices. >> Nashorn almost cuts it but only for JavaScript, not Java. >> >>> Also, is there a document somewhere describing the IETF >>> standardization work you?re talking about? >> >> You will have to wait to next week (when it becomes public), but in >> the meantime you can take a look at the core "input specifications": >> https://cyberphone.github.io/doc/security/jose-jcs.html >> https://cyberphone.github.io/doc/security/jose-jef.html >> >> Thanx, >> Anders >> >>> >>> Thanks, >>> Hannes >>> >>>> Am 28.01.2018 um 10:48 schrieb Anders Rundgren >>>> : >>>> >>>> The JSON "clear text" signature initiative seems to (finally) be >>>> headed for IETF standardization. The plan is having a BOF session >>>> at the next IETF in London. >>>> >>>> This scheme builds on EcmaScript JSON processing rules for data >>>> normalization which only rely on JSON.parse() and JSON.stringify(). >>>> >>>> A thorny issue for implementers is though serializing the JSON >>>> "Number" type. >>>> >>>> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely >>>> compatible...) solution is currently available in "Nashorn": >>>> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java >>>> >>>> >>>> It would be great if such support could for example be included as a >>>> static method in java.lang.Double, making Java and >>>> EcmaScript/JavaScript 100% interoperable with respect to this >>>> feature, the rest is actually close to trivial. >>>> >>>> thanx, >>>> Anders >>>> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 >>>> >>> >> From hannes.wallnoefer at oracle.com Mon Jan 29 15:47:42 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 29 Jan 2018 16:47:42 +0100 Subject: Da Capo: JSON "clear text" signatures In-Reply-To: <6dfd33eb-66bd-a275-cd96-409e07cc558e@gmail.com> References: <5e1cda3f-4baa-d2b2-c098-c1fd2e6663ea@gmail.com> <5A6F346B.6080709@oracle.com> <6dfd33eb-66bd-a275-cd96-409e07cc558e@gmail.com> Message-ID: <07D97AF4-4F70-41E3-A570-10E214CA16C6@oracle.com> Thanks for the clarification, Anders. If you are working from Nashorn, the simplest way to enforce JS formatting is to coerce the Java number (whatever type it is) to a JS number, e.g. using unary + operator. If you need this in Java core libs, the place to discuss this would be the core-libs-dev mailing list rather than nashorn-dev, but I think the chances to get such specialised functionality to core libs would be very slim. Hannes > Am 29.01.2018 um 15:46 schrieb Anders Rundgren : > > On 2018-01-29 15:49, Sundararajan Athijegannathan wrote: >> Just to be clear. so.. do you want a toString (static method?) variant >> in java.lang.Double class as per this specification? > > I don't think this is a major issue because all fundamental JSON types anyway needs be dealt with separately or through a super interface. > The existing Nashorn method (after upgrade to match ES better) moved to the Java layer would probably be just fine. > > Anders > >> -Sundar >> On 29/01/18, 7:45 PM, Anders Rundgren wrote: >>> On 2018-01-29 14:52, Hannes Walln?fer wrote: >>>> Hi Anders, >>>> >>>> I think I lack the context required to understand what you?re asking >>>> for. Can you explain how transmitting numbers/doubles in JSON should >>>> work and how the static method you?re asking for would enable this? >>> >>> Sure. Signatures depend on that data appears identical on both sides >>> (sender + receiver). >>> If one side outputs the integer 10 as 10.0 (which is OK JSON-wise), >>> the signature will break in an EcmaScript environment where it must be >>> 10 and nothing else. >>> JSON tools would call the proposed static method rather than building >>> their own number serializer. >>> >>> Initially I thought number serialization was a simple problem but that >>> was entirely wrong :-) >>> Fortunately the ECMA folks have the expertize needed and their >>> solution is already supported in billions of devices. >>> Nashorn almost cuts it but only for JavaScript, not Java. >>> >>>> Also, is there a document somewhere describing the IETF >>>> standardization work you?re talking about? >>> >>> You will have to wait to next week (when it becomes public), but in >>> the meantime you can take a look at the core "input specifications": >>> https://cyberphone.github.io/doc/security/jose-jcs.html >>> https://cyberphone.github.io/doc/security/jose-jef.html >>> >>> Thanx, >>> Anders >>> >>>> >>>> Thanks, >>>> Hannes >>>> >>>>> Am 28.01.2018 um 10:48 schrieb Anders Rundgren >>>>> : >>>>> >>>>> The JSON "clear text" signature initiative seems to (finally) be >>>>> headed for IETF standardization. The plan is having a BOF session >>>>> at the next IETF in London. >>>>> >>>>> This scheme builds on EcmaScript JSON processing rules for data >>>>> normalization which only rely on JSON.parse() and JSON.stringify(). >>>>> >>>>> A thorny issue for implementers is though serializing the JSON >>>>> "Number" type. >>>>> >>>>> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely >>>>> compatible...) solution is currently available in "Nashorn": >>>>> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java >>>>> >>>>> >>>>> It would be great if such support could for example be included as a >>>>> static method in java.lang.Double, making Java and >>>>> EcmaScript/JavaScript 100% interoperable with respect to this >>>>> feature, the rest is actually close to trivial. >>>>> >>>>> thanx, >>>>> Anders >>>>> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 >>>>> >>>> >>> > From anders.rundgren.net at gmail.com Mon Jan 29 16:03:52 2018 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Mon, 29 Jan 2018 17:03:52 +0100 Subject: Da Capo: JSON "clear text" signatures In-Reply-To: <07D97AF4-4F70-41E3-A570-10E214CA16C6@oracle.com> References: <5e1cda3f-4baa-d2b2-c098-c1fd2e6663ea@gmail.com> <5A6F346B.6080709@oracle.com> <6dfd33eb-66bd-a275-cd96-409e07cc558e@gmail.com> <07D97AF4-4F70-41E3-A570-10E214CA16C6@oracle.com> Message-ID: On 2018-01-29 16:47, Hannes Walln?fer wrote: > Thanks for the clarification, Anders. > > If you are working from Nashorn, the simplest way to enforce JS formatting is to coerce the Java number (whatever type it is) to a JS number, e.g. using unary + operator. > > If you need this in Java core libs, the place to discuss this would be the core-libs-dev mailing list rather than nashorn-dev, but I think the chances to get such specialised functionality to core libs would be very slim. Well the JSON java guys have to duplicate serialization not only of numbers but of strings so it appears to be on the same level as Base64 support which made it to JDK 8: https://docs.oracle.com/javase/8/docs/api/index.html?java/util/Base64.html Anders > > Hannes > >> Am 29.01.2018 um 15:46 schrieb Anders Rundgren : >> >> On 2018-01-29 15:49, Sundararajan Athijegannathan wrote: >>> Just to be clear. so.. do you want a toString (static method?) variant >>> in java.lang.Double class as per this specification? >> >> I don't think this is a major issue because all fundamental JSON types anyway needs be dealt with separately or through a super interface. >> The existing Nashorn method (after upgrade to match ES better) moved to the Java layer would probably be just fine. >> >> Anders >> >>> -Sundar >>> On 29/01/18, 7:45 PM, Anders Rundgren wrote: >>>> On 2018-01-29 14:52, Hannes Walln?fer wrote: >>>>> Hi Anders, >>>>> >>>>> I think I lack the context required to understand what you?re asking >>>>> for. Can you explain how transmitting numbers/doubles in JSON should >>>>> work and how the static method you?re asking for would enable this? >>>> >>>> Sure. Signatures depend on that data appears identical on both sides >>>> (sender + receiver). >>>> If one side outputs the integer 10 as 10.0 (which is OK JSON-wise), >>>> the signature will break in an EcmaScript environment where it must be >>>> 10 and nothing else. >>>> JSON tools would call the proposed static method rather than building >>>> their own number serializer. >>>> >>>> Initially I thought number serialization was a simple problem but that >>>> was entirely wrong :-) >>>> Fortunately the ECMA folks have the expertize needed and their >>>> solution is already supported in billions of devices. >>>> Nashorn almost cuts it but only for JavaScript, not Java. >>>> >>>>> Also, is there a document somewhere describing the IETF >>>>> standardization work you?re talking about? >>>> >>>> You will have to wait to next week (when it becomes public), but in >>>> the meantime you can take a look at the core "input specifications": >>>> https://cyberphone.github.io/doc/security/jose-jcs.html >>>> https://cyberphone.github.io/doc/security/jose-jef.html >>>> >>>> Thanx, >>>> Anders >>>> >>>>> >>>>> Thanks, >>>>> Hannes >>>>> >>>>>> Am 28.01.2018 um 10:48 schrieb Anders Rundgren >>>>>> : >>>>>> >>>>>> The JSON "clear text" signature initiative seems to (finally) be >>>>>> headed for IETF standardization. The plan is having a BOF session >>>>>> at the next IETF in London. >>>>>> >>>>>> This scheme builds on EcmaScript JSON processing rules for data >>>>>> normalization which only rely on JSON.parse() and JSON.stringify(). >>>>>> >>>>>> A thorny issue for implementers is though serializing the JSON >>>>>> "Number" type. >>>>>> >>>>>> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely >>>>>> compatible...) solution is currently available in "Nashorn": >>>>>> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java >>>>>> >>>>>> >>>>>> It would be great if such support could for example be included as a >>>>>> static method in java.lang.Double, making Java and >>>>>> EcmaScript/JavaScript 100% interoperable with respect to this >>>>>> feature, the rest is actually close to trivial. >>>>>> >>>>>> thanx, >>>>>> Anders >>>>>> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 >>>>>> >>>>> >>>> >> >