From szegedia at gmail.com Thu Jul 7 10:51:26 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 7 Jul 2016 12:51:26 +0200 Subject: Review request for JDK-8160953: Update build-nagen-eclipse task to work with JDK 9 Message-ID: <6E50CF9C-56B6-4768-8440-F197E404193E@gmail.com> So, now that we finally seem to have an Eclipse Neon build that works reasonably well with JDK 9: Please review JDK-8160953 "Update build-nagen-eclipse task to work with JDK 9" at for Thanks, Attila. From mark.reinhold at oracle.com Thu Jul 7 19:00:11 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 7 Jul 2016 12:00:11 -0700 (PDT) Subject: JEP 292: Implement Selected ECMAScript 6 Features in Nashorn Message-ID: <20160707190011.D8515B7057@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/292 - Mark From marcus at lagergren.net Sat Jul 9 04:57:38 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Sat, 9 Jul 2016 06:57:38 +0200 Subject: Review request for JDK-8160953: Update build-nagen-eclipse task to work with JDK 9 In-Reply-To: <6E50CF9C-56B6-4768-8440-F197E404193E@gmail.com> References: <6E50CF9C-56B6-4768-8440-F197E404193E@gmail.com> Message-ID: + 1 Sent from my iPhone > On 07 Jul 2016, at 12:51, Attila Szegedi wrote: > > So, now that we finally seem to have an Eclipse Neon build that works reasonably well with JDK 9: > > Please review JDK-8160953 "Update build-nagen-eclipse task to work with JDK 9" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Tue Jul 12 05:31:16 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 12 Jul 2016 11:01:16 +0530 Subject: RFR 8149929: Nashorn Parser API needs to be updated for ES6 Message-ID: Please review http://cr.openjdk.java.net/~sundar/8149929/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8149929 Nashorn Parser JEP (http://openjdk.java.net/jeps/236) added Parser API for ECMAScript ES5.1 version. The current fix is to update the Parser API for ECMAScript 6. Specdiff for specification changes is here: http://cr.openjdk.java.net/~sundar/8149929/specdiff/overview-summary.html Thanks, -Sundar From emilian.bold at gmail.com Tue Jul 12 09:21:04 2016 From: emilian.bold at gmail.com (Emilian Bold) Date: Tue, 12 Jul 2016 12:21:04 +0300 Subject: Nashorn comment nodes in the syntax tree In-Reply-To: <8893b1c1-2db3-c4dc-faa7-cfae238c4bdf@oracle.com> References:

<8893b1c1-2db3-c4dc-faa7-cfae238c4bdf@oracle.com> Message-ID: Yes, it must be a bug: comments are certainly swallowed in the nodes on my JRE. I see this for FunctionNode but also for IdentNode and perhaps more. It makes getting actual offsets a pain and I would strip-out comments from the text before sending it to the parser, but I need those too. $ uname -a Darwin mac.local 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64 $ java -version java version "1.8.0_66" Java(TM) SE Runtime Environment (build 1.8.0_66-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) Java 1.8.0_66 Script text: --begin-- function hello(){ return 'world'; } //some comment hello(); --end-- [] function {U%}hello() Function text: --begin-- { return 'world'; } //some comment --end- junit.framework.AssertionFailedError: The function should not swallow the comment Test: package com; import jdk.nashorn.internal.ir.FunctionNode; import jdk.nashorn.internal.ir.LexicalContext; import jdk.nashorn.internal.ir.visitor.NodeVisitor; import jdk.nashorn.internal.runtime.ErrorManager; import jdk.nashorn.internal.runtime.ScriptEnvironment; import jdk.nashorn.internal.runtime.Source; import jdk.nashorn.internal.runtime.options.Options; import junit.framework.TestCase; import java.io.PrintWriter; public class NashornCommentBugTest extends TestCase { public void testComment(){ System.out.println("Java " + System.getProperty("java.version")); System.out.println(); String text = "function hello(){ \n" + " return 'world';\n" + "}\n\n" + "" + "//some comment\n" + "hello();"; Source source = Source.sourceFor("test.js", text); //NOI18N Options options = new Options("nashorn"); // NOI18N options.process(new String[]{ "--parse-only=true", // NOI18N "--empty-statements=true", // NOI18N "--debug-lines=false"}); // NOI18N ScriptEnvironment env = new ScriptEnvironment(options, new PrintWriter(System.out), new PrintWriter(System.err)); ErrorManager errorManager = new ErrorManager(); jdk.nashorn.internal.parser.Parser parser = new jdk.nashorn.internal.parser.Parser(env, source, errorManager); FunctionNode root = parser.parse(); System.out.println("Script text:\n--begin--\n" + text+"\n--end--\n"); root.accept(new NodeVisitor(new LexicalContext()) { @Override public boolean enterFunctionNode(FunctionNode functionNode) { if (!functionNode.getKind().equals(FunctionNode.Kind.SCRIPT)) { System.out.println(functionNode.toString()); String functionText = text.substring(functionNode.getStart(), functionNode.getFinish()); System.out.println("Function text:\n--begin--\n" + functionText+"\n--end-\n"); assertFalse("The function should not swallow the comment", functionText.contains("some comment")); } return super.enterFunctionNode(functionNode); } }); } } --emi On Mon, Jun 13, 2016 at 6:31 AM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > start and finish should not include comments around. If it does, it is a > bug. Please do file a bug and send us test case here and we'll file a bug > > Thanks, > > -Sundar > > On 6/10/2016 9:05 PM, Emilian Bold wrote: > > BTW, jdk.nashorn.internal.ir.IdentNode (and other classes) seem to have > the habit of "absorbing" the nearby comments and have incorrect > start/finish offsets. > > Is this intentional or a bug? > > I haven't tested yet but I wonder if it propagates to the TreeAPI (ie. > does IdentifierTree also swallow adjacent comments?) > > > > --emi > > On Wed, Apr 27, 2016 at 5:18 PM, Sundararajan Athijegannathan < > > sundararajan.athijegannathan at oracle.com> wrote: > >> Hi, >> >> I filed an enhancement request: >> https://bugs.openjdk.java.net/browse/JDK-8155242 >> >> Thanks, >> >> -Sundar >> >> >> On 4/27/2016 12:40 AM, Emilian Bold wrote: >> > Hello, >> > >> > NetBeans used a modified Rhino that had useful features for an IDE like >> > comment nodes and parser-level sanitization. >> > >> > As far as I know there is no way to get the comments in the Nashorn Tree >> > API (created as part of JEP 236) or in the jdk.nashorn.internal.ir Node >> > subclasses. >> > >> > Obviously having access to comment contents and comment offsets is very >> > useful. An IDE, for example, would provide code folding for the >> multiline >> > comment. >> > >> > Am I missing some proper way to get this information? >> > >> > I believe an extra option for Parser.create() would be nice (plus a >> > CommentTree and a visitComment method). >> > >> > --emi >> >> > > From michael.haupt at oracle.com Tue Jul 12 12:29:44 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 12 Jul 2016 14:29:44 +0200 Subject: RFR 8149929: Nashorn Parser API needs to be updated for ES6 In-Reply-To: References: Message-ID: Hi Sundar, congratulations on a titanic achievement. :-) Thumbs up, with one really minor remark. In ParserImpl, the two first lines here ... + String[] newArgs = new String[args.length + 1]; + System.arraycopy(args, 0, newArgs, 0, args.length); + newArgs[args.length] = "--parse-only"; ... could be replaced with ... String[] newArgs = Arrays.copyOf(args.length + 1); ... just to make the code look a bit less like assembler. :-) Best, Michael > Am 12.07.2016 um 07:31 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8149929/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8149929 > > Nashorn Parser JEP (http://openjdk.java.net/jeps/236) added Parser API > for ECMAScript ES5.1 version. The current fix is to update the Parser > API for ECMAScript 6. > > Specdiff for specification changes is here: > http://cr.openjdk.java.net/~sundar/8149929/specdiff/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 sundararajan.athijegannathan at oracle.com Tue Jul 12 13:08:18 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 12 Jul 2016 18:38:18 +0530 Subject: RFR 8149929: Nashorn Parser API needs to be updated for ES6 In-Reply-To: References:

Message-ID: Thanks for the review! Fixed ParserImpl.java to use Arrays.copyOf as suggested: http://cr.openjdk.java.net/~sundar/8149929/webrev.01 Thanks, -Sundar On 7/12/2016 5:59 PM, Michael Haupt wrote: > Hi Sundar, > > congratulations on a titanic achievement. :-) Thumbs up, with one > really minor remark. > > In ParserImpl, the two first lines here ... > > + String[] newArgs = new String[args.length + 1]; > + System.arraycopy(args, 0, newArgs, 0, args.length); > + newArgs[args.length] = "--parse-only"; > > ... could be replaced with ... > > String[] newArgs = Arrays.copyOf(args.length + 1); > > ... just to make the code look a bit less like assembler. :-) > > Best, > > Michael > >> Am 12.07.2016 um 07:31 schrieb Sundararajan Athijegannathan >> > >: >> >> Please review http://cr.openjdk.java.net/~sundar/8149929/webrev.00/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8149929 >> >> Nashorn Parser JEP (http://openjdk.java.net/jeps/236) added Parser API >> for ECMAScript ES5.1 version. The current fix is to update the Parser >> API for ECMAScript 6. >> >> Specdiff for specification changes is here: >> http://cr.openjdk.java.net/~sundar/8149929/specdiff/overview-summary.html >> >> Thanks, >> >> -Sundar >> >> > > -- > > Oracle > 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 > Green Oracle Oracle is committed > to developing practices and products that help protect the environment > > From hannes.wallnoefer at oracle.com Tue Jul 12 13:19:29 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 12 Jul 2016 15:19:29 +0200 Subject: RFR 8149929: Nashorn Parser API needs to be updated for ES6 In-Reply-To: References: Message-ID: <1CB81222-0E44-4250-8613-AE3390CE3643@oracle.com> Looks good. Great work, Sundar! Hannes > Am 12.07.2016 um 07:31 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8149929/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8149929 > > Nashorn Parser JEP (http://openjdk.java.net/jeps/236) added Parser API > for ECMAScript ES5.1 version. The current fix is to update the Parser > API for ECMAScript 6. > > Specdiff for specification changes is here: > http://cr.openjdk.java.net/~sundar/8149929/specdiff/overview-summary.html > > Thanks, > > -Sundar > > From axeld at pinc-software.de Wed Jul 13 07:39:06 2016 From: axeld at pinc-software.de (=?UTF-8?Q?Axel_D=c3=b6rfler?=) Date: Wed, 13 Jul 2016 09:39:06 +0200 Subject: Accessing static members Message-ID: <6d951c59-9aeb-0276-05aa-13efb1f8c91c@pinc-software.de> Hi there, I've tried something like the following code: Java: public abstract class A { public static final String STRING = "TEXT"; } public class B extends A { public static final String ANOTHER = "TEST"; } JavaScript: function accessString(instanceOfB) { print(instanceOfB.STRING); print(instanceOfB.ANOTHER); } Expected output would be: TEXT TEST Actual output is: undefined TEST I guess this is a bug? Bye, Axel. From sundararajan.athijegannathan at oracle.com Wed Jul 13 08:22:50 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 13 Jul 2016 13:52:50 +0530 Subject: Accessing static members In-Reply-To: <6d951c59-9aeb-0276-05aa-13efb1f8c91c@pinc-software.de> References: <6d951c59-9aeb-0276-05aa-13efb1f8c91c@pinc-software.de> Message-ID: <36a229b2-a3ab-a959-52c3-7008a677a554@oracle.com> Two things: 1) accessString function should be passed with "type" object obtained from Java.type [or Packages object]. i.e., It can not receive an instance of a Java class A or B. Nashorn does not allow static field to be accessible via objects. Only instance fields and methods are accessible via objects. 2) Even if you pass Java.type("A") or Java.type("B") to accessString function, only the static fields, methods of *exact* type are accessible via "type" objects. i.e., inherited static fields, methods are not accessible. Only static members of the exact Java type are accessible via type object. Hope this helps, -Sundar On 7/13/2016 1:09 PM, Axel D?rfler wrote: > Hi there, > > I've tried something like the following code: > Java: > > public abstract class A { > public static final String STRING = "TEXT"; > } > > public class B extends A { > public static final String ANOTHER = "TEST"; > } > > JavaScript: > > function accessString(instanceOfB) { > print(instanceOfB.STRING); > print(instanceOfB.ANOTHER); > } > > Expected output would be: > TEXT > TEST > > Actual output is: > undefined > TEST > > I guess this is a bug? > > Bye, > Axel. From inshua at gmail.com Thu Jul 14 11:32:46 2016 From: inshua at gmail.com (=?UTF-8?B?5paw5Lmw?=) Date: Thu, 14 Jul 2016 19:32:46 +0800 Subject: let's add awesome feature:clone the entire engine,or save and resume Message-ID: In the old rhino engine, there is a powerful feature: Continuation, Continuation give a chance to save the entire engine, and can store into file,db or other persistence. Rhino: Ability to pause, save state and resume javascript - Stack Overflow http://stackoverflow.com/questions/25837444/rhino-ability-to-pause-save-state-and-resume-javascript in my solution, i want a lot's of nashorn engines running and store and awake from disk. and clone engine is a best way to avoid run the initialize script on each nashorn engine. Hope you accept this amazing suggestion ^_^ Best Regards From sundararajan.athijegannathan at oracle.com Fri Jul 15 03:19:21 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 15 Jul 2016 08:49:21 +0530 Subject: Nashorn comment nodes in the syntax tree In-Reply-To: References:

<8893b1c1-2db3-c4dc-faa7-cfae238c4bdf@oracle.com> Message-ID: <2e7df619-1565-551e-ef9e-f57f5fbcedff@oracle.com> Hi, Sorry for the delayed response. I'm yet to check your test. I'll file a bug once I reproduce/check this at my end and let you know the bug id. Thanks, -Sundar On 7/12/2016 2:51 PM, Emilian Bold wrote: > Yes, it must be a bug: comments are certainly swallowed in the nodes > on my JRE. I see this for FunctionNode but also for IdentNode and > perhaps more. > > It makes getting actual offsets a pain and I would strip-out comments > from the text before sending it to the parser, but I need those too. > > $ uname -a > Darwin mac.local 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 > 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64 > > $ java -version > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > > Java 1.8.0_66 > > Script text: > --begin-- > function hello(){ > return 'world'; > } > > //some comment > hello(); > --end-- > > [] function {U%}hello() > Function text: > --begin-- > { > return 'world'; > } > > //some comment > --end- > > > junit.framework.AssertionFailedError: The function should not swallow > the comment > > > Test: > package com; import jdk.nashorn.internal.ir.FunctionNode; import > jdk.nashorn.internal.ir.LexicalContext; import > jdk.nashorn.internal.ir.visitor.NodeVisitor; import > jdk.nashorn.internal.runtime.ErrorManager; import > jdk.nashorn.internal.runtime.ScriptEnvironment; import > jdk.nashorn.internal.runtime.Source; import > jdk.nashorn.internal.runtime.options.Options; import > junit.framework.TestCase; import java.io.PrintWriter; public class > NashornCommentBugTest extends TestCase { public void testComment(){ > System.out.println("Java " + System.getProperty("java.version")); > System.out.println(); String text = "function hello(){ \n" + " return > 'world';\n" + "}\n\n" + "" + "//some comment\n" + "hello();"; Source > source = Source.sourceFor("test.js", text); //NOI18N Options options = > new Options("nashorn"); // NOI18N options.process(new String[]{ > "--parse-only=true", // NOI18N "--empty-statements=true", // NOI18N > "--debug-lines=false"}); // NOI18N ScriptEnvironment env = new > ScriptEnvironment(options, new PrintWriter(System.out), new > PrintWriter(System.err)); ErrorManager errorManager = new > ErrorManager(); jdk.nashorn.internal.parser.Parser parser = new > jdk.nashorn.internal.parser.Parser(env, source, errorManager); > FunctionNode root = parser.parse(); System.out.println("Script > text:\n--begin--\n" + text+"\n--end--\n"); root.accept(new > NodeVisitor(new LexicalContext()) { @Override public > boolean enterFunctionNode(FunctionNode functionNode) { if > (!functionNode.getKind().equals(FunctionNode.Kind.SCRIPT)) { > System.out.println(functionNode.toString()); String functionText = > text.substring(functionNode.getStart(), functionNode.getFinish()); > System.out.println("Function text:\n--begin--\n" + > functionText+"\n--end-\n"); assertFalse("The function should not > swallow the comment", functionText.contains("some comment")); } return > super.enterFunctionNode(functionNode); } }); } } > > > > > > --emi > > On Mon, Jun 13, 2016 at 6:31 AM, Sundararajan Athijegannathan > > wrote: > > start and finish should not include comments around. If it does, > it is a bug. Please do file a bug and send us test case here and > we'll file a bug > > Thanks, > > -Sundar > > > On 6/10/2016 9:05 PM, Emilian Bold wrote: >> BTW, jdk.nashorn.internal.ir.IdentNode (and other classes) seem >> to have the habit of "absorbing" the nearby comments and have >> incorrect start/finish offsets. >> >> Is this intentional or a bug? >> >> I haven't tested yet but I wonder if it propagates to the TreeAPI >> (ie. does IdentifierTree also swallow adjacent comments?) >> >> >> >> --emi >> >> On Wed, Apr 27, 2016 at 5:18 PM, Sundararajan Athijegannathan >> > > wrote: >> >> Hi, >> >> I filed an enhancement request: >> https://bugs.openjdk.java.net/browse/JDK-8155242 >> >> Thanks, >> >> -Sundar >> >> >> On 4/27/2016 12:40 AM, Emilian Bold wrote: >> > Hello, >> > >> > NetBeans used a modified Rhino that had useful features for >> an IDE like >> > comment nodes and parser-level sanitization. >> > >> > As far as I know there is no way to get the comments in the >> Nashorn Tree >> > API (created as part of JEP 236) or in the >> jdk.nashorn.internal.ir Node >> > subclasses. >> > >> > Obviously having access to comment contents and comment >> offsets is very >> > useful. An IDE, for example, would provide code folding for >> the multiline >> > comment. >> > >> > Am I missing some proper way to get this information? >> > >> > I believe an extra option for Parser.create() would be nice >> (plus a >> > CommentTree and a visitComment method). >> > >> > --emi >> >> > > From szegedia at gmail.com Tue Jul 19 09:58:47 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 19 Jul 2016 11:58:47 +0200 Subject: Review request for JDK-8160953: Update build-nagen-eclipse task to work with JDK 9 In-Reply-To: References: <6E50CF9C-56B6-4768-8440-F197E404193E@gmail.com> Message-ID: 2nd review anyone, or can I go ahead with one? > On 09 Jul 2016, at 06:57, Marcus Lagergren wrote: > > + 1 > > Sent from my iPhone > > On 07 Jul 2016, at 12:51, Attila Szegedi > wrote: > >> So, now that we finally seem to have an Eclipse Neon build that works reasonably well with JDK 9: >> >> Please review JDK-8160953 "Update build-nagen-eclipse task to work with JDK 9" at > for > >> >> Thanks, >> Attila. From sundararajan.athijegannathan at oracle.com Tue Jul 19 10:02:43 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 19 Jul 2016 15:32:43 +0530 Subject: Review request for JDK-8160953: Update build-nagen-eclipse task to work with JDK 9 In-Reply-To: References: <6E50CF9C-56B6-4768-8440-F197E404193E@gmail.com>

Message-ID: <578DFAC3.9070409@oracle.com> +1 On 19/07/16, 3:28 PM, Attila Szegedi wrote: > 2nd review anyone, or can I go ahead with one? > >> On 09 Jul 2016, at 06:57, Marcus Lagergren wrote: >> >> + 1 >> >> Sent from my iPhone >> >> On 07 Jul 2016, at 12:51, Attila Szegedi> wrote: >> >>> So, now that we finally seem to have an Eclipse Neon build that works reasonably well with JDK 9: >>> >>> Please review JDK-8160953 "Update build-nagen-eclipse task to work with JDK 9" at> for> >>> >>> Thanks, >>> Attila. From hannes.wallnoefer at oracle.com Tue Jul 19 16:20:38 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 19 Jul 2016 18:20:38 +0200 Subject: RFR 8160034: The `this` value in the `with` is broken by the repetition of a function call Message-ID: <4DD9BD9B-0C0B-43CC-8A45-3445BF851FA6@oracle.com> Please review: Webrev: http://cr.openjdk.java.net/~hannesw/8160034/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8160034 The change in ScriptObject.megamorphicGet actually fixes the bug. It took me quite some time that it could be fixed so elegantly at this level. Before that, I tried to fix it on the Method handle level in WithObject. The cleanup in WithObject.lookup is a leftover from that. I noticed that it implements code paths for both named and unnamed operations, but WithObjects are always in scope, and scope operations are always named, so I added an assertion for that and removed the code handling unnamed operations. Finally, the change in NashornGuards is to exclude properties from WithObject expressions from the special scope guards, using the ordinary map guard instead. Previously, these guards caused properties in with statements to relink even if with objects had the same map. Thanks, Hannes From szegedia at gmail.com Tue Jul 19 17:04:31 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 19 Jul 2016 19:04:31 +0200 Subject: RFR 8160034: The `this` value in the `with` is broken by the repetition of a function call In-Reply-To: <4DD9BD9B-0C0B-43CC-8A45-3445BF851FA6@oracle.com> References: <4DD9BD9B-0C0B-43CC-8A45-3445BF851FA6@oracle.com> Message-ID: <96D0CCA6-77CD-4C30-B413-67272B307C3B@gmail.com> > On 19 Jul 2016, at 18:20, Hannes Walln?fer wrote: > > Please review: > > Webrev: http://cr.openjdk.java.net/~hannesw/8160034/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8160034 > > The change in ScriptObject.megamorphicGet actually fixes the bug. It took me quite some time that it could be fixed so elegantly at this level. Before that, I tried to fix it on the Method handle level in WithObject. So? would you say this is a solution or a workaround? What I mean is that it is a nicely small change, but is it correct in all cases? Maybe it should be further constrained by both isMethod and isScope? (Not sure whether there?s a situation where it?s !isScope and would be incorrect, though) > The cleanup in WithObject.lookup is a leftover from that. I noticed that it implements code paths for both named and unnamed operations, but WithObjects are always in scope, and scope operations are always named, so I added an assertion for that and removed the code handling unnamed operations. Yep, that part is definitely nice, +1. > > Finally, the change in NashornGuards is to exclude properties from WithObject expressions from the special scope guards, using the ordinary map guard instead. Previously, these guards caused properties in with statements to relink even if with objects had the same map. +1 too. Attila. > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Wed Jul 20 10:29:18 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 20 Jul 2016 12:29:18 +0200 Subject: RFR 8160034: The `this` value in the `with` is broken by the repetition of a function call In-Reply-To: <96D0CCA6-77CD-4C30-B413-67272B307C3B@gmail.com> References: <4DD9BD9B-0C0B-43CC-8A45-3445BF851FA6@oracle.com> <96D0CCA6-77CD-4C30-B413-67272B307C3B@gmail.com> Message-ID: Thanks for the review, Attila. Answer below. > Am 19.07.2016 um 19:04 schrieb Attila Szegedi : > >> On 19 Jul 2016, at 18:20, Hannes Walln?fer wrote: >> >> Please review: >> >> Webrev: http://cr.openjdk.java.net/~hannesw/8160034/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8160034 >> >> The change in ScriptObject.megamorphicGet actually fixes the bug. It took me quite some time that it could be fixed so elegantly at this level. Before that, I tried to fix it on the Method handle level in WithObject. > > So? would you say this is a solution or a workaround? What I mean is that it is a nicely small change, but is it correct in all cases? Maybe it should be further constrained by both isMethod and isScope? (Not sure whether there?s a situation where it?s !isScope and would be incorrect, though) > Excellent questions! I was convinced this is correct in all cases, and that in fact with statements are the only occurrence of such FindProperties. But your remark made me check this and indeed the same pattern occurs for global lexical declarations in Global.LexicalScope, and in that case this behavior is not desired. Although I wasn?t able to reproduce this with lexical bindings, I?ll have to do something to make sure functions are only bound when they?re meant to. Thanks, Hannes >> The cleanup in WithObject.lookup is a leftover from that. I noticed that it implements code paths for both named and unnamed operations, but WithObjects are always in scope, and scope operations are always named, so I added an assertion for that and removed the code handling unnamed operations. > > Yep, that part is definitely nice, +1. > >> >> Finally, the change in NashornGuards is to exclude properties from WithObject expressions from the special scope guards, using the ordinary map guard instead. Previously, these guards caused properties in with statements to relink even if with objects had the same map. > > +1 too. > > Attila. > >> >> Thanks, >> Hannes > From szegedia at gmail.com Wed Jul 20 11:24:11 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 20 Jul 2016 13:24:11 +0200 Subject: RFR 8160034: The `this` value in the `with` is broken by the repetition of a function call In-Reply-To: References: <4DD9BD9B-0C0B-43CC-8A45-3445BF851FA6@oracle.com> <96D0CCA6-77CD-4C30-B413-67272B307C3B@gmail.com> Message-ID: <097BEAAD-780B-4CD1-B4F7-1568B8D3F111@gmail.com> On 20 Jul 2016, at 12:29, Hannes Walln?fer wrote: > > Thanks for the review, Attila. Answer below. > >> Am 19.07.2016 um 19:04 schrieb Attila Szegedi : >> >>> On 19 Jul 2016, at 18:20, Hannes Walln?fer wrote: >>> >>> Please review: >>> >>> Webrev: http://cr.openjdk.java.net/~hannesw/8160034/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160034 >>> >>> The change in ScriptObject.megamorphicGet actually fixes the bug. It took me quite some time that it could be fixed so elegantly at this level. Before that, I tried to fix it on the Method handle level in WithObject. >> >> So? would you say this is a solution or a workaround? What I mean is that it is a nicely small change, but is it correct in all cases? Maybe it should be further constrained by both isMethod and isScope? (Not sure whether there?s a situation where it?s !isScope and would be incorrect, though) >> > > Excellent questions! :-) Thanks. > I was convinced this is correct in all cases, and that in fact with statements are the only occurrence of such FindProperties. But your remark made me check this and indeed the same pattern occurs for global lexical declarations in Global.LexicalScope, and in that case this behavior is not desired. Frankly, I had something else in mind (I was thinking issues with functions defined in prototypes of the object used with ?with?), but I re-read the relevant code for FindProperty and realized that I was mixing up the roles of ?self" and ?prototype? there. But if I nudged you into checking something else, great :-) As far as I?m concerned, upon further reading the FindProperty and ScriptObject code, +1 from me, unless you find that you need to adjust things for lexical scope. > Although I wasn?t able to reproduce this with lexical bindings, I?ll have to do something to make sure functions are only bound when they?re meant to. > > Thanks, > Hannes Cheers, Attila. > > >>> The cleanup in WithObject.lookup is a leftover from that. I noticed that it implements code paths for both named and unnamed operations, but WithObjects are always in scope, and scope operations are always named, so I added an assertion for that and removed the code handling unnamed operations. >> >> Yep, that part is definitely nice, +1. >> >>> >>> Finally, the change in NashornGuards is to exclude properties from WithObject expressions from the special scope guards, using the ordinary map guard instead. Previously, these guards caused properties in with statements to relink even if with objects had the same map. >> >> +1 too. >> >> Attila. >> >>> >>> Thanks, >>> Hannes From emilian.bold at gmail.com Wed Jul 20 11:35:11 2016 From: emilian.bold at gmail.com (Emilian Bold) Date: Wed, 20 Jul 2016 14:35:11 +0300 Subject: Nashorn comment nodes in the syntax tree In-Reply-To: <2e7df619-1565-551e-ef9e-f57f5fbcedff@oracle.com> References:

<8893b1c1-2db3-c4dc-faa7-cfae238c4bdf@oracle.com> <2e7df619-1565-551e-ef9e-f57f5fbcedff@oracle.com> Message-ID: Here's another more nasty test. Note how comments before / after the AccessNode property are part of the text range and it becomes impossible to know where the property is located (short of parsing myself that). Java 1.8.0_66 Script text: --begin-- hello . //some comment world /* some other comment */ = 42; --end-- AccessNode text: --begin-- hello . //some comment world /* some other comment */ --end- AccessNode base text: --begin-- hello --end- AccessNode property (approximate) text: --begin-- . //some comment world /* some other comment */ --end- // @AlwaysFails public void testIdentifierComment(){ System.out.println("Java " + System.getProperty("java.version")); System.out.println(); String text = "hello . \n" + "//some comment\n" + "world /* some other comment */ = 42;"; Source source = Source.sourceFor("test.js", text); //NOI18N Options options = new Options("nashorn"); // NOI18N options.process(new String[]{ "--parse-only=true", // NOI18N "--empty-statements=true", // NOI18N "--debug-lines=false"}); // NOI18N ScriptEnvironment env = new ScriptEnvironment(options, new PrintWriter(System.out), new PrintWriter(System.err)); ErrorManager errorManager = new ErrorManager(); jdk.nashorn.internal.parser.Parser parser = new jdk.nashorn.internal.parser.Parser(env, source, errorManager); FunctionNode root = parser.parse(); System.out.println("Script text:\n--begin--\n" + text+"\n--end--\n"); root.accept(new NodeVisitor(new LexicalContext()) { @Override public boolean enterAccessNode(AccessNode accessNode) { String accessNodeText = text.substring(accessNode.getStart(), accessNode.getFinish()); String accessNodeBaseText = text.substring(accessNode.getBase().getStart(), accessNode.getBase().getFinish()); String propertyText = text.substring(accessNode.getBase().getFinish(), accessNode.getFinish()); System.out.println("AccessNode text:\n--begin--\n" + accessNodeText+"\n--end-\n"); System.out.println("AccessNode base text:\n--begin--\n" + accessNodeBaseText+"\n--end-\n"); System.out.println("AccessNode property (approximate) text:\n--begin--\n" + propertyText+"\n--end-\n"); assertFalse("The accessnode should not swallow the comment", accessNodeText.contains("some comment")); assertFalse("The property should not swallow the comment", propertyText.contains("some comment")); return super.enterAccessNode(accessNode); } }); } --emi On Fri, Jul 15, 2016 at 6:19 AM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > Sorry for the delayed response. I'm yet to check your test. I'll file a > bug once I reproduce/check this at my end and let you know the bug id. > > Thanks, > > -Sundar > > On 7/12/2016 2:51 PM, Emilian Bold wrote: > > Yes, it must be a bug: comments are certainly swallowed in the nodes on my > JRE. I see this for FunctionNode but also for IdentNode and perhaps more. > > It makes getting actual offsets a pain and I would strip-out comments from > the text before sending it to the parser, but I need those too. > > $ uname -a > Darwin mac.local 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 > PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64 > > $ java -version > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > > Java 1.8.0_66 > > Script text: > --begin-- > function hello(){ > return 'world'; > } > > //some comment > hello(); > --end-- > > [] function {U%}hello() > Function text: > --begin-- > { > return 'world'; > } > > //some comment > --end- > > > junit.framework.AssertionFailedError: The function should not swallow the > comment > > > Test: > package com; import jdk.nashorn.internal.ir.FunctionNode; import > jdk.nashorn.internal.ir.LexicalContext; import > jdk.nashorn.internal.ir.visitor.NodeVisitor; import > jdk.nashorn.internal.runtime.ErrorManager; import > jdk.nashorn.internal.runtime.ScriptEnvironment; import > jdk.nashorn.internal.runtime.Source; import > jdk.nashorn.internal.runtime.options.Options; import > junit.framework.TestCase; import java.io.PrintWriter; public class > NashornCommentBugTest extends TestCase { public void testComment(){ > System.out.println("Java " + System.getProperty("java.version")); > System.out.println(); String text = "function hello(){ \n" + " return > 'world';\n" + "}\n\n" + "" + "//some comment\n" + "hello();"; Source source > = Source.sourceFor("test.js", text); //NOI18N Options options = new > Options("nashorn"); // NOI18N options.process(new String[]{ > "--parse-only=true", // NOI18N "--empty-statements=true", // NOI18N > "--debug-lines=false"}); // NOI18N ScriptEnvironment env = new > ScriptEnvironment(options, new PrintWriter(System.out), new > PrintWriter(System.err)); ErrorManager errorManager = new ErrorManager(); > jdk.nashorn.internal.parser.Parser parser = new > jdk.nashorn.internal.parser.Parser(env, source, errorManager); FunctionNode > root = parser.parse(); System.out.println("Script text:\n--begin--\n" + > text+"\n--end--\n"); root.accept(new NodeVisitor(new > LexicalContext()) { @Override public boolean enterFunctionNode(FunctionNode > functionNode) { if > (!functionNode.getKind().equals(FunctionNode.Kind.SCRIPT)) { > System.out.println(functionNode.toString()); String functionText = > text.substring(functionNode.getStart(), functionNode.getFinish()); > System.out.println("Function text:\n--begin--\n" + > functionText+"\n--end-\n"); assertFalse("The function should not swallow > the comment", functionText.contains("some comment")); } return > super.enterFunctionNode(functionNode); } }); } } > > > > > > --emi > > On Mon, Jun 13, 2016 at 6:31 AM, Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com> wrote: > >> start and finish should not include comments around. If it does, it is a >> bug. Please do file a bug and send us test case here and we'll file a bug >> >> Thanks, >> >> -Sundar >> >> On 6/10/2016 9:05 PM, Emilian Bold wrote: >> >> BTW, jdk.nashorn.internal.ir.IdentNode (and other classes) seem to have >> the habit of "absorbing" the nearby comments and have incorrect >> start/finish offsets. >> >> Is this intentional or a bug? >> >> I haven't tested yet but I wonder if it propagates to the TreeAPI (ie. >> does IdentifierTree also swallow adjacent comments?) >> >> >> >> --emi >> >> On Wed, Apr 27, 2016 at 5:18 PM, Sundararajan Athijegannathan < >> sundararajan.athijegannathan at oracle.com> wrote: >> >>> Hi, >>> >>> I filed an enhancement request: >>> https://bugs.openjdk.java.net/browse/JDK-8155242 >>> >>> Thanks, >>> >>> -Sundar >>> >>> >>> On 4/27/2016 12:40 AM, Emilian Bold wrote: >>> > Hello, >>> > >>> > NetBeans used a modified Rhino that had useful features for an IDE like >>> > comment nodes and parser-level sanitization. >>> > >>> > As far as I know there is no way to get the comments in the Nashorn >>> Tree >>> > API (created as part of JEP 236) or in the jdk.nashorn.internal.ir >>> Node >>> > subclasses. >>> > >>> > Obviously having access to comment contents and comment offsets is very >>> > useful. An IDE, for example, would provide code folding for the >>> multiline >>> > comment. >>> > >>> > Am I missing some proper way to get this information? >>> > >>> > I believe an extra option for Parser.create() would be nice (plus a >>> > CommentTree and a visitComment method). >>> > >>> > --emi >>> >>> >> >> > > From szegedia at gmail.com Wed Jul 20 13:45:45 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 20 Jul 2016 15:45:45 +0200 Subject: Review request for JDK-8161928: Dynalink documentation updates Message-ID: <0680288D-190D-4E7C-A63C-82F36917A882@gmail.com> Please review JDK-8161928 "Dynalink documentation updates" at for Thanks, Attila. From szegedia at gmail.com Wed Jul 20 13:53:35 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 20 Jul 2016 15:53:35 +0200 Subject: Review request for JDK-8161929: FindProperty.isInherited never used standalone Message-ID: <744FBB10-34CC-4920-A278-7451587897C9@gmail.com> Please review JDK-8161929 "FindProperty.isInherited never used standalone" at for Thanks, Attila. From hannes.wallnoefer at oracle.com Wed Jul 20 14:08:26 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 20 Jul 2016 16:08:26 +0200 Subject: Review request for JDK-8161928: Dynalink documentation updates In-Reply-To: <0680288D-190D-4E7C-A63C-82F36917A882@gmail.com> References: <0680288D-190D-4E7C-A63C-82F36917A882@gmail.com> Message-ID: <7EEF84D8-D2C5-47DC-AA8E-0ECE3918B4C8@oracle.com> Looks good. Thanks, Attila! Hannes > Am 20.07.2016 um 15:45 schrieb Attila Szegedi : > > Please review JDK-8161928 "Dynalink documentation updates" at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Wed Jul 20 14:09:43 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 20 Jul 2016 16:09:43 +0200 Subject: Review request for JDK-8161929: FindProperty.isInherited never used standalone In-Reply-To: <744FBB10-34CC-4920-A278-7451587897C9@gmail.com> References: <744FBB10-34CC-4920-A278-7451587897C9@gmail.com> Message-ID: <4E908453-935B-45D7-87BB-05A22FD2FFAB@oracle.com> +1 Hannes > Am 20.07.2016 um 15:53 schrieb Attila Szegedi : > > Please review JDK-8161929 "FindProperty.isInherited never used standalone" at for > > Thanks, > Attila. From szegedia at gmail.com Wed Jul 20 14:35:51 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 20 Jul 2016 16:35:51 +0200 Subject: Review request for JDK-8161930: Cleanup ScriptObject warnings Message-ID: <44FA2AF1-1DCC-4184-9A5C-C9783CEBF789@gmail.com> Please review JDK-8161930 "Cleanup ScriptObject warnings" at for (Last one for the day!) Thanks, Attila. From hannes.wallnoefer at oracle.com Wed Jul 20 14:45:05 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 20 Jul 2016 16:45:05 +0200 Subject: Review request for JDK-8161930: Cleanup ScriptObject warnings In-Reply-To: <44FA2AF1-1DCC-4184-9A5C-C9783CEBF789@gmail.com> References: <44FA2AF1-1DCC-4184-9A5C-C9783CEBF789@gmail.com> Message-ID: Nice, +1. Hannes > Am 20.07.2016 um 16:35 schrieb Attila Szegedi : > > Please review JDK-8161930 "Cleanup ScriptObject warnings" at for > > (Last one for the day!) > > Thanks, > Attila. From srinivas.dama at oracle.com Wed Jul 20 14:54:26 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Wed, 20 Jul 2016 07:54:26 -0700 (PDT) Subject: RFR 8142969:Nashorn logging API requires testing Message-ID: <6e4f7576-680b-444d-aa83-0a8bdce22e0f@default> Hi, Please review http://cr.openjdk.java.net/~sdama/8142969/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8142969 Fixed the existing test case and moved it from test/script/currently-failing to test/script/nosecurity directory. Regards, Srinivas From sundararajan.athijegannathan at oracle.com Thu Jul 21 01:09:17 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 21 Jul 2016 06:39:17 +0530 Subject: Review request for JDK-8161928: Dynalink documentation updates In-Reply-To: <0680288D-190D-4E7C-A63C-82F36917A882@gmail.com> References: <0680288D-190D-4E7C-A63C-82F36917A882@gmail.com> Message-ID: <579020BD.6070700@oracle.com> +1 On 20/07/16, 7:15 PM, Attila Szegedi wrote: > Please review JDK-8161928 "Dynalink documentation updates" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Jul 21 01:11:06 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 21 Jul 2016 06:41:06 +0530 Subject: Review request for JDK-8161929: FindProperty.isInherited never used standalone In-Reply-To: <744FBB10-34CC-4920-A278-7451587897C9@gmail.com> References: <744FBB10-34CC-4920-A278-7451587897C9@gmail.com> Message-ID: <5790212A.1040900@oracle.com> +1 On 20/07/16, 7:23 PM, Attila Szegedi wrote: > Please review JDK-8161929 "FindProperty.isInherited never used standalone" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Jul 21 01:13:56 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 21 Jul 2016 06:43:56 +0530 Subject: Review request for JDK-8161930: Cleanup ScriptObject warnings In-Reply-To: <44FA2AF1-1DCC-4184-9A5C-C9783CEBF789@gmail.com> References: <44FA2AF1-1DCC-4184-9A5C-C9783CEBF789@gmail.com> Message-ID: <579021D4.7090603@oracle.com> +1 On 20/07/16, 8:05 PM, Attila Szegedi wrote: > Please review JDK-8161930 "Cleanup ScriptObject warnings" at for > > (Last one for the day!) > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Jul 21 01:18:11 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 21 Jul 2016 06:48:11 +0530 Subject: RFR 8142969:Nashorn logging API requires testing In-Reply-To: <6e4f7576-680b-444d-aa83-0a8bdce22e0f@default> References: <6e4f7576-680b-444d-aa83-0a8bdce22e0f@default> Message-ID: <579022D3.105@oracle.com> +1 On 20/07/16, 8:24 PM, Srinivas Dama wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8142969/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8142969 > > Fixed the existing test case and moved it from test/script/currently-failing to test/script/nosecurity directory. > > Regards, > Srinivas From michael.haupt at oracle.com Thu Jul 21 08:55:15 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 21 Jul 2016 10:55:15 +0200 Subject: RFR 8142969:Nashorn logging API requires testing In-Reply-To: <6e4f7576-680b-444d-aa83-0a8bdce22e0f@default> References: <6e4f7576-680b-444d-aa83-0a8bdce22e0f@default> Message-ID: Hi Srini, thumbs up; I've sponsored the push. Best, Michael > Am 20.07.2016 um 16:54 schrieb Srinivas Dama : > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8142969/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8142969 > > Fixed the existing test case and moved it from test/script/currently-failing to test/script/nosecurity directory. > > Regards, > Srinivas -- 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 Thu Jul 21 09:13:00 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 21 Jul 2016 11:13:00 +0200 Subject: RFR 8142969:Nashorn logging API requires testing In-Reply-To: References: <6e4f7576-680b-444d-aa83-0a8bdce22e0f@default> Message-ID: <0A7895C1-429A-4724-BE31-2B4722C306D0@oracle.com> Hi Srini, it turns out I accidentally pushed under my user ID. Sorry about that. Best, Michael > Am 21.07.2016 um 10:55 schrieb Michael Haupt : > > Hi Srini, > > thumbs up; I've sponsored the push. > > Best, > > Michael > >> Am 20.07.2016 um 16:54 schrieb Srinivas Dama : >> >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8142969/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8142969 >> >> Fixed the existing test case and moved it from test/script/currently-failing to test/script/nosecurity directory. >> >> Regards, >> Srinivas -- 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 Jul 21 11:38:31 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 21 Jul 2016 13:38:31 +0200 Subject: RFR 8160034: The `this` value in the `with` is broken by the repetition of a function call In-Reply-To: <097BEAAD-780B-4CD1-B4F7-1568B8D3F111@gmail.com> References: <4DD9BD9B-0C0B-43CC-8A45-3445BF851FA6@oracle.com> <96D0CCA6-77CD-4C30-B413-67272B307C3B@gmail.com> <097BEAAD-780B-4CD1-B4F7-1568B8D3F111@gmail.com> Message-ID: <00BEB4D1-02C3-43F0-8EDA-F93D4C270245@oracle.com> After trying various things, I think the best solution is to introduce a new ?internal? ScriptObject flag to avoid leaking the global lexical scope (and possibly other internal objects) to scripts. In addition to Global.LexicalScope I also set this flag on WithObjects themselves, although that shouldn?t be required for the current case. The new webrev is here, please review: http://cr.openjdk.java.net/~hannesw/8160034/webrev.01/ Hannes > Am 20.07.2016 um 13:24 schrieb Attila Szegedi : > > On 20 Jul 2016, at 12:29, Hannes Walln?fer wrote: >> >> Thanks for the review, Attila. Answer below. >> >>> Am 19.07.2016 um 19:04 schrieb Attila Szegedi : >>> >>>> On 19 Jul 2016, at 18:20, Hannes Walln?fer wrote: >>>> >>>> Please review: >>>> >>>> Webrev: http://cr.openjdk.java.net/~hannesw/8160034/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160034 >>>> >>>> The change in ScriptObject.megamorphicGet actually fixes the bug. It took me quite some time that it could be fixed so elegantly at this level. Before that, I tried to fix it on the Method handle level in WithObject. >>> >>> So? would you say this is a solution or a workaround? What I mean is that it is a nicely small change, but is it correct in all cases? Maybe it should be further constrained by both isMethod and isScope? (Not sure whether there?s a situation where it?s !isScope and would be incorrect, though) >>> >> >> Excellent questions! > > :-) Thanks. > >> I was convinced this is correct in all cases, and that in fact with statements are the only occurrence of such FindProperties. But your remark made me check this and indeed the same pattern occurs for global lexical declarations in Global.LexicalScope, and in that case this behavior is not desired. > > Frankly, I had something else in mind (I was thinking issues with functions defined in prototypes of the object used with ?with?), but I re-read the relevant code for FindProperty and realized that I was mixing up the roles of ?self" and ?prototype? there. But if I nudged you into checking something else, great :-) > > As far as I?m concerned, upon further reading the FindProperty and ScriptObject code, +1 from me, unless you find that you need to adjust things for lexical scope. > >> Although I wasn?t able to reproduce this with lexical bindings, I?ll have to do something to make sure functions are only bound when they?re meant to. >> >> Thanks, >> Hannes > > Cheers, > Attila. From hannes.wallnoefer at oracle.com Thu Jul 21 15:19:14 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 21 Jul 2016 17:19:14 +0200 Subject: RFR: 8068972: Array.splice should follow the ES6 specification Message-ID: Please review: Webrev: http://cr.openjdk.java.net/~hannesw/8068972/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8068972 This updates the implementation of Array.prototype.splice to conform with ES6 when called with a single argument. Hannes From sundararajan.athijegannathan at oracle.com Fri Jul 22 07:38:01 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 22 Jul 2016 13:08:01 +0530 Subject: Nashorn comment nodes in the syntax tree Message-ID: <08d3c097-62fc-48bf-ded1-b8036b4715a5@oracle.com> Hi, Yes, comments are swallowed (by design). But, I initially though that disturbs line & column number info. [i.e., position of various trees]. i.e., that was the bug you reported. That does not seem to be the case. I wrote a simple sample and checked with jjs in jdk9 build. You can check start and end line/column numbers of subtrees (function, expression statement) are correct. Also, please note that jdk.nashorn.internal.* packages are not APIs and therefore please avoid using those. Please use nashorn parser API defined by JEP 236 [ http://openjdk.java.net/jeps/236 ] #-scripting needed var Parser = Java.type("jdk.nashorn.api.tree.Parser") var p = Parser.create(); var cu = p.parse("t.js", < Hello, Please review http://cr.openjdk.java.net/~sdama/8160801/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8160801 Regards, Srinivas From michael.haupt at oracle.com Tue Jul 26 12:36:24 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 26 Jul 2016 14:36:24 +0200 Subject: RFR 8160801 :add documentation for NativeString In-Reply-To: References: Message-ID: <6C966F49-3036-4181-AB0A-D312F664F3A6@oracle.com> Hi Srini, thumbs up, with conditions (see below). I'll be happy to sponsor the push. +String.prototype.concat=returns string value which is mix of calling object string value and string value given as argument A mix would be fun. :-) How about this: returns the string resulting from appending the argument string value to the calling object +String.prototype.indexOf=returns the index of first occurrence of specified string, starting the search from position given as argument.returns -1 if the string is not found + +String.prototype.lastIndexOf=returns the index of last occurrence of specified string, searching backwards from position given as argument.returns -1 if the string is not found Please replace ".returns" with ", returns" (note the extra space). Best, Michael > Am 26.07.2016 um 13:57 schrieb Srinivas Dama : > > Hello, > > Please review http://cr.openjdk.java.net/~sdama/8160801/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8160801 > > Regards, > Srinivas -- 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 Jul 26 12:43:39 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 26 Jul 2016 14:43:39 +0200 Subject: RFR: 8068972: Array.splice should follow the ES6 specification In-Reply-To: References: Message-ID: <21B66518-F01F-4657-93E8-5C07DB83E609@oracle.com> Hi Hannes, thumbs up. Best, Michael > Am 21.07.2016 um 17:19 schrieb Hannes Walln?fer : > > Please review: > > Webrev: http://cr.openjdk.java.net/~hannesw/8068972/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8068972 > > This updates the implementation of Array.prototype.splice to conform with ES6 when called with a single argument. > > 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 james.laskey at oracle.com Tue Jul 26 12:50:50 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 26 Jul 2016 09:50:50 -0300 Subject: RFR: 8068972: Array.splice should follow the ES6 specification In-Reply-To: References: Message-ID: <1E1656B8-18CB-4965-8E3A-47B69BF90F93@oracle.com> +1 > On Jul 21, 2016, at 12:19 PM, Hannes Walln?fer wrote: > > Please review: > > Webrev: http://cr.openjdk.java.net/~hannesw/8068972/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8068972 > > This updates the implementation of Array.prototype.splice to conform with ES6 when called with a single argument. > > Hannes From srinivas.dama at oracle.com Wed Jul 27 10:41:36 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Wed, 27 Jul 2016 03:41:36 -0700 (PDT) Subject: RFR 8160801 :add documentation for NativeString In-Reply-To: <6C966F49-3036-4181-AB0A-D312F664F3A6@oracle.com> References: <6C966F49-3036-4181-AB0A-D312F664F3A6@oracle.com> Message-ID: <2c4a4b10-5755-471f-a686-865ddbc54cc5@default> Hi Michael, ? Thank you for comments . ? Please find patch with your suggestions added at http://cr.openjdk.java.net/~sdama/8160801/webrev.00/ ? Regards, Srinivas ? From: Michael Haupt Sent: Tuesday, July 26, 2016 6:06 PM To: Srinivas Dama Cc: Nashorn-dev Subject: Re: RFR 8160801 :add documentation for NativeString ? Hi Srini, ? thumbs up, with conditions (see below). I'll be happy to sponsor the push. ? +String.prototype.concat=returns string value which is mix of calling object string value and string value given as argument ? A mix would be fun. :-) How about this: returns the string resulting from appending the argument string value to the calling object +String.prototype.indexOf=returns the index of first occurrence of specified string, starting the search from position given as argument.returns -1 if the string is not found + +String.prototype.lastIndexOf=returns the index of last occurrence of specified string, searching backwards from position given as argument.returns -1 if the string is not found ? Please replace ".returns" with ", returns" (note the extra space). ? Best, ? Michael ? Am 26.07.2016 um 13:57 schrieb Srinivas Dama : ? Hello, Please review http://cr.openjdk.java.net/~sdama/8160801/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8160801 Regards, Srinivas ? --? HYPERLINK "http://www.oracle.com/" \nOracle 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 HYPERLINK "http://www.oracle.com/commitment" \nGreen Oracle Oracle is committed to developing practices and products that help protect the environment ? From hannes.wallnoefer at oracle.com Fri Jul 29 13:07:05 2016 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 29 Jul 2016 15:07:05 +0200 Subject: RFR: 8162771: Strict equality operators should not be optimistic Message-ID: <3584B1AA-7E4D-4563-AAA7-E5A231604BE0@oracle.com> Please review 8162771: Strict equality operators should not be optimistic. Bug: https://bugs.openjdk.java.net/browse/JDK-8162771 Webrev: http://cr.openjdk.java.net/~hannesw/8162771/webrev/ Thanks, Hannes