From sundararajan.athijegannathan at oracle.com Mon Feb 1 00:19:43 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 1 Feb 2016 05:49:43 +0530 Subject: Getting the AST ? In-Reply-To: <6A8537D9-B1B7-45C4-BAB6-4D11814B8EF7@gmail.com> References: <5B6BEDB6-9658-4A31-B82E-68579BD5DFDF@pobox.com> <6A8537D9-B1B7-45C4-BAB6-4D11814B8EF7@gmail.com> Message-ID: <56AEA49F.1090308@oracle.com> Hi, jdk9 samples for Nashorn Parser API (http://openjdk.java.net/jeps/236) that Attila mentioned are: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/evalcheck.js http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/findproto.js http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/findwith.js http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/flexijson.js http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/nashornastviewer.js http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/prettyprinter.js http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/withcheck.js https://blogs.oracle.com/nashorn/entry/flexible_json_with_nashorn_parser For jdk8u, it is better to avoid nashorn internal classes. There is a JS "parse" API. You can load("nashorn:parser.js") and use "parse" function defined in it. http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/parser.js http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/astviewer.js Hope this helps, -Sundar On 1/31/2016 3:48 PM, Attila Szegedi wrote: > If you don?t mind using a prerelease JDE, JDK9 version of Nashorn has a public JavaScript parser API: > > In the JDK8 world, there?s no supported way, but you can try using jdk.nashorn.internal.parser.Parser at your own risk (of it changing in an incompatible way, or going away entirely, or becoming inaccessible in JDK9). It returns a jdk.nashorn.internal.ir.FunctionNode, an internal Nashorn AST class that represents both functions and the top-level program. All of the AST is in the jdk.nashorn.internal.ir package. It was never meant for public consumption, so it?s not as nice to work with as the JDK9 public API, e.g. there are some dubious choices in the class hierarchy etc. that you?ll need to live with. > > HTH, > Attila. > >> On Jan 30, 2016, at 5:19 PM, Geir Magnusson Jr. wrote: >> >> Hi, >> >> I?m a complete newbie to this area, so please forgive the lack of proper terminology in advance. >> >> I need to be able to transform arbitrary JS and thought that getting and transforming the AST would be a good way to do it. I was looking at things like the Shape library and it felt ? lacking, somehow. >> >> I figure nashorn is going to be better :) >> >> Is there any way (I?m ok if it isn?t portable) to use the JDK internals to do this? >> >> Thanks in advance. >> >> geir >> From rmaggi at expedia.com Mon Feb 1 09:40:18 2016 From: rmaggi at expedia.com (Riccardo Maggi) Date: Mon, 1 Feb 2016 09:40:18 +0000 Subject: meatspace memory OOME using Nashorn and Callable In-Reply-To: References: Message-ID: Hi Benjamin, Thanks for your answer. At the end we were able to reduce the number of LambdaForms generated each run of the js script. It seems that the root cause was related with a recursive function that was using a big JSON object. We suspect that the generation of new Lambda was related to the fact that the recursive function was invoked with different argument types (objects and arrays) each recursion. Do you think that a js fuction invoked with different argument types can lead to a relinking in the call site? Thanks, Riccardo. -- Riccardo Maggi Manager, Software Development Hotels.com - An Expedia Inc. Company From: Benjamin Sieffert > Date: mercoled? 27 gennaio 2016 11:36 To: Riccardo Maggi > Cc: "nashorn-dev at openjdk.java.net" > Subject: Re: meatspace memory OOME using Nashorn and Callable Hi Riccardo, I once ran into a similar issue. From what you have written, I'm not quite sure if yours is exactly the same, but anyway it might help. Here's the link. http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-November/003872.html In short: If a callsite in your JS code has more than 8 different receivers (e.g. different subclasses of Callable), the callsite will often relink, which generates new classes (LambdaForms, I guess) that eventually have to be collected. Now it's not clear to me whether you might actually have such a callsite or not, but this behaviour is something to keep in mind regarding MetaSpace consumption, when working with nashorn. Hope this helps a bit, Benjamin On 26 January 2016 at 11:58, Riccardo Maggi > wrote: Hi, We are testing Nashorn usage and we have a big issue on metaspace usage. We can't figure out why metaspace show a sawtooth that correspond to a grow and a consequent GC when its limit is reached, suggesting a class loader leak is somewhere. The metaspace patter was 1:1 with number of classes like many compilation were needed. The problem seems to be around a loop where we add callable tasks to a thread pool to be executed and how to pass parameters to the js function that represent the task logic. We found a solution for the high number of compiled classes using a code like: var tasks = arrayForTask.map(function(dataForTask, i) { return new Callable({ call: function () { print("task A " + i); } }); }); So now classes do now grow as before but the metaspace always grows... I can't find any source that clearly explain where the compiled js functions are stored (lambda form) into memory, I can understand that compilation is needed when nashorn think the js function body changed, like for references to different globals and so on. So in the end should I always expect a metaspace grow controlled by the GC?? even if the code has no leak? that seems to be kind of reasonable cause the JIT compilation is needed for a dynamic language that has no defined "class" structure but I can't understand if GC should be the only limit to my OOME or if a leak is somewhere... Thanks, Riccardo. -- Riccardo Maggi Manager, Software Development Hotels.com - An Expedia Inc. Company Venere Net S.r.l. con socio unico Via della Camilluccia 693, Roma, Italia Soggetta a direzione e coordinamento di Hotels.com LP Capitale 1.120.600 (i. v.) Sociale Codice Fiscale e P.IVA 05649781001 REA di Roma 910870 -- Benjamin Sieffert metrigo GmbH Lagerstra?e 36 20357 Hamburg Gesch?ftsf?hrer: Tobias Schlottke, Philipp Erler Die Gesellschaft ist eingetragen beim Registergericht Hamburg HRB 120447 Venere Net S.r.l. con socio unico Via della Camilluccia 693, Roma, Italia Soggetta a direzione e coordinamento di Hotels.com LP Capitale 1.120.600 (i. v.) Sociale Codice Fiscale e P.IVA 05649781001 REA di Roma 910870 From geir at pobox.com Mon Feb 1 10:34:37 2016 From: geir at pobox.com (Geir Magnusson Jr.) Date: Mon, 1 Feb 2016 05:34:37 -0500 Subject: Getting the AST ? In-Reply-To: <56AEA49F.1090308@oracle.com> References: <5B6BEDB6-9658-4A31-B82E-68579BD5DFDF@pobox.com> <6A8537D9-B1B7-45C4-BAB6-4D11814B8EF7@gmail.com> <56AEA49F.1090308@oracle.com> Message-ID: Thank you both for the help. Are there any examples in working in Java for either 8 or 9? I don?t have a ton of interested in actually *working* in javascript. > On Jan 31, 2016, at 7:19 PM, Sundararajan Athijegannathan wrote: > > Hi, > > jdk9 samples for Nashorn Parser API (http://openjdk.java.net/jeps/236) that Attila mentioned are: > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/evalcheck.js > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/findproto.js > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/findwith.js > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/flexijson.js > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/nashornastviewer.js > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/prettyprinter.js > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/withcheck.js > https://blogs.oracle.com/nashorn/entry/flexible_json_with_nashorn_parser > > For jdk8u, it is better to avoid nashorn internal classes. There is a JS "parse" API. You can load("nashorn:parser.js") and use "parse" function defined in it. > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/parser.js > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/astviewer.js > > Hope this helps, > -Sundar > > On 1/31/2016 3:48 PM, Attila Szegedi wrote: >> If you don?t mind using a prerelease JDE, JDK9 version of Nashorn has a public JavaScript parser API: >> >> In the JDK8 world, there?s no supported way, but you can try using jdk.nashorn.internal.parser.Parser at your own risk (of it changing in an incompatible way, or going away entirely, or becoming inaccessible in JDK9). It returns a jdk.nashorn.internal.ir.FunctionNode, an internal Nashorn AST class that represents both functions and the top-level program. All of the AST is in the jdk.nashorn.internal.ir package. It was never meant for public consumption, so it?s not as nice to work with as the JDK9 public API, e.g. there are some dubious choices in the class hierarchy etc. that you?ll need to live with. >> >> HTH, >> Attila. >> >>> On Jan 30, 2016, at 5:19 PM, Geir Magnusson Jr. wrote: >>> >>> Hi, >>> >>> I?m a complete newbie to this area, so please forgive the lack of proper terminology in advance. >>> >>> I need to be able to transform arbitrary JS and thought that getting and transforming the AST would be a good way to do it. I was looking at things like the Shape library and it felt ? lacking, somehow. >>> >>> I figure nashorn is going to be better :) >>> >>> Is there any way (I?m ok if it isn?t portable) to use the JDK internals to do this? >>> >>> Thanks in advance. >>> >>> geir >>> > From hc.handelsbanken at gmail.com Mon Feb 1 14:22:22 2016 From: hc.handelsbanken at gmail.com (Hakan Carlsson) Date: Mon, 1 Feb 2016 15:22:22 +0100 Subject: Problem with myIpAddress() in PAC-file environment Message-ID: Hi List, After upgrading to java8, we experienced some problem regarding use of PAC file for the java applications, i.e having the proxy config using e PAC-file. >From what I can see, the function myIpAddress() is calling the CrossDomainXML class to try to get a crossdomain.xml file. This will in our case make the myIpAddress() function recursivly call FindProxyForURL(url, host) and things starts going wrong... Stacktrace: at jdk.nashorn.internal.scripts.Script$Recompilation$520$22701AA$\^eval\_.FindProxyForURLCommon(:155)^M at *jdk.nashorn.internal.scripts.Script$Recompilation$519$24436AA$\^eval\_.FindProxyForURL(:155)^M* at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:640)^M at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)^M at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)^M at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:192)^M at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:381)^M at jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:187)^M at com.sun.deploy.net.proxy.SunAutoProxyHandler.jsGetProxyInfo(Unknown Source)^M at com.sun.deploy.net.proxy.SunAutoProxyHandler.access$100(Unknown Source)^M at com.sun.deploy.net.proxy.SunAutoProxyHandler$2.run(Unknown Source)^M at com.sun.deploy.net.proxy.SunAutoProxyHandler$2.run(Unknown Source)^M at java.security.AccessController.doPrivileged(Native Method)^M at com.sun.deploy.net.proxy.SunAutoProxyHandler.jsGetProxyInfo(Unknown Source)^M at com.sun.deploy.net.proxy.SunAutoProxyHandler.getProxyInfo(Unknown Source)^M at com.sun.deploy.net.proxy.DynamicProxyManager.getProxyList(Unknown Source)^M at com.sun.deploy.net.proxy.DeployProxySelector.select(Unknown Source)^M at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Source)^M at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source)^M at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source)^M at java.security.AccessController.doPrivileged(Native Method)^M at java.security.AccessController.doPrivileged(Unknown Source)^M at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)^M at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)^M at com.sun.deploy.net.CrossDomainXML$3.run(Unknown Source)^M at java.security.AccessController.doPrivileged(Native Method)^M at com.sun.deploy.net.CrossDomainXML.privilegedConnect(Unknown Source)^M at com.sun.deploy.net.CrossDomainXML.check(Unknown Source)^M at *com.sun.deploy.net.CrossDomainXML.check(Unknown Source)^M* at com.sun.javaws.security.JavaWebStartSecurity.checkConnectHelper(Unknown Source)^M at com.sun.javaws.security.JavaWebStartSecurity.checkConnect(Unknown Source)^M at java.net.InetAddress.getLocalHost(Unknown Source)^M at *com.sun.deploy.net.proxy.pac.PACFunctionsImpl.myIpAddress*(Unknown Source)^M at com.sun.deploy.net.proxy.SunAutoProxyHandler$5.get(Unknown Source)^M at com.sun.deploy.net.proxy.SunAutoProxyHandler$5.get(Unknown Source)^M at jdk.nashorn.internal.scripts.Script$Recompilation$517$22701AA$\^eval\_.FindProxyForURLCommon(:155)^M at jdk.nashorn.internal.scripts.Script$Recompilation$516$24436AA$\^eval\_.FindProxyForURL(:155)^M at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:640)^M at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)^M Any idea how to avoid the recursion? we really need to get the IP of the client with myIpAddress() /Hakan From sundararajan.athijegannathan at oracle.com Tue Feb 2 03:13:23 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 2 Feb 2016 08:43:23 +0530 Subject: Getting the AST ? In-Reply-To: References: <5B6BEDB6-9658-4A31-B82E-68579BD5DFDF@pobox.com> <6A8537D9-B1B7-45C4-BAB6-4D11814B8EF7@gmail.com> <56AEA49F.1090308@oracle.com> Message-ID: <56B01ED3.5060306@oracle.com> Hmm... I can't find any Java samples (although all scripts access Java API ;) ) though. But, if you want to look at the generated tree for various cases, you can look at this: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/test/script/nosecurity/treeapi Thanks, -Sundar On 2/1/2016 4:04 PM, Geir Magnusson Jr. wrote: > Thank you both for the help. > > Are there any examples in working in Java for either 8 or 9? I don?t have a ton of interested in actually *working* in javascript. > > >> On Jan 31, 2016, at 7:19 PM, Sundararajan Athijegannathan wrote: >> >> Hi, >> >> jdk9 samples for Nashorn Parser API (http://openjdk.java.net/jeps/236) that Attila mentioned are: >> >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/evalcheck.js >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/findproto.js >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/findwith.js >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/flexijson.js >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/nashornastviewer.js >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/prettyprinter.js >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/withcheck.js >> https://blogs.oracle.com/nashorn/entry/flexible_json_with_nashorn_parser >> >> For jdk8u, it is better to avoid nashorn internal classes. There is a JS "parse" API. You can load("nashorn:parser.js") and use "parse" function defined in it. >> >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/parser.js >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/a618d3e89fde/samples/astviewer.js >> >> Hope this helps, >> -Sundar >> >> On 1/31/2016 3:48 PM, Attila Szegedi wrote: >>> If you don?t mind using a prerelease JDE, JDK9 version of Nashorn has a public JavaScript parser API: >>> >>> In the JDK8 world, there?s no supported way, but you can try using jdk.nashorn.internal.parser.Parser at your own risk (of it changing in an incompatible way, or going away entirely, or becoming inaccessible in JDK9). It returns a jdk.nashorn.internal.ir.FunctionNode, an internal Nashorn AST class that represents both functions and the top-level program. All of the AST is in the jdk.nashorn.internal.ir package. It was never meant for public consumption, so it?s not as nice to work with as the JDK9 public API, e.g. there are some dubious choices in the class hierarchy etc. that you?ll need to live with. >>> >>> HTH, >>> Attila. >>> >>>> On Jan 30, 2016, at 5:19 PM, Geir Magnusson Jr. wrote: >>>> >>>> Hi, >>>> >>>> I?m a complete newbie to this area, so please forgive the lack of proper terminology in advance. >>>> >>>> I need to be able to transform arbitrary JS and thought that getting and transforming the AST would be a good way to do it. I was looking at things like the Shape library and it felt ? lacking, somehow. >>>> >>>> I figure nashorn is going to be better :) >>>> >>>> Is there any way (I?m ok if it isn?t portable) to use the JDK internals to do this? >>>> >>>> Thanks in advance. >>>> >>>> geir >>>> From sundararajan.athijegannathan at oracle.com Thu Feb 4 11:55:29 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 4 Feb 2016 17:25:29 +0530 Subject: RFR 8148926: Call site profiling fails on braces-wrapped anonymous function Message-ID: <56B33C31.1050306@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8148926/ for https://bugs.openjdk.java.net/browse/JDK-8148926 Thanks, -Sundar From christoph.sauer at nuveon.de Thu Feb 4 06:18:18 2016 From: christoph.sauer at nuveon.de (Christoph Sauer) Date: Thu, 4 Feb 2016 07:18:18 +0100 Subject: bug-report-can-t-call-static-methods-on-a-java-class-instance Message-ID: <56B2ED2A.6090201@nuveon.de> Dear Attila, i was just evaluating a switch of our huge codebase written in Javascript using the Rhino interpreter to Nashorn. We have utility classes written in Java that are are passed as objects to help users write less code in JS, because that is why we use JS in the first place. Those utility objects also contain frequently used static methods. Your design decisions will make it impossible for us to switch. Not only will we have to rewrite our code, we also will have to make separate calls to "handles" the user already has. This is against my design decision to pursue the ideal of "literate programming". The ideal to make code more readable is broken here. I agree with Tal Liron that if a programmer wants to use Java, they would. We use Javascript because of the shorthand and the goal towards cleaner code without loosing the power of using Java where need be. I felt offended to be called a "Creature". I hope I misinterpret you sentence here . Two years have passed since this post. Have you changed your mind since? Will there be at least a "strict" switch like suggested by tal? Thanks Christoph From hannes.wallnoefer at oracle.com Thu Feb 4 12:10:03 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 4 Feb 2016 13:10:03 +0100 Subject: RFR 8148926: Call site profiling fails on braces-wrapped anonymous function In-Reply-To: <56B33C31.1050306@oracle.com> References: <56B33C31.1050306@oracle.com> Message-ID: <56B33F9B.3050700@oracle.com> +1 Am 2016-02-04 um 12:55 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8148926/ for > https://bugs.openjdk.java.net/browse/JDK-8148926 > > Thanks, > -Sundar From james.laskey at oracle.com Thu Feb 4 12:17:52 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 4 Feb 2016 08:17:52 -0400 Subject: RFR 8148926: Call site profiling fails on braces-wrapped anonymous function In-Reply-To: <56B33C31.1050306@oracle.com> References: <56B33C31.1050306@oracle.com> Message-ID: <52F8510F-016A-417C-AA6C-6BA22454BECE@oracle.com> +1 > On Feb 4, 2016, at 7:55 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8148926/ for https://bugs.openjdk.java.net/browse/JDK-8148926 > > Thanks, > -Sundar From marcus at lagergren.net Thu Feb 4 12:25:48 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Thu, 4 Feb 2016 13:25:48 +0100 Subject: Review request for backport of JDK-8144020: Remove long as an internal numeric type In-Reply-To: <569F8732.8080604@oracle.com> References: <569F8732.8080604@oracle.com> Message-ID: <9AA2CF1C-0A56-443B-BE72-F8832E0F9F44@lagergren.net> +1 > On 20 Jan 2016, at 14:10, Hannes Wallnoefer wrote: > > Please review backport to 8u-dev of JDK-8144020: Remove long as an internal numeric type: > > http://cr.openjdk.java.net/~hannesw/8144020/webrev-8u/ > > There was some manual merging necessary in the following files: > > src/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java > src/jdk/nashorn/internal/codegen/SpillObjectCreator.java > src/jdk/nashorn/internal/ir/debug/NashornTextifier.java > src/jdk/nashorn/internal/objects/NativeArray.java > src/jdk/nashorn/internal/parser/Lexer.java > src/jdk/nashorn/internal/runtime/JSType.java > src/jdk/nashorn/internal/runtime/OptimisticReturnFilters.java > src/jdk/nashorn/internal/runtime/ScriptObject.java > src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java > > I chose to omit the changes to ir/debug/NashornTextifier.java and runtime/linker/NashornCallSiteDescriptor.java (cleaning up bytecode printing) as it is not an essential part of this patch and would have required more changes in NashornTextifier.java. > > Thanks > Hannes From marcus at lagergren.net Thu Feb 4 12:27:03 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Thu, 4 Feb 2016 13:27:03 +0100 Subject: Review request for backport of JDK-8146274: Thread spinning on WeakHashMap.getEntry() with concurrent use of nashorn In-Reply-To: <56A8BB61.5050000@oracle.com> References: <56A8BB61.5050000@oracle.com> Message-ID: <16404046-39D4-4318-9245-43114CFB9FD8@lagergren.net> +1 > On 27 Jan 2016, at 13:43, Hannes Wallnoefer wrote: > > Please review backport of JDK-8146274. > > Webrev: http://cr.openjdk.java.net/~hannesw/8146274/webrev-8u/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8146274 > > The patch needed a small change because the key type of the listeners map changed. Also, the original patch included jjs documentation, which is not available in 8u. > > Thanks, > Hannes From marcus at lagergren.net Thu Feb 4 12:27:53 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Thu, 4 Feb 2016 13:27:53 +0100 Subject: RFR 8148926: Call site profiling fails on braces-wrapped anonymous function In-Reply-To: <56B33C31.1050306@oracle.com> References: <56B33C31.1050306@oracle.com> Message-ID: +1 > On 04 Feb 2016, at 12:55, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8148926/ for https://bugs.openjdk.java.net/browse/JDK-8148926 > > Thanks, > -Sundar From szegedia at gmail.com Thu Feb 4 17:26:09 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 4 Feb 2016 18:26:09 +0100 Subject: bug-report-can-t-call-static-methods-on-a-java-class-instance In-Reply-To: <56B2ED2A.6090201@nuveon.de> References: <56B2ED2A.6090201@nuveon.de> Message-ID: <49A6ADE5-2101-4B10-AF1F-19A4C7982D84@gmail.com> Hi Cristoph, I presume you?re referring to this post: >. I still stand by the design decisions we made when mapping the Java class/object system to JavaScript in Nashorn. I understand the differing opinions (yours and Tal?s both), and don?t consider them wrong, just having different requirement priorities. Have you considered that for a large established system, you might not want to change the underlying JavaScript engine? Rhino is yet again in active development, so a hopefully easier way to modernize your system would be to switch from JDK-embedded JavaScript runtime to Rhino as an external library. Ideally you?d just need to touch your script engine factory instantiation code. Even if you decide to switch to Nashorn, a hopefully smaller change would be to change the methods in your utility classes from being static to being instance methods. That would even keep the change cross-compatible with Rhino. (Of course, this doesn?t help you if you have some external dependencies where you can?t change the methods from static to instance?) In terms of future advice, there?s one other approach you might take, although unfortunately it won?t be available for JDK 8, just for JDK 9. Namely, in JDK 9 Nashorn can be extended with additional linkers (see e.g. Sundar?s recent post that uses extra linkers to bridge JS to Python https://blogs.oracle.com/sundararajan/entry/nashorn_javascript_access_to_python ). It would be possible to write an additional Dynalink linker that recognizes missing members on POJOs and attempts to look up static methods instead. I know this doesn't help you now, but thought it might be worth mentioning it for completeness so it might help someone who digs this message out of an archive a year from now. As for ?creature? ? yes, you were misinterpreting it :-). ?A different kind of creature? here could be synonymous with ?a different cup of tea?, or ?another case?. I use the word as synonymous with ?being? (?something created?) without any intended negative overtones. I built fairly complex systems on top of Rhino in the past myself, and for a while both contributed to Rhino and served as the project?s administrator. I certainly have neither the moral ground nor the desire to diss Rhino or its users. Attila. > On Feb 4, 2016, at 7:18 AM, Christoph Sauer wrote: > > Dear Attila, > > i was just evaluating a switch of our huge codebase written in > Javascript using the Rhino interpreter to Nashorn. We have utility > classes written in Java that are are passed as objects to help users > write less code in JS, because that is why we use JS > in the first place. Those utility objects also contain frequently used > static methods. Your design decisions will make it impossible for us to > switch. > > Not only will we have to rewrite our code, we also will have to make > separate calls to "handles" the user already has. This is against my > design decision to pursue the ideal of "literate programming". The ideal > to make code more readable is broken here. I agree with Tal Liron > that if a programmer wants to use Java, they would. We use Javascript > because of the shorthand and the goal towards cleaner code > without loosing the power of using Java where need be. > > I felt offended to be called a "Creature". I hope I misinterpret you > sentence here . > Two years have passed since this post. Have you changed your mind since? > Will there be at least a "strict" switch like suggested by tal? > > Thanks > Christoph From hannesw at gmail.com Fri Feb 5 10:17:56 2016 From: hannesw at gmail.com (=?UTF-8?Q?Hannes_Walln=c3=b6fer?=) Date: Fri, 5 Feb 2016 11:17:56 +0100 Subject: Review request for JDK-8147558: Add support for ES6 collections Message-ID: <56B476D4.8070708@gmail.com> Please review JDK-8147558: Add support for ES6 collections: http://cr.openjdk.java.net/~hannesw/8147558/ The patch is rather large so here are a few things to point out: - The Map and Set collections use a custom linked map implementation (objects/LinkedMap) instead of using a standard Java collection such as java.util.LinkedHashMap. The reason is that the forEach method in those objects allows arbitrary modifications to the base collection during iteration by the callback function. The way this is done is that additions and deletions are reflected in visited nodes except for deletion of elements that have already been visited. See the note in http://www.ecma-international.org/ecma-262/6.0/#sec-map.prototype.foreach LinkedMap is implemented as a linked list that uses a HashMap for hashing (or, in other words, a HashMap with linked-list nodes as values). While the hash map methods are synchronized, iteration does not use any locking. I think it is safe for concurrent use, but please do have a look. - There are now a IS_ACCESSOR_PROPERTY flag and a isAccessorProperty() in runtime/Property. This is because ECMA6 defines several native properties as accessor properties (as opposed to data properties). In ECMA5, accessor properties always meant properties with user-provided get and set functions. The difference between data and accessor properties of course is that when accessed over the prototype chain accessor is called with the object at the start of the prototype chain as receiver instead of the object owning the property. That's just to explain these changes. The gist of it is that it is now possible to define accessor properties through nasgen and they should behave just like user user-defined accessor properties. - Finally, there are several small issues left in this patch that I know of, and probably more that I don't know of. I could have continued writing tests for at least another week, but I think it's good enough to push it. Thanks! Hannes From szegedia at gmail.com Fri Feb 5 13:17:01 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 5 Feb 2016 14:17:01 +0100 Subject: Review request for JDK-8147558: Add support for ES6 collections In-Reply-To: <56B476D4.8070708@gmail.com> References: <56B476D4.8070708@gmail.com> Message-ID: <4F665A0D-C7F3-461F-AEE4-AF78D9AA97D4@gmail.com> Global.java: - Documentation for Global.setWeakSet() is wrong. - It?s kinda too bad we can?t generalize those getters with lazy sentinel and builtin getters. I guess we could if they weren?t stored in fields. Sounds like a good future use case for a VarHandle :-) - Global.initPrototype uses the ?jdk.nashorn.internal.objects." string literal. It?s already used by Global.initConstructor too, maybe extract it into a constant? (FWIW, it also appears without the trailing dot in NashornLoader.java; maybe unify it into a single place somewhere?) NativeArray.java: - I?d refactor the common idiom in entries, keys, values, and getIterator into a separate method parametrized on iteration kind. FWIW, getIterator and values look exactly the same. LinkedMap.java: - why does it need to be safe for concurrent use? Seems unnecessary to me. WeakMap and WeakSet: didn?t you need the guarantees of LinkedMap with them too? I guess not. Other than that, +1; looks good to me. Quite a heroic effort! I?m very happy Nashorn will be offering more and more ES6 functionality. Attila. > On Feb 5, 2016, at 11:17 AM, Hannes Walln?fer wrote: > > Please review JDK-8147558: Add support for ES6 collections: > > http://cr.openjdk.java.net/~hannesw/8147558/ > > The patch is rather large so here are a few things to point out: > > - The Map and Set collections use a custom linked map implementation (objects/LinkedMap) instead of using a standard Java collection such as java.util.LinkedHashMap. The reason is that the forEach method in those objects allows arbitrary modifications to the base collection during iteration by the callback function. The way this is done is that additions and deletions are reflected in visited nodes except for deletion of elements that have already been visited. > > See the note in http://www.ecma-international.org/ecma-262/6.0/#sec-map.prototype.foreach > > LinkedMap is implemented as a linked list that uses a HashMap for hashing (or, in other words, a HashMap with linked-list nodes as values). While the hash map methods are synchronized, iteration does not use any locking. I think it is safe for concurrent use, but please do have a look. > > - There are now a IS_ACCESSOR_PROPERTY flag and a isAccessorProperty() in runtime/Property. This is because ECMA6 defines several native properties as accessor properties (as opposed to data properties). In ECMA5, accessor properties always meant properties with user-provided get and set functions. The difference between data and accessor properties of course is that when accessed over the prototype chain accessor is called with the object at the start of the prototype chain as receiver instead of the object owning the property. That's just to explain these changes. The gist of it is that it is now possible to define accessor properties through nasgen and they should behave just like user user-defined accessor properties. > > - Finally, there are several small issues left in this patch that I know of, and probably more that I don't know of. I could have continued writing tests for at least another week, but I think it's good enough to push it. > > Thanks! > Hannes From hannes.wallnoefer at oracle.com Fri Feb 5 14:13:17 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 5 Feb 2016 15:13:17 +0100 Subject: Review request for JDK-8147558: Add support for ES6 collections In-Reply-To: <4F665A0D-C7F3-461F-AEE4-AF78D9AA97D4@gmail.com> References: <56B476D4.8070708@gmail.com> <4F665A0D-C7F3-461F-AEE4-AF78D9AA97D4@gmail.com> Message-ID: <56B4ADFD.1090803@oracle.com> Thanks for the review, Attila! Am 2016-02-05 um 14:17 schrieb Attila Szegedi: > Global.java: > - Documentation for Global.setWeakSet() is wrong. > - It?s kinda too bad we can?t generalize those getters with lazy sentinel and builtin getters. I guess we could if they weren?t stored in fields. Sounds like a good future use case for a VarHandle :-) > - Global.initPrototype uses the ?jdk.nashorn.internal.objects." string literal. It?s already used by Global.initConstructor too, maybe extract it into a constant? (FWIW, it also appears without the trailing dot in NashornLoader.java; maybe unify it into a single place somewhere?) Thanks, will fix the documentation and clean up the string literals. > NativeArray.java: > - I?d refactor the common idiom in entries, keys, values, and getIterator into a separate method parametrized on iteration kind. FWIW, getIterator and values look exactly the same. I'm not sure I understand. These are separate methods because each one defines a @Function for nasgen. Of course we could extend the @Function annotation to allow one Java method to define multiple JS functions. But these methods are one-liners anyway, so I doubt it would get much simpler. > LinkedMap.java: > - why does it need to be safe for concurrent use? Seems unnecessary to me. You're right, it's not a requirement, but I think it's nice to have given the ubiquity of multithreading on the Java platform. > > WeakMap and WeakSet: didn?t you need the guarantees of LinkedMap with them too? I guess not. The weak collections do not allow elements to be iterated over, so this isn't an issue there. Hannes From szegedia at gmail.com Fri Feb 5 15:31:35 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 5 Feb 2016 16:31:35 +0100 Subject: Review request for JDK-8147558: Add support for ES6 collections In-Reply-To: <56B4ADFD.1090803@oracle.com> References: <56B476D4.8070708@gmail.com> <4F665A0D-C7F3-461F-AEE4-AF78D9AA97D4@gmail.com> <56B4ADFD.1090803@oracle.com> Message-ID: <36680DA8-578C-4811-9B75-353E322D7891@gmail.com> On Feb 5, 2016, at 3:13 PM, Hannes Wallnoefer wrote: > > Thanks for the review, Attila! > > Am 2016-02-05 um 14:17 schrieb Attila Szegedi: >> Global.java: >> - Documentation for Global.setWeakSet() is wrong. >> - It?s kinda too bad we can?t generalize those getters with lazy sentinel and builtin getters. I guess we could if they weren?t stored in fields. Sounds like a good future use case for a VarHandle :-) >> - Global.initPrototype uses the ?jdk.nashorn.internal.objects." string literal. It?s already used by Global.initConstructor too, maybe extract it into a constant? (FWIW, it also appears without the trailing dot in NashornLoader.java; maybe unify it into a single place somewhere?) > > Thanks, will fix the documentation and clean up the string literals. > >> NativeArray.java: >> - I?d refactor the common idiom in entries, keys, values, and getIterator into a separate method parametrized on iteration kind. FWIW, getIterator and values look exactly the same. > > I'm not sure I understand. These are separate methods because each one defines a @Function for nasgen. Of course we could extend the @Function annotation to allow one Java method to define multiple JS functions. But these methods are one-liners anyway, so I doubt it would get much simpler. private static Object createIterator(final Object self, final AbstractIterator.IterationKind kind) { return new ArrayIterator(Global.toObject(self), kind, Global.instance()); } then @Function(attributes = Attribute.NOT_ENUMERABLE) public static Object entries(final Object self) { return createIterator(AbstractIterator.IterationKind.KEY_VALUE); } etc. No big deal, but I like to eliminate all copy-paste code. > >> LinkedMap.java: >> - why does it need to be safe for concurrent use? Seems unnecessary to me. > > You're right, it's not a requirement, but I think it's nice to have given the ubiquity of multithreading on the Java platform. I?m still in disagreement. For one argument, that makes this class closer to Java 1.1 Hashtable than to HashMap. The trend in collection classes is to not make them thread safe unless they?re specifically concurrent. For another argument, we also consciously don?t make JS classes thread safe since the JS language is not thread safe, so we don?t want to incur synchronization overhead in the majority usage single-threaded case. ScriptObject is not thread safe either. It?s a design principle we followed so far: JS objects homed in a single global are not thread safe; backing structures shared across globals in a context (compiled functions etc.) are thread safe. Having a class that violates this distinction can provide a misunderstanding in someone reading the code about these design principles. Of course, if the class would start to be used in a different context too, then it might be justified to add synchronization to it (or just have it implement java.util.Map and use Collections.synchronizedMap when this is desired). > >> >> WeakMap and WeakSet: didn?t you need the guarantees of LinkedMap with them too? I guess not. > > The weak collections do not allow elements to be iterated over, so this isn't an issue there. Excellent. Thought there?s a reason :-) > > Hannes From szegedia at gmail.com Sun Feb 7 18:18:51 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 7 Feb 2016 19:18:51 +0100 Subject: Review request for JDK-8149186: Don't use indy for optimistic arithmetic Message-ID: Please review JDK-8149186 "Don't use indy for optimistic arithmetic" at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Mon Feb 8 07:55:40 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 8 Feb 2016 13:25:40 +0530 Subject: Review request for JDK-8149186: Don't use indy for optimistic arithmetic In-Reply-To: References: Message-ID: <56B849FC.9020504@oracle.com> +1 -Sundar On 2/7/2016 11:48 PM, Attila Szegedi wrote: > Please review JDK-8149186 "Don't use indy for optimistic arithmetic" at for > > Thanks, > Attila. From michael.haupt at oracle.com Mon Feb 8 07:57:58 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 8 Feb 2016 08:57:58 +0100 Subject: Review request for JDK-8149186: Don't use indy for optimistic arithmetic In-Reply-To: References: Message-ID: <419E00E2-F92F-4612-80CA-A7C9C3C38650@oracle.com> Hi Attila, lower-case thumbs up; please adjust copyright years. Best, Michael > Am 07.02.2016 um 19:18 schrieb Attila Szegedi : > > Please review JDK-8149186 "Don't use indy for optimistic arithmetic" at for > > Thanks, > Attila. -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Mon Feb 8 11:52:16 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 8 Feb 2016 12:52:16 +0100 Subject: RFR(S): 8149334: JSON.parse(JSON.stringify([])).push(10) creates an array containing two elements Message-ID: <7B958BA2-B94C-4CF9-A655-94B5DCC2D658@oracle.com> Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8149334 Webrev: http://cr.openjdk.java.net/~mhaupt/8149334/webrev.00 The problem here is that the transition from an immutable empty array (of the internal type ArrayData.UntouchedArrayData) to an array containing actual data would create an array with one entry before then appending the pushed element. The fix is to return an actually empty (if mutable) ArrayData instance in these cases. Tested in 9-dev and 8u. As this was filed against 8u60, it will be backported. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From james.laskey at oracle.com Mon Feb 8 12:05:31 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 8 Feb 2016 08:05:31 -0400 Subject: RFR(S): 8149334: JSON.parse(JSON.stringify([])).push(10) creates an array containing two elements In-Reply-To: <7B958BA2-B94C-4CF9-A655-94B5DCC2D658@oracle.com> References: <7B958BA2-B94C-4CF9-A655-94B5DCC2D658@oracle.com> Message-ID: <13C7FA1A-8A20-43FB-B052-811D80B6CA99@oracle.com> +1 > On Feb 8, 2016, at 7:52 AM, Michael Haupt wrote: > > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8149334 > Webrev: http://cr.openjdk.java.net/~mhaupt/8149334/webrev.00 > > The problem here is that the transition from an immutable empty array (of the internal type ArrayData.UntouchedArrayData) to an array containing actual data would create an array with one entry before then appending the pushed element. The fix is to return an actually empty (if mutable) ArrayData instance in these cases. > > Tested in 9-dev and 8u. As this was filed against 8u60, it will be backported. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing practices and products that help protect the environment > From sundararajan.athijegannathan at oracle.com Mon Feb 8 12:37:25 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 8 Feb 2016 18:07:25 +0530 Subject: RFR(S): 8149334: JSON.parse(JSON.stringify([])).push(10) creates an array containing two elements In-Reply-To: <7B958BA2-B94C-4CF9-A655-94B5DCC2D658@oracle.com> References: <7B958BA2-B94C-4CF9-A655-94B5DCC2D658@oracle.com> Message-ID: <56B88C05.7080608@oracle.com> +1 On 2/8/2016 5:22 PM, Michael Haupt wrote: > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8149334 > Webrev: http://cr.openjdk.java.net/~mhaupt/8149334/webrev.00 > > The problem here is that the transition from an immutable empty array (of the internal type ArrayData.UntouchedArrayData) to an array containing actual data would create an array with one entry before then appending the pushed element. The fix is to return an actually empty (if mutable) ArrayData instance in these cases. > > Tested in 9-dev and 8u. As this was filed against 8u60, it will be backported. > > Thanks, > > Michael > From michael.haupt at oracle.com Tue Feb 9 13:11:53 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 9 Feb 2016 14:11:53 +0100 Subject: RFR(S): 8149462: revert changes for 8149186 Message-ID: <7C2E280A-0591-47AF-8C04-EAEF8A647789@oracle.com> Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8149462 Webrev: http://cr.openjdk.java.net/~mhaupt/8149462/webrev.00 The changes introduced for JDK-8149186 [1] led to nightly build failures and reproducible crashes in test262parallel on Linux. A fix is proposed [2] but is pending investigation. To stabilise the nightly builds, the changes that introduced the errors should be reverted for the time being. Thanks, Michael [1] https://bugs.openjdk.java.net/browse/JDK-8149186 [2] https://bugs.openjdk.java.net/browse/JDK-8149451 -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From james.laskey at oracle.com Tue Feb 9 13:13:48 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 9 Feb 2016 09:13:48 -0400 Subject: RFR(S): 8149462: revert changes for 8149186 In-Reply-To: <7C2E280A-0591-47AF-8C04-EAEF8A647789@oracle.com> References: <7C2E280A-0591-47AF-8C04-EAEF8A647789@oracle.com> Message-ID: <203A1FB8-6CEA-4249-A3EF-E9EA398AB87E@oracle.com> +1 > On Feb 9, 2016, at 9:11 AM, Michael Haupt wrote: > > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8149462 > Webrev: http://cr.openjdk.java.net/~mhaupt/8149462/webrev.00 > > The changes introduced for JDK-8149186 [1] led to nightly build failures and reproducible crashes in test262parallel on Linux. A fix is proposed [2] but is pending investigation. To stabilise the nightly builds, the changes that introduced the errors should be reverted for the time being. > > Thanks, > > Michael > > [1] https://bugs.openjdk.java.net/browse/JDK-8149186 > [2] https://bugs.openjdk.java.net/browse/JDK-8149451 > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing practices and products that help protect the environment > From sundararajan.athijegannathan at oracle.com Tue Feb 9 13:21:52 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 9 Feb 2016 18:51:52 +0530 Subject: RFR(S): 8149462: revert changes for 8149186 In-Reply-To: <7C2E280A-0591-47AF-8C04-EAEF8A647789@oracle.com> References: <7C2E280A-0591-47AF-8C04-EAEF8A647789@oracle.com> Message-ID: <56B9E7F0.6020908@oracle.com> +1 On 2/9/2016 6:41 PM, Michael Haupt wrote: > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8149462 > Webrev: http://cr.openjdk.java.net/~mhaupt/8149462/webrev.00 > > The changes introduced for JDK-8149186 [1] led to nightly build failures and reproducible crashes in test262parallel on Linux. A fix is proposed [2] but is pending investigation. To stabilise the nightly builds, the changes that introduced the errors should be reverted for the time being. > > Thanks, > > Michael > > [1] https://bugs.openjdk.java.net/browse/JDK-8149186 > [2] https://bugs.openjdk.java.net/browse/JDK-8149451 > From james.laskey at oracle.com Tue Feb 9 20:18:09 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 9 Feb 2016 16:18:09 -0400 Subject: RFR - JDK-8141209 $EXEC should allow streaming of output Message-ID: <36957C84-91D0-4089-810E-4CBFAA6C122A@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8141209 http://cr.openjdk.java.net/~jlaskey/8141209/webrev/index.html Rough documentation can be found at https://community.oracle.com/community/java/javascript-nashorn/blog/2016/02/08/proposal-for-exec-20 From michael.haupt at oracle.com Wed Feb 10 08:07:45 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 10 Feb 2016 09:07:45 +0100 Subject: RFR - JDK-8141209 $EXEC should allow streaming of output In-Reply-To: <36957C84-91D0-4089-810E-4CBFAA6C122A@oracle.com> References: <36957C84-91D0-4089-810E-4CBFAA6C122A@oracle.com> Message-ID: Hi Jim, tested on Mac, Windows (Cygwin), Linux. Lower-case thumbs up, with one remark: ** ScriptingFunctions.java ** In the exec() method, I'd really like to have a check to make sure no illegal argument combination goes unnoticed. If arguments are passed that do not conform to any of the four forms, there should be an error message. Best, Michael > Am 09.02.2016 um 21:18 schrieb Jim Laskey (Oracle) : > > https://bugs.openjdk.java.net/browse/JDK-8141209 > http://cr.openjdk.java.net/~jlaskey/8141209/webrev/index.html > > Rough documentation can be found at https://community.oracle.com/community/java/javascript-nashorn/blog/2016/02/08/proposal-for-exec-20 > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From christoph.sauer at nuveon.de Thu Feb 11 12:04:14 2016 From: christoph.sauer at nuveon.de (Christoph Sauer) Date: Thu, 11 Feb 2016 13:04:14 +0100 Subject: bug-report-can-t-call-static-methods-on-a-java-class-instance In-Reply-To: <49A6ADE5-2101-4B10-AF1F-19A4C7982D84@gmail.com> References: <56B2ED2A.6090201@nuveon.de> <49A6ADE5-2101-4B10-AF1F-19A4C7982D84@gmail.com> Message-ID: <56BC78BE.8000101@nuveon.de> Hi Attila, thanks for your response. You wrote "Have you considered that for a large established system, you might not want to change the underlying JavaScript engine?" For now we will continue with Rhino. Since we are building our framework using Rhino since 2006 we don't use the build in JDK mechanism to instantiate it anyway. But from what I read in the press you advertise Nashorn as the successor of Rhino, offering better performance and next ECMA Script support. I don't care to much about performance right now because all the heavy lifting is done in Java API Objects that are then offered to the framework users as script vars. They make up the actual API for our framework (which contain many static methods). Nevertheless a better performance and the ECMA Script future support would buy me in. What is a showstopper right now is the separation of static/non static methods. You wrote "hopefully smaller change would be to change the methods in your utility classes from being static to being instance methods" These static methods are not only used in scripting, but of course also reused within the java framework. You usually use static methods because you don't need any context to call them except the method params you pass them. If I would make my static methods to instance methods, this would mean that in all methods that call that method they not only would need the params but also constructor params for that object. Since they are usually not available you could come to the conclusion to use an empty constructor just for the sake of simplicity. Lets look at an example. Here's how it currently works TypeUtil tutil = new TypeUtil(RuntimeObject); tutil.fmtDate(obj); //uses a property set in RuntimeObject to get the format; TypeUtil.fmtNumber(obj); //simply uses the standard Locale, does not require runtime information. TypeUtil is passed as "jtype" hook. JS developers use both jtype.fmtDate() and jtype.fmtNumber(). They don't care about the difference and they don't need to. Now for Nashorn, since I might not have that "RuntimeObject" i could make fmtNumber() to an instance method. For Nashnorn this would work perfectly fine. However unfortunately this fmtNumber() is reused in many places within the Java Framework code where RuntimeObject is not available. So the developers would be tempted to add an "Empty" contructor. new TypeUtil().fmtNumber(obj) This works fine. But what if another developer sees the empty constructor and says "hey, perfect, i use the simpler Constructor" like this: new TypeUtil().fmtDate(obj); //exception! Nullpointer since RuntimeObject is not there. You and me would not do such a thing. But your design decision would finally lead to programming like this because programmers are lazy and prefer the less cognitive load approach. They won't read this discussion here. >From my experience I never EVER had a problem with a Nullpointer deference by using a static method on an object. However it is a frequent source of problem in production code if in an edge case a method gets called on an object that is in an invalid state because of missing constructor parameters. So your design decision will lead to something that is much worse than the null pointer deference: The effect I just described I would call the "Nashorn Effect": Empty constructors leading to null pointers the way I just described on the Java side. If I would have to make a hypothesis for a research paper comparing programming errors with the Nashnorn Engine in place I would start like this |= Programming Errors |= Likeliness |= Severity |Null Pointer Deference|x |x |Nashorn Effect |x*3 |x You make it hard to switch existing projects from Rhino to Nashorn because of your conviction that null pointer deference is a bad thing. Have you based this design decision that might have such severe consequences on profound research on how severe it really is in practice? Why did Java itself not make it deprecated in the first place? You wrote "I made them in the direction of helping people write more maintainable and clear code in the long run". I think that you might have prevented a sometimes problematic habit (null pointer deference), but you increased the likeliness of an even worse habit: The Nashorn Effect. I also think you contradict yourself saying "so a theoretical JavaScript programmer should have no a priori expectations with regard to how platform integration features work". Good intention! Not allowing static methods on java will however have exactly this effect. Look at this presumably future code comment that would pop up if I would present to namespaces for nonstatic/static on the same Class to js users jtype.fmtDate(obj) ; jtypeS.fmtNumber(obj); //JS Developer: why the heck do I need jtypeS, whats the S standing for? You wrote "in JDK 9 Nashorn can be extended with additional linkers" That's my light at the end of the tunnel. Thanks for that hint. This sounds like I would get what I want while still being able to reuse my Java API without the "Nashorn Effect" threat on the Java side. If this will come anyway: wouldn't it be a low hanging fruit for you to provide us with a "sloopy switch" in the meanwhile :-) You wrote "As for 'creature'" That's what I thought. I am not a native speaker so thanks for the clarification. In German even saying "Das Nashorn ist eine Kreatur" would sound derogatory to that animal. So sorry for that question :) The only thing that is left for me is to check if I can make this in Nashorn, because this is the SINGLE MOST programming error in our framework with rhino: if (jtpye.fmtDate(obj) == "11.02.2016") //arg! java strings are not js string -> a priori expectations needed in Rhino - like you said - there you have it! Thanks for your work and the possibilities you provide us with a good js engine for the Java platform. I am really thankful for that. I am looking forward using Nashorn (hopefully) in the future. I am out for now however. Christoph Am 04.02.2016 um 18:26 schrieb Attila Szegedi: > Hi Cristoph, > > I presume you?re referring to this post: > . > > I still stand by the design decisions we made when mapping the Java > class/object system to JavaScript in Nashorn. I understand the > differing opinions (yours and Tal?s both), and don?t consider them > wrong, just having different requirement priorities. > > Have you considered that for a large established system, you might not > want to change the underlying JavaScript engine? Rhino is yet again in > active development, so a hopefully easier way to modernize your system > would be to switch from JDK-embedded JavaScript runtime to Rhino as an > external library. Ideally you?d just need to touch your script engine > factory instantiation code. > > Even if you decide to switch to Nashorn, a hopefully smaller change > would be to change the methods in your utility classes from being > static to being instance methods. That would even keep the change > cross-compatible with Rhino. (Of course, this doesn?t help you if you > have some external dependencies where you can?t change the methods > from static to instance?) > > In terms of future advice, there?s one other approach you might take, > although unfortunately it won?t be available for JDK 8, just for JDK > 9. Namely, in JDK 9 Nashorn can be extended with additional linkers > (see e.g. Sundar?s recent post that uses extra linkers to bridge JS to > Python https://blogs.oracle.com/sundararajan/entry/nashorn_javascript_access_to_python). > It would be possible to write an additional Dynalink linker that > recognizes missing members on POJOs and attempts to look up static > methods instead. I know this doesn't help you now, but thought it > might be worth mentioning it for completeness so it might help someone > who digs this message out of an archive a year from now. > > As for ?creature? ? yes, you were misinterpreting it :-). ?A different > kind of creature? here could be synonymous with ?a different cup of > tea?, or ?another case?. I use the word as synonymous with ?being? > (?something created?) without any intended negative overtones. I built > fairly complex systems on top of Rhino in the past myself, and for a > while both contributed to Rhino and served as the project?s > administrator. I certainly have neither the moral ground nor the > desire to diss Rhino or its users. > > Attila. > >> On Feb 4, 2016, at 7:18 AM, Christoph Sauer >> > wrote: >> >> Dear Attila, >> >> i was just evaluating a switch of our huge codebase written in >> Javascript using the Rhino interpreter to Nashorn. We have utility >> classes written in Java that are are passed as objects to help users >> write less code in JS, because that is why we use JS >> in the first place. Those utility objects also contain frequently used >> static methods. Your design decisions will make it impossible for us to >> switch. >> >> Not only will we have to rewrite our code, we also will have to make >> separate calls to "handles" the user already has. This is against my >> design decision to pursue the ideal of "literate programming". The ideal >> to make code more readable is broken here. I agree with Tal Liron >> that if a programmer wants to use Java, they would. We use Javascript >> because of the shorthand and the goal towards cleaner code >> without loosing the power of using Java where need be. >> >> I felt offended to be called a "Creature". I hope I misinterpret you >> sentence here . >> Two years have passed since this post. Have you changed your mind since? >> Will there be at least a "strict" switch like suggested by tal? >> >> Thanks >> Christoph > -- Christoph Sauer Gesch?ftsf?hrer CEO nuveon GmbH Felderstra?e 20 91801 Markt Berolzheim mobil : +49 (0) 170 / 272 76 76 b?ro: +49 (0) 9146 / 95 990 01 fax: +49 (0) 9146 / 94 220 45 From szegedia at gmail.com Thu Feb 11 12:28:34 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 11 Feb 2016 13:28:34 +0100 Subject: Review request for JDK-8149451: Fix bytecode generation issue after 8149186 Message-ID: Please review JDK-8149451 "Fix bytecode generation issue after 8149186" at for This changeset is basically identical to JDK-8149186 but it will allow optimistic addition on booleans. I have implemented it by delegating to Type.INT.add instead of copy-pasting the code, but that should not cause issues (famous last words, right?). If you have the opportunity to re-test on Linux, that'd be appreciated (I have no Linux machines around). Thanks, Attila. From james.laskey at oracle.com Thu Feb 11 12:32:10 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 11 Feb 2016 08:32:10 -0400 Subject: Review request for JDK-8149451: Fix bytecode generation issue after 8149186 In-Reply-To: References: Message-ID: <508E3289-C983-4227-BAEC-48F7238B1186@oracle.com> +1 > On Feb 11, 2016, at 8:28 AM, Attila Szegedi wrote: > > Please review JDK-8149451 "Fix bytecode generation issue after 8149186" at for > > This changeset is basically identical to JDK-8149186 but it will allow optimistic addition on booleans. I have implemented it by delegating to Type.INT.add instead of copy-pasting the code, but that should not cause issues (famous last words, right?). If you have the opportunity to re-test on Linux, that'd be appreciated (I have no Linux machines around). > > Thanks, > Attila. From michael.haupt at oracle.com Thu Feb 11 14:23:41 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 11 Feb 2016 15:23:41 +0100 Subject: Review request for JDK-8149451: Fix bytecode generation issue after 8149186 In-Reply-To: References: Message-ID: <9137292E-AD38-4340-B5AE-3C646EA07CE1@oracle.com> Hi Attila, I'm very sorry, but testing this I keep getting - occasionally! - crashes of the observed kind (see below). Best, Michael [java] Test(compile, run): test/script/external/test262/test/suite/ch15/15.5/15.5.4/15.5.4.19/S15.5.4.19_A7.js [java] java.lang.AssertionError: Failed generating bytecode for test/script/external/test262/test/harness/sta.js:-1 [java] at jdk.nashorn.internal.codegen.CompilationPhase$BytecodeGenerationPhase.transform(CompilationPhase.java:436) [java] at jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:630) [java] at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:656) [java] at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compileTypeSpecialization(RecompilableScriptFunctionData.java:717) [java] at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.getBest(RecompilableScriptFunctionData.java:897) [java] at jdk.nashorn.internal.runtime.ScriptFunctionData.getBest(ScriptFunctionData.java:392) [java] at jdk.nashorn.internal.runtime.ScriptFunctionData.getBestInvoker(ScriptFunctionData.java:254) [java] at jdk.nashorn.internal.runtime.ScriptFunction.findCallMethod(ScriptFunction.java:915) [java] at jdk.nashorn.internal.runtime.ScriptObject.lookup(ScriptObject.java:1862) [java] at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:102) [java] at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:94) [java] at jdk.dynalink.linker.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:184) [java] at jdk.dynalink.linker.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:132) [java] at jdk.dynalink.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:146) [java] at jdk.dynalink.DynamicLinker.relink(DynamicLinker.java:262) [java] at jdk.nashorn.internal.scripts.Script$Recompilation$528212$18490D$sta.DaylightSavingTA(test/script/external/test262/test/harness/sta.js:651) [java] at jdk.nashorn.internal.scripts.Script$Recompilation$528211$sta.:program(test/script/external/test262/test/harness/sta.js:566) [java] at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:654) [java] at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511) [java] at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) [java] at jdk.nashorn.internal.test.framework.SharedContextEvaluator.run(SharedContextEvaluator.java:135) [java] at jdk.nashorn.internal.test.framework.AbstractScriptRunnable.evaluateScript(AbstractScriptRunnable.java:200) [java] at jdk.nashorn.internal.test.framework.ParallelTestRunner$ScriptRunnable.execute(ParallelTestRunner.java:202) [java] at jdk.nashorn.internal.test.framework.AbstractScriptRunnable.runTest(AbstractScriptRunnable.java:132) [java] at jdk.nashorn.internal.test.framework.ParallelTestRunner$ScriptRunnable.call(ParallelTestRunner.java:281) [java] at jdk.nashorn.internal.test.framework.ParallelTestRunner$ScriptRunnable.call(ParallelTestRunner.java:124) [java] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [java] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1158) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) [java] at java.lang.Thread.run(Thread.java:804) [java] Caused by: java.lang.NullPointerException > Am 11.02.2016 um 13:28 schrieb Attila Szegedi : > > Please review JDK-8149451 "Fix bytecode generation issue after 8149186" at for > > This changeset is basically identical to JDK-8149186 but it will allow optimistic addition on booleans. I have implemented it by delegating to Type.INT.add instead of copy-pasting the code, but that should not cause issues (famous last words, right?). If you have the opportunity to re-test on Linux, that'd be appreciated (I have no Linux machines around). > > Thanks, > Attila. -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From szegedia at gmail.com Thu Feb 11 14:36:12 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 11 Feb 2016 15:36:12 +0100 Subject: bug-report-can-t-call-static-methods-on-a-java-class-instance In-Reply-To: <56BC78BE.8000101@nuveon.de> References: <56B2ED2A.6090201@nuveon.de> <49A6ADE5-2101-4B10-AF1F-19A4C7982D84@gmail.com> <56BC78BE.8000101@nuveon.de> Message-ID: <8A682608-D3F4-46FB-9752-4049D90DDC4A@gmail.com> On Feb 11, 2016, at 1:04 PM, Christoph Sauer wrote: > > Hi Attila, > > thanks for your response. > > You wrote "Have you considered that for a large established system, you > might not want to change the underlying JavaScript engine?" > > For now we will continue with Rhino. Since we are building our framework > using Rhino since 2006 we don't use the build in JDK mechanism to > instantiate it anyway. But from what I read in the press you advertise > Nashorn as the successor of Rhino, offering better performance and next > ECMA Script support. Nashorn is the successor to the JDK-bundled Rhino (OpenJDK or Oracle don?t have any say in what?s the successor to Mozilla Rhino?). Nashorn was undertaken for multitude of reasons: better performance, ECMAScript 5.1 compliance (now with ongoing ES6 additions), but also dogfooding invokedynamic, and very importantly (although not often emphasized): security. > I don't care to much about performance right now > because all the heavy lifting is done in Java API Objects that are then > offered to the framework users as script vars. They make up the actual > API for our framework (which contain many static methods). Nevertheless > a better performance and the ECMA Script future support would buy me in. > What is a showstopper right now is the separation of static/non static > methods. > > You wrote "hopefully smaller change would be to change the methods in > your utility classes from being static to being instance methods" > > These static methods are not only used in scripting, but of course also > reused within the java framework. You usually use static methods because > you don't need any context to call them except the method params you > pass them. If I would make my static methods to instance methods, this > would mean that in all methods that call that method they not only would > need the params but also constructor params for that object. Since they > are usually not available you could come to the conclusion to use an > empty constructor just for the sake of simplicity. Lets look at an > example. Here's how it currently works > > TypeUtil tutil = new TypeUtil(RuntimeObject); > tutil.fmtDate(obj); //uses a property set in RuntimeObject to get the > format; > TypeUtil.fmtNumber(obj); //simply uses the standard Locale, does not > require runtime information. > > TypeUtil is passed as "jtype" hook. JS developers use both > jtype.fmtDate() and jtype.fmtNumber(). They don't care about the > difference and they don't need to. So? ?jtype? is an instance of TypeUtil, right? You could do something to bridge this in Nashorn, BTW. Nashorn has a non-standard (meaning, not in ECMAScript) Object.bindProperties() function. Usage is: Object.bindProperties(dst, src). What it does, it adds all properties from ?src? object as bound properties to the ?dst? object and returns it. The fact they?re bound properties means that even invoking dst.fn(x) will make ?fn? see ?src? as its ?this?. So you could then do something like var new_jtype = {} new_jtype = Object.bindProperties(new_jtype, jtype) new_jtype = Object.bindProperties(new_jtype, Java.type(?com.foo.TypeUtil?)) jtype = new_jtype or rolled into one: jtype = Object.bindProperties(Object.bindProperties({}, jtype), Java.type(?com.foo.TypeUtil?)) You?ll then have both the instance and the static methods exposed through a single object. Of course, I understand that this only works if you?re in control of what?s exposed. If some of these utilities return other utilities, then you obviously can?t go this route? > Now for Nashorn, since I might not have that "RuntimeObject" i could > make fmtNumber() to an instance method. For Nashnorn this would work > perfectly fine. However unfortunately this fmtNumber() is reused in many > places within the Java Framework code where RuntimeObject is not > available. So the developers would be tempted to add an "Empty" contructor. > > new TypeUtil().fmtNumber(obj) > > This works fine. But what if another developer sees the empty > constructor and says "hey, perfect, i use the simpler Constructor" like > this: > > new TypeUtil().fmtDate(obj); //exception! Nullpointer since > RuntimeObject is not there. > > You and me would not do such a thing. But your design decision would > finally lead to programming like this because programmers are lazy and > prefer the less cognitive load approach. They won't read this discussion > here. > > From my experience I never EVER had a problem with a Nullpointer > deference by using a static method on an object. However it is a > frequent source of problem in production code if in an edge case a > method gets called on an object that is in an invalid state because of > missing constructor parameters. > > So your design decision will lead to something that is much worse than > the null pointer deference: The effect I just described I would call the > "Nashorn Effect": Empty constructors leading to null pointers the way I > just described on the Java side. The real ?Nashorn effect? here is the fact it exposes a deficiency in API design as the TypeUtil class clearly has some issues of separation of concerns between operations that depend on some contextual state (RuntimeObject) and those that don?t. That?s one of the things I allude to when I refer to maintainability of code. It can bite you in Java, not just JavaScript. Firstly, let?s state that you are bitten here by the fact that since Java language allows invocation of static methods on instances, javac won?t allow you to have a static method with the same signature as an instance method (as then it can?t distinguish among them since it allows the ambiguity), so you can?t choose the easier route of keeping both a static and a non-static method with the same signature. Funnily enough, this distinction doesn?t exist on the JVM level, that is, it?s legal to have a class file with both ?static void f(Object x)? and ?void f(Object x)?. May I add that the invocation of static methods on instances is also strongly discouraged practice, and practically all compilers and IDEs today will issue a warning if you do it. Basically, you have at least two sets of concerns here that are entangled in a single class: one set of concerns that can operate without a RuntimeObject and one that needs a RuntimeObject. Frankly, this smells like it would need to be two classes. I mean, suddenly you have the need to allow partially-constructed (= ?not fully configured") instances in your system? Hmm? That?s not ?Nashorn effect?, that?s a deficiency in API design. You could call it ?Nashorn effect? when it makes you aware of it :-) I posit this would?ve come to bite you sooner or later regardless of Nashorn. > If I would have to make a hypothesis > for a research paper comparing programming errors with the Nashnorn > Engine in place I would start like this > > |= Programming Errors |= Likeliness |= Severity > |Null Pointer Deference|x |x > |Nashorn Effect |x*3 |x > > You make it hard to switch existing projects from Rhino to Nashorn > because of your conviction that null pointer deference is a bad thing. That?s not the reason; I don?t even see how null pointer dereferencing is related to separating the static namespace of a class. Independently of that, I do proudly uphold the conviction that null dereferencing is a Bad Thing, though. > Have you based this design decision that might have such severe > consequences on profound research on how severe it really is in > practice? Why did Java itself not make it deprecated in the first place? Beats me. If it were up to me, this would?ve never worked. Weirdly enough this was always a pure language and compiler construct and never existed on bytecode level. You can?t invoke a static method with the INVOKEVIRTUAL bytecode instruction nor an instance method with INVOKESTATIC. I won?t go off to experiment with this, but I wager changing a method from instance to static or other way round is an incompatible class change that would make an attempt to load another class using it without recompiling the user class throw a NoSuchMethodError. > > You wrote "I made them in the direction of helping people write more > maintainable and clear code in the long run". > > I think that you might have prevented a sometimes problematic habit > (null pointer deference), but you increased the likeliness of an even > worse habit: The Nashorn Effect. I also think you contradict yourself > saying "so a theoretical JavaScript programmer should have no a priori > expectations with regard to how platform integration features work". > Good intention! Not allowing static methods on java will however have > exactly this effect. Look at this presumably future code comment that > would pop up if I would present to namespaces for nonstatic/static on > the same Class to js users > > jtype.fmtDate(obj) ; > jtypeS.fmtNumber(obj); //JS Developer: why the heck do I need jtypeS, > whats the S standing for? Maybe you could use more descriptive names so they don?t have to wonder about ?S?? :-) Speaking of descriptive namespace naming, I can take your argument a step further; your ?JS Developer? could also then ask ?why the heck do I need jtype for, what?s it standing for?? By providing various utility objects, you?re already grouping functions into namespaces represented by those objects. If splitting namespaces (and thus introducing new ones) is bad, why not eliminate them all and just give them a bunch of global functions? I?m not advocating this, mind you (although it might make sense for smallish APIs), just pointing out the logical end conclusion of your argument. Anyway, Object.bindProperties() lets you knead several otherwise separate concerns into a unified facade, if that?s what you need. > > You wrote "in JDK 9 Nashorn can be extended with additional linkers" > > That's my light at the end of the tunnel. Thanks for that hint. This > sounds like I would get what I want while still being able to reuse my > Java API without the "Nashorn Effect" threat on the Java side. If this > will come anyway: wouldn't it be a low hanging fruit for you to provide > us with a "sloopy switch" in the meanwhile :-) Well, it?s certainly possible. The bar for what?s possible is fairly low in JavaScript, isn?t it? The language is just so extremely dynamic that you can bend it pretty much any way. I?m not sure if it?s desirable, though. I?ll keep thinking about it. > > You wrote "As for 'creature'" > > That's what I thought. I am not a native speaker so thanks for the > clarification. In German even saying "Das Nashorn ist eine Kreatur" > would sound derogatory to that animal. So sorry for that question :) No worries, I figured out as much. > > The only thing that is left for me is to check if I can make this in > Nashorn, because this is the SINGLE MOST programming error in our > framework with rhino: > > if (jtpye.fmtDate(obj) == "11.02.2016") //arg! java strings are not js > string -> a priori expectations needed in Rhino - like you said - there > you have it! Heh. Nashorn internally sometimes doesn?t use strings for efficiency reasons, but we convert them into java.lang.String at runtime boundaries where they could be observed. > > Thanks for your work and the possibilities you provide us with a good js > engine for the Java platform. I am really thankful for that. I am > looking forward using Nashorn (hopefully) in the future. I am out for > now however. Thanks for taking the time to lay out your use case and for the civil discussion. It is appreciated. Attila. > > Christoph > > Am 04.02.2016 um 18:26 schrieb Attila Szegedi: >> Hi Cristoph, >> >> I presume you?re referring to this post: >> . >> >> I still stand by the design decisions we made when mapping the Java >> class/object system to JavaScript in Nashorn. I understand the >> differing opinions (yours and Tal?s both), and don?t consider them >> wrong, just having different requirement priorities. >> >> Have you considered that for a large established system, you might not >> want to change the underlying JavaScript engine? Rhino is yet again in >> active development, so a hopefully easier way to modernize your system >> would be to switch from JDK-embedded JavaScript runtime to Rhino as an >> external library. Ideally you?d just need to touch your script engine >> factory instantiation code. >> >> Even if you decide to switch to Nashorn, a hopefully smaller change >> would be to change the methods in your utility classes from being >> static to being instance methods. That would even keep the change >> cross-compatible with Rhino. (Of course, this doesn?t help you if you >> have some external dependencies where you can?t change the methods >> from static to instance?) >> >> In terms of future advice, there?s one other approach you might take, >> although unfortunately it won?t be available for JDK 8, just for JDK >> 9. Namely, in JDK 9 Nashorn can be extended with additional linkers >> (see e.g. Sundar?s recent post that uses extra linkers to bridge JS to >> Python https://blogs.oracle.com/sundararajan/entry/nashorn_javascript_access_to_python). >> It would be possible to write an additional Dynalink linker that >> recognizes missing members on POJOs and attempts to look up static >> methods instead. I know this doesn't help you now, but thought it >> might be worth mentioning it for completeness so it might help someone >> who digs this message out of an archive a year from now. >> >> As for ?creature? ? yes, you were misinterpreting it :-). ?A different >> kind of creature? here could be synonymous with ?a different cup of >> tea?, or ?another case?. I use the word as synonymous with ?being? >> (?something created?) without any intended negative overtones. I built >> fairly complex systems on top of Rhino in the past myself, and for a >> while both contributed to Rhino and served as the project?s >> administrator. I certainly have neither the moral ground nor the >> desire to diss Rhino or its users. >> >> Attila. >> >>> On Feb 4, 2016, at 7:18 AM, Christoph Sauer >>> >> wrote: >>> >>> Dear Attila, >>> >>> i was just evaluating a switch of our huge codebase written in >>> Javascript using the Rhino interpreter to Nashorn. We have utility >>> classes written in Java that are are passed as objects to help users >>> write less code in JS, because that is why we use JS >>> in the first place. Those utility objects also contain frequently used >>> static methods. Your design decisions will make it impossible for us to >>> switch. >>> >>> Not only will we have to rewrite our code, we also will have to make >>> separate calls to "handles" the user already has. This is against my >>> design decision to pursue the ideal of "literate programming". The ideal >>> to make code more readable is broken here. I agree with Tal Liron >>> that if a programmer wants to use Java, they would. We use Javascript >>> because of the shorthand and the goal towards cleaner code >>> without loosing the power of using Java where need be. >>> >>> I felt offended to be called a "Creature". I hope I misinterpret you >>> sentence here . >>> Two years have passed since this post. Have you changed your mind since? >>> Will there be at least a "strict" switch like suggested by tal? >>> >>> Thanks >>> Christoph >> > > > -- > Christoph Sauer > Gesch?ftsf?hrer > CEO > > nuveon GmbH > Felderstra?e 20 > 91801 Markt Berolzheim > > mobil : +49 (0) 170 / 272 76 76 > b?ro: +49 (0) 9146 / 95 990 01 > fax: +49 (0) 9146 / 94 220 45 From szegedia at gmail.com Thu Feb 11 14:38:24 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 11 Feb 2016 15:38:24 +0100 Subject: Review request for JDK-8149451: Fix bytecode generation issue after 8149186 In-Reply-To: <9137292E-AD38-4340-B5AE-3C646EA07CE1@oracle.com> References: <9137292E-AD38-4340-B5AE-3C646EA07CE1@oracle.com> Message-ID: <7850178F-286C-4A51-8F8C-A39DEBE8B145@gmail.com> This is frankly maddening :-) Sorry for wasting more of your time, but may I ask you for two additional, separate experiments? 1. instead of referencing Type.INT.add() just copy-paste the code from it 2. revert changes to LongType. Thanks, Attila. > On Feb 11, 2016, at 3:23 PM, Michael Haupt wrote: > > Hi Attila, > > I'm very sorry, but testing this I keep getting - occasionally! - crashes of the observed kind (see below). > > Best, > > Michael > > [java] Test(compile, run): test/script/external/test262/test/suite/ch15/15.5/15.5.4/15.5.4.19/S15.5.4.19_A7.js > [java] java.lang.AssertionError: Failed generating bytecode for test/script/external/test262/test/harness/sta.js:-1 > [java] at jdk.nashorn.internal.codegen.CompilationPhase$BytecodeGenerationPhase.transform(CompilationPhase.java:436) > [java] at jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:630) > [java] at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:656) > [java] at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compileTypeSpecialization(RecompilableScriptFunctionData.java:717) > [java] at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.getBest(RecompilableScriptFunctionData.java:897) > [java] at jdk.nashorn.internal.runtime.ScriptFunctionData.getBest(ScriptFunctionData.java:392) > [java] at jdk.nashorn.internal.runtime.ScriptFunctionData.getBestInvoker(ScriptFunctionData.java:254) > [java] at jdk.nashorn.internal.runtime.ScriptFunction.findCallMethod(ScriptFunction.java:915) > [java] at jdk.nashorn.internal.runtime.ScriptObject.lookup(ScriptObject.java:1862) > [java] at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:102) > [java] at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:94) > [java] at jdk.dynalink.linker.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:184) > [java] at jdk.dynalink.linker.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:132) > [java] at jdk.dynalink.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:146) > [java] at jdk.dynalink.DynamicLinker.relink(DynamicLinker.java:262) > [java] at jdk.nashorn.internal.scripts.Script$Recompilation$528212$18490D$sta.DaylightSavingTA(test/script/external/test262/test/harness/sta.js:651) > [java] at jdk.nashorn.internal.scripts.Script$Recompilation$528211$sta.:program(test/script/external/test262/test/harness/sta.js:566) > [java] at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:654) > [java] at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511) > [java] at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) > [java] at jdk.nashorn.internal.test.framework.SharedContextEvaluator.run(SharedContextEvaluator.java:135) > [java] at jdk.nashorn.internal.test.framework.AbstractScriptRunnable.evaluateScript(AbstractScriptRunnable.java:200) > [java] at jdk.nashorn.internal.test.framework.ParallelTestRunner$ScriptRunnable.execute(ParallelTestRunner.java:202) > [java] at jdk.nashorn.internal.test.framework.AbstractScriptRunnable.runTest(AbstractScriptRunnable.java:132) > [java] at jdk.nashorn.internal.test.framework.ParallelTestRunner$ScriptRunnable.call(ParallelTestRunner.java:281) > [java] at jdk.nashorn.internal.test.framework.ParallelTestRunner$ScriptRunnable.call(ParallelTestRunner.java:124) > [java] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [java] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1158) > [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) > [java] at java.lang.Thread.run(Thread.java:804) > [java] Caused by: java.lang.NullPointerException > >> Am 11.02.2016 um 13:28 schrieb Attila Szegedi : >> >> Please review JDK-8149451 "Fix bytecode generation issue after 8149186" at for >> >> This changeset is basically identical to JDK-8149186 but it will allow optimistic addition on booleans. I have implemented it by delegating to Type.INT.add instead of copy-pasting the code, but that should not cause issues (famous last words, right?). If you have the opportunity to re-test on Linux, that'd be appreciated (I have no Linux machines around). >> >> Thanks, >> Attila. > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing practices and products that help protect the environment > From szegedia at gmail.com Thu Feb 11 15:40:56 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 11 Feb 2016 16:40:56 +0100 Subject: RFR - JDK-8141209 $EXEC should allow streaming of output In-Reply-To: <36957C84-91D0-4089-810E-4CBFAA6C122A@oracle.com> References: <36957C84-91D0-4089-810E-4CBFAA6C122A@oracle.com> Message-ID: <8B151AC6-1C84-404F-BD7E-653D3C6B6C07@gmail.com> Few remarks (even though I see this was committed already): - ScriptingFunctions.exec declares IOException and InterruptedException, but these are never thrown by any code in the method. If the intent is for these to be propagated, it should be investigated if they?re inadvertently swallowed somewhere. - CommandExecutor.java:592 creates an unused ByteArrayInputStream (probably a leftover from editing as the same expression is repeated as one of the parameters in the line below it). Finally, CommandExecutor.createTokenizer and .stripQuotes could be static methods, and there?s a whole bunch of parameters and local variables that should be declared final. I?m just observing this for posterity as this is no big deal as we can have anybody with a configured IDE just pass it through it and it'll appropriately add the ?final? keywords where needed. Attila. > On Feb 9, 2016, at 9:18 PM, Jim Laskey (Oracle) wrote: > > https://bugs.openjdk.java.net/browse/JDK-8141209 > http://cr.openjdk.java.net/~jlaskey/8141209/webrev/index.html > > Rough documentation can be found at https://community.oracle.com/community/java/javascript-nashorn/blog/2016/02/08/proposal-for-exec-20 > From hannes.wallnoefer at oracle.com Fri Feb 12 12:55:35 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 12 Feb 2016 13:55:35 +0100 Subject: Review request for JDK-8147558: Add support for ES6 collections In-Reply-To: <36680DA8-578C-4811-9B75-353E322D7891@gmail.com> References: <56B476D4.8070708@gmail.com> <4F665A0D-C7F3-461F-AEE4-AF78D9AA97D4@gmail.com> <56B4ADFD.1090803@oracle.com> <36680DA8-578C-4811-9B75-353E322D7891@gmail.com> Message-ID: <56BDD647.6050002@oracle.com> Hi Attila, sorry for the interrupted conversation, I've been on vacation for most of this week. Having had some time to think about the synchronization issue I've come to agree with you. Making LinkedMap synchronized was overshooting the mark, and basically meant protecting against wrong use of Nashorn. I've uploaded a new webrev that follows most of your suggestions: http://cr.openjdk.java.net/~hannesw/8147558/webrev.01/ I've decided to keep the NativeArray methods in their slightly redundant form as I think the level of repetition is bearable and your distaste of it did not seem too strong :) Since the patch is quite large I've also uploaded a patch with just the changes from the first webrev: http://cr.openjdk.java.net/~hannesw/8147558/changes-attila Thanks, Hannes Am 2016-02-05 um 16:31 schrieb Attila Szegedi: > On Feb 5, 2016, at 3:13 PM, Hannes Wallnoefer wrote: >> Thanks for the review, Attila! >> >> Am 2016-02-05 um 14:17 schrieb Attila Szegedi: >>> Global.java: >>> - Documentation for Global.setWeakSet() is wrong. >>> - It?s kinda too bad we can?t generalize those getters with lazy sentinel and builtin getters. I guess we could if they weren?t stored in fields. Sounds like a good future use case for a VarHandle :-) >>> - Global.initPrototype uses the ?jdk.nashorn.internal.objects." string literal. It?s already used by Global.initConstructor too, maybe extract it into a constant? (FWIW, it also appears without the trailing dot in NashornLoader.java; maybe unify it into a single place somewhere?) >> Thanks, will fix the documentation and clean up the string literals. >> >>> NativeArray.java: >>> - I?d refactor the common idiom in entries, keys, values, and getIterator into a separate method parametrized on iteration kind. FWIW, getIterator and values look exactly the same. >> I'm not sure I understand. These are separate methods because each one defines a @Function for nasgen. Of course we could extend the @Function annotation to allow one Java method to define multiple JS functions. But these methods are one-liners anyway, so I doubt it would get much simpler. > private static Object createIterator(final Object self, final AbstractIterator.IterationKind kind) { > return new ArrayIterator(Global.toObject(self), kind, Global.instance()); > } > > then > > @Function(attributes = Attribute.NOT_ENUMERABLE) > public static Object entries(final Object self) { > return createIterator(AbstractIterator.IterationKind.KEY_VALUE); > } > > etc. No big deal, but I like to eliminate all copy-paste code. > >>> LinkedMap.java: >>> - why does it need to be safe for concurrent use? Seems unnecessary to me. >> You're right, it's not a requirement, but I think it's nice to have given the ubiquity of multithreading on the Java platform. > I?m still in disagreement. For one argument, that makes this class closer to Java 1.1 Hashtable than to HashMap. The trend in collection classes is to not make them thread safe unless they?re specifically concurrent. For another argument, we also consciously don?t make JS classes thread safe since the JS language is not thread safe, so we don?t want to incur synchronization overhead in the majority usage single-threaded case. ScriptObject is not thread safe either. It?s a design principle we followed so far: JS objects homed in a single global are not thread safe; backing structures shared across globals in a context (compiled functions etc.) are thread safe. Having a class that violates this distinction can provide a misunderstanding in someone reading the code about these design principles. > > Of course, if the class would start to be used in a different context too, then it might be justified to add synchronization to it (or just have it implement java.util.Map and use Collections.synchronizedMap when this is desired). > >>> WeakMap and WeakSet: didn?t you need the guarantees of LinkedMap with them too? I guess not. >> The weak collections do not allow elements to be iterated over, so this isn't an issue there. > Excellent. Thought there?s a reason :-) > >> Hannes From michael.haupt at oracle.com Fri Feb 12 15:30:00 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 12 Feb 2016 16:30:00 +0100 Subject: Review request for JDK-8149451: Fix bytecode generation issue after 8149186 In-Reply-To: <7850178F-286C-4A51-8F8C-A39DEBE8B145@gmail.com> References: <9137292E-AD38-4340-B5AE-3C646EA07CE1@oracle.com> <7850178F-286C-4A51-8F8C-A39DEBE8B145@gmail.com> Message-ID: Hi Attila, > Am 11.02.2016 um 15:38 schrieb Attila Szegedi : > This is frankly maddening :-) rightfully so, as it turns out this code is not the cause of the observed nightly failures. See https://bugs.openjdk.java.net/browse/JDK-8149727. The push for 8149186 merely coincided with the first nightly breaks. Sorry about the fuss. So, consider this a lower-case thumbs-up review. :-) Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Fri Feb 12 15:36:11 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 12 Feb 2016 16:36:11 +0100 Subject: RFR(S): 8149744: fix testng.jar delivery in Nashorn build.xml Message-ID: <35A8F0E8-CBE2-4D67-AAC1-FEAED70A9A5E@oracle.com> Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8149744 Webrev: http://cr.openjdk.java.net/~mhaupt/8149744/webrev.00/ Nashorn's build.xml used to download a TestNG ZIP file and extract the required testng.jar from that. The URL of the ZIP file is no longer valid. The change addresses this by having build.xml download the four required JAR files (TestNG and dependencies). Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Fri Feb 12 15:57:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 12 Feb 2016 21:27:04 +0530 Subject: RFR(S): 8149744: fix testng.jar delivery in Nashorn build.xml In-Reply-To: <35A8F0E8-CBE2-4D67-AAC1-FEAED70A9A5E@oracle.com> References: <35A8F0E8-CBE2-4D67-AAC1-FEAED70A9A5E@oracle.com> Message-ID: <56BE00D0.5070107@oracle.com> +1 On 2/12/2016 9:06 PM, Michael Haupt wrote: > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8149744 > Webrev: http://cr.openjdk.java.net/~mhaupt/8149744/webrev.00/ > > Nashorn's build.xml used to download a TestNG ZIP file and extract the required testng.jar from that. The URL of the ZIP file is no longer valid. The change addresses this by having build.xml download the four required JAR files (TestNG and dependencies). > > Thanks, > > Michael > From hannes.wallnoefer at oracle.com Fri Feb 12 15:57:41 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 12 Feb 2016 16:57:41 +0100 Subject: RFR(S): 8149744: fix testng.jar delivery in Nashorn build.xml In-Reply-To: <35A8F0E8-CBE2-4D67-AAC1-FEAED70A9A5E@oracle.com> References: <35A8F0E8-CBE2-4D67-AAC1-FEAED70A9A5E@oracle.com> Message-ID: <56BE00F5.5000703@oracle.com> +1 Am 2016-02-12 um 16:36 schrieb Michael Haupt: > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8149744 > Webrev: http://cr.openjdk.java.net/~mhaupt/8149744/webrev.00/ > > Nashorn's build.xml used to download a TestNG ZIP file and extract the required testng.jar from that. The URL of the ZIP file is no longer valid. The change addresses this by having build.xml download the four required JAR files (TestNG and dependencies). > > Thanks, > > Michael > From michael.haupt at oracle.com Mon Feb 15 11:32:22 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 15 Feb 2016 12:32:22 +0100 Subject: [8u] approval request for 8149744: fix testng.jar delivery in Nashorn build.xml Message-ID: <77ACAAAC-6487-4D40-B2C1-083E9E7B8364@oracle.com> Dear all, please approve the backport of the following patch to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8149744 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/005955.html 8u webrev: http://cr.openjdk.java.net/~mhaupt/8149744-8u/webrev.00/ The patch for 8u differs from the one for 9 as the affected files were different. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Mon Feb 15 12:48:37 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 15 Feb 2016 18:18:37 +0530 Subject: [8u] approval request for 8149744: fix testng.jar delivery in Nashorn build.xml In-Reply-To: <77ACAAAC-6487-4D40-B2C1-083E9E7B8364@oracle.com> References: <77ACAAAC-6487-4D40-B2C1-083E9E7B8364@oracle.com> Message-ID: <56C1C925.1050108@oracle.com> +1 On 2/15/2016 5:02 PM, Michael Haupt wrote: > Dear all, > > please approve the backport of the following patch to 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149744 > JDK 9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/005955.html > 8u webrev: http://cr.openjdk.java.net/~mhaupt/8149744-8u/webrev.00/ > > The patch for 8u differs from the one for 9 as the affected files were different. > > Thanks, > > Michael > From rob.mckenna at oracle.com Mon Feb 15 13:04:06 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 15 Feb 2016 13:04:06 +0000 Subject: [8u] approval request for 8149744: fix testng.jar delivery in Nashorn build.xml In-Reply-To: <56C1C925.1050108@oracle.com> References: <77ACAAAC-6487-4D40-B2C1-083E9E7B8364@oracle.com> <56C1C925.1050108@oracle.com> Message-ID: <56C1CCC6.8040401@oracle.com> Approved -Rob On 15/02/16 12:48, Sundararajan Athijegannathan wrote: > +1 > > > On 2/15/2016 5:02 PM, Michael Haupt wrote: >> Dear all, >> >> please approve the backport of the following patch to 8u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149744 >> JDK 9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/005955.html >> 8u webrev: http://cr.openjdk.java.net/~mhaupt/8149744-8u/webrev.00/ >> >> The patch for 8u differs from the one for 9 as the affected files >> were different. >> >> Thanks, >> >> Michael >> > From michael.haupt at oracle.com Mon Feb 15 15:04:43 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 15 Feb 2016 16:04:43 +0100 Subject: Review request for JDK-8149451: Fix bytecode generation issue after 8149186 In-Reply-To: References: <9137292E-AD38-4340-B5AE-3C646EA07CE1@oracle.com> <7850178F-286C-4A51-8F8C-A39DEBE8B145@gmail.com> Message-ID: <8E4AEC14-3BC9-4186-8675-55FBF49D6B64@oracle.com> Hi Attila, this may have been lost in the noise, but you have two reviews, and the nightly build failure only seemed to have anything to do with your change, so you're good to go. :-) Best, Michael > Am 12.02.2016 um 16:30 schrieb Michael Haupt : > > Hi Attila, > >> Am 11.02.2016 um 15:38 schrieb Attila Szegedi : >> This is frankly maddening :-) > > > rightfully so, as it turns out this code is not the cause of the observed nightly failures. See https://bugs.openjdk.java.net/browse/JDK-8149727. The push for 8149186 merely coincided with the first nightly breaks. Sorry about the fuss. > > So, consider this a lower-case thumbs-up review. :-) > > Best, > > Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Mon Feb 15 15:10:45 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 15 Feb 2016 20:40:45 +0530 Subject: Review request for JDK-8149451: Fix bytecode generation issue after 8149186 In-Reply-To: <8E4AEC14-3BC9-4186-8675-55FBF49D6B64@oracle.com> References: <9137292E-AD38-4340-B5AE-3C646EA07CE1@oracle.com> <7850178F-286C-4A51-8F8C-A39DEBE8B145@gmail.com> <8E4AEC14-3BC9-4186-8675-55FBF49D6B64@oracle.com> Message-ID: <56C1EA75.70801@oracle.com> +1 On 2/15/2016 8:34 PM, Michael Haupt wrote: > Hi Attila, > > this may have been lost in the noise, but you have two reviews, and the nightly build failure only seemed to have anything to do with your change, so you're good to go. :-) > > Best, > > Michael > >> Am 12.02.2016 um 16:30 schrieb Michael Haupt : >> >> Hi Attila, >> >>> Am 11.02.2016 um 15:38 schrieb Attila Szegedi : >>> This is frankly maddening :-) >> >> rightfully so, as it turns out this code is not the cause of the observed nightly failures. See https://bugs.openjdk.java.net/browse/JDK-8149727. The push for 8149186 merely coincided with the first nightly breaks. Sorry about the fuss. >> >> So, consider this a lower-case thumbs-up review. :-) >> >> Best, >> >> Michael From michael.haupt at oracle.com Mon Feb 15 15:52:03 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 15 Feb 2016 16:52:03 +0100 Subject: Review request for JDK-8147558: Add support for ES6 collections In-Reply-To: <56BDD647.6050002@oracle.com> References: <56B476D4.8070708@gmail.com> <4F665A0D-C7F3-461F-AEE4-AF78D9AA97D4@gmail.com> <56B4ADFD.1090803@oracle.com> <36680DA8-578C-4811-9B75-353E322D7891@gmail.com> <56BDD647.6050002@oracle.com> Message-ID: <88EBC6FC-C1E9-473D-99D3-E84D231256F5@oracle.com> Hi Hannes, lower-case thumbs up. Best, Michael > Am 12.02.2016 um 13:55 schrieb Hannes Wallnoefer : > > Hi Attila, > > sorry for the interrupted conversation, I've been on vacation for most of this week. > > Having had some time to think about the synchronization issue I've come to agree with you. Making LinkedMap synchronized was overshooting the mark, and basically meant protecting against wrong use of Nashorn. > > I've uploaded a new webrev that follows most of your suggestions: > > http://cr.openjdk.java.net/~hannesw/8147558/webrev.01/ > > I've decided to keep the NativeArray methods in their slightly redundant form as I think the level of repetition is bearable and your distaste of it did not seem too strong :) > > Since the patch is quite large I've also uploaded a patch with just the changes from the first webrev: > > http://cr.openjdk.java.net/~hannesw/8147558/changes-attila > > Thanks, > Hannes > > > Am 2016-02-05 um 16:31 schrieb Attila Szegedi: >> On Feb 5, 2016, at 3:13 PM, Hannes Wallnoefer wrote: >>> Thanks for the review, Attila! >>> >>> Am 2016-02-05 um 14:17 schrieb Attila Szegedi: >>>> Global.java: >>>> - Documentation for Global.setWeakSet() is wrong. >>>> - It?s kinda too bad we can?t generalize those getters with lazy sentinel and builtin getters. I guess we could if they weren?t stored in fields. Sounds like a good future use case for a VarHandle :-) >>>> - Global.initPrototype uses the ?jdk.nashorn.internal.objects." string literal. It?s already used by Global.initConstructor too, maybe extract it into a constant? (FWIW, it also appears without the trailing dot in NashornLoader.java; maybe unify it into a single place somewhere?) >>> Thanks, will fix the documentation and clean up the string literals. >>> >>>> NativeArray.java: >>>> - I?d refactor the common idiom in entries, keys, values, and getIterator into a separate method parametrized on iteration kind. FWIW, getIterator and values look exactly the same. >>> I'm not sure I understand. These are separate methods because each one defines a @Function for nasgen. Of course we could extend the @Function annotation to allow one Java method to define multiple JS functions. But these methods are one-liners anyway, so I doubt it would get much simpler. >> private static Object createIterator(final Object self, final AbstractIterator.IterationKind kind) { >> return new ArrayIterator(Global.toObject(self), kind, Global.instance()); >> } >> >> then >> >> @Function(attributes = Attribute.NOT_ENUMERABLE) >> public static Object entries(final Object self) { >> return createIterator(AbstractIterator.IterationKind.KEY_VALUE); >> } >> >> etc. No big deal, but I like to eliminate all copy-paste code. >> >>>> LinkedMap.java: >>>> - why does it need to be safe for concurrent use? Seems unnecessary to me. >>> You're right, it's not a requirement, but I think it's nice to have given the ubiquity of multithreading on the Java platform. >> I?m still in disagreement. For one argument, that makes this class closer to Java 1.1 Hashtable than to HashMap. The trend in collection classes is to not make them thread safe unless they?re specifically concurrent. For another argument, we also consciously don?t make JS classes thread safe since the JS language is not thread safe, so we don?t want to incur synchronization overhead in the majority usage single-threaded case. ScriptObject is not thread safe either. It?s a design principle we followed so far: JS objects homed in a single global are not thread safe; backing structures shared across globals in a context (compiled functions etc.) are thread safe. Having a class that violates this distinction can provide a misunderstanding in someone reading the code about these design principles. >> >> Of course, if the class would start to be used in a different context too, then it might be justified to add synchronization to it (or just have it implement java.util.Map and use Collections.synchronizedMap when this is desired). >> >>>> WeakMap and WeakSet: didn?t you need the guarantees of LinkedMap with them too? I guess not. >>> The weak collections do not allow elements to be iterated over, so this isn't an issue there. >> Excellent. Thought there?s a reason :-) >> >>> Hannes > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Tue Feb 16 14:40:05 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 16 Feb 2016 15:40:05 +0100 Subject: RFR(S): 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects Message-ID: <5014BC19-0F55-4ADE-97B8-C954FACF9C53@oracle.com> Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8148140 Webrev: http://cr.openjdk.java.net/~mhaupt/8148140/webrev.00/ The change fixes apply calls for functions defined as JSObjects by treating them like vararg calls (the arguments are passed in an array). Prior to the change, the code used to always collect arguments in an array, which led to apply calls being passed an array containing the argument array as the sole argument. Piggybacked: added copyright notice for one test. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Tue Feb 16 15:25:25 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 16 Feb 2016 16:25:25 +0100 Subject: RFR(S): 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects In-Reply-To: <5014BC19-0F55-4ADE-97B8-C954FACF9C53@oracle.com> References: <5014BC19-0F55-4ADE-97B8-C954FACF9C53@oracle.com> Message-ID: <56C33F65.4050901@oracle.com> +1 Am 2016-02-16 um 15:40 schrieb Michael Haupt: > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8148140 > Webrev: http://cr.openjdk.java.net/~mhaupt/8148140/webrev.00/ > > The change fixes apply calls for functions defined as JSObjects by treating them like vararg calls (the arguments are passed in an array). Prior to the change, the code used to always collect arguments in an array, which led to apply calls being passed an array containing the argument array as the sole argument. > > Piggybacked: added copyright notice for one test. > > Thanks, > > Michael > From sundararajan.athijegannathan at oracle.com Tue Feb 16 16:24:39 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 16 Feb 2016 21:54:39 +0530 Subject: RFR(S): 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects In-Reply-To: <5014BC19-0F55-4ADE-97B8-C954FACF9C53@oracle.com> References: <5014BC19-0F55-4ADE-97B8-C954FACF9C53@oracle.com> Message-ID: <56C34D47.9030105@oracle.com> +1 On 2/16/2016 8:10 PM, Michael Haupt wrote: > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8148140 > Webrev: http://cr.openjdk.java.net/~mhaupt/8148140/webrev.00/ > > The change fixes apply calls for functions defined as JSObjects by treating them like vararg calls (the arguments are passed in an array). Prior to the change, the code used to always collect arguments in an array, which led to apply calls being passed an array containing the argument array as the sole argument. > > Piggybacked: added copyright notice for one test. > > Thanks, > > Michael > From tomas at tzima.cz Mon Feb 22 23:47:38 2016 From: tomas at tzima.cz (=?UTF-8?B?VG9tw6HFoSBaw61tYQ==?=) Date: Tue, 23 Feb 2016 00:47:38 +0100 Subject: time limit for compiled script Message-ID: <56CB9E1A.9010007@tzima.cz> Hello, is there any recommended way to kill (compiled) unresponsive script? In a service we're running, pieces of JavaScript code are submitted by users and introducing some limitations is absolutely necessary. I'd like to avoid using deprecated stop() method on the thread, which is currently the only solution I can think of. I know it's dangerous to forcefully stop the execution as it can leave the application in an inconsistent or corrupted state (and that's why stop() is deprecated), but this is something I can't deal with right now. Thank you. -tzima From szegedia at gmail.com Tue Feb 23 01:36:09 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 22 Feb 2016 17:36:09 -0800 Subject: time limit for compiled script In-Reply-To: <56CB9E1A.9010007@tzima.cz> References: <56CB9E1A.9010007@tzima.cz> Message-ID: <8B895E17-7C4A-4D62-A50B-EC58283E99C3@gmail.com> There isn?t, and really there couldn?t be - by definition any external stopping would stop the script at unpredictable time, right? It can?t really be safer than Thread.stop(). Nashorn compiles to JVM bytecode; it?s as suitable for stopped execution as any Java class? code would be; which is to say, as well as with Thread.stop(). Attila. > On Feb 22, 2016, at 3:47 PM, Tom?? Z?ma wrote: > > Hello, > > is there any recommended way to kill (compiled) unresponsive script? In a service we're running, pieces of JavaScript code are submitted by users and introducing some limitations is absolutely necessary. I'd like to avoid using deprecated stop() method on the thread, which is currently the only solution I can think of. > > I know it's dangerous to forcefully stop the execution as it can leave the application in an inconsistent or corrupted state (and that's why stop() is deprecated), but this is something I can't deal with right now. > > Thank you. > -tzima > From rl_houtman at yahoo.com Tue Feb 23 14:40:17 2016 From: rl_houtman at yahoo.com (r houtman) Date: Tue, 23 Feb 2016 14:40:17 +0000 (UTC) Subject: nashorn memory footprint with large amount of compiled scripts References: <805321187.8787204.1456238417904.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <805321187.8787204.1456238417904.JavaMail.yahoo@mail.yahoo.com> Dear Devs, ?We?re running Nashorn on Java 1.8u45, and we?refacing issues because we require considerable scripts to run side by side.?We load about 2000 different javascripts andcompile them. Before starting the scripts the used JVM heap memoryis 177 MB and after compilation 468 MB. This is an avarage of 145 KB/script. Why is the memory consumption for a compiledscript so large? Are there settings which could reduce/optimize thememory footprint??Each script has its own memory context.The ?io? variable is an java-object stored in thememory context.Every script is executed every 100 msec withits own (same) memory context.An average script looks like this:?------------------------------------------------------------?var iPVar0 =io.input(1) == 1 ? Number(io.input(0)) : io.input(0);var iPVar1 =Number(io.input(2));var iPVar2 =io.input(4) == 1 ? Number(io.input(3)) : io.input(3);var iPVar3 =Number(io.input(5));var oPVar1_B;var oPVar2_TP;?if(iPVar0 =="AOF"){? io.output(0,io.input(6));? oPVar2_TP = 0;? oPVar1_B = 0;}else if(iPVar1 == 9 &&iPVar2 != 34){?io.output(0,io.input(7));? oPVar2_TP = 1;? if(iPVar3 ==0){???oPVar1_B = 1;? }else{???oPVar1_B = 0;? }}else if(iPVar3 == 0){?io.output(0,io.input(8));? oPVar2_TP = 0;? oPVar1_B = 1;}else{?io.output(0,io.input(9));? oPVar1_B = 0;? oPVar2_TP = 0;}?io.output(1,oPVar1_B);io.output(2,oPVar2_TP);---------------------------------------------------Kind regards ?? From forax at univ-mlv.fr Tue Feb 23 19:54:23 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 23 Feb 2016 20:54:23 +0100 (CET) Subject: time limit for compiled script In-Reply-To: <8B895E17-7C4A-4D62-A50B-EC58283E99C3@gmail.com> References: <56CB9E1A.9010007@tzima.cz> <8B895E17-7C4A-4D62-A50B-EC58283E99C3@gmail.com> Message-ID: <621823199.1025089.1456257263769.JavaMail.zimbra@u-pem.fr> Hi Attila, if your JavaScript is single threaded, you can stop the execution of the script as you want (you also need that the exception used to stop the script to be non catchable) or am i wrong ? R?mi ----- Mail original ----- > De: "Attila Szegedi" > ?: "Tom?? Z?ma" > Cc: nashorn-dev at openjdk.java.net > Envoy?: Mardi 23 F?vrier 2016 02:36:09 > Objet: Re: time limit for compiled script > > There isn?t, and really there couldn?t be - by definition any external > stopping would stop the script at unpredictable time, right? It can?t really > be safer than Thread.stop(). > > Nashorn compiles to JVM bytecode; it?s as suitable for stopped execution as > any Java class? code would be; which is to say, as well as with > Thread.stop(). > > Attila. > > > On Feb 22, 2016, at 3:47 PM, Tom?? Z?ma wrote: > > > > Hello, > > > > is there any recommended way to kill (compiled) unresponsive script? In a > > service we're running, pieces of JavaScript code are submitted by users > > and introducing some limitations is absolutely necessary. I'd like to > > avoid using deprecated stop() method on the thread, which is currently the > > only solution I can think of. > > > > I know it's dangerous to forcefully stop the execution as it can leave the > > application in an inconsistent or corrupted state (and that's why stop() > > is deprecated), but this is something I can't deal with right now. > > > > Thank you. > > -tzima > > > > From szegedia at gmail.com Tue Feb 23 23:08:16 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 23 Feb 2016 15:08:16 -0800 Subject: time limit for compiled script In-Reply-To: <621823199.1025089.1456257263769.JavaMail.zimbra@u-pem.fr> References: <56CB9E1A.9010007@tzima.cz> <8B895E17-7C4A-4D62-A50B-EC58283E99C3@gmail.com> <621823199.1025089.1456257263769.JavaMail.zimbra@u-pem.fr> Message-ID: Yeah, that was my point, really. You can still use Thread.stop(), and it'll throw a ThreadDeath, which is typically uncaught (it being an Error, not an Exception). On Tue, Feb 23, 2016 at 11:54 AM, Remi Forax wrote: > Hi Attila, > if your JavaScript is single threaded, you can stop the execution of the > script as you want > (you also need that the exception used to stop the script to be non > catchable) > > or am i wrong ? > > R?mi > > ----- Mail original ----- > > De: "Attila Szegedi" > > ?: "Tom?? Z?ma" > > Cc: nashorn-dev at openjdk.java.net > > Envoy?: Mardi 23 F?vrier 2016 02:36:09 > > Objet: Re: time limit for compiled script > > > > There isn?t, and really there couldn?t be - by definition any external > > stopping would stop the script at unpredictable time, right? It can?t > really > > be safer than Thread.stop(). > > > > Nashorn compiles to JVM bytecode; it?s as suitable for stopped execution > as > > any Java class? code would be; which is to say, as well as with > > Thread.stop(). > > > > Attila. > > > > > On Feb 22, 2016, at 3:47 PM, Tom?? Z?ma wrote: > > > > > > Hello, > > > > > > is there any recommended way to kill (compiled) unresponsive script? > In a > > > service we're running, pieces of JavaScript code are submitted by users > > > and introducing some limitations is absolutely necessary. I'd like to > > > avoid using deprecated stop() method on the thread, which is currently > the > > > only solution I can think of. > > > > > > I know it's dangerous to forcefully stop the execution as it can leave > the > > > application in an inconsistent or corrupted state (and that's why > stop() > > > is deprecated), but this is something I can't deal with right now. > > > > > > Thank you. > > > -tzima > > > > > > > > From Roland.Houtman at nl.yokogawa.com Wed Feb 24 15:32:39 2016 From: Roland.Houtman at nl.yokogawa.com (Houtman, Roland) Date: Wed, 24 Feb 2016 15:32:39 +0000 Subject: How to improve nashorn memory footprint with large amount of compiled scripts? Message-ID: Dear Devs, We're running Nashorn on Java 1.8u45, and we're facing issues because we require considerable scripts to run side by side. We load about 2000 different javascripts and compile them. Before starting the scripts the used JVM heap memory is 177 MB and after compilation 468 MB. This is an average of 145 KB/script. - Why is the memory consumption for a compiled script so large? - Are there settings which could reduce/optimize the memory footprint? The "io" variable is an java-object stored in the memory context. Every script is executed every 100 msec. Each script keeps its own memory context across executions. An average script looks like this: ------------------------------------------------------------ var iPVar0 = io.input(1) == 1 ? Number(io.input(0)) : io.input(0); var iPVar1 = Number(io.input(2)); var iPVar2 = io.input(4) == 1 ? Number(io.input(3)) : io.input(3); var iPVar3 = Number(io.input(5)); var oPVar1_B; var oPVar2_TP; if(iPVar0 == "AOF"){ io.output(0,io.input(6)); oPVar2_TP = 0; oPVar1_B = 0; }else if(iPVar1 == 9 && iPVar2 != 34){ io.output(0,io.input(7)); oPVar2_TP = 1; if(iPVar3 == 0){ oPVar1_B = 1; }else{ oPVar1_B = 0; } }else if(iPVar3 == 0){ io.output(0,io.input(8)); oPVar2_TP = 0; oPVar1_B = 1; }else{ io.output(0,io.input(9)); oPVar1_B = 0; oPVar2_TP = 0; } io.output(1,oPVar1_B); io.output(2,oPVar2_TP); --------------------------------------------------- Kind regards From sundararajan.athijegannathan at oracle.com Thu Feb 25 02:47:42 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 25 Feb 2016 08:17:42 +0530 Subject: RFR 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications Message-ID: <56CE6B4E.7040001@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8148379/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8148379 Specdiff is here -> http://cr.openjdk.java.net/~sundar/8148379/specdiff0.1/overview-summary.html Thanks, -Sundar From michael.haupt at oracle.com Thu Feb 25 07:31:35 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 25 Feb 2016 08:31:35 +0100 Subject: RFR 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications In-Reply-To: <56CE6B4E.7040001@oracle.com> References: <56CE6B4E.7040001@oracle.com> Message-ID: Hi Sundar, lower-case thumbs up. Best, Michael > Am 25.02.2016 um 03:47 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8148379/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8148379 > > Specdiff is here -> http://cr.openjdk.java.net/~sundar/8148379/specdiff0.1/overview-summary.html > > Thanks, > -Sundar -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Thu Feb 25 07:31:28 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 25 Feb 2016 08:31:28 +0100 Subject: RFR 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications In-Reply-To: <56CE6B4E.7040001@oracle.com> References: <56CE6B4E.7040001@oracle.com> Message-ID: <56CEADD0.2020409@oracle.com> +1 Am 2016-02-25 um 03:47 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8148379/webrev.01/ > for https://bugs.openjdk.java.net/browse/JDK-8148379 > > Specdiff is here -> > http://cr.openjdk.java.net/~sundar/8148379/specdiff0.1/overview-summary.html > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Thu Feb 25 11:31:51 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 25 Feb 2016 17:01:51 +0530 Subject: [8u] approval request for 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications In-Reply-To: <56CEE5FE.1010007@oracle.com> References: <56CEE5FE.1010007@oracle.com> Message-ID: <56CEE627.5070103@oracle.com> On 2/25/2016 5:01 PM, Sundararajan Athijegannathan wrote: > Please approve the following backport: > > bug: https://bugs.openjdk.java.net/browse/JDK-8148379 > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/005973.html > jdk8u webrev: http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/ > > the patch wouldn't apply 'as is' (apart from source layout changes). I > had to do manual merge in two files: > > build.xml: > > http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/make/build.xml.udiff.html > > > -- because jdk8u build.xml and jdk9-dev build.xml are different now > and hence line numbers don't match > > http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/src/jdk/nashorn/api/scripting/AbstractJSObject.java.udiff.html > > > -- 8u source is slightly different. > > I'm cc'ing nashorn-dev alias as well. > > -Sundar From Roland.Houtman at nl.yokogawa.com Thu Feb 25 11:48:35 2016 From: Roland.Houtman at nl.yokogawa.com (Houtman, Roland) Date: Thu, 25 Feb 2016 11:48:35 +0000 Subject: nashorn Java8u45 Message-ID: Dear Devs, Can someone tell me if compiled scripts are cached and reused when the same script-text is compiled again. Maybe in this version, or which version this does happen? Kind regards, Roland From hannes.wallnoefer at oracle.com Thu Feb 25 12:40:05 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 25 Feb 2016 13:40:05 +0100 Subject: nashorn Java8u45 In-Reply-To: References: Message-ID: <56CEF625.8050006@oracle.com> Hi Roland, I think caching of scripts within a global scope was implemented from the initial JDK8 release. In 8u20 we broadened this to ScriptEngine scope, meaning that multiple global scopes running within the same engine could share compiled scripts. The cache size is limited to 50 scripts by default, you can set that using the -ccs or --class-cache-size option and disable it all together by setting that option to 0. Hannes Am 2016-02-25 um 12:48 schrieb Houtman, Roland: > Dear Devs, > > Can someone tell me if compiled scripts are cached and reused when the same script-text is compiled again. > Maybe in this version, or which version this does happen? > > Kind regards, > Roland > From sean.coffey at oracle.com Thu Feb 25 12:44:41 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 25 Feb 2016 12:44:41 +0000 Subject: [8u] approval request for 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications In-Reply-To: <56CEE627.5070103@oracle.com> References: <56CEE5FE.1010007@oracle.com> <56CEE627.5070103@oracle.com> Message-ID: <56CEF739.7000807@oracle.com> I see you've already obtained CCC approval for JDK 8u. Approved but subject to peer code review. Regards, Sean. On 25/02/2016 11:31, Sundararajan Athijegannathan wrote: > > > On 2/25/2016 5:01 PM, Sundararajan Athijegannathan wrote: >> Please approve the following backport: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8148379 >> jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/005973.html >> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/ >> >> the patch wouldn't apply 'as is' (apart from source layout changes). >> I had to do manual merge in two files: >> >> build.xml: >> >> http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/make/build.xml.udiff.html >> >> >> -- because jdk8u build.xml and jdk9-dev build.xml are different now >> and hence line numbers don't match >> >> http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/src/jdk/nashorn/api/scripting/AbstractJSObject.java.udiff.html >> >> >> -- 8u source is slightly different. >> >> I'm cc'ing nashorn-dev alias as well. >> >> -Sundar > From hannes.wallnoefer at oracle.com Thu Feb 25 12:48:08 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 25 Feb 2016 13:48:08 +0100 Subject: [8u] approval request for 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications In-Reply-To: <56CEE627.5070103@oracle.com> References: <56CEE5FE.1010007@oracle.com> <56CEE627.5070103@oracle.com> Message-ID: <56CEF808.3050100@oracle.com> The backport looks good to me. Hannes Am 2016-02-25 um 12:31 schrieb Sundararajan Athijegannathan: > > > On 2/25/2016 5:01 PM, Sundararajan Athijegannathan wrote: >> Please approve the following backport: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8148379 >> jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/005973.html >> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/ >> >> the patch wouldn't apply 'as is' (apart from source layout changes). >> I had to do manual merge in two files: >> >> build.xml: >> >> http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/make/build.xml.udiff.html >> >> >> -- because jdk8u build.xml and jdk9-dev build.xml are different now >> and hence line numbers don't match >> >> http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/src/jdk/nashorn/api/scripting/AbstractJSObject.java.udiff.html >> >> >> -- 8u source is slightly different. >> >> I'm cc'ing nashorn-dev alias as well. >> >> -Sundar > From szegedia at gmail.com Sun Feb 28 02:53:34 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 28 Feb 2016 03:53:34 +0100 Subject: [8u] approval request for 8148379: jdk.nashorn.api.scripting spec. adjustments, clarifications In-Reply-To: <56CEF739.7000807@oracle.com> References: <56CEE5FE.1010007@oracle.com> <56CEE627.5070103@oracle.com> <56CEF739.7000807@oracle.com> Message-ID: <9E6E563C-E860-4B18-AE76-9D390EA58622@gmail.com> +1 on the backported changes. > On Feb 25, 2016, at 1:44 PM, Se?n Coffey wrote: > > I see you've already obtained CCC approval for JDK 8u. Approved but subject to peer code review. > > Regards, > Sean. > > On 25/02/2016 11:31, Sundararajan Athijegannathan wrote: >> >> >> On 2/25/2016 5:01 PM, Sundararajan Athijegannathan wrote: >>> Please approve the following backport: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8148379 >>> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/005973.html >>> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/ >>> >>> the patch wouldn't apply 'as is' (apart from source layout changes). I had to do manual merge in two files: >>> >>> build.xml: >>> >>> http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/make/build.xml.udiff.html >>> >>> -- because jdk8u build.xml and jdk9-dev build.xml are different now and hence line numbers don't match >>> >>> http://cr.openjdk.java.net/~sundar/8148379/8u/webrev.00/src/jdk/nashorn/api/scripting/AbstractJSObject.java.udiff.html >>> >>> -- 8u source is slightly different. >>> >>> I'm cc'ing nashorn-dev alias as well. >>> >>> -Sundar >> > From szegedia at gmail.com Sun Feb 28 03:05:14 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 28 Feb 2016 04:05:14 +0100 Subject: RFR(S): 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects In-Reply-To: <5014BC19-0F55-4ADE-97B8-C954FACF9C53@oracle.com> References: <5014BC19-0F55-4ADE-97B8-C954FACF9C53@oracle.com> Message-ID: <1D46C997-4693-4B69-8476-C5BD679DE4FE@gmail.com> Sorry, late to the party here, but it seems to me that there?s a discrepancy between the path and the "package jdk.nashorn.internal.runtime.test" declaration it contains. > On Feb 16, 2016, at 3:40 PM, Michael Haupt wrote: > > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8148140 > Webrev: http://cr.openjdk.java.net/~mhaupt/8148140/webrev.00/ > > The change fixes apply calls for functions defined as JSObjects by treating them like vararg calls (the arguments are passed in an array). Prior to the change, the code used to always collect arguments in an array, which led to apply calls being passed an array containing the argument array as the sole argument. > > Piggybacked: added copyright notice for one test. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing practices and products that help protect the environment > From szegedia at gmail.com Sun Feb 28 03:37:44 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 28 Feb 2016 04:37:44 +0100 Subject: Review request for JDK-8150218: Autoconversion SAM adapters sometimes don't get privileges Message-ID: <28825093-D3D2-4667-AEAF-9B83BECDF55F@gmail.com> Please review JDK-8150218 "Autoconversion SAM adapters sometimes don't get privileges" at for Thanks, Attila. From michael.haupt at oracle.com Mon Feb 29 08:07:36 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 29 Feb 2016 09:07:36 +0100 Subject: RFR(S): 8148140: arguments are handled differently in apply for JS functions and AbstractJSObjects In-Reply-To: <1D46C997-4693-4B69-8476-C5BD679DE4FE@gmail.com> References: <5014BC19-0F55-4ADE-97B8-C954FACF9C53@oracle.com> <1D46C997-4693-4B69-8476-C5BD679DE4FE@gmail.com> Message-ID: <6B4FFD6D-7A55-481E-A768-78886ED8E185@oracle.com> Hi Attila, > Am 28.02.2016 um 04:05 schrieb Attila Szegedi : > Sorry, late to the party here, but it seems to me that there?s a discrepancy between the path and the "package jdk.nashorn.internal.runtime.test" declaration it contains. whoa, thanks, Attila. Tracked in https://bugs.openjdk.java.net/browse/JDK-8150814, fix coming soon. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Mon Feb 29 08:12:16 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 29 Feb 2016 09:12:16 +0100 Subject: RFR(XXS): 8150814: correct package declaration in Nashorn test Message-ID: <3B698630-4F1A-4DFB-86C8-FF6F9C0FAB9C@oracle.com> Dear all, please review this very small fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8150814 Webrev: http://cr.openjdk.java.net/~mhaupt/8150814/webrev.00/ Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Mon Feb 29 08:38:07 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 29 Feb 2016 09:38:07 +0100 Subject: Review request for JDK-8150218: Autoconversion SAM adapters sometimes don't get privileges In-Reply-To: <28825093-D3D2-4667-AEAF-9B83BECDF55F@gmail.com> References: <28825093-D3D2-4667-AEAF-9B83BECDF55F@gmail.com> Message-ID: Hi Attila, > Am 28.02.2016 um 04:37 schrieb Attila Szegedi : > Please review JDK-8150218 "Autoconversion SAM adapters sometimes don't get privileges" at for lower-case thumbs up, with one remark about SecureLookupSupplier, lines 57/58: not sure the exact same text is really needed twice. :-) There also is a little webrev issue: the change for ScriptUtils.java is empty in the webrev, but appears in the patch. It seems this is because the change in that file is simply the removal of a single space character. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Mon Feb 29 08:42:31 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 29 Feb 2016 14:12:31 +0530 Subject: RFR(XXS): 8150814: correct package declaration in Nashorn test In-Reply-To: <3B698630-4F1A-4DFB-86C8-FF6F9C0FAB9C@oracle.com> References: <3B698630-4F1A-4DFB-86C8-FF6F9C0FAB9C@oracle.com> Message-ID: <56D40477.1090807@oracle.com> +1 On 2/29/2016 1:42 PM, Michael Haupt wrote: > Dear all, > > please review this very small fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8150814 > Webrev: http://cr.openjdk.java.net/~mhaupt/8150814/webrev.00/ > > Thanks, > > Michael > From sundararajan.athijegannathan at oracle.com Mon Feb 29 10:37:39 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 29 Feb 2016 16:07:39 +0530 Subject: Review request for JDK-8150218: Autoconversion SAM adapters sometimes don't get privileges In-Reply-To: <28825093-D3D2-4667-AEAF-9B83BECDF55F@gmail.com> References: <28825093-D3D2-4667-AEAF-9B83BECDF55F@gmail.com> Message-ID: <56D41F73.30402@oracle.com> +1 On 2/28/2016 9:07 AM, Attila Szegedi wrote: > Please review JDK-8150218 "Autoconversion SAM adapters sometimes don't get privileges" at for > > Thanks, > Attila. From szegedia at gmail.com Mon Feb 29 12:04:17 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 29 Feb 2016 13:04:17 +0100 Subject: RFR(XXS): 8150814: correct package declaration in Nashorn test In-Reply-To: <3B698630-4F1A-4DFB-86C8-FF6F9C0FAB9C@oracle.com> References: <3B698630-4F1A-4DFB-86C8-FF6F9C0FAB9C@oracle.com> Message-ID: +1 > On Feb 29, 2016, at 9:12 AM, Michael Haupt wrote: > > Dear all, > > please review this very small fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8150814 > Webrev: http://cr.openjdk.java.net/~mhaupt/8150814/webrev.00/ > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing practices and products that help protect the environment > From szegedia at gmail.com Mon Feb 29 12:14:33 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 29 Feb 2016 13:14:33 +0100 Subject: Review request for JDK-8150218: Autoconversion SAM adapters sometimes don't get privileges In-Reply-To: References: <28825093-D3D2-4667-AEAF-9B83BECDF55F@gmail.com> Message-ID: <35657A43-43AC-48AF-A944-518F9D80158A@gmail.com> On Feb 29, 2016, at 9:38 AM, Michael Haupt wrote: > > Hi Attila, > >> Am 28.02.2016 um 04:37 schrieb Attila Szegedi : >> Please review JDK-8150218 "Autoconversion SAM adapters sometimes don't get privileges" at for > > > lower-case thumbs up, with one remark about SecureLookupSupplier, lines 57/58: not sure the exact same text is really needed twice. :-) I agree, it can look silly, but that?s that?s pretty much the accepted practice for how getters are documented across JDK, e.g. > > > There also is a little webrev issue: the change for ScriptUtils.java is empty in the webrev, but appears in the patch. It seems this is because the change in that file is simply the removal of a single space character. Slightly annoying, yeah. I?ve come across this before too reading other people?s webrevs :-) Thanks, Attila. > > Best, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany > > ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > Oracle is committed to developing practices and products that help protect the environment > From srinivas.dama at oracle.com Mon Feb 29 16:28:43 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Mon, 29 Feb 2016 08:28:43 -0800 (PST) Subject: Review request for JDK-8138906 Message-ID: <310ec1a6-bd89-4cad-be27-b9f586071214@default> Hello All, Please review : Bug : https://bugs.openjdk.java.net/browse/JDK-8138906 Webrev : http://cr.openjdk.java.net/~sdama/8138906/webrev.01 Fix is to pick 'java' from specified JAVA_HOME folder, along with this, I have added some utility functions(can be added more) which can be used in all nashorn test case to make them work Independent of underlying shell.(removed dependency on shell commands like : which) Regards, Srinivas