From jesse at dreamtsoft.com Thu Jun 1 22:30:01 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Thu, 01 Jun 2017 22:30:01 +0000 Subject: How to properly implement JSObject to provide conversion of Gson JsonElement objects? In-Reply-To: References: Message-ID: Ironically, I'm hitting a similar issue with a library doing an Object.keys() call against a custom JSObject, can you share the solution you've taken? Also, I'm guessing this is the RFE you created: https://bugs.openjdk.java.net/browse/JDK-8181203?jql=text%20~%20%22Object.keys%20nashorn%22 Thanks! Jesse On Tue, May 30, 2017 at 9:34 AM Daniel Einspanjer wrote: > Thank you, yes that is very similar to the approach I went down. > Ultimately I hit another roadblock that forced me to approach the entire > issue differently. The JS library I am interacting with uses Object.keys() > and currently, Nashorn doesn't support Object.keys() calls with custom > JSObjects. I filed an RFE for that, but due to the issue, I'm having to > avoid using JSObject entirely. > > Thanks again for your reply. > > -Daniel > > On Tue, May 30, 2017 at 12:29 PM Jesse Schulman > wrote: > >> If you haven't got this working yet, one possible solution is to return >> anonymous inner AbstractJSObject that returns true for isFunction calls: >> >> public Object getMember(String name) { >> if ("map".equals(name)) { >> return new AbstractJSObject() { >> @Override >> public Object call(Object thiz, Object... args) { >> // delegate to your JsonArray.map method from this >> annonymous inner class >> // in your example nashorn should pass you a single >> instance of ScriptObjectMirror for args that returns true for isFunction() >> call >> } >> >> @Override >> public boolean isFunction() { >> return true; >> } >> }; >> } >> >> return null; >> } >> >> >> Hope that helps! >> Jesse >> >> On Thu, May 25, 2017 at 1:11 PM Daniel Einspanjer >> wrote: >> >>> I have a project that makes extensive use of the Google Gson library. >>> >>> In this particular case, I have a JsonArray object (which implements >>> iterable) containing a collection of objects. In pure JSON it would look >>> like this: >>> >>> [ 1, true, {"a": "b"}, [1,2] ] >>> >>> In Gson JsonElements, it looks like this: >>> >>> arr = new JsonArray(); >>> arr.add(1); >>> arr.add(true); >>> >>> obj = new JsonObject(); >>> obj.addProperty("a", "b"); >>> >>> arr.add(obj); >>> >>> innerArr = new JsonArray(); >>> innerArr.add(1); >>> innerArr.add(2); >>> >>> arr.add(innerArr); >>> >>> I am calling a Javascript function in Nashorn that is trying to do a map >>> over this array: >>> >>> nash.eval("function doIt(arr) { print(arr.map(function(item) { return >>> (typeof item); })); }"); >>> >>> So, in order for this to work with my own arbitrary object (JsonArray), I >>> believe I need to implement JSObject. >>> >>> I created the wrapper class that implements it, using the underlying >>> JsonArray object as a delegate. things like isArray() and such are >>> trivial, but I'm having trouble with the map. >>> I have a map method that takes a functional interface which is available >>> for the JsonArray object. >>> >>> Nashorn calls getMember("map") when the doIt function is executed. I >>> cannot figure out how to give it an appropriate function reference to my >>> JsonArray.map method. >>> I was able to handle getMember("toString") easily enough, but the problem >>> is that method doesn't take any arguments, so returning a simple >>> Callable is fine for it, but map is going to take arguments that >>> I >>> don't know about ahead of time. >>> >>> I would really appreciate some assistance here. Thanks. >>> >>> -Daniel >>> >> From deinspanjer at gmail.com Fri Jun 2 00:32:00 2017 From: deinspanjer at gmail.com (Daniel Einspanjer) Date: Fri, 02 Jun 2017 00:32:00 +0000 Subject: How to properly implement JSObject to provide conversion of Gson JsonElement objects? In-Reply-To: References: Message-ID: Yes, that is the bug. My work around isn't great, I just had to avoid using any form of custom JSObject. Instead, I do an eval('new Object()') to get a holder and put my object and functions inside it via put(). -Daniel On Thu, Jun 1, 2017, 6:30 PM Jesse Schulman wrote: > Ironically, I'm hitting a similar issue with a library doing an > Object.keys() call against a custom JSObject, can you share the solution > you've taken? > > Also, I'm guessing this is the RFE you created: > https://bugs.openjdk.java.net/browse/JDK-8181203?jql=text%20~%20%22Object.keys%20nashorn%22 > > Thanks! > Jesse > > On Tue, May 30, 2017 at 9:34 AM Daniel Einspanjer > wrote: > >> Thank you, yes that is very similar to the approach I went down. >> Ultimately I hit another roadblock that forced me to approach the entire >> issue differently. The JS library I am interacting with uses Object.keys() >> and currently, Nashorn doesn't support Object.keys() calls with custom >> JSObjects. I filed an RFE for that, but due to the issue, I'm having to >> avoid using JSObject entirely. >> >> Thanks again for your reply. >> >> -Daniel >> >> On Tue, May 30, 2017 at 12:29 PM Jesse Schulman >> wrote: >> >>> If you haven't got this working yet, one possible solution is to return >>> anonymous inner AbstractJSObject that returns true for isFunction calls: >>> >>> public Object getMember(String name) { >>> if ("map".equals(name)) { >>> return new AbstractJSObject() { >>> @Override >>> public Object call(Object thiz, Object... args) { >>> // delegate to your JsonArray.map method from this >>> annonymous inner class >>> // in your example nashorn should pass you a single >>> instance of ScriptObjectMirror for args that returns true for isFunction() >>> call >>> } >>> >>> @Override >>> public boolean isFunction() { >>> return true; >>> } >>> }; >>> } >>> >>> return null; >>> } >>> >>> >>> Hope that helps! >>> Jesse >>> >>> On Thu, May 25, 2017 at 1:11 PM Daniel Einspanjer >>> wrote: >>> >>>> I have a project that makes extensive use of the Google Gson library. >>>> >>>> In this particular case, I have a JsonArray object (which implements >>>> iterable) containing a collection of objects. In pure JSON it would >>>> look >>>> like this: >>>> >>>> [ 1, true, {"a": "b"}, [1,2] ] >>>> >>>> In Gson JsonElements, it looks like this: >>>> >>>> arr = new JsonArray(); >>>> arr.add(1); >>>> arr.add(true); >>>> >>>> obj = new JsonObject(); >>>> obj.addProperty("a", "b"); >>>> >>>> arr.add(obj); >>>> >>>> innerArr = new JsonArray(); >>>> innerArr.add(1); >>>> innerArr.add(2); >>>> >>>> arr.add(innerArr); >>>> >>>> I am calling a Javascript function in Nashorn that is trying to do a map >>>> over this array: >>>> >>>> nash.eval("function doIt(arr) { print(arr.map(function(item) { return >>>> (typeof item); })); }"); >>>> >>>> So, in order for this to work with my own arbitrary object (JsonArray), >>>> I >>>> believe I need to implement JSObject. >>>> >>>> I created the wrapper class that implements it, using the underlying >>>> JsonArray object as a delegate. things like isArray() and such are >>>> trivial, but I'm having trouble with the map. >>>> I have a map method that takes a functional interface which is available >>>> for the JsonArray object. >>>> >>>> Nashorn calls getMember("map") when the doIt function is executed. I >>>> cannot figure out how to give it an appropriate function reference to my >>>> JsonArray.map method. >>>> I was able to handle getMember("toString") easily enough, but the >>>> problem >>>> is that method doesn't take any arguments, so returning a simple >>>> Callable is fine for it, but map is going to take arguments >>>> that I >>>> don't know about ahead of time. >>>> >>>> I would really appreciate some assistance here. Thanks. >>>> >>>> -Daniel >>>> >>> From jesse at dreamtsoft.com Fri Jun 2 16:38:42 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Fri, 02 Jun 2017 16:38:42 +0000 Subject: How to properly implement JSObject to provide conversion of Gson JsonElement objects? In-Reply-To: References: Message-ID: That's the approach I took too, however I avoided the eval by doing bindings.get("Object").newObject() but you should be able to do the same thing against the engine if you don't use different bindings. On Thu, Jun 1, 2017 at 5:32 PM Daniel Einspanjer wrote: > Yes, that is the bug. > > My work around isn't great, I just had to avoid using any form of custom > JSObject. Instead, I do an eval('new Object()') to get a holder and put my > object and functions inside it via put(). > > -Daniel > > On Thu, Jun 1, 2017, 6:30 PM Jesse Schulman wrote: > >> Ironically, I'm hitting a similar issue with a library doing an >> Object.keys() call against a custom JSObject, can you share the solution >> you've taken? >> >> Also, I'm guessing this is the RFE you created: >> https://bugs.openjdk.java.net/browse/JDK-8181203?jql=text%20~%20%22Object.keys%20nashorn%22 >> >> Thanks! >> Jesse >> >> On Tue, May 30, 2017 at 9:34 AM Daniel Einspanjer >> wrote: >> >>> Thank you, yes that is very similar to the approach I went down. >>> Ultimately I hit another roadblock that forced me to approach the entire >>> issue differently. The JS library I am interacting with uses Object.keys() >>> and currently, Nashorn doesn't support Object.keys() calls with custom >>> JSObjects. I filed an RFE for that, but due to the issue, I'm having to >>> avoid using JSObject entirely. >>> >>> Thanks again for your reply. >>> >>> -Daniel >>> >>> On Tue, May 30, 2017 at 12:29 PM Jesse Schulman >>> wrote: >>> >>>> If you haven't got this working yet, one possible solution is to return >>>> anonymous inner AbstractJSObject that returns true for isFunction calls: >>>> >>>> public Object getMember(String name) { >>>> if ("map".equals(name)) { >>>> return new AbstractJSObject() { >>>> @Override >>>> public Object call(Object thiz, Object... args) { >>>> // delegate to your JsonArray.map method from this >>>> annonymous inner class >>>> // in your example nashorn should pass you a single >>>> instance of ScriptObjectMirror for args that returns true for isFunction() >>>> call >>>> } >>>> >>>> @Override >>>> public boolean isFunction() { >>>> return true; >>>> } >>>> }; >>>> } >>>> >>>> return null; >>>> } >>>> >>>> >>>> Hope that helps! >>>> Jesse >>>> >>>> On Thu, May 25, 2017 at 1:11 PM Daniel Einspanjer < >>>> deinspanjer at gmail.com> wrote: >>>> >>>>> I have a project that makes extensive use of the Google Gson library. >>>>> >>>>> In this particular case, I have a JsonArray object (which implements >>>>> iterable) containing a collection of objects. In pure JSON it would >>>>> look >>>>> like this: >>>>> >>>>> [ 1, true, {"a": "b"}, [1,2] ] >>>>> >>>>> In Gson JsonElements, it looks like this: >>>>> >>>>> arr = new JsonArray(); >>>>> arr.add(1); >>>>> arr.add(true); >>>>> >>>>> obj = new JsonObject(); >>>>> obj.addProperty("a", "b"); >>>>> >>>>> arr.add(obj); >>>>> >>>>> innerArr = new JsonArray(); >>>>> innerArr.add(1); >>>>> innerArr.add(2); >>>>> >>>>> arr.add(innerArr); >>>>> >>>>> I am calling a Javascript function in Nashorn that is trying to do a >>>>> map >>>>> over this array: >>>>> >>>>> nash.eval("function doIt(arr) { print(arr.map(function(item) { return >>>>> (typeof item); })); }"); >>>>> >>>>> So, in order for this to work with my own arbitrary object >>>>> (JsonArray), I >>>>> believe I need to implement JSObject. >>>>> >>>>> I created the wrapper class that implements it, using the underlying >>>>> JsonArray object as a delegate. things like isArray() and such are >>>>> trivial, but I'm having trouble with the map. >>>>> I have a map method that takes a functional interface which is >>>>> available >>>>> for the JsonArray object. >>>>> >>>>> Nashorn calls getMember("map") when the doIt function is executed. I >>>>> cannot figure out how to give it an appropriate function reference to >>>>> my >>>>> JsonArray.map method. >>>>> I was able to handle getMember("toString") easily enough, but the >>>>> problem >>>>> is that method doesn't take any arguments, so returning a simple >>>>> Callable is fine for it, but map is going to take arguments >>>>> that I >>>>> don't know about ahead of time. >>>>> >>>>> I would really appreciate some assistance here. Thanks. >>>>> >>>>> -Daniel >>>>> >>>> From deinspanjer at gmail.com Fri Jun 2 17:05:46 2017 From: deinspanjer at gmail.com (Daniel Einspanjer) Date: Fri, 02 Jun 2017 17:05:46 +0000 Subject: How to properly implement JSObject to provide conversion of Gson JsonElement objects? In-Reply-To: References: Message-ID: Thanks for the tip! On Fri, Jun 2, 2017, 12:38 PM Jesse Schulman wrote: > That's the approach I took too, however I avoided the eval by doing > bindings.get("Object").newObject() but you should be able to do the same > thing against the engine if you don't use different bindings. > > On Thu, Jun 1, 2017 at 5:32 PM Daniel Einspanjer > wrote: > >> Yes, that is the bug. >> >> My work around isn't great, I just had to avoid using any form of custom >> JSObject. Instead, I do an eval('new Object()') to get a holder and put my >> object and functions inside it via put(). >> >> -Daniel >> >> On Thu, Jun 1, 2017, 6:30 PM Jesse Schulman wrote: >> >>> Ironically, I'm hitting a similar issue with a library doing an >>> Object.keys() call against a custom JSObject, can you share the solution >>> you've taken? >>> >>> Also, I'm guessing this is the RFE you created: >>> https://bugs.openjdk.java.net/browse/JDK-8181203?jql=text%20~%20%22Object.keys%20nashorn%22 >>> >>> Thanks! >>> Jesse >>> >>> On Tue, May 30, 2017 at 9:34 AM Daniel Einspanjer >>> wrote: >>> >>>> Thank you, yes that is very similar to the approach I went down. >>>> Ultimately I hit another roadblock that forced me to approach the entire >>>> issue differently. The JS library I am interacting with uses Object.keys() >>>> and currently, Nashorn doesn't support Object.keys() calls with custom >>>> JSObjects. I filed an RFE for that, but due to the issue, I'm having to >>>> avoid using JSObject entirely. >>>> >>>> Thanks again for your reply. >>>> >>>> -Daniel >>>> >>>> On Tue, May 30, 2017 at 12:29 PM Jesse Schulman >>>> wrote: >>>> >>>>> If you haven't got this working yet, one possible solution is to >>>>> return anonymous inner AbstractJSObject that returns true for isFunction >>>>> calls: >>>>> >>>>> public Object getMember(String name) { >>>>> if ("map".equals(name)) { >>>>> return new AbstractJSObject() { >>>>> @Override >>>>> public Object call(Object thiz, Object... args) { >>>>> // delegate to your JsonArray.map method from this >>>>> annonymous inner class >>>>> // in your example nashorn should pass you a single >>>>> instance of ScriptObjectMirror for args that returns true for isFunction() >>>>> call >>>>> } >>>>> >>>>> @Override >>>>> public boolean isFunction() { >>>>> return true; >>>>> } >>>>> }; >>>>> } >>>>> >>>>> return null; >>>>> } >>>>> >>>>> >>>>> Hope that helps! >>>>> Jesse >>>>> >>>>> On Thu, May 25, 2017 at 1:11 PM Daniel Einspanjer < >>>>> deinspanjer at gmail.com> wrote: >>>>> >>>>>> I have a project that makes extensive use of the Google Gson library. >>>>>> >>>>>> In this particular case, I have a JsonArray object (which implements >>>>>> iterable) containing a collection of objects. In pure JSON it would >>>>>> look >>>>>> like this: >>>>>> >>>>>> [ 1, true, {"a": "b"}, [1,2] ] >>>>>> >>>>>> In Gson JsonElements, it looks like this: >>>>>> >>>>>> arr = new JsonArray(); >>>>>> arr.add(1); >>>>>> arr.add(true); >>>>>> >>>>>> obj = new JsonObject(); >>>>>> obj.addProperty("a", "b"); >>>>>> >>>>>> arr.add(obj); >>>>>> >>>>>> innerArr = new JsonArray(); >>>>>> innerArr.add(1); >>>>>> innerArr.add(2); >>>>>> >>>>>> arr.add(innerArr); >>>>>> >>>>>> I am calling a Javascript function in Nashorn that is trying to do a >>>>>> map >>>>>> over this array: >>>>>> >>>>>> nash.eval("function doIt(arr) { print(arr.map(function(item) { return >>>>>> (typeof item); })); }"); >>>>>> >>>>>> So, in order for this to work with my own arbitrary object >>>>>> (JsonArray), I >>>>>> believe I need to implement JSObject. >>>>>> >>>>>> I created the wrapper class that implements it, using the underlying >>>>>> JsonArray object as a delegate. things like isArray() and such are >>>>>> trivial, but I'm having trouble with the map. >>>>>> I have a map method that takes a functional interface which is >>>>>> available >>>>>> for the JsonArray object. >>>>>> >>>>>> Nashorn calls getMember("map") when the doIt function is executed. I >>>>>> cannot figure out how to give it an appropriate function reference to >>>>>> my >>>>>> JsonArray.map method. >>>>>> I was able to handle getMember("toString") easily enough, but the >>>>>> problem >>>>>> is that method doesn't take any arguments, so returning a simple >>>>>> Callable is fine for it, but map is going to take arguments >>>>>> that I >>>>>> don't know about ahead of time. >>>>>> >>>>>> I would really appreciate some assistance here. Thanks. >>>>>> >>>>>> -Daniel >>>>>> >>>>> From hannes.wallnoefer at oracle.com Tue Jun 13 15:51:32 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 13 Jun 2017 17:51:32 +0200 Subject: RFR (10): JDK-8181191: getUint32 returning Long Message-ID: <4FEBF39E-2B92-47DB-9C42-4B5788230993@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8181191 Webrev: http://cr.openjdk.java.net/~hannesw/8181191/webrev/ Thanks, Hannes From szegedia at gmail.com Tue Jun 13 16:17:07 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 13 Jun 2017 18:17:07 +0200 Subject: RFR (10): JDK-8181191: getUint32 returning Long In-Reply-To: <4FEBF39E-2B92-47DB-9C42-4B5788230993@oracle.com> References: <4FEBF39E-2B92-47DB-9C42-4B5788230993@oracle.com> Message-ID: <63AC75E0-F5BB-4E0B-AB5D-045FFFE0A5D9@gmail.com> +1 the test described in the issue was failing because we treated Long objects as JS objects, right? Attila. > On 13 Jun 2017, at 17:51, Hannes Walln?fer wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181191 > Webrev: http://cr.openjdk.java.net/~hannesw/8181191/webrev/ > > Thanks, > Hannes From james.laskey at oracle.com Tue Jun 13 16:17:39 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 13 Jun 2017 13:17:39 -0300 Subject: RFR (10): JDK-8181191: getUint32 returning Long In-Reply-To: <4FEBF39E-2B92-47DB-9C42-4B5788230993@oracle.com> References: <4FEBF39E-2B92-47DB-9C42-4B5788230993@oracle.com> Message-ID: <1E341E45-8212-4ADF-B08D-7F45F76498B8@oracle.com> +1 > On Jun 13, 2017, at 12:51 PM, Hannes Walln?fer wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181191 > Webrev: http://cr.openjdk.java.net/~hannesw/8181191/webrev/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Tue Jun 13 16:28:58 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 13 Jun 2017 18:28:58 +0200 Subject: RFR (10): JDK-8181191: getUint32 returning Long In-Reply-To: <63AC75E0-F5BB-4E0B-AB5D-045FFFE0A5D9@gmail.com> References: <4FEBF39E-2B92-47DB-9C42-4B5788230993@oracle.com> <63AC75E0-F5BB-4E0B-AB5D-045FFFE0A5D9@gmail.com> Message-ID: <124BFC78-108D-4C6A-961B-ED560EF80D9A@oracle.com> > Am 13.06.2017 um 18:17 schrieb Attila Szegedi : > > the test described in the issue was failing because we treated Long objects as JS objects, right? > Yes. 127 compared equal to itself because Long instances between -128 and 127 are cached, 128 is just outside that range. Thanks for the review! Hannes > Attila. > >> On 13 Jun 2017, at 17:51, Hannes Walln?fer wrote: >> >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8181191 >> Webrev: http://cr.openjdk.java.net/~hannesw/8181191/webrev/ >> >> Thanks, >> Hannes > From andrey.x.nazarov at oracle.com Thu Jun 22 01:13:24 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 21 Jun 2017 18:13:24 -0700 Subject: RFR: 8181105: Nashorn file descriptor leaks Message-ID: <0187A1A8-2E52-4DB0-92BF-5C2BEA68CB2E@oracle.com> Hi, Please review fix for 8181105 Webrev: http://cr.openjdk.java.net/~anazarov/JDK-8181105/webrev.00/webrev/ JBS: https://bugs.openjdk.java.net/browse/JDK-8181105 ?Andrei From sundararajan.athijegannathan at oracle.com Thu Jun 22 03:13:49 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 22 Jun 2017 08:43:49 +0530 Subject: RFR: 8181105: Nashorn file descriptor leaks In-Reply-To: <0187A1A8-2E52-4DB0-92BF-5C2BEA68CB2E@oracle.com> References: <0187A1A8-2E52-4DB0-92BF-5C2BEA68CB2E@oracle.com> Message-ID: <594B35ED.1020704@oracle.com> Looks good! PS. I think this fix is a backport candidate. -Sundar On 22/06/17, 6:43 AM, Andrey Nazarov wrote: > Hi, > > Please review fix for 8181105 > Webrev: http://cr.openjdk.java.net/~anazarov/JDK-8181105/webrev.00/webrev/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8181105 > > > ?Andrei From hannes.wallnoefer at oracle.com Thu Jun 22 09:00:20 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 22 Jun 2017 11:00:20 +0200 Subject: RFR: 8181105: Nashorn file descriptor leaks In-Reply-To: <594B35ED.1020704@oracle.com> References: <0187A1A8-2E52-4DB0-92BF-5C2BEA68CB2E@oracle.com> <594B35ED.1020704@oracle.com> Message-ID: <38E1C0DE-4CA1-4D89-9074-B0B82E1E72AE@oracle.com> +1 Hannes > Am 22.06.2017 um 05:13 schrieb Sundararajan Athijegannathan : > > Looks good! > > PS. I think this fix is a backport candidate. > > -Sundar > > On 22/06/17, 6:43 AM, Andrey Nazarov wrote: >> Hi, >> >> Please review fix for 8181105 >> Webrev: http://cr.openjdk.java.net/~anazarov/JDK-8181105/webrev.00/webrev/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8181105 >> >> >> ?Andrei From james.laskey at oracle.com Thu Jun 22 12:08:07 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 22 Jun 2017 09:08:07 -0300 Subject: RFR: 8181105: Nashorn file descriptor leaks In-Reply-To: <0187A1A8-2E52-4DB0-92BF-5C2BEA68CB2E@oracle.com> References: <0187A1A8-2E52-4DB0-92BF-5C2BEA68CB2E@oracle.com> Message-ID: +1 > On Jun 21, 2017, at 10:13 PM, Andrey Nazarov wrote: > > Hi, > > Please review fix for 8181105 > Webrev: http://cr.openjdk.java.net/~anazarov/JDK-8181105/webrev.00/webrev/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8181105 > > > ?Andrei From jesse at dreamtsoft.com Mon Jun 26 22:23:56 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Mon, 26 Jun 2017 22:23:56 +0000 Subject: Issue with cached/compiled function signatures Message-ID: In our application we expose some of our java classes to javascript via the JSObject interface, one of which provides a commons-js type require function. We also use Class from prototypejs and most of the javascript that is returned from require calls is returning a "Class" that is created by Class.create() from prototypejs. We recently started having an issue when a certain code pattern is hit where it seems that an incorrect signature is cached for the klass function that is part of the constructor functionality of Class.create, we found that accessing arguments within the klass function seems to prevent that caching, but this seems to be a workaround for what feels like a bigger issue. We have reproduced this outside our application and pushed to a github repo https://github.com/jesseschulman/nashorn_issue, along with some debugging notes in the readme. Note that this repo represents our code path that caused the issue, but it seems the same issue happens with other code paths, such as not involving SubClass.js and only calling SuperClass.js (as noted in comments). In Class.js there are two fixes commented out starting at line 33, they both workaround/resolve our issue but seem to produce slightly different invoker signatures for the MethodHandle as noted in the comments. Please let me know if there are any questions or if there is more information that we can provide to help with this. Thanks! Jesse From hannes.wallnoefer at oracle.com Tue Jun 27 12:12:48 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 27 Jun 2017 14:12:48 +0200 Subject: Issue with cached/compiled function signatures In-Reply-To: References: Message-ID: <4852443A-8C19-40B7-AF1A-2ADE2EA6724C@oracle.com> Hi Jesse, Thanks for the detailed report and reproducer. I?m looking into the issue and will let you know when I find out more. Hannes > Am 27.06.2017 um 00:23 schrieb Jesse Schulman : > > In our application we expose some of our java classes to javascript via the > JSObject interface, one of which provides a commons-js type require > function. We also use Class from prototypejs and most of the javascript > that is returned from require calls is returning a "Class" that is created > by Class.create() from prototypejs. > > We recently started having an issue when a certain code pattern is hit > where it seems that an incorrect signature is cached for the klass function > that is part of the constructor functionality of Class.create, we found > that accessing arguments within the klass function seems to prevent that > caching, but this seems to be a workaround for what feels like a bigger > issue. > > We have reproduced this outside our application and pushed to a github repo > https://github.com/jesseschulman/nashorn_issue, along with some debugging > notes in the readme. > > Note that this repo represents our code path that caused the issue, but it > seems the same issue happens with other code paths, such as not involving > SubClass.js and only calling SuperClass.js (as noted in comments). > > In Class.js there are two fixes commented out starting at line 33, they > both workaround/resolve our issue but seem to produce slightly different > invoker signatures for the MethodHandle as noted in the comments. > > Please let me know if there are any questions or if there is more > information that we can provide to help with this. > > Thanks! > Jesse From hannes.wallnoefer at oracle.com Wed Jun 28 13:34:21 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 28 Jun 2017 15:34:21 +0200 Subject: RFR: 8182996: Incorrect mapping Long type to JavaScript equivalent Message-ID: Please review 8182996: Incorrect mapping Long type to JavaScript equivalent: Bug: https://bugs.openjdk.java.net/browse/JDK-8182996 Webrev: http://cr.openjdk.java.net/~hannesw/8182996/webrev/ Thanks, Hannes From james.laskey at oracle.com Wed Jun 28 13:49:12 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 28 Jun 2017 10:49:12 -0300 Subject: RFR: 8182996: Incorrect mapping Long type to JavaScript equivalent In-Reply-To: References: Message-ID: +1 > On Jun 28, 2017, at 10:34 AM, Hannes Walln?fer wrote: > > Please review 8182996: Incorrect mapping Long type to JavaScript equivalent: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8182996 > Webrev: http://cr.openjdk.java.net/~hannesw/8182996/webrev/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Thu Jun 29 01:58:51 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 29 Jun 2017 07:28:51 +0530 Subject: RFR: 8182996: Incorrect mapping Long type to JavaScript equivalent In-Reply-To: References: Message-ID: <59545EDB.3020707@oracle.com> +1 -Sundar On 28/06/17, 7:04 PM, Hannes Walln?fer wrote: > Please review 8182996: Incorrect mapping Long type to JavaScript equivalent: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8182996 > Webrev: http://cr.openjdk.java.net/~hannesw/8182996/webrev/ > > Thanks, > Hannes