From brian.goetz at oracle.com Mon Oct 1 16:08:21 2018 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 01 Oct 2018 16:08:21 +0000 Subject: hg: amber/amber: Remove implements-Constable from XxxDesc lcasses, will come back when symbolic-mode BSMs are available Message-ID: <201810011608.w91G8LeE024844@aojmv0008.oracle.com> Changeset: 0bcf1413c14f Author: briangoetz Date: 2018-10-01 12:06 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/0bcf1413c14f Remove implements-Constable from XxxDesc lcasses, will come back when symbolic-mode BSMs are available ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/constant/AsTypeMethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/ClassDesc.java ! src/java.base/share/classes/java/lang/constant/ConstantDescs.java ! src/java.base/share/classes/java/lang/constant/ConstantUtils.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDescImpl.java ! src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java ! src/java.base/share/classes/java/lang/constant/PrimitiveClassDescImpl.java ! src/java.base/share/classes/java/lang/constant/ReferenceClassDescImpl.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! test/jdk/java/lang/constant/SymbolicDescTest.java ! test/jdk/java/lang/constant/boottest/java.base/java/lang/constant/ConstantUtilsTest.java From john.r.rose at oracle.com Mon Oct 1 18:06:31 2018 From: john.r.rose at oracle.com (John Rose) Date: Mon, 1 Oct 2018 11:06:31 -0700 Subject: Bug when lowering a method ref (concise method) In-Reply-To: <28920591.62806.1538313117778.JavaMail.zimbra@u-pem.fr> References: <28920591.62806.1538313117778.JavaMail.zimbra@u-pem.fr> Message-ID: <813750F2-0ED8-48D3-91D0-8923166818A3@oracle.com> On Sep 30, 2018, at 6:11 AM, Remi Forax wrote: > > public void run() -> null; Random thoughts on null for void, and returning a "safe default"? When we get to reified generics, there will be this: interface HasM { default T m() -> T.default; } There's also the usual question of "why isn't void a type"? And if void were a type, and still more a nullable type, then the "-> null" would be valid. But if void were a primitive type, and Void were its wrapper. In that case passing (Void)null up to void deserves NPE, just as passing (Integer)null up to int gets NPE. Unless declaring void as nullable allowed it to avoid that fate. ? John From brian.goetz at oracle.com Mon Oct 1 18:49:49 2018 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 01 Oct 2018 18:49:49 +0000 Subject: hg: amber/amber: Add Kind::valueOf methods tin DirectMethodHandleDesc Message-ID: <201810011849.w91Innu9008737@aojmv0008.oracle.com> Changeset: e8be92b72e89 Author: briangoetz Date: 2018-10-01 14:49 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/e8be92b72e89 Add Kind::valueOf methods tin DirectMethodHandleDesc ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java ! test/jdk/java/lang/constant/MethodHandleDescTest.java From forax at univ-mlv.fr Mon Oct 1 21:59:49 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 1 Oct 2018 23:59:49 +0200 (CEST) Subject: Bug when lowering a method ref (concise method) In-Reply-To: <813750F2-0ED8-48D3-91D0-8923166818A3@oracle.com> References: <28920591.62806.1538313117778.JavaMail.zimbra@u-pem.fr> <813750F2-0ED8-48D3-91D0-8923166818A3@oracle.com> Message-ID: <520551810.6096.1538431189506.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "Remi Forax" > Cc: "Vicente Romero" , "amber-dev" > > Envoy?: Lundi 1 Octobre 2018 20:06:31 > Objet: Re: Bug when lowering a method ref (concise method) > On Sep 30, 2018, at 6:11 AM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> public void run() -> null; > Random thoughts on null for void, and returning a "safe default"? > When we get to reified generics, there will be this: > interface HasM { default T m() -> T.default; } > There's also the usual question of "why isn't void a type"? > And if void were a type, and still more a nullable type, > then the "-> null" would be valid. > But if void were a primitive type, and Void were its wrapper. > In that case passing (Void)null up to void deserves NPE, > just as passing (Integer)null up to int gets NPE. Unless > declaring void as nullable allowed it to avoid that fate. as we said in another discussion, void can be retconed (in the additive way) to be an empty value type, in that case the only possible value of void is void.default. > ? John R?mi From vicente.romero at oracle.com Tue Oct 2 00:18:49 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 02 Oct 2018 00:18:49 +0000 Subject: hg: amber/amber: fixing assertion during parsing Message-ID: <201810020018.w920IoZc009367@aojmv0008.oracle.com> Changeset: 531a0335dc49 Author: vromero Date: 2018-10-01 16:54 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/531a0335dc49 fixing assertion during parsing ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! test/langtools/tools/javac/concise_methods/ConciseMethodsNegTest01.java ! test/langtools/tools/javac/concise_methods/ConciseMethodsNegTest01.out From vicente.romero at oracle.com Tue Oct 2 02:54:34 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 02 Oct 2018 02:54:34 +0000 Subject: hg: amber/amber: verifier error when inner class access field of enclosing class Message-ID: <201810020254.w922sZr8014272@aojmv0008.oracle.com> Changeset: fbed49487ec4 Author: vromero Date: 2018-10-01 19:37 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/fbed49487ec4 verifier error when inner class access field of enclosing class ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/langtools/tools/javac/concise_methods/VerifierErrorAccessingFieldEnclosingClass.java From forax at univ-mlv.fr Tue Oct 2 15:15:42 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 2 Oct 2018 17:15:42 +0200 (CEST) Subject: Bug when lowering a method ref (concise method) In-Reply-To: <28920591.62806.1538313117778.JavaMail.zimbra@u-pem.fr> References: <28920591.62806.1538313117778.JavaMail.zimbra@u-pem.fr> Message-ID: <1140841583.125368.1538493342839.JavaMail.zimbra@u-pem.fr> Hi Vicente, the test case public class ConciseMethodRef implements Runnable { public void run() { } Runnable f(Runnable r) -> r; void m() = f(this)::run; } still cause an issue. java.lang.NullPointerException at jdk.compiler/com.sun.tools.javac.tree.TreeMaker.Ident(TreeMaker.java:681) at jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDefInternal(Lower.java:2552) at jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDef(Lower.java:2449) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2084) at jdk.compiler/com.sun.tools.javac.comp.Lower.visitClassDef(Lower.java:2222) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:780) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2084) at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2103) at jdk.compiler/com.sun.tools.javac.comp.Lower.translateTopLevelClass(Lower.java:3854) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1579) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) at jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) at least with jdk 12-amber+0-fbed49487ec4 R?mi ----- Mail original ----- > De: "Remi Forax" > ?: "Vicente Romero" , "amber-dev" > Envoy?: Dimanche 30 Septembre 2018 15:11:57 > Objet: Bug when lowering a method ref (concise method) > Hi Vicente, > another test case not handled by javac. > > public class ConciseMethodRef implements Runnable { > public void run() -> null; > > Runnable f(Runnable r) -> r; > > void m() = f(this)::run; > } > > An exception has occurred in the compiler (12-amber). Please file a bug against > the Java compiler via the Java bug reporting page (http://bugreport.java.com) > after checking the Bug Database (http://bugs.java.com) for duplicates. Include > your program and the following diagnostic in your report. Thank you. > java.lang.NullPointerException > at > jdk.compiler/com.sun.tools.javac.tree.TreeMaker.isUnqualifiable(TreeMaker.java:1084) > at jdk.compiler/com.sun.tools.javac.tree.TreeMaker.QualIdent(TreeMaker.java:699) > at > jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDefInternal(Lower.java:2549) > at jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDef(Lower.java:2447) > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2082) > at jdk.compiler/com.sun.tools.javac.comp.Lower.visitClassDef(Lower.java:2220) > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:780) > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2082) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2101) > at > jdk.compiler/com.sun.tools.javac.comp.Lower.translateTopLevelClass(Lower.java:3850) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1579) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > at > jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) > at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) > > R?mi From vicente.romero at oracle.com Tue Oct 2 17:57:28 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 02 Oct 2018 17:57:28 +0000 Subject: hg: amber/amber: NPE when a method reference qualifier is a method call Message-ID: <201810021757.w92HvSX3027415@aojmv0008.oracle.com> Changeset: ad90da891ae0 Author: vromero Date: 2018-10-02 10:34 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/ad90da891ae0 NPE when a method reference qualifier is a method call ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/langtools/tools/javac/concise_methods/NPEQualifierIsCall.java From vicente.romero at oracle.com Tue Oct 2 18:39:13 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 2 Oct 2018 14:39:13 -0400 Subject: Bug when lowering a method ref (concise method) In-Reply-To: <1140841583.125368.1538493342839.JavaMail.zimbra@u-pem.fr> References: <28920591.62806.1538313117778.JavaMail.zimbra@u-pem.fr> <1140841583.125368.1538493342839.JavaMail.zimbra@u-pem.fr> Message-ID: <58c3b0ed-ba44-fc9c-14f3-8f97480bf52f@oracle.com> not anymore ;) Thanks for all the bug reports, I have fixed most of them already, Vicente On 10/02/2018 11:15 AM, Remi Forax wrote: > Hi Vicente, > the test case > > public class ConciseMethodRef implements Runnable { > public void run() { } > > Runnable f(Runnable r) -> r; > > void m() = f(this)::run; > } > > still cause an issue. > > java.lang.NullPointerException > at jdk.compiler/com.sun.tools.javac.tree.TreeMaker.Ident(TreeMaker.java:681) > at jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDefInternal(Lower.java:2552) > at jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDef(Lower.java:2449) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2084) > at jdk.compiler/com.sun.tools.javac.comp.Lower.visitClassDef(Lower.java:2222) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:780) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2084) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2103) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translateTopLevelClass(Lower.java:3854) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1579) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > at jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) > at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) > > at least with jdk 12-amber+0-fbed49487ec4 > > R?mi > > > > ----- Mail original ----- >> De: "Remi Forax" >> ?: "Vicente Romero" , "amber-dev" >> Envoy?: Dimanche 30 Septembre 2018 15:11:57 >> Objet: Bug when lowering a method ref (concise method) >> Hi Vicente, >> another test case not handled by javac. >> >> public class ConciseMethodRef implements Runnable { >> public void run() -> null; >> >> Runnable f(Runnable r) -> r; >> >> void m() = f(this)::run; >> } >> >> An exception has occurred in the compiler (12-amber). Please file a bug against >> the Java compiler via the Java bug reporting page (http://bugreport.java.com) >> after checking the Bug Database (http://bugs.java.com) for duplicates. Include >> your program and the following diagnostic in your report. Thank you. >> java.lang.NullPointerException >> at >> jdk.compiler/com.sun.tools.javac.tree.TreeMaker.isUnqualifiable(TreeMaker.java:1084) >> at jdk.compiler/com.sun.tools.javac.tree.TreeMaker.QualIdent(TreeMaker.java:699) >> at >> jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDefInternal(Lower.java:2549) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDef(Lower.java:2447) >> at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) >> at >> jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2082) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.visitClassDef(Lower.java:2220) >> at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:780) >> at >> jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2082) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2101) >> at >> jdk.compiler/com.sun.tools.javac.comp.Lower.translateTopLevelClass(Lower.java:3850) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1579) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >> at >> jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) >> at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) >> >> R?mi From vicente.romero at oracle.com Tue Oct 2 18:42:17 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 2 Oct 2018 14:42:17 -0400 Subject: Bug when lowering a method ref (concise method) In-Reply-To: <1140841583.125368.1538493342839.JavaMail.zimbra@u-pem.fr> References: <28920591.62806.1538313117778.JavaMail.zimbra@u-pem.fr> <1140841583.125368.1538493342839.JavaMail.zimbra@u-pem.fr> Message-ID: <1fee9144-c29c-b6c7-996b-45a1de44b66e@oracle.com> Hi Remi, I have fixed all the bugs you reported, Thanks! Vicente On 10/02/2018 11:15 AM, Remi Forax wrote: > Hi Vicente, > the test case > > public class ConciseMethodRef implements Runnable { > public void run() { } > > Runnable f(Runnable r) -> r; > > void m() = f(this)::run; > } > > still cause an issue. > > java.lang.NullPointerException > at jdk.compiler/com.sun.tools.javac.tree.TreeMaker.Ident(TreeMaker.java:681) > at jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDefInternal(Lower.java:2552) > at jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDef(Lower.java:2449) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2084) > at jdk.compiler/com.sun.tools.javac.comp.Lower.visitClassDef(Lower.java:2222) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:780) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2084) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2103) > at jdk.compiler/com.sun.tools.javac.comp.Lower.translateTopLevelClass(Lower.java:3854) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1579) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > at jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) > at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) > > at least with jdk 12-amber+0-fbed49487ec4 > > R?mi > > > > ----- Mail original ----- >> De: "Remi Forax" >> ?: "Vicente Romero" , "amber-dev" >> Envoy?: Dimanche 30 Septembre 2018 15:11:57 >> Objet: Bug when lowering a method ref (concise method) >> Hi Vicente, >> another test case not handled by javac. >> >> public class ConciseMethodRef implements Runnable { >> public void run() -> null; >> >> Runnable f(Runnable r) -> r; >> >> void m() = f(this)::run; >> } >> >> An exception has occurred in the compiler (12-amber). Please file a bug against >> the Java compiler via the Java bug reporting page (http://bugreport.java.com) >> after checking the Bug Database (http://bugs.java.com) for duplicates. Include >> your program and the following diagnostic in your report. Thank you. >> java.lang.NullPointerException >> at >> jdk.compiler/com.sun.tools.javac.tree.TreeMaker.isUnqualifiable(TreeMaker.java:1084) >> at jdk.compiler/com.sun.tools.javac.tree.TreeMaker.QualIdent(TreeMaker.java:699) >> at >> jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDefInternal(Lower.java:2549) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.visitMethodDef(Lower.java:2447) >> at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) >> at >> jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2082) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.visitClassDef(Lower.java:2220) >> at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:780) >> at >> jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2082) >> at jdk.compiler/com.sun.tools.javac.comp.Lower.translate(Lower.java:2101) >> at >> jdk.compiler/com.sun.tools.javac.comp.Lower.translateTopLevelClass(Lower.java:3850) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1579) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >> at >> jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) >> at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) >> >> R?mi From vicente.romero at oracle.com Fri Oct 5 17:40:05 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 05 Oct 2018 17:40:05 +0000 Subject: hg: amber/amber: initial push amber-demo branch Message-ID: <201810051740.w95He613000429@aojmv0008.oracle.com> Changeset: c68abf42965a Author: vromero Date: 2018-10-05 10:24 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/c68abf42965a initial push amber-demo branch From vicente.romero at oracle.com Fri Oct 5 17:43:03 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 05 Oct 2018 17:43:03 +0000 Subject: hg: amber/amber: setting the dependencies Message-ID: <201810051743.w95Hh38n003666@aojmv0008.oracle.com> Changeset: a8d4aa1f4e14 Author: vromero Date: 2018-10-05 10:26 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/a8d4aa1f4e14 setting the dependencies + deps.txt From maurizio.cimadamore at oracle.com Fri Oct 5 17:48:06 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 05 Oct 2018 17:48:06 +0000 Subject: hg: amber/amber: Automatic merge with patterns Message-ID: <201810051748.w95Hm6No005472@aojmv0008.oracle.com> Changeset: 268a41142f4b Author: mcimadamore Date: 2018-10-05 19:50 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/268a41142f4b Automatic merge with patterns From vicente.romero at oracle.com Fri Oct 5 20:31:32 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 05 Oct 2018 20:31:32 +0000 Subject: hg: amber/amber: manual merge with datum Message-ID: <201810052031.w95KVXuR009796@aojmv0008.oracle.com> Changeset: 9a7a275389fc Author: vromero Date: 2018-10-05 13:15 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/9a7a275389fc manual merge with datum ! src/java.base/share/classes/module-info.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/langtools/jdk/jshell/CompletenessTest.java From vicente.romero at oracle.com Fri Oct 5 20:42:52 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 05 Oct 2018 20:42:52 +0000 Subject: hg: amber/amber: manual merge with concise methods Message-ID: <201810052042.w95Kgq6f015543@aojmv0008.oracle.com> Changeset: 36302405aa09 Author: vromero Date: 2018-10-05 13:27 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/36302405aa09 manual merge with concise methods ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java From vicente.romero at oracle.com Fri Oct 5 21:32:06 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 05 Oct 2018 21:32:06 +0000 Subject: hg: amber/amber: refactoring to ease future merges Message-ID: <201810052132.w95LW7ga006422@aojmv0008.oracle.com> Changeset: f38b0eae105b Author: vromero Date: 2018-10-05 14:11 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/f38b0eae105b refactoring to ease future merges ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From maurizio.cimadamore at oracle.com Fri Oct 5 21:38:13 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 05 Oct 2018 21:38:13 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810052138.w95LcENl008656@aojmv0008.oracle.com> Changeset: 62f972dd087f Author: mcimadamore Date: 2018-10-05 23:40 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/62f972dd087f Automatic merge with datum ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From forax at univ-mlv.fr Fri Oct 5 22:46:54 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 6 Oct 2018 00:46:54 +0200 (CEST) Subject: Oops, AIOOBE ? Message-ID: <2114477942.571459.1538779614062.JavaMail.zimbra@u-pem.fr> Hi Vicente, another bug :) import java.util.HashMap; import java.util.function.Function; public class Visitor { private final HashMap, Function> map = new HashMap<>(); public void call(Object o) = map.get(o.getClass())::apply; } An exception has occurred in the compiler (12-amber). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 16 at jdk.compiler/com.sun.tools.javac.jvm.Code$State.pop(Code.java:1764) at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:862) at jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:256) at jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:269) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:814) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitTypeCast(Gen.java:2007) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCTypeCast.accept(JCTree.java:2098) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:812) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1590) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1524) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:611) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:662) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1026) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1033) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:896) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:859) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2196) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1635) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1603) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) at jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) regards, R?mi From maurizio.cimadamore at oracle.com Fri Oct 5 22:55:39 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 5 Oct 2018 23:55:39 +0100 Subject: Oops, AIOOBE ? In-Reply-To: <2114477942.571459.1538779614062.JavaMail.zimbra@u-pem.fr> References: <2114477942.571459.1538779614062.JavaMail.zimbra@u-pem.fr> Message-ID: Should 'o' even be in scope in the receiver expression of the method reference body? Maurizio On 05/10/18 23:46, Remi Forax wrote: > Hi Vicente, > another bug :) > > import java.util.HashMap; > import java.util.function.Function; > > public class Visitor { > private final HashMap, Function> map = new HashMap<>(); > > public void call(Object o) = map.get(o.getClass())::apply; > } > > > An exception has occurred in the compiler (12-amber). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. > java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 16 > at jdk.compiler/com.sun.tools.javac.jvm.Code$State.pop(Code.java:1764) > at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:862) > at jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:256) > at jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:269) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:814) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitTypeCast(Gen.java:2007) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCTypeCast.accept(JCTree.java:2098) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:812) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1590) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1524) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:611) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:662) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1026) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1033) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:896) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:859) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2196) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1635) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1603) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > at jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) > at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) > > > regards, > R?mi From maurizio.cimadamore at oracle.com Fri Oct 5 23:00:40 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 6 Oct 2018 00:00:40 +0100 Subject: Oops, AIOOBE ? In-Reply-To: References: <2114477942.571459.1538779614062.JavaMail.zimbra@u-pem.fr> Message-ID: <8fe8e49c-edd4-d26d-dd68-d890835488ee@oracle.com> I see this has also been discussed in the spec-experts mailing list: http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-October/000798.html In his response to Kevin, Brian seems to end up in the same place I did - this code should be rejected. Maurizio On 05/10/18 23:55, Maurizio Cimadamore wrote: > Should 'o' even be in scope in the receiver expression of the method > reference body? > > Maurizio > > > On 05/10/18 23:46, Remi Forax wrote: >> Hi Vicente, >> another bug :) >> >> import java.util.HashMap; >> import java.util.function.Function; >> >> public class Visitor { >> ?? private final HashMap, Function> map = new >> HashMap<>(); >> ?? ?? public void call(Object o) = map.get(o.getClass())::apply; >> } >> >> >> An exception has occurred in the compiler (12-amber). Please file a >> bug against the Java compiler via the Java bug reporting page >> (http://bugreport.java.com) after checking the Bug Database >> (http://bugs.java.com) for duplicates. Include your program and the >> following diagnostic in your report. Thank you. >> java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for >> length 16 >> ????at >> jdk.compiler/com.sun.tools.javac.jvm.Code$State.pop(Code.java:1764) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:862) >> ????at >> jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:256) >> ????at >> jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:269) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:814) >> ????at >> jdk.compiler/com.sun.tools.javac.jvm.Gen.visitTypeCast(Gen.java:2007) >> ????at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCTypeCast.accept(JCTree.java:2098) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:812) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1590) >> ????at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1524) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:611) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:662) >> ????at >> jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1026) >> ????at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1033) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:896) >> ????at >> jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:859) >> ????at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) >> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2196) >> ????at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) >> ????at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1635) >> ????at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1603) >> ????at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >> ????at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >> ????at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >> ????at >> jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) >> ????at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) >> >> >> regards, >> R?mi > From forax at univ-mlv.fr Sat Oct 6 09:16:13 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 6 Oct 2018 11:16:13 +0200 (CEST) Subject: Oops, AIOOBE ? In-Reply-To: <8fe8e49c-edd4-d26d-dd68-d890835488ee@oracle.com> References: <2114477942.571459.1538779614062.JavaMail.zimbra@u-pem.fr> <8fe8e49c-edd4-d26d-dd68-d890835488ee@oracle.com> Message-ID: <995446387.583267.1538817373349.JavaMail.zimbra@u-pem.fr> I will just point out that using a Consumer instead of a Function actually works, public class Visitor { private final HashMap, Consumer> map = new HashMap<>(); public void register(Class type, Consumer consumer) -> map.put(type, o -> consumer.accept(type.cast(o))); public void call(Object o) = map.get(o.getClass())::accept; } so i think it still worth digging to find the source of this AIIOOBE. R?mi ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "Remi Forax" , "Vicente Romero" , "amber-dev" > > Envoy?: Samedi 6 Octobre 2018 01:00:40 > Objet: Re: Oops, AIOOBE ? > I see this has also been discussed in the spec-experts mailing list: > > http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-October/000798.html > > In his response to Kevin, Brian seems to end up in the same place I did > - this code should be rejected. > > Maurizio > > > On 05/10/18 23:55, Maurizio Cimadamore wrote: >> Should 'o' even be in scope in the receiver expression of the method >> reference body? >> >> Maurizio >> >> >> On 05/10/18 23:46, Remi Forax wrote: >>> Hi Vicente, >>> another bug :) >>> >>> import java.util.HashMap; >>> import java.util.function.Function; >>> >>> public class Visitor { >>> ?? private final HashMap, Function> map = new >>> HashMap<>(); >>> ?? ?? public void call(Object o) = map.get(o.getClass())::apply; >>> } >>> >>> >>> An exception has occurred in the compiler (12-amber). Please file a >>> bug against the Java compiler via the Java bug reporting page >>> (http://bugreport.java.com) after checking the Bug Database >>> (http://bugs.java.com) for duplicates. Include your program and the >>> following diagnostic in your report. Thank you. >>> java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for >>> length 16 >>> ????at >>> jdk.compiler/com.sun.tools.javac.jvm.Code$State.pop(Code.java:1764) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:862) >>> ????at >>> jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:256) >>> ????at >>> jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:269) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:814) >>> ????at >>> jdk.compiler/com.sun.tools.javac.jvm.Gen.visitTypeCast(Gen.java:2007) >>> ????at >>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCTypeCast.accept(JCTree.java:2098) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:812) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1590) >>> ????at >>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1524) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:611) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:662) >>> ????at >>> jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1026) >>> ????at >>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1033) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:896) >>> ????at >>> jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:859) >>> ????at >>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) >>> ????at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2196) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1635) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1603) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >>> ????at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >>> ????at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) >>> ????at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) >>> >>> >>> regards, >>> R?mi From shade at redhat.com Sat Oct 6 09:39:25 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 6 Oct 2018 11:39:25 +0200 Subject: Build failure in amber-demo branch Message-ID: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> Hi, Thanks for creating amber-demo branch! I assume that is the branch that merges all development work in one convenient place? I set up builders to produce binaries for that branch: https://builds.shipilev.net/openjdk-amber/ Current branch fails to build though. Part of it is fixed in upstream jdk/jdk, but there are amber-specific failures, it seems: https://builds.shipilev.net/openjdk-amber/openjdk-amber-b4-jdk-12+13-linux-x86_64-fastdebug.build.log /pool/buildbot/slaves/sobornost/amber/build/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:2573: error: variable dc is already defined in method blockStatement() Comment dc; ^ Thanks, -Aleksey From forax at univ-mlv.fr Sat Oct 6 09:57:14 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 6 Oct 2018 11:57:14 +0200 (CEST) Subject: Build failure in amber-demo branch In-Reply-To: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> References: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> Message-ID: <464098882.584079.1538819834451.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Aleksey Shipilev" > ?: "amber-dev" > Envoy?: Samedi 6 Octobre 2018 11:39:25 > Objet: Build failure in amber-demo branch > Hi, > > Thanks for creating amber-demo branch! I assume that is the branch that merges > all development work > in one convenient place? I set up builders to produce binaries for that branch: > https://builds.shipilev.net/openjdk-amber/ yes, a very fine idea ! > > Current branch fails to build though. Part of it is fixed in upstream jdk/jdk, > but there are > amber-specific failures, it seems: > https://builds.shipilev.net/openjdk-amber/openjdk-amber-b4-jdk-12+13-linux-x86_64-fastdebug.build.log > > /pool/buildbot/slaves/sobornost/amber/build/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:2573: > error: variable dc is already defined in method blockStatement() > Comment dc; > ^ > > Thanks, > -Aleksey R?mi From brian.goetz at oracle.com Sat Oct 6 14:59:11 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 6 Oct 2018 10:59:11 -0400 Subject: Build failure in amber-demo branch In-Reply-To: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> References: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> Message-ID: <7E5D17C4-D62E-4CB5-9846-EF130BF42776@oracle.com> Actually, the intent was far less ambitious than that ? it was a ?trial-fit? mostly for purposes of, well, doing some demos, and seeing how they fit together. But, the three features feeding into it are moderately stable, so it will probably be useful for more than just this for a while. If the merge overhead becomes significant, we may take it down. More broadly, we haven?t yet enumerated a policy for when a branch is stable enough that we should try merging it with other feature branches. There?s definitely desire for a ?all the amber features that are good enough to try out? branch. For the record, here?s a catalog of the current branches: condy-folding: enhanced constant folding (JEP 303) and intrinsics for indy/ldc. jep-334: Constants API (dependency of condy-folding), in the process of final review for PTT patterns: experimental branch for pattern matching patterns-stage-1: curated branch with the subset of pattern matching features to be launched first enhanced-enums: dormant, associated with Enhanced Enums JEP, which ran into a fatal collision with generics stats-before-this: experimental branch, dormant lambda-leftovers: experimental branch associated with Lambda Leftovers JEP, dormant datum: prototype for records, relatively stable concise-method-declarations: recent JEP for concise method declarations The ?demo? branch derives from patterns, datum, and concise-method-declarations > On Oct 6, 2018, at 5:39 AM, Aleksey Shipilev wrote: > > Hi, > > Thanks for creating amber-demo branch! I assume that is the branch that merges all development work > in one convenient place? I set up builders to produce binaries for that branch: > https://builds.shipilev.net/openjdk-amber/ > > Current branch fails to build though. Part of it is fixed in upstream jdk/jdk, but there are > amber-specific failures, it seems: > https://builds.shipilev.net/openjdk-amber/openjdk-amber-b4-jdk-12+13-linux-x86_64-fastdebug.build.log > > /pool/buildbot/slaves/sobornost/amber/build/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:2573: > error: variable dc is already defined in method blockStatement() > Comment dc; > ^ > > Thanks, > -Aleksey > From brian.goetz at oracle.com Sat Oct 6 21:00:41 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 6 Oct 2018 17:00:41 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> Message-ID: What we decided to do here is to hold back on ?implements Constable? for the symbolic descriptor classes in the initial push of JEP-334, and then when we have the symbolic expression mode for BSMs, re-implement those in XxxDesc using that. Implementing Constable isn?t needed until we get to the full constant folding anyway. That linearizes the dependencies ? first JEP-334, then symbolic mode BSM, then update JEP-334 classes to implement Constable using symbolic mode BSM. > On Sep 13, 2018, at 9:07 PM, John Rose wrote: > > I am running a review of VM-level work on bootstrap methods > which can optionally help simplify some of these APIs: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html > > Specifically, this work can be use to implement a "symbolic > expression mode" for BSMs which causes the JVM to unpack > constant pool nodes directly as ConstantDesc items to present > to BSMs. This might simplify the condy forms of ConstantDesc > instances, if javac stores native constants to reflect, rather than > lists of strings to reassemble. > > ? John > > On Sep 11, 2018, at 12:50 PM, Vicente Romero wrote: >> >> Please review the first iteration of the implementation for JEP-334 [1] JVM Constants API. The implementation can be found at [2]. JEP-334 introduces an API to model nominal descriptions of key class-file and run-time artifacts, in particular constants that are loadable from the constant pool and has already been the subject of several discussions. The implementation of this JEP has been publicly accessible throw the amber repo at [3] in the jep-334 branch. Thanks to all members of the Amber project and specially to Brian for all the hard work on the design and the implementation of this API. Thanks for all the feedback we have received so far, most of it has been integrated in the current implementation. >> >> Thanks, >> Vicente >> >> [1] http://openjdk.java.net/jeps/334 >> [2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch >> [3] http://hg.openjdk.java.net/amber/amber > From vicente.romero at oracle.com Sun Oct 7 16:16:59 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sun, 07 Oct 2018 16:16:59 +0000 Subject: hg: amber/amber: removing double declaration introduced by merge Message-ID: <201810071616.w97GGxFx001280@aojmv0008.oracle.com> Changeset: 16ef25fac6d1 Author: vromero Date: 2018-10-07 09:00 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/16ef25fac6d1 removing double declaration introduced by merge ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From vicente.romero at oracle.com Sun Oct 7 16:26:05 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Sun, 7 Oct 2018 12:26:05 -0400 Subject: Build failure in amber-demo branch In-Reply-To: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> References: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> Message-ID: Hi, I fixed the issue, probably due to an automatic bad-merge. Thanks, Vicente On 10/06/2018 05:39 AM, Aleksey Shipilev wrote: > Hi, > > Thanks for creating amber-demo branch! I assume that is the branch that merges all development work > in one convenient place? I set up builders to produce binaries for that branch: > https://builds.shipilev.net/openjdk-amber/ > > Current branch fails to build though. Part of it is fixed in upstream jdk/jdk, but there are > amber-specific failures, it seems: > https://builds.shipilev.net/openjdk-amber/openjdk-amber-b4-jdk-12+13-linux-x86_64-fastdebug.build.log > > /pool/buildbot/slaves/sobornost/amber/build/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java:2573: > error: variable dc is already defined in method blockStatement() > Comment dc; > ^ > > Thanks, > -Aleksey > From vicente.romero at oracle.com Sun Oct 7 16:43:19 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sun, 07 Oct 2018 16:43:19 +0000 Subject: hg: amber/amber: small refactoring to prevent merge issues Message-ID: <201810071643.w97GhK0M011979@aojmv0008.oracle.com> Changeset: 2d12bf1331f9 Author: vromero Date: 2018-10-07 09:15 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/2d12bf1331f9 small refactoring to prevent merge issues ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From vicente.romero at oracle.com Sun Oct 7 16:50:15 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sun, 07 Oct 2018 16:50:15 +0000 Subject: hg: amber/amber: small refactoring to reduce merge issues Message-ID: <201810071650.w97GoF0L014180@aojmv0008.oracle.com> Changeset: 35841735961c Author: vromero Date: 2018-10-07 09:30 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/35841735961c small refactoring to reduce merge issues ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From vicente.romero at oracle.com Sun Oct 7 17:35:09 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sun, 07 Oct 2018 17:35:09 +0000 Subject: hg: amber/amber: manual merge with patterns Message-ID: <201810071735.w97HZ9CZ001462@aojmv0008.oracle.com> Changeset: 59bd83783308 Author: vromero Date: 2018-10-07 10:19 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/59bd83783308 manual merge with patterns ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From vicente.romero at oracle.com Sun Oct 7 17:51:32 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sun, 07 Oct 2018 17:51:32 +0000 Subject: hg: amber/amber: manual merge with concise methods Message-ID: <201810071751.w97HpXA2007632@aojmv0008.oracle.com> Changeset: 100f5811cd57 Author: vromero Date: 2018-10-07 10:35 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/100f5811cd57 manual merge with concise methods ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From shade at redhat.com Mon Oct 8 07:14:18 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Oct 2018 09:14:18 +0200 Subject: Build failure in amber-demo branch In-Reply-To: References: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> Message-ID: On 10/07/2018 06:26 PM, Vicente Romero wrote: > Hi, > > I fixed the issue, probably due to an automatic bad-merge. Yes, thanks! x86_64 builds are fine now. (But no other builds are fine, until you pull the recent build fixes from jdk/jdk). -Aleksey From vicente.romero at oracle.com Mon Oct 8 13:42:09 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 8 Oct 2018 09:42:09 -0400 Subject: Build failure in amber-demo branch In-Reply-To: References: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> Message-ID: <937a1a47-7a49-623f-7924-edfbc7620db5@oracle.com> On 10/08/2018 03:14 AM, Aleksey Shipilev wrote: > On 10/07/2018 06:26 PM, Vicente Romero wrote: >> Hi, >> >> I fixed the issue, probably due to an automatic bad-merge. > Yes, thanks! x86_64 builds are fine now. (But no other builds are fine, until you pull the recent > build fixes from jdk/jdk). I see, there is an automated pull that happens every Thursday and brings all the changes from jdk/jdk. I can force it sooner if needed > > -Aleksey > Vicente From shade at redhat.com Mon Oct 8 13:49:16 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Oct 2018 15:49:16 +0200 Subject: Build failure in amber-demo branch In-Reply-To: <937a1a47-7a49-623f-7924-edfbc7620db5@oracle.com> References: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> <937a1a47-7a49-623f-7924-edfbc7620db5@oracle.com> Message-ID: <00e79d4b-7625-b22b-4aa6-5cf6c877bfd9@redhat.com> On 10/08/2018 03:42 PM, Vicente Romero wrote: >> Yes, thanks! x86_64 builds are fine now. (But no other builds are fine, until you pull the >> recent build fixes from jdk/jdk). > > I see, there is an automated pull that happens every Thursday and brings all the changes from > jdk/jdk. I can force it sooner if needed No need, let it run in due course. -Aleksey From vicente.romero at oracle.com Mon Oct 8 16:59:16 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 08 Oct 2018 16:59:16 +0000 Subject: hg: amber/amber: remove arguments from the scope of concise methods Message-ID: <201810081659.w98GxHI5008120@aojmv0008.oracle.com> Changeset: 32f06d86416e Author: vromero Date: 2018-10-08 09:38 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/32f06d86416e remove arguments from the scope of concise methods ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/concise_methods/ConciseMethodsNegTest01.out From vicente.romero at oracle.com Mon Oct 8 17:02:17 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 8 Oct 2018 13:02:17 -0400 Subject: Oops, AIOOBE ? In-Reply-To: <2114477942.571459.1538779614062.JavaMail.zimbra@u-pem.fr> References: <2114477942.571459.1538779614062.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, I have pushed a fix [1] that removes arguments from scope in concise methods with the `=` form. This will effectively forbid cases like the one you found a bug for. Arguments will still be in scope in the `->` form. Thanks, Vicente [1] http://hg.openjdk.java.net/amber/amber/rev/32f06d86416e On 10/05/2018 06:46 PM, Remi Forax wrote: > Hi Vicente, > another bug :) > > import java.util.HashMap; > import java.util.function.Function; > > public class Visitor { > private final HashMap, Function> map = new HashMap<>(); > > public void call(Object o) = map.get(o.getClass())::apply; > } > > > An exception has occurred in the compiler (12-amber). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. > java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 16 > at jdk.compiler/com.sun.tools.javac.jvm.Code$State.pop(Code.java:1764) > at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:862) > at jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:256) > at jdk.compiler/com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:269) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:814) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitTypeCast(Gen.java:2007) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCTypeCast.accept(JCTree.java:2098) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:812) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1590) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1524) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:611) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:662) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1026) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1033) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:625) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:896) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:859) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:879) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:590) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2196) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1635) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1603) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > at jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) > at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) > > > regards, > R?mi From vicente.romero at oracle.com Mon Oct 8 18:06:47 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 08 Oct 2018 18:06:47 +0000 Subject: hg: amber/amber: manual merge with concise methods branch Message-ID: <201810081806.w98I6lJ1007395@aojmv0008.oracle.com> Changeset: 8c442a53c552 Author: vromero Date: 2018-10-08 10:50 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/8c442a53c552 manual merge with concise methods branch ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java From vicente.romero at oracle.com Mon Oct 8 18:17:24 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 08 Oct 2018 18:17:24 +0000 Subject: hg: amber/amber: 103 new changesets Message-ID: <201810081817.w98IHVXa014387@aojmv0008.oracle.com> Changeset: 0f7d0bb6cfe2 Author: jcbeyler Date: 2018-09-27 15:56 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/0f7d0bb6cfe2 8211036: Remove the NSK_STUB macros from vmTestbase for non jvmti Summary: Remove the NSK_STUB macros from code outside of the jvmti subfolder Reviewed-by: iignatyev, amenkov, dholmes ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/StackTraceController.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/Deadlock.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/LockingThreads.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/RecursiveMonitoringThread.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/JVMTIagent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/README ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/native/README ! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/nsk_strace.h ! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace006.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/nativeAndMH.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/redefineClasses.cpp Changeset: 1d12935177ed Author: mbaesken Date: 2018-09-28 09:20 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/1d12935177ed 8210964: add more ld preloading related info to hs_error file on Linux Reviewed-by: clanger, stuefe ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp Changeset: 5e9c922eafbc Author: mbaesken Date: 2018-09-27 15:37 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/5e9c922eafbc 8211149: fix potential memleak in getJavaIDFromLangID after failing SetupI18nProps call [windows] Reviewed-by: naoto, lucy ! src/java.base/windows/native/libjava/java_props_md.c Changeset: 28085dba5d9a Author: jjiang Date: 2018-09-28 15:42 +0800 URL: http://hg.openjdk.java.net/amber/amber/rev/28085dba5d9a 8209546: Make sun/security/tools/keytool/autotest.sh to support macosx Summary: Refactor autotest.sh to java test and remove standard.sh Reviewed-by: weijun ! test/jdk/ProblemList.txt ! test/jdk/sun/security/pkcs11/PKCS11Test.java ! test/jdk/sun/security/tools/keytool/KeyToolTest.java + test/jdk/sun/security/tools/keytool/NssTest.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh Changeset: c573d2633417 Author: rkennke Date: 2018-09-28 10:57 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/c573d2633417 8211269: Make declaration of Allocation protected in MemAllocator Reviewed-by: shade ! src/hotspot/share/gc/shared/memAllocator.hpp Changeset: 7bd8d6b011c9 Author: sballal Date: 2018-09-28 14:31 +0530 URL: http://hg.openjdk.java.net/amber/amber/rev/7bd8d6b011c9 8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file Reviewed-by: dholmes, jgeorge ! test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestJmapCore.java Changeset: 2d980757fd07 Author: chegar Date: 2018-09-28 12:47 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/2d980757fd07 8211092: test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java fails intermittently when cleaning up Reviewed-by: dfuchs ! test/jdk/ProblemList.txt ! test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java Changeset: 5ba442f14818 Author: avoitylov Date: 2018-09-28 15:39 +0300 URL: http://hg.openjdk.java.net/amber/amber/rev/5ba442f14818 8211212: ARM: -Werror=switch build failure Reviewed-by: shade ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp Changeset: 2a1e47af3c6b Author: mbaesken Date: 2018-09-27 17:13 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/2a1e47af3c6b 8211208: make AllocateHeapAt an unsupported option on AIX Reviewed-by: shade, tschatzl ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/gc/TestAllocateHeapAt.java ! test/hotspot/jtreg/gc/TestAllocateHeapAtError.java ! test/hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java ! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithAllocateHeapAt.java Changeset: a1c24d06e2b5 Author: dl Date: 2018-09-28 08:45 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/a1c24d06e2b5 8210971: Add exception handling methods to CompletionStage and CompletableFuture Reviewed-by: martin, chegar ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/CompletionStage.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java Changeset: 1239bfca87f8 Author: dl Date: 2018-09-28 08:45 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/1239bfca87f8 8207003: Miscellaneous changes imported from jsr166 CVS 2018-09 Reviewed-by: martin, chegar ! test/jdk/java/util/Collections/EmptyNavigableSet.java ! test/jdk/java/util/PriorityQueue/AddNonComparable.java ! test/jdk/java/util/concurrent/tck/AbstractQueuedSynchronizerTest.java ! test/jdk/java/util/concurrent/tck/CountedCompleterTest.java ! test/jdk/java/util/concurrent/tck/DelayQueueTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinPool8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinTask8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java ! test/jdk/java/util/concurrent/tck/FutureTaskTest.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/concurrent/tck/RecursiveActionTest.java ! test/jdk/java/util/concurrent/tck/RecursiveTaskTest.java ! test/jdk/java/util/concurrent/tck/ReentrantLockTest.java ! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java Changeset: e374b0383035 Author: shade Date: 2018-09-28 18:28 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/e374b0383035 8211272: x86_32 build failures after JDK-8210764 (Update avx512 implementation) Reviewed-by: rkennke, kvn ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp Changeset: 3aac38c47955 Author: shade Date: 2018-09-28 18:28 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/3aac38c47955 8211274: x86_32 build failures after JDK-8211029 (Have a common set of enabled warnings for all native libraries) Reviewed-by: dholmes, tschatzl ! src/hotspot/cpu/x86/jniFastGetField_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp Changeset: d82660ddd75c Author: shade Date: 2018-09-28 18:28 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/d82660ddd75c 8211268: Disable unsupported GCs for Zero Reviewed-by: sgehwolf, erikj ! make/autoconf/hotspot.m4 Changeset: d38cb687d631 Author: dtitov Date: 2018-09-28 12:04 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/d38cb687d631 8163083: SocketListeningConnector does not allow invocations with port 0 Reviewed-by: sspitsyn, amenkov, gadams, jcbeyler ! src/jdk.jdi/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/GenericListeningConnector.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketListeningConnector.java + test/jdk/com/sun/jdi/connect/WildcardPortSupport.java Changeset: f1f7ff620f83 Author: gadams Date: 2018-09-28 14:31 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/f1f7ff620f83 8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again Reviewed-by: cjplummer, amenkov ! test/hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java Changeset: 2712735bc434 Author: jcbeyler Date: 2018-09-28 13:01 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/2712735bc434 8210842: Handle JNIGlobalRefLocker.cpp Summary: Add checking for JNI calls via a new ExceptionCheckingJniEnv Reviewed-by: sspitsyn, amenkov, dholmes, mikael ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIGlobalRefLocker.cpp + test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp + test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp Changeset: 53a4760e9fcc Author: henryjen Date: 2018-09-28 13:15 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/53a4760e9fcc 8210810: Escaped character at specific position in argument file is not handled properly Reviewed-by: alanb Contributed-by: Bo Zhang ! src/java.base/share/native/libjli/args.c ! test/jdk/tools/launcher/ArgFileSyntax.java Changeset: db0c3952de52 Author: coleenp Date: 2018-09-28 16:07 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/db0c3952de52 8209645: Split ClassLoaderData and ClassLoaderDataGraph into separate files Reviewed-by: iklam, stuefe ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/classfile/classLoaderData.inline.hpp + src/hotspot/share/classfile/classLoaderDataGraph.cpp + src/hotspot/share/classfile/classLoaderDataGraph.hpp + src/hotspot/share/classfile/classLoaderDataGraph.inline.hpp ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp ! src/hotspot/share/classfile/classLoaderStats.cpp ! src/hotspot/share/classfile/loaderConstraints.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp ! src/hotspot/share/gc/g1/g1FullGCMarkTask.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/parallel/pcTasks.cpp ! src/hotspot/share/gc/parallel/psMarkSweep.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psTasks.cpp ! src/hotspot/share/gc/serial/genMarkSweep.cpp ! src/hotspot/share/gc/shared/cardTableRS.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/parallelCleaning.hpp ! src/hotspot/share/gc/z/zRootsIterator.cpp ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/saveRestore.cpp ! src/hotspot/share/jfr/periodic/jfrModuleEvent.cpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/klassVtable.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/biasedLocking.cpp ! src/hotspot/share/runtime/compilationPolicy.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/memprofiler.cpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/heapDumper.cpp ! src/hotspot/share/services/memBaseline.cpp Changeset: bb1d5dd64897 Author: mikael Date: 2018-09-28 14:11 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/bb1d5dd64897 8211176: Initialize ObjectMonitor eagerly Reviewed-by: dholmes, adinn, redestad ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 540c1a848dd8 Author: mikael Date: 2018-09-28 14:53 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/540c1a848dd8 8211291: Backout JDK-8210842 Handle JNIGlobalRefLocker.cpp Reviewed-by: kbarrett, iignatyev, jcbeyler ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIGlobalRefLocker.cpp - test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp - test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp Changeset: 628909466216 Author: jiangli Date: 2018-10-01 00:52 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/628909466216 8210926: vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/TestDescription.java failed with JVMTI_ERROR_INVALID_CLASS in CDS mode Summary: Reset InstanceKlass _init_state to 'allocated' before writing out shared classes at dump time. Reviewed-by: dholmes, coleenp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 8f0f7f2ae20b Author: aph Date: 2018-09-26 18:11 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/8f0f7f2ae20b 8211170: AArch64: Warnings in C1 and template interpreter Reviewed-by: adinn ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Changeset: d034d46065fb Author: aph Date: 2018-10-01 09:56 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/d034d46065fb Merge - src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java - src/java.desktop/share/classes/sun/applet/AppletClassLoader.java - src/java.desktop/share/classes/sun/applet/AppletSecurity.java - src/java.desktop/share/classes/sun/applet/AppletThreadGroup.java - src/java.desktop/share/classes/sun/awt/HToolkit.java - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h - test/jdk/com/sun/awt/SecurityWarning/CustomSecurityManager.java - test/jdk/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java - test/jdk/com/sun/awt/TEST.properties - test/jdk/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/jdk/java/awt/dnd/BadSerializaionTest/badAction - test/jdk/java/awt/dnd/BadSerializaionTest/good - test/jdk/java/awt/dnd/BadSerializaionTest/noEvents - test/jdk/java/awt/dnd/BadSerializaionTest/nullComponent - test/jdk/java/awt/dnd/BadSerializaionTest/nullDragSource - test/jdk/java/awt/dnd/BadSerializaionTest/nullOrigin - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java Changeset: 358a3b99198a Author: aph Date: 2018-09-20 18:29 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/358a3b99198a 8210972: Add comment text to C1 patching code Reviewed-by: kvn ! src/hotspot/share/c1/c1_Runtime1.cpp Changeset: 2a2a78bd1fc3 Author: lucy Date: 2018-10-01 12:07 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/2a2a78bd1fc3 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) Reviewed-by: shade, simonis ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/assembler_s390.cpp ! src/hotspot/cpu/s390/assembler_s390.hpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp Changeset: 933b0abb2211 Author: rkennke Date: 2018-10-01 16:34 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/933b0abb2211 8211241: Missing obj equals in TemplateTable::fast_aldc Reviewed-by: dcubed, coleenp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp Changeset: 5bdf60cd0ed0 Author: shade Date: 2018-10-01 16:41 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/5bdf60cd0ed0 8211239: Build fails without JFR: empty JFR events signatures mismatch Reviewed-by: mgronlun, dholmes ! make/src/classes/build/tools/jfr/GenerateJfrFiles.java Changeset: 02421ca2cc85 Author: rkennke Date: 2018-10-01 17:47 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/02421ca2cc85 8211071: unpack.cpp fails to compile with statement has no effect [-Werror=unused-value] Reviewed-by: ihse, clanger ! src/jdk.pack/share/native/common-unpack/unpack.cpp Changeset: 7cbb77546f87 Author: aph Date: 2018-10-01 12:29 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/7cbb77546f87 8211333: AArch64: Fix another build failure after JDK-8211029 Reviewed-by: shade, aph Contributed-by: pengfei.li at arm.com ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Changeset: 26810c5fe290 Author: aph Date: 2018-10-01 12:30 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/26810c5fe290 Merge Changeset: 67619141f027 Author: lancea Date: 2018-10-01 13:05 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/67619141f027 8211295: DriverManager.getConnection fails when called from com.sun.rowset.JdbcRowSetImpl Reviewed-by: mchung, alanb ! src/java.sql/share/classes/java/sql/DriverManager.java ! test/jdk/java/sql/testng/util/StubConnection.java + test/jdk/javax/sql/testng/test/rowset/jdbcrowset/JdbcRowSetDriverManagerTest.java Changeset: 2f1698b6db15 Author: simonis Date: 2018-10-01 19:08 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/2f1698b6db15 8211328: Different declaration and definition of ClassLoaderData::classes_do() leads to build failures Reviewed-by: dcubed, coleenp ! src/hotspot/share/classfile/classLoaderData.hpp Changeset: c5b97602cd4b Author: rkennke Date: 2018-10-01 20:23 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/c5b97602cd4b 8211129: compiler/whitebox/ForceNMethodSweepTest.java fails after JDK-8132849 Reviewed-by: eosterlund, thartmann ! src/hotspot/share/runtime/sweeper.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 94b9b7a09001 Author: ccheung Date: 2018-10-01 11:36 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/94b9b7a09001 8211278: Update ProblemList Reviewed-by: iklam ! test/jdk/ProblemList-Xcomp.txt Changeset: 390f529f4f22 Author: kvn Date: 2018-10-01 11:54 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/390f529f4f22 8211251: Default mask register for avx512 instructions Summary: Encode AVX 512 instructions as unmasked instruction where mask register is not specified. Reviewed-by: kvn Contributed-by: sandhya.viswanathan at intel.com ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp Changeset: a8862960c19f Author: iignatyev Date: 2018-10-01 14:54 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/a8862960c19f 8211171: move JarUtils to top-level testlibrary Reviewed-by: alanb ! test/hotspot/jtreg/runtime/Dictionary/ProtectionDomainCacheTest.java - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java ! test/jdk/java/io/FilePermission/ReadFileOnPath.java ! test/jdk/java/io/Serializable/packageAccess/PackageAccessTest.java ! test/jdk/java/io/Serializable/resolveClass/consTest/ConsTest.java ! test/jdk/java/io/Serializable/resolveClass/consTest/SetupJar.java ! test/jdk/java/io/Serializable/resolveClass/deserializeButton/DeserializeButtonTest.java ! test/jdk/java/io/Serializable/superclassDataLoss/SuperclassDataLossTest.java ! test/jdk/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java ! test/jdk/java/lang/ClassLoader/getResource/automaticmodules/Driver.java ! test/jdk/java/lang/ClassLoader/securityManager/ClassLoaderTest.java ! test/jdk/java/lang/Package/IsCompatibleWithDriver.java ! test/jdk/java/lang/Package/PackageFromManifest.java ! test/jdk/java/lang/instrument/executableJAR/ExecJarWithAgent.java ! test/jdk/java/lang/module/AutomaticModulesTest.java ! test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/jdk/java/lang/module/MultiReleaseJarTest.java ! test/jdk/java/lang/module/customfs/ModulesInCustomFileSystem.java ! test/jdk/java/net/URLClassLoader/closetest/CloseTest.java ! test/jdk/java/net/URLClassLoader/closetest/GetResourceAsStream.java ! test/jdk/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/jdk/java/nio/channels/AsynchronousChannelGroup/SetupJar.java ! test/jdk/java/nio/charset/spi/CharsetProviderBasicTest.java ! test/jdk/java/nio/charset/spi/SetupJar.java ! test/jdk/java/rmi/module/ModuleTest.java ! test/jdk/java/security/Provider/SecurityProviderModularTest.java ! test/jdk/java/util/ServiceLoader/ModulesTest.java ! test/jdk/java/util/ServiceLoader/basic/ServiceLoaderBasicTest.java ! test/jdk/javax/security/auth/login/modules/JaasModularClientTest.java ! test/jdk/javax/security/auth/login/modules/JaasModularDefaultHandlerTest.java ! test/jdk/jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java - test/jdk/lib/testlibrary/JarUtils.java ! test/jdk/sun/net/www/protocol/jar/jarbug/TestDriver.java ! test/jdk/tools/jlink/basic/BasicTest.java ! test/jdk/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java ! test/jdk/tools/launcher/modules/addreads/AddReadsTest.java ! test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java ! test/jdk/tools/launcher/modules/patch/basic/PatchTest.java ! test/jdk/tools/launcher/modules/patch/basic/PatchTestWarningError.java ! test/jdk/tools/launcher/modules/validate/ValidateModulesTest.java ! test/lib/jdk/test/lib/util/JarUtils.java Changeset: 4756af2308a1 Author: manc Date: 2018-10-01 20:16 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/4756af2308a1 8210716: Detailed GC logging request misses some Summary: Changed log tags from (heap, ergo) to (gc, ergo, heap). Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/parallel/adjoiningGenerations.cpp ! src/hotspot/share/gc/parallel/psMarkSweep.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 3241975b1830 Author: weijun Date: 2018-10-02 16:02 +0800 URL: http://hg.openjdk.java.net/amber/amber/rev/3241975b1830 8210821: Support dns_canonicalize_hostname in krb5.conf Reviewed-by: valeriep ! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java + test/jdk/sun/security/krb5/auto/DnsCanonicalizeHostname.java + test/jdk/sun/security/krb5/auto/dns_canonicalize_hostname.hosts Changeset: 191c2b7d7186 Author: chegar Date: 2018-10-02 09:05 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/191c2b7d7186 8211325: test/jdk/java/net/Socket/LingerTest.java fails with cleaning up Reviewed-by: dfuchs ! test/jdk/ProblemList.txt ! test/jdk/java/net/Socket/LingerTest.java Changeset: 48dec0c13bec Author: chegar Date: 2018-10-02 10:40 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/48dec0c13bec 8209454: [error-prone] TypeParameterUnusedInFormals in jdk.net Reviewed-by: dfuchs ! src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java Changeset: df8ae450fce3 Author: dfuchs Date: 2018-10-02 14:17 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/df8ae450fce3 8211349: Bad HTML in {@link} for HttpResponse.BodyHandlers.ofPublisher Summary: Fixed links by moving <> out of the link as was done elsewhere in the file. Reviewed-by: chegar ! src/java.net.http/share/classes/java/net/http/HttpResponse.java Changeset: 2a12a3865916 Author: roland Date: 2018-09-27 16:25 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/2a12a3865916 8211231: BarrierSetC1::generate_referent_check() confuses register allocator Reviewed-by: iveresov, kvn ! src/hotspot/share/gc/shared/c1/barrierSetC1.cpp Changeset: 2ef304ee001d Author: roland Date: 2018-09-28 10:42 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/2ef304ee001d 8210887: Tweak C2 gc api for arraycopy Reviewed-by: kvn, thartmann ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.hpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/arraycopynode.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp Changeset: 08c296fe9458 Author: cushon Date: 2018-10-01 21:14 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/08c296fe9458 8211057: Gensrc step CompileProperties generates unstable CompilerProperties output Reviewed-by: mcimadamore, vromero ! make/langtools/tools/propertiesparser/gen/ClassGenerator.java Changeset: c1db377f6300 Author: igerasim Date: 2018-10-02 10:19 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/c1db377f6300 8200381: Typos in javadoc - missing verb "be" and alike Reviewed-by: lancea, darcy, wetmore ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java ! src/java.base/share/classes/java/nio/channels/Selector.java ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java ! src/java.base/share/classes/sun/security/provider/DSA.java ! src/java.base/share/classes/sun/security/provider/certpath/IndexedCollectionCertStore.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/x509/OCSPNoCheckExtension.java Changeset: c4010f88ea68 Author: amenkov Date: 2018-10-02 12:06 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/c4010f88ea68 8203928: [Test] Convert non-JDB scaffolding serviceability shell script tests to java Reviewed-by: jcbeyler, cjplummer ! test/jdk/com/sun/jdi/ImmutableResourceTest.java - test/jdk/com/sun/jdi/ImmutableResourceTest.sh ! test/jdk/com/sun/jdi/JITDebug.java - test/jdk/com/sun/jdi/JITDebug.sh + test/jdk/com/sun/jdi/PrivateTransportTest.java - test/jdk/com/sun/jdi/PrivateTransportTest.sh ! test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.java - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh ! test/jdk/com/sun/jdi/redefine/RedefineTest.java - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh ! test/jdk/com/sun/jdi/redefineMethod/RedefineTest.java Changeset: 1bf7a2919e06 Author: amenkov Date: 2018-10-02 12:08 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/1bf7a2919e06 8209332: [TEST] test/jdk/com/sun/jdi/CatchPatternTest.sh is incorrect Reviewed-by: jcbeyler, dtitov, cjplummer + test/jdk/com/sun/jdi/CatchPatternTest.java - test/jdk/com/sun/jdi/CatchPatternTest.sh Changeset: 7ac0ac1e57b6 Author: dholmes Date: 2018-10-02 17:12 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/7ac0ac1e57b6 8211175: Remove temporary clock initialization duplication Reviewed-by: rehn, mikael ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/posix/os_posix.hpp Changeset: 6003e034cdd8 Author: iklam Date: 2018-10-02 14:32 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/6003e034cdd8 8209946: [TESTBUG] CDS tests should use "@run driver" Reviewed-by: ccheung, jiangli, mseledtsov ! test/hotspot/jtreg/runtime/SharedArchiveFile/ArchiveDoesNotExist.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/CdsSameObjectAlignment.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/DumpSharedDictionary.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/NonBootLoaderClasses.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedBaseAddress.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStrings.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsDedup.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsRunAuto.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/TestInterpreterMethodEntries.java ! test/hotspot/jtreg/runtime/appcds/AppendClasspath.java ! test/hotspot/jtreg/runtime/appcds/BootClassPathMismatch.java ! test/hotspot/jtreg/runtime/appcds/CDSandJFR.java ! test/hotspot/jtreg/runtime/appcds/CaseSensitiveClassPath.java ! test/hotspot/jtreg/runtime/appcds/ClassLoaderTest.java ! test/hotspot/jtreg/runtime/appcds/ClassPathAttr.java ! test/hotspot/jtreg/runtime/appcds/CommandLineFlagComboNegative.java ! test/hotspot/jtreg/runtime/appcds/DirClasspathTest.java ! test/hotspot/jtreg/runtime/appcds/DumpClassList.java ! test/hotspot/jtreg/runtime/appcds/ExtraSymbols.java ! test/hotspot/jtreg/runtime/appcds/FieldAnnotationsTest.java ! test/hotspot/jtreg/runtime/appcds/FreeUnusedMetadata.java ! test/hotspot/jtreg/runtime/appcds/HelloExtTest.java ! test/hotspot/jtreg/runtime/appcds/HelloTest.java ! test/hotspot/jtreg/runtime/appcds/IgnoreEmptyClassPaths.java ! test/hotspot/jtreg/runtime/appcds/JvmtiAddPath.java ! test/hotspot/jtreg/runtime/appcds/MissingSuperTest.java ! test/hotspot/jtreg/runtime/appcds/MoveJDKTest.java ! test/hotspot/jtreg/runtime/appcds/MultiProcessSharing.java ! test/hotspot/jtreg/runtime/appcds/OldClassTest.java ! test/hotspot/jtreg/runtime/appcds/PackageSealing.java ! test/hotspot/jtreg/runtime/appcds/ParallelLoad2.java ! test/hotspot/jtreg/runtime/appcds/ParallelLoadTest.java ! test/hotspot/jtreg/runtime/appcds/ProhibitedPackage.java ! test/hotspot/jtreg/runtime/appcds/ProtectionDomain.java ! test/hotspot/jtreg/runtime/appcds/RewriteBytecodesTest.java ! test/hotspot/jtreg/runtime/appcds/SharedPackages.java ! test/hotspot/jtreg/runtime/appcds/SignedJar.java ! test/hotspot/jtreg/runtime/appcds/SpecifySysLoaderProp.java ! test/hotspot/jtreg/runtime/appcds/TestWithProfiler.java ! test/hotspot/jtreg/runtime/appcds/TraceLongClasspath.java ! test/hotspot/jtreg/runtime/appcds/WideIloadTest.java ! test/hotspot/jtreg/runtime/appcds/WrongClasspath.java ! test/hotspot/jtreg/runtime/appcds/XShareAutoWithChangedJar.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedIntegerCacheTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleComboTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleCompareTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedMirrorTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedResolvedReferences.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/DumpTimeVerifyFailure.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/GCStressTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/MirrorWithReferenceFieldsTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/OpenArchiveRegion.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/PrimitiveTypesTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassTest.java ! test/hotspot/jtreg/runtime/appcds/condy/CondyHelloTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatA.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatB.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatC.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatD.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatE.java ! test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom.java ! test/hotspot/jtreg/runtime/appcds/customLoader/LoaderSegregationTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestMultiFP.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestSingleFP.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ProhibitedPackageNamesTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ProtectionDomain.java ! test/hotspot/jtreg/runtime/appcds/customLoader/SameNameInTwoLoadersTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/UnintendedLoadersTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/UnloadUnregisteredLoaderTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/UnsupportedPlatforms.java ! test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTest.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/CheckUnsupportedDumpingOptions.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/JigsawOptionsCombo.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/AppClassInCP.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/CustomPackage.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/MismatchedPatchModule.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchDir.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchJavaBase.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/Simple.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/SubClassOfPatchedClass.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/TwoJars.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/BootAppendTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/ClassPathTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/DummyClassesInBootClassPath.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddModules.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddOpens.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddReads.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ExportModule.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/JvmtiAddPath.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/MainModuleOnly.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ModulePathAndCP.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/OverrideTests.java ! test/hotspot/jtreg/runtime/appcds/jvmti/parallelLoad/ParallelLoadAndTransformTest.java ! test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java ! test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/ExerciseGC.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/FlagCombo.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/InternSharedString.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/InvalidFileFormat.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/LargePages.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/LockSharedStrings.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasicPlus.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsStress.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsWbTest.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java Changeset: ad00713a0562 Author: mikael Date: 2018-10-02 15:01 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/ad00713a0562 8211364: Remove expired flags Reviewed-by: dholmes, egahlin ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/runtime/CommandLine/ObsoleteFlagErrorMessage.java ! test/jdk/jdk/jfr/event/compiler/TestAllocInNewTLAB.java ! test/jdk/jdk/jfr/event/compiler/TestAllocOutsideTLAB.java ! test/jdk/jdk/jfr/event/oldobject/TestAllocationTime.java ! test/jdk/jdk/jfr/event/oldobject/TestLargeRootSet.java ! test/jdk/jdk/jfr/event/oldobject/TestLastKnownHeapUsage.java ! test/jdk/jdk/jfr/startupargs/TestOldObjectQueueSize.java Changeset: 266a89a5d1af Author: ccheung Date: 2018-10-02 20:52 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/266a89a5d1af 8211287: ClassPathTests.java fails due to "Unable to map MiscData shared space at required address." Summary: catch the InvocationTargetException and rethrow exception based on the cause Reviewed-by: jiangli, iklam ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/ClassPathTests.java Changeset: c0d05cf1d19d Author: pkoppula Date: 2018-10-02 21:38 +0530 URL: http://hg.openjdk.java.net/amber/amber/rev/c0d05cf1d19d 8211107: LDAPS communication failure with jdk 1.8.0_181 Reviewed-by: chegar, coffeys, vtewari ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java Changeset: 7577686cc9bd Author: mikael Date: 2018-10-02 22:36 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/7577686cc9bd 8211350: Remove jprt support Reviewed-by: dholmes, erikj, mchung, alanb, jjg - make/Jprt.gmk ! make/Main.gmk ! make/conf/jib-profiles.js - make/jprt.properties ! src/hotspot/os/linux/os_linux.cpp ! test/TestCommon.gmk ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/jprt.config ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/com/sun/jdi/cds/CDSJDITest.java ! test/jdk/java/lang/String/CompactString/CompactString.java ! test/jdk/java/lang/StringBuffer/CompactStringBuffer.java ! test/jdk/java/lang/StringBuilder/CompactStringBuilder.java - test/jdk/jprt.config ! test/jdk/lib/security/CheckBlacklistedCerts.java ! test/jdk/tools/jimage/JImageTest.java ! test/jdk/tools/jlink/plugins/StringSharingPluginTest.java ! test/jdk/tools/jlink/plugins/StripDebugPluginTest.java ! test/jdk/tools/lib/tests/Helper.java ! test/jdk/tools/pack200/Pack200Test.java ! test/jdk/tools/pack200/TestExceptions.java ! test/langtools/Makefile Changeset: f7babf9d1592 Author: pmuthuswamy Date: 2018-10-03 11:43 +0530 URL: http://hg.openjdk.java.net/amber/amber/rev/f7babf9d1592 8208531: -javafx mode should be on by default when JavaFX is available Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java + test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFxMode.java Changeset: 84743156e780 Author: dholmes Date: 2018-10-03 03:41 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/84743156e780 8188764: Obsolete AssumeMP and then remove all support for non-MP builds Reviewed-by: mikael, mdoerr, bulasevich, eosterlund ! src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/compiledIC_arm.cpp ! src/hotspot/cpu/arm/jniFastGetField_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/compiledIC_ppc.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/compiledIC_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/sparc/compiledIC_sparc.cpp ! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp ! src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp ! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp ! src/hotspot/cpu/sparc/templateInterpreterGenerator_sparc.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/compiledIC_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/jniFastGetField_x86_32.cpp ! src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp ! src/hotspot/os_cpu/bsd_x86/bsd_x86_32.s ! src/hotspot/os_cpu/linux_arm/orderAccess_linux_arm.hpp ! src/hotspot/share/c1/c1_CodeStubs.hpp ! src/hotspot/share/c1/c1_InstructionPrinter.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/shared/c1/barrierSetC1.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/os.hpp ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 9ce37fa2e179 Author: hseigel Date: 2018-10-03 09:46 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/9ce37fa2e179 8209138: Symbol constructor uses u1 as the element type of its name argument Summary: Maske u1 the type for Symbol values and add a function to return it as a char. Reviewed-by: dholmes, coleenp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciObjArrayKlass.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciSymbol.cpp ! src/hotspot/share/ci/ciSymbol.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/verificationType.cpp ! src/hotspot/share/classfile/verificationType.hpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/fieldType.cpp ! src/hotspot/share/runtime/fieldType.hpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/heapDumper.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/Field.java Changeset: 27b48d82272c Author: redestad Date: 2018-10-03 15:05 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/27b48d82272c 8211384: Obsolete -XX:+/-MonitorInUseLists option Reviewed-by: mikael, rkennke, shade, dcubed ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 7d036fb69443 Author: rraghavan Date: 2018-10-03 08:03 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/7d036fb69443 8211168: Solaris-X64 build failure with error nreg hides the same name in an outer scope Summary: Corrected nreg definition Reviewed-by: dcubed, kvn, shade ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: dac71e2465ca Author: akolarkunnu Date: 2018-10-01 18:03 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/dac71e2465ca 8211160: Handle different look and feels in JInternalFrameOperator Reviewed-by: serb Contributed-by: abdul.kolarkunnu at oracle.com ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/drivers/DefaultDriverInstaller.java + test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/drivers/windows/InternalFramePopupMenuDriver.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/operators/JInternalFrameOperator.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/version_info Changeset: 0b36afd411ec Author: aph Date: 2018-10-03 17:29 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/0b36afd411ec 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean Reviewed-by: shade, alanb ! src/java.base/unix/native/libjava/Console_md.c Changeset: 8897e41b327c Author: aph Date: 2018-10-03 17:45 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/8897e41b327c Merge Changeset: be4614f04eb6 Author: shade Date: 2018-10-03 18:46 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/be4614f04eb6 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions) Reviewed-by: kvn ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp Changeset: 22ca7ba0c50c Author: gziemski Date: 2018-10-03 12:34 -0500 URL: http://hg.openjdk.java.net/amber/amber/rev/22ca7ba0c50c 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF Summary: Added ATTRIBUTE_PRINTF to JVMFlag::printError Reviewed-by: kbarrett, coleenp ! src/hotspot/share/gc/cms/jvmFlagConstraintsCMS.cpp ! src/hotspot/share/runtime/flags/jvmFlag.hpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp Changeset: 4236fa9582bb Author: kvn Date: 2018-10-03 10:38 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/4236fa9582bb 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI Summary: use default compile threshold for these tests Reviewed-by: thartmann ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/compiler/profiling/TestSpecTrapClassUnloading.java ! test/hotspot/jtreg/compiler/profiling/TestTypeProfiling.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass/Launcher.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java Changeset: 82dc590fa586 Author: gadams Date: 2018-10-03 07:41 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/82dc590fa586 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false Reviewed-by: cjplummer, amenkov ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java Changeset: b16820c2336d Author: poonam Date: 2018-10-03 19:30 +0000 URL: http://hg.openjdk.java.net/amber/amber/rev/b16820c2336d 8211150: G1 Full GC not purging code root memory and hence causing memory leak Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 6f04692c7d51 Author: sherman Date: 2018-10-03 12:54 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/6f04692c7d51 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative Reviewed-by: alanb, lancea ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipDirectoryStream.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java ! test/jdk/jdk/nio/zipfs/Basic.java Changeset: 35511492cd6d Author: kvn Date: 2018-10-03 14:53 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/35511492cd6d 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError Summary: exclude this test from running with Java Graal Reviewed-by: iveresov ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: ef114f6afcf1 Author: jwilhelm Date: 2018-10-04 00:50 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/ef114f6afcf1 Added tag jdk-12+14 for changeset 8897e41b327c ! .hgtags Changeset: 8705c6d536c5 Author: jwilhelm Date: 2018-10-04 10:35 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/8705c6d536c5 Added tag jdk-12+14 for changeset 6f04692c7d51 ! .hgtags Changeset: 6f58ecdb060a Author: nishjain Date: 2018-10-04 17:25 +0530 URL: http://hg.openjdk.java.net/amber/amber/rev/6f58ecdb060a 8166138: DateTimeFormatter.ISO_INSTANT should handle offsets Reviewed-by: rriggs, scolebourne, naoto Contributed-by: pallavi.sonal at oracle.com ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/jdk/java/time/tck/java/time/format/TCKInstantPrinterParser.java Changeset: 92383597fa21 Author: rehn Date: 2018-10-04 14:03 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/92383597fa21 8210303: VM_HandshakeAllThreads fails assert with "failed: blocked and not walkable" Reviewed-by: dcubed, dholmes ! src/hotspot/share/runtime/handshake.cpp Changeset: 1aa9beac610e Author: mdoerr Date: 2018-10-04 16:39 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/1aa9beac610e 8210754: print_location is not reliable enough (printing register info) Reviewed-by: stuefe, coleenp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 821bfc24d750 Author: mchung Date: 2018-10-04 08:45 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/821bfc24d750 8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass Reviewed-by: alanb, egahlin ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/jdk/internal/reflect/ClassDefiner.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventClassBuilder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventHandlerCreator.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java ! test/hotspot/jtreg/compiler/jsr292/NonInlinedCall/RedefineTest.java ! test/hotspot/jtreg/compiler/unsafe/UnsafeGetConstantField.java ! test/hotspot/jtreg/runtime/Dictionary/CleanProtectionDomain.java Changeset: 9ea22a0f9540 Author: vromero Date: 2018-10-04 08:37 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/9ea22a0f9540 8211148: var in implicit lambdas shouldn't be accepted for source < 11 Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/langtools/tools/javac/diags/examples/VarInImplicitLambda.java ! test/langtools/tools/javac/lambda/LambdaParserTest.java ! test/langtools/tools/javac/var_implicit_lambda/VarInImplicitLambdaNegTest01.java ! test/langtools/tools/javac/var_implicit_lambda/VarInImplicitLambdaNegTest01.out + test/langtools/tools/javac/var_implicit_lambda/VarInImplicitLambdaNegTest01_source10.out Changeset: d3424ddad792 Author: gdub Date: 2018-08-17 12:19 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/d3424ddad792 8209136: [JVMCI] Make sure volatile fields are read as volatile during constant reflection. Reviewed-by: kvn ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java Changeset: 592dff6ac440 Author: erikj Date: 2018-10-04 09:43 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/592dff6ac440 8211677: Java resource copy and clean should use MakeTargetDir macro Reviewed-by: tbell, ihse ! make/common/JavaCompilation.gmk Changeset: d63efc278e93 Author: vromero Date: 2018-10-04 10:19 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/d63efc278e93 8210789: langtools/tools/javac/T8152616.java missing @modules Reviewed-by: jjg ! test/langtools/tools/javac/T8152616.java Changeset: 4c247dde38ed Author: mchung Date: 2018-10-04 13:02 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/4c247dde38ed 8206240: java.lang.Class.newInstance() is causing caller to leak Reviewed-by: alanb ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/ReflectAccess.java ! src/java.base/share/classes/jdk/internal/reflect/LangReflectAccess.java ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! test/jdk/java/lang/StackWalker/ReflectionFrames.java ! test/jdk/java/lang/reflect/callerCache/AccessTest.java ! test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java ! test/jdk/jdk/modules/open/Basic.java Changeset: 7b90af8664ca Author: naoto Date: 2018-10-04 14:12 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/7b90af8664ca 8211398: Square character support for the Japanese new era Reviewed-by: rriggs ! make/data/unicodedata/UnicodeData.txt ! src/java.base/share/classes/java/lang/Character.java ! test/jdk/java/lang/Character/Scripts.txt ! test/jdk/java/lang/Character/UnicodeData.txt ! test/jdk/java/lang/Character/charprop00.bin Changeset: 804792ce736f Author: rwestberg Date: 2018-10-05 07:54 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/804792ce736f 8210459: Add support for generating compile_commands.json Reviewed-by: erikj, ihse + make/CompileCommands.gmk ! make/Main.gmk ! make/ModuleWrapper.gmk ! make/common/JdkNativeCompilation.gmk ! make/common/NativeCompilation.gmk ! make/conf/jib-profiles.js ! make/hotspot/lib/CompileJvm.gmk ! make/launcher/Launcher-jdk.pack.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/Lib-jdk.accessibility.gmk ! make/lib/LibCommon.gmk + test/make/TestCompileCommands.gmk ! test/make/TestMake.gmk Changeset: d0c04d180a3b Author: michaelm Date: 2018-10-05 11:28 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/d0c04d180a3b 8211420: com.sun.net.httpserver.HttpServer returns Content-length header for 204 response code Reviewed-by: chegar ! src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java + test/jdk/com/sun/net/httpserver/bugs/B8211420.java Changeset: 257ae7e677c3 Author: hseigel Date: 2018-10-05 08:50 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/257ae7e677c3 8211438: [Testbug] runtime/XCheckJniJsig/XCheckJSig.java looks for libjsig in wrong location Summary: Remove the os_arch string and JRE path from the test. Also add JNIEXPORT to libjsig symbols so dlsym can find them Reviewed-by: dholmes, lfoltan ! src/java.base/unix/native/libjsig/jsig.c ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/XCheckJniJsig/XCheckJSig.java Changeset: e75f6076d391 Author: coleenp Date: 2018-10-05 09:15 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/e75f6076d391 8209889: RedefineStress tests crash Summary: Create CompileTaskWrapper before potential safepoint Reviewed-by: mdoerr, dlong ! src/hotspot/share/compiler/compileBroker.cpp Changeset: 286389b60292 Author: kbarrett Date: 2018-10-05 14:28 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/286389b60292 8211296: Remove HotSpot deprecation warning suppression for Mac/clang Summary: Removed deprecation warning suppression, fixed uses of deprecated functions. Reviewed-by: dholmes, mikael ! make/hotspot/lib/CompileJvm.gmk ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp Changeset: 549bc49734e8 Author: jcbeyler Date: 2018-10-05 13:38 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/549bc49734e8 8211123: GC Metaspace printing after full gc Summary: Move GC printing to after usage is calculated Reviewed-by: tschatzl, stuefe Contributed-by: nijiaben at perfma.com, jcbeyler at google.com ! src/hotspot/share/gc/shared/genCollectedHeap.cpp + test/hotspot/jtreg/gc/logging/TestMetaSpaceLog.java + test/hotspot/jtreg/gc/logging/testcases.jar Changeset: 951d401ac00f Author: bpb Date: 2018-10-05 15:37 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/951d401ac00f 8211794: Remove jdk/java/nio/channels/Selector/RacyDeregister.java from problem list Reviewed-by: bchristi ! test/jdk/ProblemList.txt Changeset: ccfa71bacd6f Author: kvn Date: 2018-10-05 15:46 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/ccfa71bacd6f 8206963: [AOT] bug with multiple class loaders Summary: AOT should not support custom class loaders. Reviewed-by: dlong, iveresov ! src/hotspot/share/aot/aotCodeHeap.cpp Changeset: 57862a02bf4b Author: jiangli Date: 2018-10-05 18:56 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/57862a02bf4b 8202951: Implementation of JEP 341: Default CDS Archives 8210592: Convert CDS-mode test sets in tier5 and tier6 to non-CDS-mode tests 8209739: [TESTBUG] javax/imageio/plugins/png/ItxtUtf8Test.java fails with OutOfMemoryError when running in CDS mode Summary: Generate the default CDS archive at JDK build time. Reviewed-by: erikj, ihse, dholmes, iklam, ccheung, mseledtsov Contributed-by: erik.joelsson at oracle.com, jiangli.zhou at oracle.com, calvin.cheung at oracle.com ! make/Images.gmk ! make/autoconf/configure.ac ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/scripts/compare.sh ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! test/TestCommon.gmk - test/hotspot/jtreg/ProblemList-cds-mode.txt + test/hotspot/jtreg/ProblemList-non-cds-mode.txt + test/hotspot/jtreg/runtime/SharedArchiveFile/CheckDefaultArchiveFile.java + test/hotspot/jtreg/runtime/SharedArchiveFile/CheckSharingWithDefaultArchive.java ! test/hotspot/jtreg/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java ! test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java ! test/lib/jdk/test/lib/Platform.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: ecb72543c632 Author: rkennke Date: 2018-09-27 13:56 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/ecb72543c632 8211219: Type inconsistency in LIRGenerator::atomic_cmpxchg(..) Reviewed-by: eosterlund, iveresov ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp Changeset: 2f7a2e7c3221 Author: vaibhav Date: 2018-10-05 18:25 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/2f7a2e7c3221 8210376: [TESTBUG] @requires vm.cds should be replaced by @requires vm.cds.archived.java.heap and documentation is required for vm.gc==null Summary: @requires vm.cds should be replaced by @requires vm.cds.archived.java.heap and documentation is required for vm.gc==null Reviewed-by: iklam, jiangli Contributed-by: Vaibhav Choudhary ! test/hotspot/jtreg/runtime/appcds/CommandLineFlagCombo.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/OpenArchiveRegion.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions_noCompactStrings.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions_stringDedup.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java Changeset: d6aa9ea2405d Author: dnsimon Date: 2018-10-05 20:03 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/d6aa9ea2405d 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation Reviewed-by: never, kvn, sspitsyn ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayKlass.cpp ! src/hotspot/share/oops/typeArrayKlass.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotBackend.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotHostForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java Changeset: c83bc5def0d4 Author: lancea Date: 2018-10-07 14:35 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/c83bc5def0d4 8211765: JarFile constructor throws undocumented exception Reviewed-by: lancea, sherman, alanb, chegar Contributed-by: Jaikiran Pai ! src/java.base/share/classes/java/util/zip/ZipFile.java ! test/jdk/java/util/jar/JarFile/Constructor.java Changeset: f697ba5b18d2 Author: weijun Date: 2018-10-08 13:25 +0800 URL: http://hg.openjdk.java.net/amber/amber/rev/f697ba5b18d2 8210395: Add doc to SecurityTools.java Reviewed-by: mullan ! test/lib/jdk/test/lib/SecurityTools.java ! test/lib/jdk/test/lib/util/JarUtils.java Changeset: 5d6d636cefff Author: roland Date: 2018-10-05 16:47 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/5d6d636cefff 8211776: 8210887 broke arraycopy optimization when ZGC is enabled Reviewed-by: kvn ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp Changeset: d2a6c3cbc110 Author: eosterlund Date: 2018-10-08 14:48 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/d2a6c3cbc110 8211718: Supporting multiple concurrent OopStorage iterators Reviewed-by: pliden, kbarrett ! src/hotspot/share/gc/shared/oopStorage.cpp ! src/hotspot/share/gc/shared/oopStorage.hpp ! src/hotspot/share/gc/shared/oopStorageParState.hpp Changeset: 957de5be48bc Author: vromero Date: 2018-10-08 06:52 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/957de5be48bc 8209407: VerifyError is thrown for inner class with lambda Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/langtools/tools/javac/lambda/T8209407/VerifierErrorInnerPlusLambda.java Changeset: 15a9f90aa00f Author: simonis Date: 2018-10-08 17:41 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/15a9f90aa00f 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS Reviewed-by: shade, goetz, mdoerr, iklam ! make/autoconf/hotspot.m4 ! make/autoconf/jdk-options.m4 Changeset: d8aebcc2d3ac Author: redestad Date: 2018-10-08 18:16 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/d8aebcc2d3ac 8211860: Avoid reading security properties eagerly on Manifest class initialization Reviewed-by: mullan, alanb ! src/java.base/share/classes/java/util/jar/Manifest.java ! src/java.base/share/classes/sun/security/util/SecurityProperties.java Changeset: 54e8e34a7243 Author: chegar Date: 2018-10-08 18:29 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/54e8e34a7243 8211863: Problem list test/jdk/javax/naming/module/RunBasic.java Reviewed-by: lancea ! test/jdk/ProblemList.txt Changeset: ba67866e9c12 Author: gadams Date: 2018-10-08 07:18 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/ba67866e9c12 8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently Reviewed-by: cjplummer, dcubed ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java Changeset: 50dc6dd40e6a Author: jjg Date: 2018-10-08 11:14 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/50dc6dd40e6a 8211407: Bad links to non-existent entries on serialized-form page Reviewed-by: jlahoda ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java + test/langtools/jdk/javadoc/doclet/testSerialTag/TestSerialTag.java From maurizio.cimadamore at oracle.com Mon Oct 8 18:22:42 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 18:22:42 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201810081822.w98IMhi4015650@aojmv0008.oracle.com> Changeset: be8a0c68aaf9 Author: mcimadamore Date: 2018-10-08 20:24 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/be8a0c68aaf9 Automatic merge with default - make/Jprt.gmk ! make/autoconf/spec.gmk.in - make/jprt.properties ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/java.base/share/classes/java/lang/Class.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh From maurizio.cimadamore at oracle.com Mon Oct 8 18:23:01 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 18:23:01 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201810081823.w98IN177015947@aojmv0008.oracle.com> Changeset: 82d785fc4c29 Author: mcimadamore Date: 2018-10-08 20:25 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/82d785fc4c29 Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh From maurizio.cimadamore at oracle.com Mon Oct 8 18:23:21 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 18:23:21 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201810081823.w98INLMV016436@aojmv0008.oracle.com> Changeset: 35b214e3f722 Author: mcimadamore Date: 2018-10-08 20:25 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/35b214e3f722 Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh From maurizio.cimadamore at oracle.com Mon Oct 8 18:23:39 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 18:23:39 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201810081823.w98INeu1016731@aojmv0008.oracle.com> Changeset: bc788b3c1e29 Author: mcimadamore Date: 2018-10-08 20:25 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/bc788b3c1e29 Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh From maurizio.cimadamore at oracle.com Mon Oct 8 18:23:58 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 18:23:58 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201810081823.w98INwxm017460@aojmv0008.oracle.com> Changeset: 7d8275e2d0c5 Author: mcimadamore Date: 2018-10-08 20:26 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/7d8275e2d0c5 Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh ! test/langtools/tools/javac/lambda/LambdaParserTest.java From maurizio.cimadamore at oracle.com Mon Oct 8 18:24:17 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 18:24:17 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201810081824.w98IOHcK017958@aojmv0008.oracle.com> Changeset: d5b4ca33d66b Author: mcimadamore Date: 2018-10-08 20:26 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/d5b4ca33d66b Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh From maurizio.cimadamore at oracle.com Mon Oct 8 18:24:35 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 18:24:35 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201810081824.w98IOa34018241@aojmv0008.oracle.com> Changeset: 9bb1a300931e Author: mcimadamore Date: 2018-10-08 20:26 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/9bb1a300931e Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh From vicente.romero at oracle.com Mon Oct 8 19:31:18 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 08 Oct 2018 19:31:18 +0000 Subject: hg: amber/amber: manual merge with default Message-ID: <201810081931.w98JVIFQ017701@aojmv0008.oracle.com> Changeset: 6aac02158033 Author: vromero Date: 2018-10-08 12:15 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/6aac02158033 manual merge with default - make/Jprt.gmk - make/jprt.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh From maurizio.cimadamore at oracle.com Mon Oct 8 19:33:18 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 19:33:18 +0000 Subject: hg: amber/amber: Automatic merge with concise-method-declarations Message-ID: <201810081933.w98JXI7x018912@aojmv0008.oracle.com> Changeset: b6dea1885221 Author: mcimadamore Date: 2018-10-08 21:35 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/b6dea1885221 Automatic merge with concise-method-declarations - make/Jprt.gmk ! make/autoconf/spec.gmk.in - make/jprt.properties ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/java.base/share/classes/java/lang/Class.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh From vicente.romero at oracle.com Mon Oct 8 20:05:16 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 08 Oct 2018 20:05:16 +0000 Subject: hg: amber/amber: manual merge with patterns Message-ID: <201810082005.w98K5Gdl002446@aojmv0008.oracle.com> Changeset: 4bf6459e4d5e Author: vromero Date: 2018-10-08 12:49 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/4bf6459e4d5e manual merge with patterns ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties From vicente.romero at oracle.com Mon Oct 8 20:26:30 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 08 Oct 2018 20:26:30 +0000 Subject: hg: amber/amber: manual merge with patterns Message-ID: <201810082026.w98KQUsQ012685@aojmv0008.oracle.com> Changeset: 38902a2c1ad5 Author: vromero Date: 2018-10-08 13:09 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/38902a2c1ad5 manual merge with patterns ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties From forax at univ-mlv.fr Tue Oct 9 10:45:07 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 9 Oct 2018 12:45:07 +0200 (CEST) Subject: amber-demo branch has trouble with the switch on String Message-ID: <328600180.298133.1539081907328.JavaMail.zimbra@u-pem.fr> Hi all, this was reported by one of my students. It seems there is a bad merge somewhere with the amber-demo branch, this issue is no reproducible with the latest beta of jdk 12. javac struggle with the following code: public static String exprStringSwitch(String index) { return switch(index) { case "viva zorg", "foo" -> "zero"; case "bar" -> "one"; case "baz" -> "a lot"; default -> throw new IllegalArgumentException("number should be foo, bar, baz or viva zorg. Having : " + index); }; } Note: ./src/main/java/fr.umlv.javainside.labthree/fr/umlv/javainside/labthree/ExprSwitches.java uses preview language features. Note: Recompile with -Xlint:preview for details. An exception has occurred in the compiler (12-amber). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.NullPointerException at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:662) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:647) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitSwitch(Gen.java:1226) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitch.accept(JCTree.java:1260) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:626) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:612) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:663) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1027) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1052) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:626) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:612) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:663) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitLetExpr(Gen.java:2152) at jdk.compiler/com.sun.tools.javac.tree.JCTree$LetExpr.accept(JCTree.java:3202) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:813) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1623) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1665) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:626) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:612) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:663) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1027) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1052) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:626) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:897) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:860) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:894) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2204) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1647) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1615) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) at jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) cheers, R?mi From vicente.romero at oracle.com Tue Oct 9 18:24:35 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 09 Oct 2018 18:24:35 +0000 Subject: hg: amber/amber: initial push asm-condy branch Message-ID: <201810091824.w99IOZxY022169@aojmv0008.oracle.com> Changeset: 668b141c6734 Author: vromero Date: 2018-10-09 11:08 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/668b141c6734 initial push asm-condy branch From vicente.romero at oracle.com Tue Oct 9 18:31:09 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 09 Oct 2018 18:31:09 +0000 Subject: hg: amber/amber: pushing ASM version ASM_7_0_BETA, for condy testing Message-ID: <201810091831.w99IVAth027448@aojmv0008.oracle.com> Changeset: ef0a836069eb Author: vromero Date: 2018-10-09 11:15 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/ef0a836069eb pushing ASM version ASM_7_0_BETA, for condy testing ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Attribute.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassTooLargeException.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/ConstantDynamic.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Context.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/CurrentFrame.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Edge.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Handle.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Handler.java - src/java.base/share/classes/jdk/internal/org/objectweb/asm/Item.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Label.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodTooLargeException.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ModuleVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ModuleWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/Symbol.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/SymbolTable.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/TypePath.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/TypeReference.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AnnotationRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ClassRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/FieldRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/MethodRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleHashesAttribute.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleResolutionAttribute.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleTargetAttribute.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SignatureRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LabelNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableAnnotationNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleExportNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleOpenNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleProvideNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleRequireNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ParameterNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TypeAnnotationNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/UnsupportedClassVersionException.java + src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/Util.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Value.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckModuleAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceModuleVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/version.txt From vicente.romero at oracle.com Tue Oct 9 19:04:30 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 09 Oct 2018 19:04:30 +0000 Subject: hg: amber/amber: suppressing some warnings in ASM code Message-ID: <201810091904.w99J4ULV013632@aojmv0008.oracle.com> Changeset: 78ec06b98729 Author: vromero Date: 2018-10-09 11:48 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/78ec06b98729 suppressing some warnings in ASM code ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassTooLargeException.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodTooLargeException.java From jbvernee at xs4all.nl Tue Oct 9 19:08:44 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Tue, 09 Oct 2018 21:08:44 +0200 Subject: Feedback on concise methods Message-ID: Hello, I saw the recently proposed JEP for concise methods [1], and wanted to voice my opinion while I have the chance. I have some experience with similar features in C# and Kotlin, and I have to say that I generally don't like them. public static int length(String s) -> s.length(); I believe this harms readability by blurring the lines between the way fields and methods look too much. This is problematic when visually scanning a class, as it becomes harder to tell at a glance whether you're looking at a field or a method. It was mentioned in the JEP that lambdas also have a more concise form with the curly braces and return statement omitted, but by doing the some for method declarations, that also means that different language elements will look similar, and it becomes harder to distinguish between them. In the pragmatic context of a class body together with other field and verbose-form method declarations, imho the concise form is harder to read since you have to spend extra time deciding whether you're looking at a field or a method. The JEP gives a good example of this as well: class C { Function fun1() -> this::bar; Function fun2() = this::bar; String bar(String s) { return null; } Function bar() { return null; } } Where I find it difficult to tell whether the first declaration is a concise-form method, or it is a field with a functional interface type and a lambda expression as initializer. I also feel that there is a serious readability malice to having 3 ways of reading a method, instead of just one, and having to multiplex between reading the different forms. I feel all this goes against the "reading is more important than writing" principle. Though, to be honest, I don't see how it makes writing code any easier either. One of the main use cases for the arrow form seems to be getters, but I don't manually write getters any ways, I always generate them with my IDE. In other cases IDE auto-completion could fill in the curly braces and return statement: public static int length(String s) { Becomes: public static int length(String s) { return ; } It might seem that the method reference form makes a stronger case here, since it also allows you to avoid having to manually forward parameters. But I find that my IDE tries to automatically fill in the arguments to a method call I'm auto-completing with variables from the context scope already: public String m(A a, B b) { return x.m ; } Becomes: public String m(A a, B b) { return x.m(a, b); } And in that sense it kind of feels like the language is trying to do the IDE's job, as far as writeability goes. To be frank; I don't see the concise form as better, just different, and having different ways of doing the same thing has it's own cost to it. I just don't see what weakness or restriction is being removed by adding this feature. Best regards, Jorn Vernee [1] : http://openjdk.java.net/jeps/8209434 From vicente.romero at oracle.com Tue Oct 9 19:33:20 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 09 Oct 2018 19:33:20 +0000 Subject: hg: amber/amber: Opcodes.ASM6 -> Opcodes.ASM7 Message-ID: <201810091933.w99JXLCR029833@aojmv0008.oracle.com> Changeset: 72bd4c6ac1e7 Author: vromero Date: 2018-10-09 12:13 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/72bd4c6ac1e7 Opcodes.ASM6 -> Opcodes.ASM7 ! make/nashorn/buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java From scolebourne at joda.org Tue Oct 9 21:34:17 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 9 Oct 2018 22:34:17 +0100 Subject: Concise Method Bodies feedback Message-ID: My first reaction to concise method bodies was "yuck". But I wasn't fully sure why, so I held back on commenting here to see some of the points in the discussion. The headline is that I am mostly in agreement with Kevin's response. That adding this to Java will be adding a lot of style discussions and mental overload for something that mostly seems pretty low value. There needs to be more evidence of benefits to justify this change. - Which method variant should I use for the method I'm writing? - Should I change others in the file to match? - Does it make it less likely that I'll add that extra bit of code in because of the hassle of converting back from the short form to the long form? (I hate it when I have to convert back from method ref to lambda) - Will this just result in office debate? (I hate that IntelliJ has a helpful hint to convert lambdas to method refs and too many unthinking IntelliJ users therefore assume method refs are better) - Why do I need to think about all this, its not helping me write code (and certainly making it harder to read)? --- Comments One of my first reactions was also the lack of consideration of comments (something I've also noted with records). For a typical getter-style method this feature may target, there will typically be 3 to 5 lines of Javadoc to 3 lines of code: /** * Gets the foo. *

* The foo is used for bar and baz. */ public String getFoo() { return foo; } With properly documented code, CMB clearly won't be saving as much of the codebase as it might initially appear. The situation is worse for methods that take arguments. For example, LocalTime has factory methods that take hour/minute and could call the factory that takes hour/minute/sec/nano. But the docs dominate, so the "saving" isn't really there. /** * Obtains an instance of {@code LocalTime} from an hour and minute. *

* This returns a {@code LocalTime} with the specified hour and minute. * The second and nanosecond fields will be set to zero. * * @param hour the hour-of-day to represent, from 0 to 23 * @param minute the minute-of-hour to represent, from 0 to 59 * @return the local time, not null * @throws DateTimeException if the value of any field is out of range */ public static LocalTime of(int hour, int minute) -> of(hour, minute, 0, 0); (woo! I saved 2 lines out of 14. And made the code harder to read) And when I hit the line length limits and have to wrap the method parameters? It will look damn ugly. --- Use cases So far, my reading of the thread and JEP is that the use cases are not particularly motivating. The comparator one is better, but I want more than one use case. The trouble is that I can't say I've ever felt that the braces on a method are holding me back and the discussion so far isn't selling it as a feature. --- Readabilty Some of the examples posted on the spec-experts thread have been downright unreadable. I find myself really struggling to work out whether a line is an instance variable or a method declaration. That simply shouldn't be the case! --- Syntax/Semantics (Its not too early to talk syntax, when the feature is mostly syntactic) For the method ref form, I'm not sold on full expressions on the LHS of :: particularly wrt when the expression is evaluated. I'm also struggling to see use cases beyond instance variables, this and types, so semantically I'd prefer to keep it simple. For the expression form, the semantics are obvious, but the need seems very low. A method can be written on one line today, so this saves very little, and at a high cost. I'm not a fan of either the = or arrow syntax here. The equals is understandable, but does make the code blend into instance variables when written without comments (I'm sure there is a puzzler there...). The arrow is being subverted again. It should be just for mobile code, whereas the code here runs in the context you see. And arrow is particularly painful here because a lambda can have parameters to the left of the arrow, so the eye has to backtrack all the way to the method name and the absence of an = to determine that this is a method declaration rather than an instance variable with an initial value of a lambda. Since its not too late to change switch, I'll argue for colon and colon-equals: public static LocalTime of(int hour, int minute): of(hour, minute, 0, 0); public static LocalTime of(int hour, int minute):= LocalTime::create; switch (trafficLight) { when RED: doRed(); } ie. Colon introduces some code that runs within the context you can see. Arrow introduces some code that is mobile and may be run in another context. --- Summary Having seen the debate and use cases, there might be a case for a simple version of the method ref CMB using a syntax other than =. But I really struggle with the expression form. It just seems to be adding complexity, making code harder to write and harder to read. Could the solution be to keep method ref form and dump the expression form? Thanks for listening Stephen From vicente.romero at oracle.com Tue Oct 9 21:35:11 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 09 Oct 2018 21:35:11 +0000 Subject: hg: amber/amber: removing references to ASMX where X < 7 in tests Message-ID: <201810092135.w99LZCdF027644@aojmv0008.oracle.com> Changeset: 50acd80d3b6e Author: vromero Date: 2018-10-09 13:18 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/50acd80d3b6e removing references to ASMX where X < 7 in tests ! test/jdk/java/lang/invoke/accessProtectedSuper/Test.java From brian.goetz at oracle.com Wed Oct 10 13:05:21 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 10 Oct 2018 09:05:21 -0400 Subject: Concise Method Bodies feedback In-Reply-To: References: Message-ID: <2C07E9C7-855C-4A53-A96F-2D92C9893C63@oracle.com> Thanks for taking the time to pen these thoughts (and for waiting a bit to give your initial subjective reaction a voice.) In many ways, these are the ?obvious? reactions (in the sense that, I usually do a ?what reactions might I expect? exercise before I send something out, and all of these were on the list, so that?s good), so let me share the ?obvious? context and counter-arguments. > My first reaction to concise method bodies was "yuck?. I expected a lot of people to have this reaction. And also a lot would have the other reaction. So far, my expectations have been confirmed :) So, ++subjectiveYuck noted :) The idea didn?t come from nowhere; C# added it a while back, and Scala and Kotlin have similar features. And over the years, a lot of programmers who like these languages have bent my ear about it. So while there are obvious counter-arguments, there is also a certain amount of pent-up desire for it. At first, my reaction was the same as yours ? ?not worth it.? But, as I worked through the Amber programme, and the theme of ?needless repetition is where bugs hide? came up over and over again, it started to grow on me, especially the ?equals? form. I also found myself using it when writing code on whiteboards and such. So I felt it deserved a broader airing. > That adding this to Java will be adding a lot of style discussions and > mental overload for something that mostly seems pretty low value. Yes, I discussed this exact concern with the C# stewards a while back, to see what the arc of reaction and adoption was in their community. They allowed as how there was an initial period of ?style guide wars? as people grappled with the right way to use this feature (you listed a number of such issues), and that the initial round generated the expected share of noise and angst, but that eventually things equilibrated to a pretty reasonable balance, and that in the end, people are quite happy to have the feature, and would be sad to lose it. > (and certainly making it harder to read)? People have a tendency to level the ?hard to read? accusation against any new feature they don?t love. But, the C# community took about 5 minutes to get over this; I have full confidence that the Java community would be the same. > One of my first reactions was also the lack of consideration of > comments Oh, there was a lot of consideration for this. In APIs, where Javadoc often overwhelms code ? and which describes most of the code I write ? I agree this feature is mostly silly. But, now let?s talk about the other 99% of Java code out there. The vast, vast majority of Java code has NO JAVADOC WHATSOEVER. It is implementation code for domain data and logic ? and way too much of it. These people are in pain, and that?s who this feature is for. (I can understand how this would be confusing, because ordinarily we over-rotate towards the needs of library developers in selecting language features. This one is for everyone else. We?re allowed to do that once in a while.) OK, so will this feature save those guys? Of course not. There are many other sources of needless boilerplate, and we?re thinking about all of them, and may be ready to propose features for some more of them soon. This one was simplest, so it escaped the lab first. > I can't say I've ever felt that > the braces on a method are holding me back and the discussion so far > isn't selling it as a feature. Fair. Just bear in mind that others feel differently. I hear a lot of opinions about the experience of coding in Java (and other languages). My job is to balance them. > Syntax/Semantics > (Its not too early to talk syntax, when the feature is mostly syntactic) OK, so just bear in mind that this exchange will probably have used up the entire quota for public syntax discussion until the feature is otherwise perfect. > For the method ref form, I'm not sold on full expressions on the LHS > of :: particularly wrt when the expression is evaluated. That?s not syntax, so I won?t hold it against the quota. This is a fair concern, and you?ll see that such things are being discussed on a-s-e. I think it would be reasonable to restrict the LHS to final fields, which eliminates a number of timing questions, and likely preserves all the important use cases. But, I?d rather complete the exploration of possible use cases before clamping down. Prematurely narrowing the scope often results in missing an important use case or interaction. > For the expression form, the semantics are obvious, but the need seems > very low. A method can be written on one line today, so this saves > very little, and at a high cost. I don?t necessarily disagree with the conclusion, but the claim of ?high cost? is ? excessive. (I get it, you don?t think the benefits outweigh the costs. Totally fair. Say that instead.) > I'm not a fan of either the = or arrow syntax here. The equals is > understandable, but does make the code blend into instance variables > when written without comments (I'm sure there is a puzzler there...). > The arrow is being subverted again. It should be just for mobile code, > whereas the code here runs in the context you see. If anything, I?d put it the opposite way. There are valid objections (and probably valid alternatives) to using equals here, but to suggest anything but the arrow for the expression form seems ... silly. > I really struggle with the expression form. It just seems to be adding > complexity, making code harder to write and harder to read. Could the > solution be to keep method ref form and dump the expression form? I agree that most of the power is in the delegation form, because it is more than mere concision ? it is a higher-level declaration of implementation by delegation, and capturing that is valuable. It also eliminates more repetition (the arguments) than the expression form. (Why do we have method refs, when lambdas will do the job? Because names matter, and saying ?that method over there? is clearer than a bag of imperative code that calls it. Same story.) But, I think the two features support each other, in that by having both, we arrive at a regular 3x2 grid of (statements, expression, delegate) x (method declaration, behavioral expression) scheme for describing invocable behavior. Dropping one creates an irregularity in this scheme, and such irregularities have a cost too ? they make the language harder to learn, understand, and reason about. So I think they swim or sink together, because the regularity strengthens both of them. (I know you didn?t value this aspect for switch, so I don?t expect you will value it here either.) Cheers, -Brian From vicente.romero at oracle.com Wed Oct 10 15:31:26 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 10 Oct 2018 15:31:26 +0000 Subject: hg: amber/amber: removing additional references to outdated ASM versions Message-ID: <201810101531.w9AFVQLk003580@aojmv0008.oracle.com> Changeset: 6409248d836c Author: vromero Date: 2018-10-10 08:14 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/6409248d836c removing additional references to outdated ASM versions ! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/ConstructorTracerWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/ConstructorWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIClassInstrumentation.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIInliner.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIMethodCallInliner.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIMethodMergeAdapter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! test/jdk/java/lang/instrument/asmlib/Instrumentor.java ! test/jdk/jdk/jfr/event/compiler/TestCompilerInlining.java ! test/jdk/jdk/jfr/event/io/TestInstrumentation.java From vicente.romero at oracle.com Wed Oct 10 16:30:30 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 10 Oct 2018 12:30:30 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> Message-ID: Hi all, I have updated the webrev [1], this version removes the `implements Constable` from the symbolic descriptor classes. Feedback is mostly appreciated, Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01/jdk12.dev.patch On 10/06/2018 05:00 PM, Brian Goetz wrote: > What we decided to do here is to hold back on ?implements Constable? for the symbolic descriptor classes in the initial push of JEP-334, and then when we have the symbolic expression mode for BSMs, re-implement those in XxxDesc using that. Implementing Constable isn?t needed until we get to the full constant folding anyway. That linearizes the dependencies ? first JEP-334, then symbolic mode BSM, then update JEP-334 classes to implement Constable using symbolic mode BSM. > >> On Sep 13, 2018, at 9:07 PM, John Rose wrote: >> >> I am running a review of VM-level work on bootstrap methods >> which can optionally help simplify some of these APIs: >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html >> >> Specifically, this work can be use to implement a "symbolic >> expression mode" for BSMs which causes the JVM to unpack >> constant pool nodes directly as ConstantDesc items to present >> to BSMs. This might simplify the condy forms of ConstantDesc >> instances, if javac stores native constants to reflect, rather than >> lists of strings to reassemble. >> >> ? John >> >> On Sep 11, 2018, at 12:50 PM, Vicente Romero wrote: >>> Please review the first iteration of the implementation for JEP-334 [1] JVM Constants API. The implementation can be found at [2]. JEP-334 introduces an API to model nominal descriptions of key class-file and run-time artifacts, in particular constants that are loadable from the constant pool and has already been the subject of several discussions. The implementation of this JEP has been publicly accessible throw the amber repo at [3] in the jep-334 branch. Thanks to all members of the Amber project and specially to Brian for all the hard work on the design and the implementation of this API. Thanks for all the feedback we have received so far, most of it has been integrated in the current implementation. >>> >>> Thanks, >>> Vicente >>> >>> [1] http://openjdk.java.net/jeps/334 >>> [2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch >>> [3] http://hg.openjdk.java.net/amber/amber From vicente.romero at oracle.com Thu Oct 11 20:45:58 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 11 Oct 2018 20:45:58 +0000 Subject: hg: amber/amber: renaming CR_* -> CD_* and MHR_* -> MHD_* Message-ID: <201810112045.w9BKjwiR005067@aojmv0008.oracle.com> Changeset: db399ba166ac Author: vromero Date: 2018-10-11 13:29 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/db399ba166ac renaming CR_* -> CD_* and MHR_* -> MHD_* ! src/java.base/share/classes/java/lang/constant/AsTypeMethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/ConstantDescs.java ! src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java ! src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/PrimitiveClassDescImpl.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! test/jdk/java/lang/constant/ClassDescTest.java ! test/jdk/java/lang/constant/CondyDescTest.java ! test/jdk/java/lang/constant/IndyDescTest.java ! test/jdk/java/lang/constant/MethodHandleDescTest.java ! test/jdk/java/lang/constant/MethodTypeDescTest.java ! test/jdk/java/lang/constant/SymbolicDescTest.java ! test/jdk/java/lang/constant/TypeDescriptorTest.java From vicente.romero at oracle.com Thu Oct 11 21:45:02 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 11 Oct 2018 21:45:02 +0000 Subject: hg: amber/amber: manual merge with jep-334 Message-ID: <201810112145.w9BLj2Xf004795@aojmv0008.oracle.com> Changeset: 74ee15ed51dc Author: vromero Date: 2018-10-11 14:29 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/74ee15ed51dc manual merge with jep-334 ! make/Images.gmk - make/Jprt.gmk ! make/Main.gmk ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/common/JavaCompilation.gmk ! make/common/NativeCompilation.gmk - make/jprt.properties ! make/scripts/compare.sh ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/constant/AsTypeMethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/ClassDesc.java ! src/java.base/share/classes/java/lang/constant/ConstantDescs.java ! src/java.base/share/classes/java/lang/constant/ConstantUtils.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDescImpl.java ! src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java ! src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java ! src/java.base/share/classes/java/lang/constant/PrimitiveClassDescImpl.java ! src/java.base/share/classes/java/lang/constant/ReferenceClassDescImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh ! test/jdk/java/lang/constant/SymbolicDescTest.java ! test/jdk/java/lang/constant/TypeDescriptorTest.java - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh From shade at redhat.com Fri Oct 12 08:27:06 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 12 Oct 2018 10:27:06 +0200 Subject: Build failure in amber-demo branch In-Reply-To: <00e79d4b-7625-b22b-4aa6-5cf6c877bfd9@redhat.com> References: <284f4bd7-a2ef-568d-697b-d1c4e823a18e@redhat.com> <937a1a47-7a49-623f-7924-edfbc7620db5@oracle.com> <00e79d4b-7625-b22b-4aa6-5cf6c877bfd9@redhat.com> Message-ID: On 10/08/2018 03:49 PM, Aleksey Shipilev wrote: > On 10/08/2018 03:42 PM, Vicente Romero wrote: >>> Yes, thanks! x86_64 builds are fine now. (But no other builds are fine, until you pull the >>> recent build fixes from jdk/jdk). >> >> I see, there is an automated pull that happens every Thursday and brings all the changes from >> jdk/jdk. I can force it sooner if needed > > No need, let it run in due course. amber-demo builds are fine now: https://builds.shipilev.net/openjdk-amber/ Cheers, -Aleksey From vicente.romero at oracle.com Mon Oct 15 17:51:51 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 15 Oct 2018 13:51:51 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> Message-ID: <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> adding core-libs in the loop On 10/10/2018 12:30 PM, Vicente Romero wrote: > Hi all, > > I have updated the webrev [1], this version removes the `implements > Constable` from the symbolic descriptor classes. Feedback is mostly > appreciated, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01/jdk12.dev.patch > > On 10/06/2018 05:00 PM, Brian Goetz wrote: >> What we decided to do here is to hold back on ?implements Constable? >> for the symbolic descriptor classes in the initial push of JEP-334, >> and then when we have the symbolic expression mode for BSMs, >> re-implement those in XxxDesc using that.? Implementing Constable >> isn?t needed until we get to the full constant folding anyway.? That >> linearizes the dependencies ? first JEP-334, then symbolic mode BSM, >> then update JEP-334 classes to implement Constable using symbolic >> mode BSM. >> >>> On Sep 13, 2018, at 9:07 PM, John Rose wrote: >>> >>> I am running a review of VM-level work on bootstrap methods >>> which can optionally help simplify some of these APIs: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html >>> >>> >>> Specifically, this work can be use to implement a "symbolic >>> expression mode" for BSMs which causes the JVM to unpack >>> constant pool nodes directly as ConstantDesc items to present >>> to BSMs.? This might simplify the condy forms of ConstantDesc >>> instances, if javac stores native constants to reflect, rather than >>> lists of strings to reassemble. >>> >>> ? John >>> >>> On Sep 11, 2018, at 12:50 PM, Vicente Romero >>> wrote: >>>> Please review the first iteration of the implementation for JEP-334 >>>> [1] JVM Constants API. The implementation can be found at [2]. >>>> JEP-334 introduces an API to model nominal descriptions of key >>>> class-file and run-time artifacts, in particular constants that are >>>> loadable from the constant pool and has already been the subject of >>>> several discussions. The implementation of this JEP has been >>>> publicly accessible throw the amber repo at [3] in the jep-334 >>>> branch. Thanks to all members of the Amber project and specially to >>>> Brian for all the hard work on the design and the implementation of >>>> this API. Thanks for all the feedback we have received so far, most >>>> of it has been integrated in the current implementation. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://openjdk.java.net/jeps/334 >>>> [2] >>>> http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch >>>> [3] http://hg.openjdk.java.net/amber/amber > From vicente.romero at oracle.com Mon Oct 15 18:12:40 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 15 Oct 2018 14:12:40 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> Message-ID: <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> Hi all, sorry for the repeated number of mails on this issue. I have added a direct link to the patch the right link to the webrev is [1] there is a previous version at [2] if you want to see the differences with the last version. Basically we have dropped the `implements Constable` for the symbolic descriptor classes and removed all of the code that was useful for constant folding but not strictly necessary for the API. For more information on the JEP see [3] [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01 [2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00 [3] http://openjdk.java.net/jeps/334 On 10/15/2018 01:51 PM, Vicente Romero wrote: > adding core-libs in the loop > > On 10/10/2018 12:30 PM, Vicente Romero wrote: >> Hi all, >> >> I have updated the webrev [1], this version removes the `implements >> Constable` from the symbolic descriptor classes. Feedback is mostly >> appreciated, >> >> Thanks, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/8210031/webrev.01/jdk12.dev.patch >> >> On 10/06/2018 05:00 PM, Brian Goetz wrote: >>> What we decided to do here is to hold back on ?implements Constable? >>> for the symbolic descriptor classes in the initial push of JEP-334, >>> and then when we have the symbolic expression mode for BSMs, >>> re-implement those in XxxDesc using that.? Implementing Constable >>> isn?t needed until we get to the full constant folding anyway.? That >>> linearizes the dependencies ? first JEP-334, then symbolic mode BSM, >>> then update JEP-334 classes to implement Constable using symbolic >>> mode BSM. >>> >>>> On Sep 13, 2018, at 9:07 PM, John Rose wrote: >>>> >>>> I am running a review of VM-level work on bootstrap methods >>>> which can optionally help simplify some of these APIs: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html >>>> >>>> >>>> Specifically, this work can be use to implement a "symbolic >>>> expression mode" for BSMs which causes the JVM to unpack >>>> constant pool nodes directly as ConstantDesc items to present >>>> to BSMs.? This might simplify the condy forms of ConstantDesc >>>> instances, if javac stores native constants to reflect, rather than >>>> lists of strings to reassemble. >>>> >>>> ? John >>>> >>>> On Sep 11, 2018, at 12:50 PM, Vicente Romero >>>> wrote: >>>>> Please review the first iteration of the implementation for >>>>> JEP-334 [1] JVM Constants API. The implementation can be found at >>>>> [2]. JEP-334 introduces an API to model nominal descriptions of >>>>> key class-file and run-time artifacts, in particular constants >>>>> that are loadable from the constant pool and has already been the >>>>> subject of several discussions. The implementation of this JEP has >>>>> been publicly accessible throw the amber repo at [3] in the >>>>> jep-334 branch. Thanks to all members of the Amber project and >>>>> specially to Brian for all the hard work on the design and the >>>>> implementation of this API. Thanks for all the feedback we have >>>>> received so far, most of it has been integrated in the current >>>>> implementation. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] http://openjdk.java.net/jeps/334 >>>>> [2] >>>>> http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch >>>>> [3] http://hg.openjdk.java.net/amber/amber >> > From stuart.marks at oracle.com Mon Oct 15 18:39:49 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 15 Oct 2018 11:39:49 -0700 Subject: some experiments with Concise Method Bodies Message-ID: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> When I first saw the CMB proposal, I immediately thought "delegation" and so I thought it would be useful to see how CMB could be applied in this area. The example I chose was the implementation class for Collections.unmodifiableCollection(), which returns an instance of a wrapper class [1] that delegates most (but not all) method calls to the backing collection. I cloned the amber repo and updated to the concise-method-declarations branch. Building the JDK from this branch worked smoothly. Compiling "Hello, world" worked: public class Concise { public static void main(String[] args) -> System.out.println("Hello, concise method bodies!"); } I took Collections$UnmodifiableCollection and extracted it into a standalone class UnmodColl1.java [2] and stripped out some extraneous stuff. I then copied it to UnmodColl2.java [3] and converted it to use CMB. Along the way I made some shortening transformations that didn't directly relate to CMB, so I retrofitted them back to UnmodColl1.java. The results are more-or-less diff-able. Observations: * I was able to use CMB for almost everything. These wrapper classes consistent almost entirely of one-liners, to which CMB can be directly applied. * The CMB version is a bit prettier. Lack of 'return' and braces reduces visual clutter, and in a few cases it enabled things to be moved onto a single line, reducing vertical space. * Note that these wrapper classes already bend the usual style rules for braces and statements of a method body, e.g., even in the original we have the method public int size() {return c.size();} written on a single line. If the style were followed strictly, this would be written on three lines. There's a reason for this; writing all these one-liners in standard style would waste an egregious amount of vertical space. CMB syntax provides a much bigger win over standard style than over the non-standard, compact style used in these Collections wrapper classes. On the other hand, while the non-standard, compact style does save vertical space, it's kind of annoying to deal with, because it's non-standard. In my opinion the tradeoff is in favor of the compact style. But CMB mostly relieves us of having to make this tradeoff at all. * None of these methods have javadoc, since this is a private implementation class. * Many of the delegating methods can be written using the method reference form: public int size() = c::size; This would produce a marginal improvement in the syntax, mostly by removing the need for a set of parens and the need to pass parameters explicitly. The issue of time-of-evaluation of the receiver mostly doesn't arise here, since the delegate is a final field initialized by the constructor. * I tried to use CMB for the constructor, but I got an error message saying it was disallowed. No great loss, and makes some sense, I guess. * Many of the methods throw exceptions. I had a bit of a wrestling match with this. My first attempt was UnsupportedOperationException uoe() -> new UnsupportedOperationException; public boolean add(E e) -> throw uoe(); But this doesn't work, because 'throw' isn't an expression, and the concise body is required to be an expression of the right type even though we know the method can never return normally. Of course, one can do this: public boolean add(E e) { throw uoe(); } but I wanted to use CMB. My next attempt was this: boolean throwUOE() { throw new UnsupportedOperationException(); } public boolean add(E e) -> throwUOE(); Now this works, but it's a hack. Most of the throwing methods happen to return boolean, so I was able to declare the helper method to return boolean as well. It can also be used for void-returning methods. But if I had needed to delegate several throwing methods that had different return types, I wouldn't be able to do this. I tried to use the method reference form to deal with the throwing methods, but that didn't work, since those methods all take different parameters. It would be nice if I could just do public boolean add(E e) -> throw new UnsupportedOperationException(); or public boolean add(E e) -> throw uoe(); where uoe() returns an exception instance. ** Summary: it was fun playing with this feature. It seems to clean things up a little bit, and for classes that are all one-liner methods the little savings add up to a lot. The savings are incrementally greater compared to a hypothetical wrapper class that uses the standard coding style. CMB doesn't seem to be a must-have feature, at least not yet, but it does seem to have some potential. s'marks [1] http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/Collections.java#l1021 [2] http://cr.openjdk.java.net/~smarks/amber/UnmodColl1.java [3] http://cr.openjdk.java.net/~smarks/amber/UnmodColl2.java From talden at gmail.com Mon Oct 15 19:32:09 2018 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Tue, 16 Oct 2018 08:32:09 +1300 Subject: some experiments with Concise Method Bodies In-Reply-To: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> References: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> Message-ID: > public boolean add(E e) -> throw new UnsupportedOperationException(); This is similar to issues with flow-control. It would be nice to be able to do.. final Result r = condition ? goodPath() : throw new BadStuffException(); ... instead of... final Result; if (condition) { result = goodPath(); } else { throw new BadStuffException(); } ... Either branch of the ternary should be allowed to be a throw and, if both are throws the ternary is a Void expression (allowing for a concise 'which exception are we throwing'). -- Aaron Scott-Boddendijk On Tue, Oct 16, 2018 at 7:40 AM Stuart Marks wrote: > When I first saw the CMB proposal, I immediately thought "delegation" and > so I > thought it would be useful to see how CMB could be applied in this area. > The > example I chose was the implementation class for > Collections.unmodifiableCollection(), which returns an instance of a > wrapper > class [1] that delegates most (but not all) method calls to the backing > collection. > > I cloned the amber repo and updated to the concise-method-declarations > branch. > Building the JDK from this branch worked smoothly. Compiling "Hello, > world" worked: > > public class Concise { > public static void main(String[] args) > -> System.out.println("Hello, concise method bodies!"); > } > > I took Collections$UnmodifiableCollection and extracted it into a > standalone > class UnmodColl1.java [2] and stripped out some extraneous stuff. I then > copied > it to UnmodColl2.java [3] and converted it to use CMB. Along the way I > made some > shortening transformations that didn't directly relate to CMB, so I > retrofitted > them back to UnmodColl1.java. The results are more-or-less diff-able. > > Observations: > > * I was able to use CMB for almost everything. These wrapper classes > consistent > almost entirely of one-liners, to which CMB can be directly applied. > > * The CMB version is a bit prettier. Lack of 'return' and braces reduces > visual > clutter, and in a few cases it enabled things to be moved onto a single > line, > reducing vertical space. > > * Note that these wrapper classes already bend the usual style rules for > braces > and statements of a method body, e.g., even in the original we have the > method > > public int size() {return c.size();} > > written on a single line. If the style were followed strictly, this would > be > written on three lines. There's a reason for this; writing all these > one-liners > in standard style would waste an egregious amount of vertical space. CMB > syntax > provides a much bigger win over standard style than over the non-standard, > compact style used in these Collections wrapper classes. > > On the other hand, while the non-standard, compact style does save > vertical > space, it's kind of annoying to deal with, because it's non-standard. In > my > opinion the tradeoff is in favor of the compact style. But CMB mostly > relieves > us of having to make this tradeoff at all. > > * None of these methods have javadoc, since this is a private > implementation class. > > * Many of the delegating methods can be written using the method reference > form: > > public int size() = c::size; > > This would produce a marginal improvement in the syntax, mostly by > removing the > need for a set of parens and the need to pass parameters explicitly. The > issue > of time-of-evaluation of the receiver mostly doesn't arise here, since the > delegate is a final field initialized by the constructor. > > * I tried to use CMB for the constructor, but I got an error message > saying it > was disallowed. No great loss, and makes some sense, I guess. > > * Many of the methods throw exceptions. I had a bit of a wrestling match > with > this. My first attempt was > > UnsupportedOperationException uoe() -> new > UnsupportedOperationException; > public boolean add(E e) -> throw uoe(); > > But this doesn't work, because 'throw' isn't an expression, and the > concise body > is required to be an expression of the right type even though we know the > method > can never return normally. Of course, one can do this: > > public boolean add(E e) { throw uoe(); } > > but I wanted to use CMB. My next attempt was this: > > boolean throwUOE() { throw new UnsupportedOperationException(); } > public boolean add(E e) -> throwUOE(); > > Now this works, but it's a hack. Most of the throwing methods happen to > return > boolean, so I was able to declare the helper method to return boolean as > well. > It can also be used for void-returning methods. But if I had needed to > delegate > several throwing methods that had different return types, I wouldn't be > able to > do this. > > I tried to use the method reference form to deal with the throwing > methods, but > that didn't work, since those methods all take different parameters. > > It would be nice if I could just do > > public boolean add(E e) -> throw new UnsupportedOperationException(); > > or > > public boolean add(E e) -> throw uoe(); > > where uoe() returns an exception instance. > > ** > > Summary: it was fun playing with this feature. It seems to clean things up > a > little bit, and for classes that are all one-liner methods the little > savings > add up to a lot. The savings are incrementally greater compared to a > hypothetical wrapper class that uses the standard coding style. CMB > doesn't seem > to be a must-have feature, at least not yet, but it does seem to have some > potential. > > s'marks > > > [1] > > http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/Collections.java#l1021 > > [2] http://cr.openjdk.java.net/~smarks/amber/UnmodColl1.java > > [3] http://cr.openjdk.java.net/~smarks/amber/UnmodColl2.java > > From brian.goetz at oracle.com Mon Oct 15 20:17:44 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 15 Oct 2018 16:17:44 -0400 Subject: some experiments with Concise Method Bodies In-Reply-To: References: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> Message-ID: Not surprisingly, we explored this ground, and decided we liked things where they are. Your "instead of" example makes the alternative look worse than it is.? You could instead say: if (!condition) throw new BadStuffException(); final Result result = goodPath(); which isn't nearly as fussy, and is more clear, as it puts your preconditions up front. In the run-up to switch expressions, we explored allowing `throw` to be an expression, but that would lead to code for which the control flow is much harder to read: if (isFoo(x) || isBar(y) || throw new NotFooExpression()) { ... } or if (methodWithSideEffect(x) && throw new UnrelatedException()) { /* dead */ } or, even m(3, 4, throw new XYZException(...)) Now, you could say "Sure, I don't want all that, but I want it for ternary", and that would be a reasonable opinion, but at this point the cost-benefit of the incremental complexity starts to tilt the other way. Refactoring a ternary to an if, as above, really isn't so bad -- and it is more clear. So we decided to not create a special case for this. On 10/15/2018 3:32 PM, Aaron Scott-Boddendijk wrote: >> public boolean add(E e) -> throw new UnsupportedOperationException(); > This is similar to issues with flow-control. It would be nice to be able > to do.. > > final Result r = condition ? goodPath() : throw new BadStuffException(); > ... > > instead of... > > final Result; > if (condition) { > result = goodPath(); > } else { > throw new BadStuffException(); > } > ... > > Either branch of the ternary should be allowed to be a throw and, if both > are throws the ternary is a Void expression (allowing for a concise 'which > exception are we throwing'). > > -- > Aaron Scott-Boddendijk > > > On Tue, Oct 16, 2018 at 7:40 AM Stuart Marks > wrote: > >> When I first saw the CMB proposal, I immediately thought "delegation" and >> so I >> thought it would be useful to see how CMB could be applied in this area. >> The >> example I chose was the implementation class for >> Collections.unmodifiableCollection(), which returns an instance of a >> wrapper >> class [1] that delegates most (but not all) method calls to the backing >> collection. >> >> I cloned the amber repo and updated to the concise-method-declarations >> branch. >> Building the JDK from this branch worked smoothly. Compiling "Hello, >> world" worked: >> >> public class Concise { >> public static void main(String[] args) >> -> System.out.println("Hello, concise method bodies!"); >> } >> >> I took Collections$UnmodifiableCollection and extracted it into a >> standalone >> class UnmodColl1.java [2] and stripped out some extraneous stuff. I then >> copied >> it to UnmodColl2.java [3] and converted it to use CMB. Along the way I >> made some >> shortening transformations that didn't directly relate to CMB, so I >> retrofitted >> them back to UnmodColl1.java. The results are more-or-less diff-able. >> >> Observations: >> >> * I was able to use CMB for almost everything. These wrapper classes >> consistent >> almost entirely of one-liners, to which CMB can be directly applied. >> >> * The CMB version is a bit prettier. Lack of 'return' and braces reduces >> visual >> clutter, and in a few cases it enabled things to be moved onto a single >> line, >> reducing vertical space. >> >> * Note that these wrapper classes already bend the usual style rules for >> braces >> and statements of a method body, e.g., even in the original we have the >> method >> >> public int size() {return c.size();} >> >> written on a single line. If the style were followed strictly, this would >> be >> written on three lines. There's a reason for this; writing all these >> one-liners >> in standard style would waste an egregious amount of vertical space. CMB >> syntax >> provides a much bigger win over standard style than over the non-standard, >> compact style used in these Collections wrapper classes. >> >> On the other hand, while the non-standard, compact style does save >> vertical >> space, it's kind of annoying to deal with, because it's non-standard. In >> my >> opinion the tradeoff is in favor of the compact style. But CMB mostly >> relieves >> us of having to make this tradeoff at all. >> >> * None of these methods have javadoc, since this is a private >> implementation class. >> >> * Many of the delegating methods can be written using the method reference >> form: >> >> public int size() = c::size; >> >> This would produce a marginal improvement in the syntax, mostly by >> removing the >> need for a set of parens and the need to pass parameters explicitly. The >> issue >> of time-of-evaluation of the receiver mostly doesn't arise here, since the >> delegate is a final field initialized by the constructor. >> >> * I tried to use CMB for the constructor, but I got an error message >> saying it >> was disallowed. No great loss, and makes some sense, I guess. >> >> * Many of the methods throw exceptions. I had a bit of a wrestling match >> with >> this. My first attempt was >> >> UnsupportedOperationException uoe() -> new >> UnsupportedOperationException; >> public boolean add(E e) -> throw uoe(); >> >> But this doesn't work, because 'throw' isn't an expression, and the >> concise body >> is required to be an expression of the right type even though we know the >> method >> can never return normally. Of course, one can do this: >> >> public boolean add(E e) { throw uoe(); } >> >> but I wanted to use CMB. My next attempt was this: >> >> boolean throwUOE() { throw new UnsupportedOperationException(); } >> public boolean add(E e) -> throwUOE(); >> >> Now this works, but it's a hack. Most of the throwing methods happen to >> return >> boolean, so I was able to declare the helper method to return boolean as >> well. >> It can also be used for void-returning methods. But if I had needed to >> delegate >> several throwing methods that had different return types, I wouldn't be >> able to >> do this. >> >> I tried to use the method reference form to deal with the throwing >> methods, but >> that didn't work, since those methods all take different parameters. >> >> It would be nice if I could just do >> >> public boolean add(E e) -> throw new UnsupportedOperationException(); >> >> or >> >> public boolean add(E e) -> throw uoe(); >> >> where uoe() returns an exception instance. >> >> ** >> >> Summary: it was fun playing with this feature. It seems to clean things up >> a >> little bit, and for classes that are all one-liner methods the little >> savings >> add up to a lot. The savings are incrementally greater compared to a >> hypothetical wrapper class that uses the standard coding style. CMB >> doesn't seem >> to be a must-have feature, at least not yet, but it does seem to have some >> potential. >> >> s'marks >> >> >> [1] >> >> http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/Collections.java#l1021 >> >> [2] http://cr.openjdk.java.net/~smarks/amber/UnmodColl1.java >> >> [3] http://cr.openjdk.java.net/~smarks/amber/UnmodColl2.java >> >> From forax at univ-mlv.fr Mon Oct 15 20:36:05 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 15 Oct 2018 22:36:05 +0200 (CEST) Subject: some experiments with Concise Method Bodies In-Reply-To: References: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> Message-ID: <961247339.179203.1539635765881.JavaMail.zimbra@u-pem.fr> while throw is not an expression, currently the syntax "-> throw" is allowed in an expression switch but not allowed neither in a lambda and nor as a concise method body. I believe we should fix these discrepancies by allowing -> throw as part of a lambda or a CMB. R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Aaron Scott-Boddendijk" , "Stuart Marks" > Cc: "amber-dev" > Envoy?: Lundi 15 Octobre 2018 22:17:44 > Objet: Re: some experiments with Concise Method Bodies > Not surprisingly, we explored this ground, and decided we liked things > where they are. > > Your "instead of" example makes the alternative look worse than it is. > You could instead say: > > if (!condition) > throw new BadStuffException(); > final Result result = goodPath(); > > which isn't nearly as fussy, and is more clear, as it puts your preconditions up > front. > > In the run-up to switch expressions, we explored allowing `throw` to be an > expression, but that would lead to code for which the control flow is much > harder to read: > > if (isFoo(x) || isBar(y) || throw new NotFooExpression()) { ... } > > or > > if (methodWithSideEffect(x) && throw new UnrelatedException()) { /* dead */ } > > or, even > > m(3, 4, throw new XYZException(...)) > > Now, you could say "Sure, I don't want all that, but I want it for ternary", and > that would be a reasonable opinion, but at this point the cost-benefit of the > incremental complexity starts to tilt the other way. Refactoring a ternary to > an if, as above, really isn't so bad -- and it is more clear. So we decided to > not create a special case for this. > > > > > On 10/15/2018 3:32 PM, Aaron Scott-Boddendijk wrote: >>> public boolean add(E e) -> throw new UnsupportedOperationException(); >> This is similar to issues with flow-control. It would be nice to be able >> to do.. >> >> final Result r = condition ? goodPath() : throw new BadStuffException(); >> ... >> >> instead of... >> >> final Result; >> if (condition) { >> result = goodPath(); >> } else { >> throw new BadStuffException(); >> } >> ... >> >> Either branch of the ternary should be allowed to be a throw and, if both >> are throws the ternary is a Void expression (allowing for a concise 'which >> exception are we throwing'). >> >> -- >> Aaron Scott-Boddendijk >> >> >> On Tue, Oct 16, 2018 at 7:40 AM Stuart Marks >> wrote: >> >>> When I first saw the CMB proposal, I immediately thought "delegation" and >>> so I >>> thought it would be useful to see how CMB could be applied in this area. >>> The >>> example I chose was the implementation class for >>> Collections.unmodifiableCollection(), which returns an instance of a >>> wrapper >>> class [1] that delegates most (but not all) method calls to the backing >>> collection. >>> >>> I cloned the amber repo and updated to the concise-method-declarations >>> branch. >>> Building the JDK from this branch worked smoothly. Compiling "Hello, >>> world" worked: >>> >>> public class Concise { >>> public static void main(String[] args) >>> -> System.out.println("Hello, concise method bodies!"); >>> } >>> >>> I took Collections$UnmodifiableCollection and extracted it into a >>> standalone >>> class UnmodColl1.java [2] and stripped out some extraneous stuff. I then >>> copied >>> it to UnmodColl2.java [3] and converted it to use CMB. Along the way I >>> made some >>> shortening transformations that didn't directly relate to CMB, so I >>> retrofitted >>> them back to UnmodColl1.java. The results are more-or-less diff-able. >>> >>> Observations: >>> >>> * I was able to use CMB for almost everything. These wrapper classes >>> consistent >>> almost entirely of one-liners, to which CMB can be directly applied. >>> >>> * The CMB version is a bit prettier. Lack of 'return' and braces reduces >>> visual >>> clutter, and in a few cases it enabled things to be moved onto a single >>> line, >>> reducing vertical space. >>> >>> * Note that these wrapper classes already bend the usual style rules for >>> braces >>> and statements of a method body, e.g., even in the original we have the >>> method >>> >>> public int size() {return c.size();} >>> >>> written on a single line. If the style were followed strictly, this would >>> be >>> written on three lines. There's a reason for this; writing all these >>> one-liners >>> in standard style would waste an egregious amount of vertical space. CMB >>> syntax >>> provides a much bigger win over standard style than over the non-standard, >>> compact style used in these Collections wrapper classes. >>> >>> On the other hand, while the non-standard, compact style does save >>> vertical >>> space, it's kind of annoying to deal with, because it's non-standard. In >>> my >>> opinion the tradeoff is in favor of the compact style. But CMB mostly >>> relieves >>> us of having to make this tradeoff at all. >>> >>> * None of these methods have javadoc, since this is a private >>> implementation class. >>> >>> * Many of the delegating methods can be written using the method reference >>> form: >>> >>> public int size() = c::size; >>> >>> This would produce a marginal improvement in the syntax, mostly by >>> removing the >>> need for a set of parens and the need to pass parameters explicitly. The >>> issue >>> of time-of-evaluation of the receiver mostly doesn't arise here, since the >>> delegate is a final field initialized by the constructor. >>> >>> * I tried to use CMB for the constructor, but I got an error message >>> saying it >>> was disallowed. No great loss, and makes some sense, I guess. >>> >>> * Many of the methods throw exceptions. I had a bit of a wrestling match >>> with >>> this. My first attempt was >>> >>> UnsupportedOperationException uoe() -> new >>> UnsupportedOperationException; >>> public boolean add(E e) -> throw uoe(); >>> >>> But this doesn't work, because 'throw' isn't an expression, and the >>> concise body >>> is required to be an expression of the right type even though we know the >>> method >>> can never return normally. Of course, one can do this: >>> >>> public boolean add(E e) { throw uoe(); } >>> >>> but I wanted to use CMB. My next attempt was this: >>> >>> boolean throwUOE() { throw new UnsupportedOperationException(); } >>> public boolean add(E e) -> throwUOE(); >>> >>> Now this works, but it's a hack. Most of the throwing methods happen to >>> return >>> boolean, so I was able to declare the helper method to return boolean as >>> well. >>> It can also be used for void-returning methods. But if I had needed to >>> delegate >>> several throwing methods that had different return types, I wouldn't be >>> able to >>> do this. >>> >>> I tried to use the method reference form to deal with the throwing >>> methods, but >>> that didn't work, since those methods all take different parameters. >>> >>> It would be nice if I could just do >>> >>> public boolean add(E e) -> throw new UnsupportedOperationException(); >>> >>> or >>> >>> public boolean add(E e) -> throw uoe(); >>> >>> where uoe() returns an exception instance. >>> >>> ** >>> >>> Summary: it was fun playing with this feature. It seems to clean things up >>> a >>> little bit, and for classes that are all one-liner methods the little >>> savings >>> add up to a lot. The savings are incrementally greater compared to a >>> hypothetical wrapper class that uses the standard coding style. CMB >>> doesn't seem >>> to be a must-have feature, at least not yet, but it does seem to have some >>> potential. >>> >>> s'marks >>> >>> >>> [1] >>> >>> http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/Collections.java#l1021 >>> >>> [2] http://cr.openjdk.java.net/~smarks/amber/UnmodColl1.java >>> >>> [3] http://cr.openjdk.java.net/~smarks/amber/UnmodColl2.java >>> From brian.goetz at oracle.com Mon Oct 15 20:55:20 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 15 Oct 2018 16:55:20 -0400 Subject: some experiments with Concise Method Bodies In-Reply-To: <961247339.179203.1539635765881.JavaMail.zimbra@u-pem.fr> References: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> <961247339.179203.1539635765881.JavaMail.zimbra@u-pem.fr> Message-ID: <675a4018-7668-1e6f-aeab-5f07341fde75@oracle.com> For lambdas, is the difference between ??? () -> { throw E; } and ??? () -> throw E; which seems pretty harmless, but probably isn't worth much either.? For CMBs (bringing this back around to on-topic!), let's consider other statement forms too, such as setters.? I think drawing the line at "statements needs braces" is probably a cleaner way to draw it.? (Note that methods whose bodies are a single, non-return statement gain even less out of CMB, because there's no "return" to be elided.) On 10/15/2018 4:36 PM, Remi Forax wrote: > while throw is not an expression, > currently the syntax "-> throw" is allowed in an expression switch but not allowed neither in a lambda and nor as a concise method body. > > I believe we should fix these discrepancies by allowing -> throw as part of a lambda or a CMB. > > R?mi > > ----- Mail original ----- >> De: "Brian Goetz" >> ?: "Aaron Scott-Boddendijk" , "Stuart Marks" >> Cc: "amber-dev" >> Envoy?: Lundi 15 Octobre 2018 22:17:44 >> Objet: Re: some experiments with Concise Method Bodies >> Not surprisingly, we explored this ground, and decided we liked things >> where they are. >> >> Your "instead of" example makes the alternative look worse than it is. >> You could instead say: >> >> if (!condition) >> throw new BadStuffException(); >> final Result result = goodPath(); >> >> which isn't nearly as fussy, and is more clear, as it puts your preconditions up >> front. >> >> In the run-up to switch expressions, we explored allowing `throw` to be an >> expression, but that would lead to code for which the control flow is much >> harder to read: >> >> if (isFoo(x) || isBar(y) || throw new NotFooExpression()) { ... } >> >> or >> >> if (methodWithSideEffect(x) && throw new UnrelatedException()) { /* dead */ } >> >> or, even >> >> m(3, 4, throw new XYZException(...)) >> >> Now, you could say "Sure, I don't want all that, but I want it for ternary", and >> that would be a reasonable opinion, but at this point the cost-benefit of the >> incremental complexity starts to tilt the other way. Refactoring a ternary to >> an if, as above, really isn't so bad -- and it is more clear. So we decided to >> not create a special case for this. >> >> >> >> >> On 10/15/2018 3:32 PM, Aaron Scott-Boddendijk wrote: >>>> public boolean add(E e) -> throw new UnsupportedOperationException(); >>> This is similar to issues with flow-control. It would be nice to be able >>> to do.. >>> >>> final Result r = condition ? goodPath() : throw new BadStuffException(); >>> ... >>> >>> instead of... >>> >>> final Result; >>> if (condition) { >>> result = goodPath(); >>> } else { >>> throw new BadStuffException(); >>> } >>> ... >>> >>> Either branch of the ternary should be allowed to be a throw and, if both >>> are throws the ternary is a Void expression (allowing for a concise 'which >>> exception are we throwing'). >>> >>> -- >>> Aaron Scott-Boddendijk >>> >>> >>> On Tue, Oct 16, 2018 at 7:40 AM Stuart Marks >>> wrote: >>> >>>> When I first saw the CMB proposal, I immediately thought "delegation" and >>>> so I >>>> thought it would be useful to see how CMB could be applied in this area. >>>> The >>>> example I chose was the implementation class for >>>> Collections.unmodifiableCollection(), which returns an instance of a >>>> wrapper >>>> class [1] that delegates most (but not all) method calls to the backing >>>> collection. >>>> >>>> I cloned the amber repo and updated to the concise-method-declarations >>>> branch. >>>> Building the JDK from this branch worked smoothly. Compiling "Hello, >>>> world" worked: >>>> >>>> public class Concise { >>>> public static void main(String[] args) >>>> -> System.out.println("Hello, concise method bodies!"); >>>> } >>>> >>>> I took Collections$UnmodifiableCollection and extracted it into a >>>> standalone >>>> class UnmodColl1.java [2] and stripped out some extraneous stuff. I then >>>> copied >>>> it to UnmodColl2.java [3] and converted it to use CMB. Along the way I >>>> made some >>>> shortening transformations that didn't directly relate to CMB, so I >>>> retrofitted >>>> them back to UnmodColl1.java. The results are more-or-less diff-able. >>>> >>>> Observations: >>>> >>>> * I was able to use CMB for almost everything. These wrapper classes >>>> consistent >>>> almost entirely of one-liners, to which CMB can be directly applied. >>>> >>>> * The CMB version is a bit prettier. Lack of 'return' and braces reduces >>>> visual >>>> clutter, and in a few cases it enabled things to be moved onto a single >>>> line, >>>> reducing vertical space. >>>> >>>> * Note that these wrapper classes already bend the usual style rules for >>>> braces >>>> and statements of a method body, e.g., even in the original we have the >>>> method >>>> >>>> public int size() {return c.size();} >>>> >>>> written on a single line. If the style were followed strictly, this would >>>> be >>>> written on three lines. There's a reason for this; writing all these >>>> one-liners >>>> in standard style would waste an egregious amount of vertical space. CMB >>>> syntax >>>> provides a much bigger win over standard style than over the non-standard, >>>> compact style used in these Collections wrapper classes. >>>> >>>> On the other hand, while the non-standard, compact style does save >>>> vertical >>>> space, it's kind of annoying to deal with, because it's non-standard. In >>>> my >>>> opinion the tradeoff is in favor of the compact style. But CMB mostly >>>> relieves >>>> us of having to make this tradeoff at all. >>>> >>>> * None of these methods have javadoc, since this is a private >>>> implementation class. >>>> >>>> * Many of the delegating methods can be written using the method reference >>>> form: >>>> >>>> public int size() = c::size; >>>> >>>> This would produce a marginal improvement in the syntax, mostly by >>>> removing the >>>> need for a set of parens and the need to pass parameters explicitly. The >>>> issue >>>> of time-of-evaluation of the receiver mostly doesn't arise here, since the >>>> delegate is a final field initialized by the constructor. >>>> >>>> * I tried to use CMB for the constructor, but I got an error message >>>> saying it >>>> was disallowed. No great loss, and makes some sense, I guess. >>>> >>>> * Many of the methods throw exceptions. I had a bit of a wrestling match >>>> with >>>> this. My first attempt was >>>> >>>> UnsupportedOperationException uoe() -> new >>>> UnsupportedOperationException; >>>> public boolean add(E e) -> throw uoe(); >>>> >>>> But this doesn't work, because 'throw' isn't an expression, and the >>>> concise body >>>> is required to be an expression of the right type even though we know the >>>> method >>>> can never return normally. Of course, one can do this: >>>> >>>> public boolean add(E e) { throw uoe(); } >>>> >>>> but I wanted to use CMB. My next attempt was this: >>>> >>>> boolean throwUOE() { throw new UnsupportedOperationException(); } >>>> public boolean add(E e) -> throwUOE(); >>>> >>>> Now this works, but it's a hack. Most of the throwing methods happen to >>>> return >>>> boolean, so I was able to declare the helper method to return boolean as >>>> well. >>>> It can also be used for void-returning methods. But if I had needed to >>>> delegate >>>> several throwing methods that had different return types, I wouldn't be >>>> able to >>>> do this. >>>> >>>> I tried to use the method reference form to deal with the throwing >>>> methods, but >>>> that didn't work, since those methods all take different parameters. >>>> >>>> It would be nice if I could just do >>>> >>>> public boolean add(E e) -> throw new UnsupportedOperationException(); >>>> >>>> or >>>> >>>> public boolean add(E e) -> throw uoe(); >>>> >>>> where uoe() returns an exception instance. >>>> >>>> ** >>>> >>>> Summary: it was fun playing with this feature. It seems to clean things up >>>> a >>>> little bit, and for classes that are all one-liner methods the little >>>> savings >>>> add up to a lot. The savings are incrementally greater compared to a >>>> hypothetical wrapper class that uses the standard coding style. CMB >>>> doesn't seem >>>> to be a must-have feature, at least not yet, but it does seem to have some >>>> potential. >>>> >>>> s'marks >>>> >>>> >>>> [1] >>>> >>>> http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/Collections.java#l1021 >>>> >>>> [2] http://cr.openjdk.java.net/~smarks/amber/UnmodColl1.java >>>> >>>> [3] http://cr.openjdk.java.net/~smarks/amber/UnmodColl2.java >>>> From forax at univ-mlv.fr Mon Oct 15 21:32:13 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 15 Oct 2018 23:32:13 +0200 (CEST) Subject: some experiments with Concise Method Bodies In-Reply-To: <675a4018-7668-1e6f-aeab-5f07341fde75@oracle.com> References: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> <961247339.179203.1539635765881.JavaMail.zimbra@u-pem.fr> <675a4018-7668-1e6f-aeab-5f07341fde75@oracle.com> Message-ID: <1649699175.200118.1539639133054.JavaMail.zimbra@u-pem.fr> Your argument "statement need braces" is also valid for a statement switch that using the arrow syntax, but currently, "-> throw" is a valid syntax for such switch. With my teacher hat, i value far more consistency in term of syntax than some rationale depending on the semantics. R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "Remi Forax" > Cc: "Aaron Scott-Boddendijk" , "Stuart Marks" , "amber-dev" > > Envoy?: Lundi 15 Octobre 2018 22:55:20 > Objet: Re: some experiments with Concise Method Bodies > For lambdas, is the difference between > > ??? () -> { throw E; } > and > ??? () -> throw E; > > which seems pretty harmless, but probably isn't worth much either.? For > CMBs (bringing this back around to on-topic!), let's consider other > statement forms too, such as setters.? I think drawing the line at > "statements needs braces" is probably a cleaner way to draw it.? (Note > that methods whose bodies are a single, non-return statement gain even > less out of CMB, because there's no "return" to be elided.) > > On 10/15/2018 4:36 PM, Remi Forax wrote: >> while throw is not an expression, >> currently the syntax "-> throw" is allowed in an expression switch but not >> allowed neither in a lambda and nor as a concise method body. >> >> I believe we should fix these discrepancies by allowing -> throw as part of a >> lambda or a CMB. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Brian Goetz" >>> ?: "Aaron Scott-Boddendijk" , "Stuart Marks" >>> >>> Cc: "amber-dev" >>> Envoy?: Lundi 15 Octobre 2018 22:17:44 >>> Objet: Re: some experiments with Concise Method Bodies >>> Not surprisingly, we explored this ground, and decided we liked things >>> where they are. >>> >>> Your "instead of" example makes the alternative look worse than it is. >>> You could instead say: >>> >>> if (!condition) >>> throw new BadStuffException(); >>> final Result result = goodPath(); >>> >>> which isn't nearly as fussy, and is more clear, as it puts your preconditions up >>> front. >>> >>> In the run-up to switch expressions, we explored allowing `throw` to be an >>> expression, but that would lead to code for which the control flow is much >>> harder to read: >>> >>> if (isFoo(x) || isBar(y) || throw new NotFooExpression()) { ... } >>> >>> or >>> >>> if (methodWithSideEffect(x) && throw new UnrelatedException()) { /* dead */ } >>> >>> or, even >>> >>> m(3, 4, throw new XYZException(...)) >>> >>> Now, you could say "Sure, I don't want all that, but I want it for ternary", and >>> that would be a reasonable opinion, but at this point the cost-benefit of the >>> incremental complexity starts to tilt the other way. Refactoring a ternary to >>> an if, as above, really isn't so bad -- and it is more clear. So we decided to >>> not create a special case for this. >>> >>> >>> >>> >>> On 10/15/2018 3:32 PM, Aaron Scott-Boddendijk wrote: >>>>> public boolean add(E e) -> throw new UnsupportedOperationException(); >>>> This is similar to issues with flow-control. It would be nice to be able >>>> to do.. >>>> >>>> final Result r = condition ? goodPath() : throw new BadStuffException(); >>>> ... >>>> >>>> instead of... >>>> >>>> final Result; >>>> if (condition) { >>>> result = goodPath(); >>>> } else { >>>> throw new BadStuffException(); >>>> } >>>> ... >>>> >>>> Either branch of the ternary should be allowed to be a throw and, if both >>>> are throws the ternary is a Void expression (allowing for a concise 'which >>>> exception are we throwing'). >>>> >>>> -- >>>> Aaron Scott-Boddendijk >>>> >>>> >>>> On Tue, Oct 16, 2018 at 7:40 AM Stuart Marks >>>> wrote: >>>> >>>>> When I first saw the CMB proposal, I immediately thought "delegation" and >>>>> so I >>>>> thought it would be useful to see how CMB could be applied in this area. >>>>> The >>>>> example I chose was the implementation class for >>>>> Collections.unmodifiableCollection(), which returns an instance of a >>>>> wrapper >>>>> class [1] that delegates most (but not all) method calls to the backing >>>>> collection. >>>>> >>>>> I cloned the amber repo and updated to the concise-method-declarations >>>>> branch. >>>>> Building the JDK from this branch worked smoothly. Compiling "Hello, >>>>> world" worked: >>>>> >>>>> public class Concise { >>>>> public static void main(String[] args) >>>>> -> System.out.println("Hello, concise method bodies!"); >>>>> } >>>>> >>>>> I took Collections$UnmodifiableCollection and extracted it into a >>>>> standalone >>>>> class UnmodColl1.java [2] and stripped out some extraneous stuff. I then >>>>> copied >>>>> it to UnmodColl2.java [3] and converted it to use CMB. Along the way I >>>>> made some >>>>> shortening transformations that didn't directly relate to CMB, so I >>>>> retrofitted >>>>> them back to UnmodColl1.java. The results are more-or-less diff-able. >>>>> >>>>> Observations: >>>>> >>>>> * I was able to use CMB for almost everything. These wrapper classes >>>>> consistent >>>>> almost entirely of one-liners, to which CMB can be directly applied. >>>>> >>>>> * The CMB version is a bit prettier. Lack of 'return' and braces reduces >>>>> visual >>>>> clutter, and in a few cases it enabled things to be moved onto a single >>>>> line, >>>>> reducing vertical space. >>>>> >>>>> * Note that these wrapper classes already bend the usual style rules for >>>>> braces >>>>> and statements of a method body, e.g., even in the original we have the >>>>> method >>>>> >>>>> public int size() {return c.size();} >>>>> >>>>> written on a single line. If the style were followed strictly, this would >>>>> be >>>>> written on three lines. There's a reason for this; writing all these >>>>> one-liners >>>>> in standard style would waste an egregious amount of vertical space. CMB >>>>> syntax >>>>> provides a much bigger win over standard style than over the non-standard, >>>>> compact style used in these Collections wrapper classes. >>>>> >>>>> On the other hand, while the non-standard, compact style does save >>>>> vertical >>>>> space, it's kind of annoying to deal with, because it's non-standard. In >>>>> my >>>>> opinion the tradeoff is in favor of the compact style. But CMB mostly >>>>> relieves >>>>> us of having to make this tradeoff at all. >>>>> >>>>> * None of these methods have javadoc, since this is a private >>>>> implementation class. >>>>> >>>>> * Many of the delegating methods can be written using the method reference >>>>> form: >>>>> >>>>> public int size() = c::size; >>>>> >>>>> This would produce a marginal improvement in the syntax, mostly by >>>>> removing the >>>>> need for a set of parens and the need to pass parameters explicitly. The >>>>> issue >>>>> of time-of-evaluation of the receiver mostly doesn't arise here, since the >>>>> delegate is a final field initialized by the constructor. >>>>> >>>>> * I tried to use CMB for the constructor, but I got an error message >>>>> saying it >>>>> was disallowed. No great loss, and makes some sense, I guess. >>>>> >>>>> * Many of the methods throw exceptions. I had a bit of a wrestling match >>>>> with >>>>> this. My first attempt was >>>>> >>>>> UnsupportedOperationException uoe() -> new >>>>> UnsupportedOperationException; >>>>> public boolean add(E e) -> throw uoe(); >>>>> >>>>> But this doesn't work, because 'throw' isn't an expression, and the >>>>> concise body >>>>> is required to be an expression of the right type even though we know the >>>>> method >>>>> can never return normally. Of course, one can do this: >>>>> >>>>> public boolean add(E e) { throw uoe(); } >>>>> >>>>> but I wanted to use CMB. My next attempt was this: >>>>> >>>>> boolean throwUOE() { throw new UnsupportedOperationException(); } >>>>> public boolean add(E e) -> throwUOE(); >>>>> >>>>> Now this works, but it's a hack. Most of the throwing methods happen to >>>>> return >>>>> boolean, so I was able to declare the helper method to return boolean as >>>>> well. >>>>> It can also be used for void-returning methods. But if I had needed to >>>>> delegate >>>>> several throwing methods that had different return types, I wouldn't be >>>>> able to >>>>> do this. >>>>> >>>>> I tried to use the method reference form to deal with the throwing >>>>> methods, but >>>>> that didn't work, since those methods all take different parameters. >>>>> >>>>> It would be nice if I could just do >>>>> >>>>> public boolean add(E e) -> throw new UnsupportedOperationException(); >>>>> >>>>> or >>>>> >>>>> public boolean add(E e) -> throw uoe(); >>>>> >>>>> where uoe() returns an exception instance. >>>>> >>>>> ** >>>>> >>>>> Summary: it was fun playing with this feature. It seems to clean things up >>>>> a >>>>> little bit, and for classes that are all one-liner methods the little >>>>> savings >>>>> add up to a lot. The savings are incrementally greater compared to a >>>>> hypothetical wrapper class that uses the standard coding style. CMB >>>>> doesn't seem >>>>> to be a must-have feature, at least not yet, but it does seem to have some >>>>> potential. >>>>> >>>>> s'marks >>>>> >>>>> >>>>> [1] >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/Collections.java#l1021 >>>>> >>>>> [2] http://cr.openjdk.java.net/~smarks/amber/UnmodColl1.java >>>>> >>>>> [3] http://cr.openjdk.java.net/~smarks/amber/UnmodColl2.java From scolebourne at joda.org Mon Oct 15 22:01:44 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 15 Oct 2018 23:01:44 +0100 Subject: some experiments with Concise Method Bodies In-Reply-To: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> References: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> Message-ID: On Mon, 15 Oct 2018 at 19:40, Stuart Marks wrote: > Observations: > * I was able to use CMB for almost everything. These wrapper classes consistent > almost entirely of one-liners, to which CMB can be directly applied. - On the code changes, I'm not a fan of the desire to line up all the arrows. Why do that when that isn't the general style of the JDK? Was it to do with readability? What would you do if the code exceeded the line length? - I'm not a fan of the throwUOE() approach. If CMB is to go in, I think "-> throw" would be needed (and should be in lambda too). And yes, I don't think it should be a full expression usable anywhere. - Part of the driver was about delegation. But was this change successful on that measure? There was still redundant code. Specifically, you still had the full method signatures that you were delegating even though they are inherited from an interface. Method parameter names were needed when they didn't matter for example. A focussed delegate language change might well look quite different, such as (not taking this too seriously...): class UnmodList implements List { private final List underlying as delegate { get(int), size(), isEmpty(), contains(Object), toArray(), toString() }; } My point being that it is a Good Thing if a language feature is able to tackle multiple problems. But only if it tackles those problems well. Does CMB actually tackle multiple different problems well, or does it prevent better solutions for key use cases? Stephen From vicente.romero at oracle.com Mon Oct 15 22:06:02 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 15 Oct 2018 22:06:02 +0000 Subject: hg: amber/amber: add LinkageError to ConstantDesc::resolveConstantDesc Message-ID: <201810152206.w9FM628B013822@aojmv0008.oracle.com> Changeset: 8b0bd1ee3674 Author: vromero Date: 2018-10-15 14:45 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/8b0bd1ee3674 add LinkageError to ConstantDesc::resolveConstantDesc ! src/java.base/share/classes/java/lang/constant/ConstantDesc.java From maurizio.cimadamore at oracle.com Mon Oct 15 22:51:18 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 15 Oct 2018 22:51:18 +0000 Subject: hg: amber/amber: Automatic merge with jep-334 Message-ID: <201810152251.w9FMpI3D005443@aojmv0008.oracle.com> Changeset: 7f2d95b14b4a Author: mcimadamore Date: 2018-10-16 00:53 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/7f2d95b14b4a Automatic merge with jep-334 ! src/java.base/share/classes/java/lang/constant/ConstantDesc.java From stuart.marks at oracle.com Tue Oct 16 17:25:51 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 16 Oct 2018 10:25:51 -0700 Subject: some experiments with Concise Method Bodies In-Reply-To: References: <20adda2d-bf65-f27c-cdbc-55a9785d0e8f@oracle.com> Message-ID: <3316f5bc-4012-049a-dd1f-412bbb5ed326@oracle.com> On 10/15/18 3:01 PM, Stephen Colebourne wrote: > - On the code changes, I'm not a fan of the desire to line up all the > arrows. Why do that when that isn't the general style of the JDK? Was > it to do with readability? What would you do if the code exceeded the > line length? If you look at the original source file [1] you'll see that several of the method bodies use a "non-standard, compact" style, and they're all lined up: public int size() {return c.size();} public boolean isEmpty() {return c.isEmpty();} public boolean contains(Object o) {return c.contains(o);} public Object[] toArray() {return c.toArray();} public T[] toArray(T[] a) {return c.toArray(a);} public T[] toArray(IntFunction f) {return c.toArray(f);} public String toString() {return c.toString();} This "style" appears to date back all the way to the introduction of Collections in JDK 1.2. It occurs several times elsewhere in the same file. I've simply copied it in my CMB experiment. There's one case in my experiment [2] where the CMB didn't fit on the same line. I moved it to the next line, but indented it so that its arrow lines up with the others: public boolean hasNext() -> i.hasNext(); public E next() -> i.next(); public void remove() -> throwUOE(); public void forEachRemaining(Consumer action) -> i.forEachRemaining(action); Of course, it's up to you whether you want to line up arrows or equals for CMBs, but I think it makes it a bit easier to see what's going on. > - Part of the driver was about delegation. But was this change > successful on that measure? There was still redundant code. > Specifically, you still had the full method signatures that you were > delegating even though they are inherited from an interface. Method > parameter names were needed when they didn't matter for example. A > focussed delegate language change might well look quite different, > such as (not taking this too seriously...): [...] I think we need to be careful about "driver" here. My example was about using CMB for delegation; but that doesn't mean the "driver" for the CMB feature is delegation. I don't see the need to declare success or failure; I reported some observations that I hope are useful in deciding whether to or how to continue developing the CMB proposal. It may be that there are some improvements that can be made to CMB that will help the delegation case, but I'm not going to advocate for changes that turn CMB into a feature centered around supporting delegation. s'marks [1] http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/Collections.java#l1021 [2] http://cr.openjdk.java.net/~smarks/amber/UnmodColl2.java From vicente.romero at oracle.com Tue Oct 16 17:33:21 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 16 Oct 2018 17:33:21 +0000 Subject: hg: amber/amber: restrict the LHS of a bound method to one of: constant expression, final field Message-ID: <201810161733.w9GHXM4O010823@aojmv0008.oracle.com> Changeset: eaf0bc8fc95c Author: vromero Date: 2018-10-16 10:13 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/eaf0bc8fc95c restrict the LHS of a bound method to one of: constant expression, final field ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/concise_methods/ConciseMethodsNegTest01.java ! test/langtools/tools/javac/concise_methods/ConciseMethodsNegTest01.out - test/langtools/tools/javac/concise_methods/NPEQualifierIsCall.java From maurizio.cimadamore at oracle.com Tue Oct 16 17:38:48 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 16 Oct 2018 17:38:48 +0000 Subject: hg: amber/amber: Automatic merge with concise-method-declarations Message-ID: <201810161738.w9GHcmgn014003@aojmv0008.oracle.com> Changeset: 14f96db5f5f8 Author: mcimadamore Date: 2018-10-16 19:40 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/14f96db5f5f8 Automatic merge with concise-method-declarations ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/langtools/tools/javac/concise_methods/NPEQualifierIsCall.java From vicente.romero at oracle.com Tue Oct 16 20:43:39 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 16 Oct 2018 20:43:39 +0000 Subject: hg: amber/amber: remove test from jep-334 branch, merge issue Message-ID: <201810162043.w9GKhdn4015534@aojmv0008.oracle.com> Changeset: 7485ade5ea80 Author: vromero Date: 2018-10-16 13:27 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/7485ade5ea80 remove test from jep-334 branch, merge issue - test/langtools/tools/javac/specialConstantFolding/DynamicConstantDescTest.java From maurizio.cimadamore at oracle.com Tue Oct 16 20:48:44 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 16 Oct 2018 20:48:44 +0000 Subject: hg: amber/amber: Automatic merge with jep-334 Message-ID: <201810162048.w9GKmiMF018001@aojmv0008.oracle.com> Changeset: b273792ba635 Author: mcimadamore Date: 2018-10-16 22:50 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/b273792ba635 Automatic merge with jep-334 - test/langtools/tools/javac/specialConstantFolding/DynamicConstantDescTest.java From jan.lahoda at oracle.com Wed Oct 17 11:57:47 2018 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 17 Oct 2018 11:57:47 +0000 Subject: hg: amber/amber: Fixing String switch expression bug as reported by forax on amber-dev. Message-ID: <201810171157.w9HBvlkb029488@aojmv0008.oracle.com> Changeset: 37bbcd1f1f50 Author: jlahoda Date: 2018-10-17 13:56 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/37bbcd1f1f50 Fixing String switch expression bug as reported by forax on amber-dev. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransSwitches.java ! test/langtools/tools/javac/switchexpr/ExpressionSwitch-old.out ! test/langtools/tools/javac/switchexpr/ExpressionSwitch.java From maurizio.cimadamore at oracle.com Wed Oct 17 12:03:43 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Oct 2018 12:03:43 +0000 Subject: hg: amber/amber: Automatic merge with patterns Message-ID: <201810171203.w9HC3iYE003690@aojmv0008.oracle.com> Changeset: eb75b11c373d Author: mcimadamore Date: 2018-10-17 14:05 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/eb75b11c373d Automatic merge with patterns From vicente.romero at oracle.com Wed Oct 17 14:55:48 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 17 Oct 2018 10:55:48 -0400 Subject: amber-demo branch has trouble with the switch on String In-Reply-To: <328600180.298133.1539081907328.JavaMail.zimbra@u-pem.fr> References: <328600180.298133.1539081907328.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, Thanks again for reporting this bug. It has been fixed in the patterns repo [1], thanks Jan, and automagically imported to the amber-demo Vicente [1] http://hg.openjdk.java.net/amber/amber/rev/37bbcd1f1f50 On 10/9/18 6:45 AM, Remi Forax wrote: > Hi all, > this was reported by one of my students. > > It seems there is a bad merge somewhere with the amber-demo branch, > this issue is no reproducible with the latest beta of jdk 12. > > javac struggle with the following code: > public static String exprStringSwitch(String index) { > return switch(index) { > case "viva zorg", "foo" -> "zero"; > case "bar" -> "one"; > case "baz" -> "a lot"; > default -> throw new IllegalArgumentException("number should be foo, bar, baz or viva zorg. Having : " + index); > }; > } > > Note: ./src/main/java/fr.umlv.javainside.labthree/fr/umlv/javainside/labthree/ExprSwitches.java uses preview language features. > Note: Recompile with -Xlint:preview for details. > An exception has occurred in the compiler (12-amber). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. > java.lang.NullPointerException > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:662) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:647) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitSwitch(Gen.java:1226) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitch.accept(JCTree.java:1260) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:626) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:612) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:663) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1027) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1052) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:626) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:612) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:663) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitLetExpr(Gen.java:2152) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$LetExpr.accept(JCTree.java:3202) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:813) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1623) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1665) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:626) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:612) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:663) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1027) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1052) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:626) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:897) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:860) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:894) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:591) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2204) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1647) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1615) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > at jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) > at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) > > cheers, > R?mi From vicente.romero at oracle.com Thu Oct 18 19:43:22 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 18 Oct 2018 19:43:22 +0000 Subject: hg: amber/amber: changes after review comments Message-ID: <201810181943.w9IJhMf6003128@aojmv0008.oracle.com> Changeset: 533a0c8e1567 Author: vromero Date: 2018-10-18 12:24 -0700 URL: http://hg.openjdk.java.net/amber/amber/rev/533a0c8e1567 changes after review comments ! src/java.base/share/classes/java/lang/constant/ConstantDescs.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java From vicente.romero at oracle.com Thu Oct 18 21:09:37 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 18 Oct 2018 17:09:37 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> Message-ID: Hi all, Please review also the CSR at [1]. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8202031 On 10/15/18 2:12 PM, Vicente Romero wrote: > Hi all, > > sorry for the repeated number of mails on this issue. I have added a > direct link to the patch the right link to the webrev is [1] there is > a previous version at [2] if you want to see the differences with the > last version. Basically we have dropped the `implements Constable` for > the symbolic descriptor classes and removed all of the code that was > useful for constant folding but not strictly necessary for the API. > For more information on the JEP see [3] > > [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01 > [2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00 > [3] http://openjdk.java.net/jeps/334 > > On 10/15/2018 01:51 PM, Vicente Romero wrote: >> adding core-libs in the loop >> >> On 10/10/2018 12:30 PM, Vicente Romero wrote: >>> Hi all, >>> >>> I have updated the webrev [1], this version removes the `implements >>> Constable` from the symbolic descriptor classes. Feedback is mostly >>> appreciated, >>> >>> Thanks, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/8210031/webrev.01/jdk12.dev.patch >>> >>> On 10/06/2018 05:00 PM, Brian Goetz wrote: >>>> What we decided to do here is to hold back on ?implements >>>> Constable? for the symbolic descriptor classes in the initial push >>>> of JEP-334, and then when we have the symbolic expression mode for >>>> BSMs, re-implement those in XxxDesc using that.? Implementing >>>> Constable isn?t needed until we get to the full constant folding >>>> anyway. That linearizes the dependencies ? first JEP-334, then >>>> symbolic mode BSM, then update JEP-334 classes to implement >>>> Constable using symbolic mode BSM. >>>> >>>>> On Sep 13, 2018, at 9:07 PM, John Rose >>>>> wrote: >>>>> >>>>> I am running a review of VM-level work on bootstrap methods >>>>> which can optionally help simplify some of these APIs: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html >>>>> >>>>> >>>>> Specifically, this work can be use to implement a "symbolic >>>>> expression mode" for BSMs which causes the JVM to unpack >>>>> constant pool nodes directly as ConstantDesc items to present >>>>> to BSMs.? This might simplify the condy forms of ConstantDesc >>>>> instances, if javac stores native constants to reflect, rather than >>>>> lists of strings to reassemble. >>>>> >>>>> ? John >>>>> >>>>> On Sep 11, 2018, at 12:50 PM, Vicente Romero >>>>> wrote: >>>>>> Please review the first iteration of the implementation for >>>>>> JEP-334 [1] JVM Constants API. The implementation can be found at >>>>>> [2]. JEP-334 introduces an API to model nominal descriptions of >>>>>> key class-file and run-time artifacts, in particular constants >>>>>> that are loadable from the constant pool and has already been the >>>>>> subject of several discussions. The implementation of this JEP >>>>>> has been publicly accessible throw the amber repo at [3] in the >>>>>> jep-334 branch. Thanks to all members of the Amber project and >>>>>> specially to Brian for all the hard work on the design and the >>>>>> implementation of this API. Thanks for all the feedback we have >>>>>> received so far, most of it has been integrated in the current >>>>>> implementation. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] http://openjdk.java.net/jeps/334 >>>>>> [2] >>>>>> http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch >>>>>> [3] http://hg.openjdk.java.net/amber/amber >>> >> > From mandy.chung at oracle.com Fri Oct 19 01:55:41 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 18 Oct 2018 18:55:41 -0700 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> Message-ID: On 10/15/18 11:12 AM, Vicente Romero wrote: > > [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01 I reviewed java.lang.invoke change in details.? I have skimmed through the new classes. I will look at the new tests next. @since 12 is missing in the new APIs VarHandle.java 1887 public final String toString() { 1888 // @@@ defer to concrete type for additional description 1889 // see https://bugs.openjdk.java.net/browse/JDK-8199149 You may want to take out this comment or L1889 as we can refer back to JDK-8199149. VarHandles.java ?169???????? // @@@ This is a little fragile assuming the base is the class Maybe FieldStaticReadOnly and FieldStaticReadWrite constructor and getStaticFieldFromBaseAndOffset method should take Class refc rather than Object base. FieldStaticReadXXX will do the cast when calling getStaticFieldFromBaseAndOffset. java.base module-info.java ?? It'd be good to keep the exported APIs in alphabetical order. java/lang/invoke/TypeDescriptor.java ?? copyright header is missing Mandy From vicente.romero at oracle.com Fri Oct 19 17:47:23 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 19 Oct 2018 17:47:23 +0000 Subject: hg: amber/amber: adding since 12 to API, missing copyright, etc Message-ID: <201810191747.w9JHlNae029923@aojmv0008.oracle.com> Changeset: e4624753b153 Author: vromero Date: 2018-10-19 13:23 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/e4624753b153 adding since 12 to API, missing copyright, etc ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/constant/ClassDesc.java ! src/java.base/share/classes/java/lang/constant/Constable.java ! src/java.base/share/classes/java/lang/constant/ConstantDesc.java ! src/java.base/share/classes/java/lang/constant/ConstantDescs.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java ! src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java ! src/java.base/share/classes/java/lang/constant/package-info.java ! src/java.base/share/classes/java/lang/invoke/TypeDescriptor.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/module-info.java ! test/jdk/java/lang/constant/ClassDescTest.java ! test/jdk/java/lang/constant/CondyDescTest.java ! test/jdk/java/lang/constant/MethodHandleDescTest.java ! test/jdk/java/lang/constant/MethodTypeDescTest.java ! test/jdk/java/lang/constant/SymbolicDescTest.java ! test/jdk/java/lang/constant/TestHelpers.java ! test/jdk/java/lang/constant/TypeDescriptorTest.java From vicente.romero at oracle.com Fri Oct 19 17:59:30 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 19 Oct 2018 13:59:30 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> Message-ID: <8e1aa029-c9f1-a686-710a-82bbfb1ee5d6@oracle.com> Hi all, Thanks Mandy for the review. I have uploaded a new iteration [1]. Vicente [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.02/ On 10/18/18 9:55 PM, Mandy Chung wrote: > > > On 10/15/18 11:12 AM, Vicente Romero wrote: >> >> [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01 > > I reviewed java.lang.invoke change in details.? I have skimmed through > the new classes. > I will look at the new tests next. > > @since 12 is missing in the new APIs > > VarHandle.java > 1887 public final String toString() { > 1888 // @@@ defer to concrete type for additional description > 1889 // see https://bugs.openjdk.java.net/browse/JDK-8199149 You may > want to take out this comment or L1889 as we can refer back to > JDK-8199149. VarHandles.java > ?169???????? // @@@ This is a little fragile assuming the base is the > class > > Maybe FieldStaticReadOnly and FieldStaticReadWrite constructor and > getStaticFieldFromBaseAndOffset method should take Class refc > rather than Object base. FieldStaticReadXXX will do the cast when > calling getStaticFieldFromBaseAndOffset. > > java.base module-info.java > ?? It'd be good to keep the exported APIs in alphabetical order. > > java/lang/invoke/TypeDescriptor.java > ?? copyright header is missing > > Mandy From vicente.romero at oracle.com Fri Oct 19 19:21:12 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 19 Oct 2018 19:21:12 +0000 Subject: hg: amber/amber: renaming __match -> match Message-ID: <201810191921.w9JJLCjB014587@aojmv0008.oracle.com> Changeset: 11e665279521 Author: vromero Date: 2018-10-19 15:20 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/11e665279521 renaming __match -> match ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java ! test/langtools/tools/javac/patterns/BindingsTest1.java ! test/langtools/tools/javac/patterns/BindingsTest2.java ! test/langtools/tools/javac/patterns/BindingsTest2.out ! test/langtools/tools/javac/patterns/CastConversionMatch.java ! test/langtools/tools/javac/patterns/ConstantPatternTest1.java ! test/langtools/tools/javac/patterns/DuplicateBindingTest.java ! test/langtools/tools/javac/patterns/DuplicateBindingTest.out ! test/langtools/tools/javac/patterns/EnsureTypesOrderTest.java ! test/langtools/tools/javac/patterns/ExamplesFromProposal.java ! test/langtools/tools/javac/patterns/ImpossibleTypeTest.java ! test/langtools/tools/javac/patterns/ImpossibleTypeTest.out ! test/langtools/tools/javac/patterns/MatchBindingScopeTest.java ! test/langtools/tools/javac/patterns/MatchBindingScopeTest.out ! test/langtools/tools/javac/patterns/MatchesToken.java ! test/langtools/tools/javac/patterns/NestingMatchAndMatches.java ! test/langtools/tools/javac/patterns/NullsInPatterns.java ! test/langtools/tools/javac/patterns/PatternMatchPosTest.java ! test/langtools/tools/javac/patterns/PatternMatchPosTest.out ! test/langtools/tools/javac/patterns/PatternTypeTest1.java ! test/langtools/tools/javac/patterns/PatternTypeTest2.java ! test/langtools/tools/javac/patterns/PatternVariablesAreFinal.java ! test/langtools/tools/javac/patterns/PatternVariablesAreFinal2.java ! test/langtools/tools/javac/patterns/UncheckedWarningOnMatchesTest.java From forax at univ-mlv.fr Sat Oct 20 11:33:26 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 20 Oct 2018 13:33:26 +0200 (CEST) Subject: hg: amber/amber: suppressing some warnings in ASM code In-Reply-To: <201810091904.w99J4ULV013632@aojmv0008.oracle.com> References: <201810091904.w99J4ULV013632@aojmv0008.oracle.com> Message-ID: <237427522.1044928.1540035206569.JavaMail.zimbra@u-pem.fr> Hi Vicente, i've fixed those warnings upstream in the ASM sources. regards, R?mi ----- Mail original ----- > De: "Vicente Romero" > ?: "amber-dev" > Envoy?: Mardi 9 Octobre 2018 21:04:30 > Objet: hg: amber/amber: suppressing some warnings in ASM code > Changeset: 78ec06b98729 > Author: vromero > Date: 2018-10-09 11:48 -0700 > URL: http://hg.openjdk.java.net/amber/amber/rev/78ec06b98729 > > suppressing some warnings in ASM code > > ! > src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassTooLargeException.java > ! > src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodTooLargeException.java From vicente.romero at oracle.com Sat Oct 20 17:51:21 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 20 Oct 2018 13:51:21 -0400 Subject: hg: amber/amber: suppressing some warnings in ASM code In-Reply-To: <237427522.1044928.1540035206569.JavaMail.zimbra@u-pem.fr> References: <201810091904.w99J4ULV013632@aojmv0008.oracle.com> <237427522.1044928.1540035206569.JavaMail.zimbra@u-pem.fr> Message-ID: <96914b7a-fc10-4321-54fd-1cd09d0c1ca2@oracle.com> On 10/20/18 7:33 AM, Remi Forax wrote: > Hi Vicente, > i've fixed those warnings upstream in the ASM sources. cool :) Thanks, Vicente > > regards, > R?mi > > ----- Mail original ----- >> De: "Vicente Romero" >> ?: "amber-dev" >> Envoy?: Mardi 9 Octobre 2018 21:04:30 >> Objet: hg: amber/amber: suppressing some warnings in ASM code >> Changeset: 78ec06b98729 >> Author: vromero >> Date: 2018-10-09 11:48 -0700 >> URL: http://hg.openjdk.java.net/amber/amber/rev/78ec06b98729 >> >> suppressing some warnings in ASM code >> >> ! >> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassTooLargeException.java >> ! >> src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodTooLargeException.java From vicente.romero at oracle.com Sat Oct 20 21:07:41 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 20 Oct 2018 21:07:41 +0000 Subject: hg: amber/amber: renaming XXXRef -> XXXDesc and updating copyrights in tests Message-ID: <201810202107.w9KL7fV1008825@aojmv0008.oracle.com> Changeset: 9b2652a213e2 Author: vromero Date: 2018-10-20 17:02 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/9b2652a213e2 renaming XXXRef -> XXXDesc and updating copyrights in tests ! src/java.base/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues003.java ! test/jdk/java/lang/constant/ClassDescTest.java ! test/jdk/java/lang/constant/CondyDescTest.java ! test/jdk/java/lang/constant/IndyDescTest.java ! test/jdk/java/lang/constant/MethodHandleDescTest.java ! test/jdk/java/lang/constant/MethodTypeDescTest.java ! test/jdk/java/lang/constant/SymbolicDescTest.java ! test/jdk/java/lang/constant/TestHelpers.java ! test/jdk/java/lang/constant/TypeDescriptorTest.java ! test/jdk/java/lang/constant/boottest/java.base/java/lang/constant/ConstantUtilsTest.java From brian.goetz at oracle.com Mon Oct 22 19:45:00 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 22 Oct 2018 15:45:00 -0400 Subject: New draft JEP: intrinsics for String::format and Objects::hash (among others) Message-ID: <6cc558c4-bd92-512f-b0fe-c1a11ff5423d@oracle.com> For those of you following the saga of improved constant folding, which includes JEPs 334 and 303 (see https://www.youtube.com/watch?v=iSEjlLFCS3E), another installment of the story ... ??? https://bugs.openjdk.java.net/browse/JDK-8205637 While JEP 303 provides intrinsics for pseudo-methods (ldc, invokedynamic) whose semantics will be spelled out in the JLS, this JEP provides for more ad-hoc transformation of method invocations to LDC/indy, and outlines the initial candidate for this treatment String::format and Objects::hash.? (It does not rely on the constant folding and propagation that JEP 303 relies on, and so can be delivered before those are.)? The initial scope is deliberately limited; it can be expanded later. We're working on some performance numbers that will provide the context on why we chose these particular methods -- these will be added to the JEP when ready. From jbvernee at xs4all.nl Mon Oct 22 22:38:50 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Tue, 23 Oct 2018 00:38:50 +0200 Subject: New draft JEP: intrinsics for String::format and Objects::hash (among others) In-Reply-To: <6cc558c4-bd92-512f-b0fe-c1a11ff5423d@oracle.com> References: <6cc558c4-bd92-512f-b0fe-c1a11ff5423d@oracle.com> Message-ID: <77f4b128f1770f6385140c043928f46b@xs4all.nl> This is an interesting step! It's something I have been thinking about lately to solve a similar problem. The problem being that a call site of a method might have additional information and I'd like to be able to pass on that information to a bootstrap to create and then use a specialization for that particular call site. A 'per call site specialization' if you will. I'm interested to know what else you have to say about this subject. One of the ideas I'd arrived at myself was to have some kind of annotation that specifies some bootstrap method for the specialization e.g.: ``` @Specializable(boostrap="myBootstrap") // you get the idea int countDigits(String maybeConstant) {...} static Callsite myBootstrap(Lookup l, String name, MethodType callsiteType, ArgInfo args) { if(args.isConstant(0)) { String s = (String) args.getConstantValue(0); return } return } ``` Which I hope is also more friendly to user-space since the behavior of the bootstrap method is deterministic, you could say that whatever the bootstrap method returns is part of the intended behavior, but I haven't really thought about the spec implications that much there. One other notion is that invokedynamic is just _one_ way to do the specialization. Maybe specialization could also be (re-)done after inlining/profiling, which could help when the annotated method is 'hiding' behind an interface: ``` interface MyInterface { int countDigits(String maybeConstant); } class MyClass implements MyInterface { @Override @Specializable(...) int countDigits(String s) {...} } ``` Where after inlining/profiling you might determine a certain call site always uses `MyClass`, and while the static type of the receiver is `MyInterface`, you could still do the specialization for the monomorphic callsite. The use case I'm thinking of is generating a unique implementation for a user-defined interface, where we're currently re-computing varargs calls as fixed-arity for every invocation [1]. It would be nice to be able to specify some kind of per call site specialization mechanism in the generated backing implementation, so that eventually the varargs call will fall-over to a specialized version that only has to be re-computed as fixed-arity once. Jorn [1] : http://hg.openjdk.java.net/panama/dev/file/a43735f1fe86/src/java.base/share/classes/jdk/internal/foreign/invokers/VarargsInvoker.java#l62 Brian Goetz schreef op 2018-10-22 21:45: > For those of you following the saga of improved constant folding, > which includes JEPs 334 and 303 (see > https://www.youtube.com/watch?v=iSEjlLFCS3E), another installment of > the story ... > > ??? https://bugs.openjdk.java.net/browse/JDK-8205637 > > While JEP 303 provides intrinsics for pseudo-methods (ldc, > invokedynamic) whose semantics will be spelled out in the JLS, this > JEP provides for more ad-hoc transformation of method invocations to > LDC/indy, and outlines the initial candidate for this treatment > String::format and Objects::hash.? (It does not rely on the constant > folding and propagation that JEP 303 relies on, and so can be > delivered before those are.)? The initial scope is deliberately > limited; it can be expanded later. > > We're working on some performance numbers that will provide the > context on why we chose these particular methods -- these will be > added to the JEP when ready. From brian.goetz at oracle.com Tue Oct 23 00:24:07 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 22 Oct 2018 20:24:07 -0400 Subject: New draft JEP: intrinsics for String::format and Objects::hash (among others) In-Reply-To: <77f4b128f1770f6385140c043928f46b@xs4all.nl> References: <6cc558c4-bd92-512f-b0fe-c1a11ff5423d@oracle.com> <77f4b128f1770f6385140c043928f46b@xs4all.nl> Message-ID: <9A78A61F-E28A-4F5D-A7E9-3C2D88094C1D@oracle.com> > This is an interesting step! It's something I have been thinking about lately to solve a similar problem. The problem being that a call site of a method might have additional information and I'd like to be able to pass on that information to a bootstrap to create and then use a specialization for that particular call site. A 'per call site specialization' if you will. > > I'm interested to know what else you have to say about this subject. There are several tricks / sources sources of information one might use to select an alternate translation (which can be combined arbitrarily): - Type information. Here, you use information about the shape of the call to ?sharpen? the call site. This applies most readily with varargs methods, like ? String::format. At every call site, the ?descriptor? of the call is constant; translations can take advantage of this. (The work on indifying string concatenation is an example of this, though (at least in Java) the plus operator is not strictly a ?method call?.) - Constancy information. Here, you take advantage of knowing that some of the arguments (including the receiver) are compile-time constants. JEP 303 pushes at the extreme end of this, where it has both a richer notion of constant, and applies its treatment only to calls where _all_ arguments are constant. However, sometimes partial constancy is still highly effective; in most calls to String::format, the format string is a constant, and we can mine quite a lot of that. (More generally, we could attempt to do partial application of code to constant arguments.) - Strength reduction. Here, you observe that the user is calling a ?more powerful? method than is needed. For example, suppose you have two methods: Object eval(String program) { return eval(compile(program)); } Object eval(CompiledProgram p) { ? } We can intrinsify calls to the former, when the input string is a constant, by linking to an indy site that does the compile() step at link time and binds the resulting CompiledProgram to eval, and links to that. (This game can be played for the String methods that take regexes encoded as strings, rather than Pattern, to avoid the redundant recomputation of the Pattern.) So there?s lots of fruit that can be picked just in common JDK methods. In fact, the hardest thing to do is not go overboard with a cool new hammer like this. > One other notion is that invokedynamic is just _one_ way to do the specialization. Yes; simple alternates include reducing to a constant (replacing with LDC) or redirecting to another method (say with some permutation of the arguments.) But there?s a slippery slope here, labeled ?But I Just Want Compiler Macros?. Not going there. > The use case I'm thinking of is generating a unique implementation for a user-defined interface, where we're currently re-computing varargs calls as fixed-arity for every invocation [1]. It would be nice to be able to specify some kind of per call site specialization mechanism in the generated backing implementation, so that eventually the varargs call will fall-over to a specialized version that only has to be re-computed as fixed-arity once. Varargs is a good example of ?today?s problems come from yesterday?s solutions.? In 2002, the array encoding for varargs seemed clever; now it is recognized as a persistent source of performance and security bugs. Targeted intrinsics should help for the worst offenders (e.g., String::format.) But yes, this mechanism should be able to match to specialized implementations quite easily. A more interesting direction is methods that _have no actual body_, but for which calls are redirected to an indy bootstrap. This would allow libraries to expose method-like APIs, but with the ability to generate at runtime only the code that is actually needed. I think that?s really what you?re looking for. Its not something we?re planning to do as part of this JEP, but it?s not too far afield. From vicente.romero at oracle.com Tue Oct 23 03:49:19 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 23 Oct 2018 03:49:19 +0000 Subject: hg: amber/amber: parsing the record attribute in hotspot Message-ID: <201810230349.w9N3nJEI022614@aojmv0008.oracle.com> Changeset: 429ef256f955 Author: vromero Date: 2018-10-22 23:48 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/429ef256f955 parsing the record attribute in hotspot ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp + src/hotspot/share/oops/recordParamInfo.hpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java From maurizio.cimadamore at oracle.com Tue Oct 23 03:53:48 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 23 Oct 2018 03:53:48 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810230353.w9N3rmqd025140@aojmv0008.oracle.com> Changeset: ec835e2ed021 Author: mcimadamore Date: 2018-10-23 05:55 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/ec835e2ed021 Automatic merge with datum From vicente.romero at oracle.com Wed Oct 24 03:23:15 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 24 Oct 2018 03:23:15 +0000 Subject: hg: amber/amber: 4 new changesets Message-ID: <201810240323.w9O3NFgg009056@aojmv0008.oracle.com> Changeset: 5df8e3b41af0 Author: vromero Date: 2018-10-23 23:17 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/5df8e3b41af0 rename: Symbol::isDatum -> Symbol::isRecord ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java Changeset: 23dd48526a07 Author: vromero Date: 2018-10-23 23:18 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/23dd48526a07 adding more record related methods to InstanceKlass ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/recordParamInfo.hpp Changeset: 4dbbe4e4d001 Author: vromero Date: 2018-10-23 23:21 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/4dbbe4e4d001 adding hs/share/oops/recordParamStreams + src/hotspot/share/oops/recordParamStreams.hpp Changeset: 9fca582660cc Author: vromero Date: 2018-10-23 23:21 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/9fca582660cc adding support for native method: getRecordParameters ! make/hotspot/symbols/symbols-unix ! src/hotspot/share/include/jvm.h ! src/hotspot/share/oops/recordParamInfo.hpp ! src/hotspot/share/oops/recordParamStreams.hpp ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/native/libjava/Class.c From maurizio.cimadamore at oracle.com Wed Oct 24 03:28:42 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 24 Oct 2018 03:28:42 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810240328.w9O3ShqN014305@aojmv0008.oracle.com> Changeset: 84c4bed32dd2 Author: mcimadamore Date: 2018-10-24 05:30 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/84c4bed32dd2 Automatic merge with datum ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java From forax at univ-mlv.fr Wed Oct 24 10:08:32 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 24 Oct 2018 12:08:32 +0200 (CEST) Subject: pattern matching bug Message-ID: <1100555016.317894.1540375712694.JavaMail.zimbra@u-pem.fr> Using the amber-demo branch, this code prints bug *and* temp :) Again this bug was found by Francois Green. public class SwitchBug { static String hold(String item) -> switch(item) { case String s -> { System.out.println(s); } default -> "temp"; } public static void main(String[] args) { System.out.println(hold("bug")); } } R?mi From brian.goetz at oracle.com Wed Oct 24 18:43:24 2018 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 24 Oct 2018 18:43:24 +0000 Subject: hg: amber/amber: Refactoring Extractor factories, more tests Message-ID: <201810241843.w9OIhOk3002690@aojmv0008.oracle.com> Changeset: fcd04bbc2cd2 Author: briangoetz Date: 2018-10-24 14:43 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/fcd04bbc2cd2 Refactoring Extractor factories, more tests ! src/java.base/share/classes/java/lang/compiler/Extractor.java ! src/java.base/share/classes/java/lang/compiler/ExtractorCarriers.java ! src/java.base/share/classes/java/lang/compiler/ExtractorImpl.java ! test/jdk/java/lang/compiler/ExtractorTest.java + test/jdk/java/lang/compiler/boottest/TEST.properties + test/jdk/java/lang/compiler/boottest/java.base/java/lang/compiler/CarrierTest.java From maurizio.cimadamore at oracle.com Wed Oct 24 18:48:43 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 24 Oct 2018 18:48:43 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810241848.w9OImicu005048@aojmv0008.oracle.com> Changeset: 334332456aa1 Author: mcimadamore Date: 2018-10-24 20:50 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/334332456aa1 Automatic merge with datum ! src/java.base/share/classes/java/lang/compiler/Extractor.java From vicente.romero at oracle.com Wed Oct 24 21:09:34 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 24 Oct 2018 21:09:34 +0000 Subject: hg: amber/amber: adding java.lang.Class::getRecordParameters and gluing everything Message-ID: <201810242109.w9OL9YH3007979@aojmv0008.oracle.com> Changeset: 2b7b9c2711b3 Author: vromero Date: 2018-10-24 17:03 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/2b7b9c2711b3 adding java.lang.Class::getRecordParameters and gluing everything ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/recordParamInfo.hpp ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/Class.java From maurizio.cimadamore at oracle.com Wed Oct 24 21:13:44 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 24 Oct 2018 21:13:44 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810242113.w9OLDimC012373@aojmv0008.oracle.com> Changeset: c40c92b3249b Author: mcimadamore Date: 2018-10-24 23:15 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/c40c92b3249b Automatic merge with datum From jan.lahoda at oracle.com Thu Oct 25 16:17:56 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 25 Oct 2018 18:17:56 +0200 Subject: pattern matching bug In-Reply-To: <1100555016.317894.1540375712694.JavaMail.zimbra@u-pem.fr> References: <1100555016.317894.1540375712694.JavaMail.zimbra@u-pem.fr> Message-ID: <5BD1ECB4.30501@oracle.com> Hi Remi, Thanks for the report. I've filled this as: https://bugs.openjdk.java.net/browse/JDK-8212982 I believe this program should not compile (for switch expressions with rule cases, the case shouldn't complete normally). Jan On 24.10.2018 12:08, Remi Forax wrote: > Using the amber-demo branch, this code prints bug *and* temp :) > Again this bug was found by Francois Green. > > public class SwitchBug { > > static String hold(String item) -> switch(item) { > case String s -> { System.out.println(s); } > default -> "temp"; > } > > public static void main(String[] args) { > System.out.println(hold("bug")); > } > } > > R?mi > From brian.goetz at oracle.com Thu Oct 25 16:30:00 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 25 Oct 2018 12:30:00 -0400 Subject: pattern matching bug In-Reply-To: <5BD1ECB4.30501@oracle.com> References: <1100555016.317894.1540375712694.JavaMail.zimbra@u-pem.fr> <5BD1ECB4.30501@oracle.com> Message-ID: <48CE11D7-EB26-41CA-8D6B-573E8ACF420B@oracle.com> Correct. The RHS must either be an expression or complete abruptly for reason ?break-with-value?. Also, the example falls afoul of exhaustiveness; we should be able to prove that the default branch is dead (the switch is not nullable, because it has no nullable cases, and the String case is total. So the default should be dead.) > On Oct 25, 2018, at 12:17 PM, Jan Lahoda wrote: > > Hi Remi, > > Thanks for the report. I've filled this as: > https://bugs.openjdk.java.net/browse/JDK-8212982 > > I believe this program should not compile (for switch expressions with rule cases, the case shouldn't complete normally). > > Jan > > On 24.10.2018 12:08, Remi Forax wrote: >> Using the amber-demo branch, this code prints bug *and* temp :) >> Again this bug was found by Francois Green. >> >> public class SwitchBug { >> >> static String hold(String item) -> switch(item) { >> case String s -> { System.out.println(s); } >> default -> "temp"; >> } >> >> public static void main(String[] args) { >> System.out.println(hold("bug")); >> } >> } >> >> R?mi >> From forax at univ-mlv.fr Thu Oct 25 16:35:07 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 25 Oct 2018 18:35:07 +0200 (CEST) Subject: pattern matching bug In-Reply-To: <5BD1ECB4.30501@oracle.com> References: <1100555016.317894.1540375712694.JavaMail.zimbra@u-pem.fr> <5BD1ECB4.30501@oracle.com> Message-ID: <1470592822.675882.1540485307711.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "jan lahoda" > ?: "Remi Forax" , "amber-dev" > Envoy?: Jeudi 25 Octobre 2018 18:17:56 > Objet: Re: pattern matching bug > Hi Remi, > > Thanks for the report. I've filled this as: > https://bugs.openjdk.java.net/browse/JDK-8212982 > > I believe this program should not compile (for switch expressions with > rule cases, the case shouldn't complete normally). yes, I agree. > > Jan R?mi > > On 24.10.2018 12:08, Remi Forax wrote: >> Using the amber-demo branch, this code prints bug *and* temp :) >> Again this bug was found by Francois Green. >> >> public class SwitchBug { >> >> static String hold(String item) -> switch(item) { >> case String s -> { System.out.println(s); } >> default -> "temp"; >> } >> >> public static void main(String[] args) { >> System.out.println(hold("bug")); >> } >> } >> >> R?mi From jan.lahoda at oracle.com Fri Oct 26 11:51:34 2018 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 26 Oct 2018 11:51:34 +0000 Subject: hg: amber/amber: 2 new changesets Message-ID: <201810261151.w9QBpYRa028641@aojmv0008.oracle.com> Changeset: 2cb2cae03443 Author: jlahoda Date: 2018-10-24 17:25 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/2cb2cae03443 Merging patterns-stage-1 branch into the patterns branch. ! src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java - src/jdk.compiler/share/classes/com/sun/source/tree/MatchesTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CompileStates.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MatchBindingsComputer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/langtools/jdk/jshell/CompletenessTest.java ! test/langtools/tools/javac/api/TestGetElementReferenceData.java ! test/langtools/tools/javac/diags/examples/MatchBindingExists.java ! test/langtools/tools/javac/diags/examples/PatternBindingMayNotBeAssigned.java ! test/langtools/tools/javac/patterns/CastConversionMatch.java ! test/langtools/tools/javac/patterns/ConstantPatternTest1.java + test/langtools/tools/javac/patterns/ConstantPatternTest2.java + test/langtools/tools/javac/patterns/ConstantPatternTest2.out ! test/langtools/tools/javac/patterns/DuplicateBindingTest.java ! test/langtools/tools/javac/patterns/DuplicateBindingTest.out ! test/langtools/tools/javac/patterns/EnsureTypesOrderTest.java ! test/langtools/tools/javac/patterns/ExamplesFromProposal.java ! test/langtools/tools/javac/patterns/MatchBindingScopeTest.java ! test/langtools/tools/javac/patterns/MatchBindingScopeTest.out - test/langtools/tools/javac/patterns/MatchesToken.java ! test/langtools/tools/javac/patterns/NestingMatchAndMatches.java ! test/langtools/tools/javac/patterns/NullsInPatterns.java + test/langtools/tools/javac/patterns/NullsInPatterns2.java + test/langtools/tools/javac/patterns/NullsInPatterns2.out ! test/langtools/tools/javac/patterns/PatternMatchPosTest.java ! test/langtools/tools/javac/patterns/PatternMatchPosTest.out ! test/langtools/tools/javac/patterns/PatternTypeTest1.java ! test/langtools/tools/javac/patterns/PatternVariablesAreFinal.java ! test/langtools/tools/javac/patterns/PatternVariablesAreFinal.out ! test/langtools/tools/javac/patterns/UncheckedWarningOnMatchesTest.java ! test/langtools/tools/javac/patterns/UncheckedWarningOnMatchesTest.out Changeset: efece18d4b96 Author: jlahoda Date: 2018-10-24 17:28 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/efece18d4b96 Adding dependency info for the patterns branch. + deps.txt From vicente.romero at oracle.com Fri Oct 26 16:12:32 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 26 Oct 2018 16:12:32 +0000 Subject: hg: amber/amber: adding the pipes to support Class::getRecordParametersCount, JNI, etc Message-ID: <201810261612.w9QGCXld001794@aojmv0008.oracle.com> Changeset: f9cc2fc9cf12 Author: vromero Date: 2018-10-26 12:01 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/f9cc2fc9cf12 adding the pipes to support Class::getRecordParametersCount, JNI, etc ! make/hotspot/symbols/symbols-unix ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/native/libjava/Class.c From maurizio.cimadamore at oracle.com Fri Oct 26 16:18:47 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 26 Oct 2018 16:18:47 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810261618.w9QGIlCg004711@aojmv0008.oracle.com> Changeset: 7d3c741eb854 Author: mcimadamore Date: 2018-10-26 18:20 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/7d3c741eb854 Automatic merge with datum From vicente.romero at oracle.com Fri Oct 26 16:41:35 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 26 Oct 2018 16:41:35 +0000 Subject: hg: amber/amber: updating Class::getRecordParameterNames to use native methods Message-ID: <201810261641.w9QGfZtU017097@aojmv0008.oracle.com> Changeset: 350f92339d2f Author: vromero Date: 2018-10-26 12:41 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/350f92339d2f updating Class::getRecordParameterNames to use native methods ! src/java.base/share/classes/java/lang/Class.java From maurizio.cimadamore at oracle.com Fri Oct 26 16:43:41 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 26 Oct 2018 16:43:41 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810261643.w9QGhfLK019070@aojmv0008.oracle.com> Changeset: 30e15200fb90 Author: mcimadamore Date: 2018-10-26 18:45 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/30e15200fb90 Automatic merge with datum From vicente.romero at oracle.com Fri Oct 26 16:59:02 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 26 Oct 2018 16:59:02 +0000 Subject: hg: amber/amber: adding Class::getRecordParameterTypes Message-ID: <201810261659.w9QGx2HM026755@aojmv0008.oracle.com> Changeset: 716341307709 Author: vromero Date: 2018-10-26 12:58 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/716341307709 adding Class::getRecordParameterTypes ! src/java.base/share/classes/java/lang/Class.java From maurizio.cimadamore at oracle.com Fri Oct 26 17:03:41 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 26 Oct 2018 17:03:41 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810261703.w9QH3gBf028988@aojmv0008.oracle.com> Changeset: 3486dd38dbda Author: mcimadamore Date: 2018-10-26 19:05 +0200 URL: http://hg.openjdk.java.net/amber/amber/rev/3486dd38dbda Automatic merge with datum From vicente.romero at oracle.com Fri Oct 26 18:17:57 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 26 Oct 2018 18:17:57 +0000 Subject: hg: amber/amber: manual merge with jep-334 Message-ID: <201810261817.w9QIHwSG004570@aojmv0008.oracle.com> Changeset: f2da31f2dc71 Author: vromero Date: 2018-10-26 14:17 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/f2da31f2dc71 manual merge with jep-334 ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/constant/ClassDesc.java ! src/java.base/share/classes/java/lang/constant/Constable.java ! src/java.base/share/classes/java/lang/constant/ConstantDesc.java ! src/java.base/share/classes/java/lang/constant/ConstantDescs.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java ! src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java ! src/java.base/share/classes/java/lang/constant/package-info.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/module-info.java ! test/jdk/java/lang/constant/TypeDescriptorTest.java From gavin.bierman at oracle.com Mon Oct 29 13:51:07 2018 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Mon, 29 Oct 2018 14:51:07 +0100 Subject: New [draft] JEPs for Pattern Matching In-Reply-To: <6cc558c4-bd92-512f-b0fe-c1a11ff5423d@oracle.com> References: <6cc558c4-bd92-512f-b0fe-c1a11ff5423d@oracle.com> Message-ID: <6B85A8E7-A0EB-4584-9536-00CC853E45F3@oracle.com> In the context of the new rapid release model for Java, we?d like to break up the proposed pattern matching features so we can deliver them to you faster. To that end, we?ve rewritten JEP 305 to now cover adding pattern matching to just instanceof: https://bugs.openjdk.java.net/browse/JDK-8181287 And there?s a new draft JEP that covers adding pattern matching to switch (and some other possible extensions): https://bugs.openjdk.java.net/browse/JDK-8213076 Essentially this is just dividing the old pattern matching JEP into two parts. Comments welcome! Gavin From brian.goetz at oracle.com Mon Oct 29 19:12:35 2018 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 29 Oct 2018 19:12:35 +0000 Subject: hg: amber/amber: Add nesting combinator for Extractor Message-ID: <201810291912.w9TJCauZ010389@aojmv0008.oracle.com> Changeset: cb7760bcb5b5 Author: briangoetz Date: 2018-10-29 15:12 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/cb7760bcb5b5 Add nesting combinator for Extractor ! .hgignore ! src/java.base/share/classes/java/lang/compiler/Extractor.java ! src/java.base/share/classes/java/lang/compiler/ExtractorImpl.java ! test/jdk/java/lang/compiler/ExtractorTest.java + test/jdk/java/lang/compiler/RecordTest.java From vicente.romero at oracle.com Mon Oct 29 20:26:33 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 29 Oct 2018 20:26:33 +0000 Subject: hg: amber/amber: allow records with no parameters Message-ID: <201810292026.w9TKQYsh009922@aojmv0008.oracle.com> Changeset: 89969d71c998 Author: vromero Date: 2018-10-29 16:25 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/89969d71c998 allow records with no parameters ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/langtools/tools/javac/datum/DatumShouldDeclareAtLeastOneFieldTest.java - test/langtools/tools/javac/datum/DatumShouldDeclareAtLeastOneFieldTest.out From brian.goetz at oracle.com Mon Oct 29 21:34:26 2018 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 29 Oct 2018 21:34:26 +0000 Subject: hg: amber/amber: Add bootstraps for switch, including pattern switch Message-ID: <201810292134.w9TLYQ8R008215@aojmv0008.oracle.com> Changeset: b1d6664ce434 Author: briangoetz Date: 2018-10-29 17:34 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/b1d6664ce434 Add bootstraps for switch, including pattern switch ! src/java.base/share/classes/java/lang/compiler/Extractor.java + src/java.base/share/classes/java/lang/compiler/SwitchBootstraps.java ! test/jdk/java/lang/compiler/ExtractorTest.java ! test/jdk/java/lang/compiler/RecordTest.java + test/jdk/java/lang/compiler/SwitchBootstrapsTest.java From vicente.romero at oracle.com Tue Oct 30 02:18:09 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 30 Oct 2018 02:18:09 +0000 Subject: hg: amber/amber: analyzer to find generic arrays in signatures Message-ID: <201810300218.w9U2I9sk013759@aojmv0008.oracle.com> Changeset: dd5c0716ba41 Author: vromero Date: 2018-10-29 22:17 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/dd5c0716ba41 analyzer to find generic arrays in signatures ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties From vicente.romero at oracle.com Tue Oct 30 02:48:25 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 30 Oct 2018 02:48:25 +0000 Subject: hg: amber/amber: applying ASM7 code Message-ID: <201810300248.w9U2mPag026212@aojmv0008.oracle.com> Changeset: 74a30fa0d1e5 Author: vromero Date: 2018-10-29 22:22 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/74a30fa0d1e5 applying ASM7 code ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Attribute.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassTooLargeException.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ConstantDynamic.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Context.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/CurrentFrame.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Edge.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Handle.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Handler.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Label.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodTooLargeException.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ModuleVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ModuleWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Symbol.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/SymbolTable.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/TypePath.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/TypeReference.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AnnotationRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ClassRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/FieldRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/MethodRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleHashesAttribute.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleResolutionAttribute.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleTargetAttribute.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SignatureRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LabelNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableAnnotationNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleExportNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleOpenNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleProvideNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleRequireNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ParameterNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TypeAnnotationNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/UnsupportedClassVersionException.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/Util.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Value.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckModuleAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceModuleVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/version.txt From james.laskey at oracle.com Tue Oct 30 16:56:03 2018 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 30 Oct 2018 16:56:03 +0000 Subject: hg: amber/amber: 5 new changesets Message-ID: <201810301656.w9UGu4oI015624@aojmv0008.oracle.com> Changeset: a8f1c7af59ba Author: jlaskey Date: 2018-10-30 13:53 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/a8f1c7af59ba imported patch compiler + src/java.base/share/classes/java/lang/Program.java ! src/java.base/share/classes/java/lang/String.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java + src/jdk.compiler/share/classes/com/sun/tools/javac/comp/IntrinsicsVisitor.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/FormatterProcessorFactory.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/HashProcessorFactory.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/IntrinsicContext.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/IntrinsicProcessor.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/IntrinsicProcessorFactory.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/Intrinsics.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/ProgramProcessorFactory.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/StringProcessorFactory.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/module-info.java Changeset: c89c84ecd231 Author: jlaskey Date: 2018-10-30 13:53 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/c89c84ecd231 imported patch intrinsics ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/util/Objects.java Changeset: 4123e0d13898 Author: jlaskey Date: 2018-10-30 13:53 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/4123e0d13898 imported patch formatter ! src/java.base/share/classes/java/util/Formatter.java Changeset: ea53f37a1f64 Author: jlaskey Date: 2018-10-30 13:53 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/ea53f37a1f64 imported patch bootstraps + src/java.base/share/classes/java/lang/compiler/IntrinsicCandidate.java + src/java.base/share/classes/java/lang/invoke/FormatterBootstraps.java + src/java.base/share/classes/java/lang/invoke/IntrinsicFactory.java + src/java.base/share/classes/java/lang/invoke/ObjectsBootstraps.java Changeset: 03e5ab63f7b4 Author: jlaskey Date: 2018-10-30 13:53 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/03e5ab63f7b4 imported patch formatter-tests ! test/jdk/java/util/Formatter/Basic-X.java.template ! test/jdk/java/util/Formatter/BasicBigDecimal.java ! test/jdk/java/util/Formatter/BasicBigInteger.java ! test/jdk/java/util/Formatter/BasicBoolean.java ! test/jdk/java/util/Formatter/BasicBooleanObject.java ! test/jdk/java/util/Formatter/BasicByte.java ! test/jdk/java/util/Formatter/BasicByteObject.java ! test/jdk/java/util/Formatter/BasicChar.java ! test/jdk/java/util/Formatter/BasicCharObject.java ! test/jdk/java/util/Formatter/BasicDateTime.java ! test/jdk/java/util/Formatter/BasicDouble.java ! test/jdk/java/util/Formatter/BasicDoubleObject.java ! test/jdk/java/util/Formatter/BasicFloat.java ! test/jdk/java/util/Formatter/BasicFloatObject.java ! test/jdk/java/util/Formatter/BasicInt.java ! test/jdk/java/util/Formatter/BasicIntObject.java ! test/jdk/java/util/Formatter/BasicLong.java ! test/jdk/java/util/Formatter/BasicLongObject.java ! test/jdk/java/util/Formatter/BasicShort.java ! test/jdk/java/util/Formatter/BasicShortObject.java ! test/jdk/java/util/Formatter/EncodingTest.java ! test/jdk/java/util/Formatter/FormatLocale.java + test/jdk/java/util/Formatter/JavacIntrinsicsSupport.java ! test/jdk/java/util/Formatter/NullArg.java From james.laskey at oracle.com Tue Oct 30 17:01:13 2018 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 30 Oct 2018 17:01:13 +0000 Subject: hg: amber/amber: clean up Message-ID: <201810301701.w9UH1DcA018479@aojmv0008.oracle.com> Changeset: d8323e0e38af Author: jlaskey Date: 2018-10-30 14:01 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/d8323e0e38af clean up ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/IntrinsicsVisitor.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/IntrinsicContext.java - src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/ProgramProcessorFactory.java ! src/jdk.compiler/share/classes/module-info.java From maurizio.cimadamore at oracle.com Tue Oct 30 17:02:45 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 30 Oct 2018 17:02:45 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810301702.w9UH2jju020022@aojmv0008.oracle.com> Changeset: b49697bf259d Author: mcimadamore Date: 2018-10-30 18:08 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/b49697bf259d Automatic merge with datum ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties - test/langtools/tools/javac/datum/DatumShouldDeclareAtLeastOneFieldTest.java - test/langtools/tools/javac/datum/DatumShouldDeclareAtLeastOneFieldTest.out From maurizio.cimadamore at oracle.com Tue Oct 30 17:03:03 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 30 Oct 2018 17:03:03 +0000 Subject: hg: amber/amber: Automatic merge with concise-method-declarations Message-ID: <201810301703.w9UH33k5020340@aojmv0008.oracle.com> Changeset: 75b290883f15 Author: mcimadamore Date: 2018-10-30 18:09 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/75b290883f15 Automatic merge with concise-method-declarations ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties From james.laskey at oracle.com Tue Oct 30 17:09:11 2018 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 30 Oct 2018 17:09:11 +0000 Subject: hg: amber/amber: clean up Message-ID: <201810301709.w9UH9Bbe024686@aojmv0008.oracle.com> Changeset: c9d66af26668 Author: jlaskey Date: 2018-10-30 14:08 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/c9d66af26668 clean up - src/java.base/share/classes/java/lang/Program.java From james.laskey at oracle.com Tue Oct 30 17:28:27 2018 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 30 Oct 2018 17:28:27 +0000 Subject: hg: amber/amber: undo changes to allow for jep-334 dependency Message-ID: <201810301728.w9UHSR1Z009426@aojmv0008.oracle.com> Changeset: dcfc30acfb3a Author: jlaskey Date: 2018-10-30 14:28 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/dcfc30acfb3a undo changes to allow for jep-334 dependency ! src/java.base/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/Float.java ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! src/java.base/share/classes/java/util/Formatter.java ! src/java.base/share/classes/java/util/Objects.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/invoke/util/Wrapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues003.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleBaseByteArrayTest.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/jdk/java/util/Formatter/Basic-X.java.template ! test/jdk/java/util/Formatter/BasicBigDecimal.java ! test/jdk/java/util/Formatter/BasicBigInteger.java ! test/jdk/java/util/Formatter/BasicBoolean.java ! test/jdk/java/util/Formatter/BasicBooleanObject.java ! test/jdk/java/util/Formatter/BasicByte.java ! test/jdk/java/util/Formatter/BasicByteObject.java ! test/jdk/java/util/Formatter/BasicChar.java ! test/jdk/java/util/Formatter/BasicCharObject.java ! test/jdk/java/util/Formatter/BasicDateTime.java ! test/jdk/java/util/Formatter/BasicDouble.java ! test/jdk/java/util/Formatter/BasicDoubleObject.java ! test/jdk/java/util/Formatter/BasicFloat.java ! test/jdk/java/util/Formatter/BasicFloatObject.java ! test/jdk/java/util/Formatter/BasicInt.java ! test/jdk/java/util/Formatter/BasicIntObject.java ! test/jdk/java/util/Formatter/BasicLong.java ! test/jdk/java/util/Formatter/BasicLongObject.java ! test/jdk/java/util/Formatter/BasicShort.java ! test/jdk/java/util/Formatter/BasicShortObject.java ! test/jdk/java/util/Formatter/EncodingTest.java ! test/jdk/java/util/Formatter/FormatLocale.java ! test/jdk/java/util/Formatter/NullArg.java ! test/langtools/jdk/javadoc/doclet/lib/JavadocTester.java ! test/langtools/jdk/javadoc/doclet/testClassTree/TestClassTree.java ! test/langtools/jdk/jshell/TypeNameTest.java ! test/langtools/tools/javac/T8187978/FilterOutCandidatesForDiagnosticsTest.out ! test/langtools/tools/javac/generics/inference/8176534/TestUncheckedCalls.java ! test/langtools/tools/javac/generics/inference/EagerReturnTypeResolution/EagerReturnTypeResolutionTestb.out ! test/langtools/tools/javac/lvti/harness/NonDenotableTest.java ! test/langtools/tools/javac/varargs/6806876/T6806876.out From james.laskey at oracle.com Tue Oct 30 17:42:15 2018 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 30 Oct 2018 17:42:15 +0000 Subject: hg: amber/amber: add jep-334 dependency Message-ID: <201810301742.w9UHgG7d017177@aojmv0008.oracle.com> Changeset: c3ecd531c027 Author: jlaskey Date: 2018-10-30 14:42 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/c3ecd531c027 add jep-334 dependency + deps.txt From james.laskey at oracle.com Tue Oct 30 17:58:15 2018 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 30 Oct 2018 17:58:15 +0000 Subject: hg: amber/amber: aborted attempt to use jep-334 dependency Message-ID: <201810301758.w9UHwFie025889@aojmv0008.oracle.com> Changeset: 3dde39c46f43 Author: jlaskey Date: 2018-10-30 14:55 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/3dde39c46f43 aborted attempt to use jep-334 dependency From james.laskey at oracle.com Tue Oct 30 18:33:45 2018 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 30 Oct 2018 18:33:45 +0000 Subject: hg: amber/amber: initial push intrinsics-project branch Message-ID: <201810301833.w9UIXjtb012596@aojmv0008.oracle.com> Changeset: 4ef17deee584 Author: jlaskey Date: 2018-10-30 15:33 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/4ef17deee584 initial push intrinsics-project branch + deps.txt From maurizio.cimadamore at oracle.com Tue Oct 30 18:39:15 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 30 Oct 2018 18:39:15 +0000 Subject: hg: amber/amber: Automatic merge with jep-334 Message-ID: <201810301839.w9UIdF8J015699@aojmv0008.oracle.com> Changeset: cb6d96ac7cdb Author: mcimadamore Date: 2018-10-30 19:45 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/cb6d96ac7cdb Automatic merge with jep-334 ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/Float.java ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template From jan.lahoda at oracle.com Tue Oct 30 19:49:19 2018 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 30 Oct 2018 19:49:19 +0000 Subject: hg: amber/amber: Improving the AST model for concise method bodies. Message-ID: <201810301949.w9UJnKmU020743@aojmv0008.oracle.com> Changeset: 15bcdae1ec0d Author: jlahoda Date: 2018-10-30 20:46 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/15bcdae1ec0d Improving the AST model for concise method bodies. ! src/jdk.compiler/share/classes/com/sun/source/tree/MethodTree.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java From maurizio.cimadamore at oracle.com Tue Oct 30 20:10:07 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 30 Oct 2018 20:10:07 +0000 Subject: hg: amber/amber: Automatic merge with concise-method-declarations Message-ID: <201810302010.w9UKA7bF001608@aojmv0008.oracle.com> Changeset: 51aa9496a1dd Author: mcimadamore Date: 2018-10-30 21:16 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/51aa9496a1dd Automatic merge with concise-method-declarations ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java From vicente.romero at oracle.com Wed Oct 31 00:59:31 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 30 Oct 2018 20:59:31 -0400 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: References: Message-ID: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> Hi all, I have sent the patch to the hotspot list as this patch is touching some native code and I would like to have some feedback from the runtime wizards, please let me know if there is a better list for that. This patch has been pushed the the record branch in amber project [1]. The records project is about, well adding data classes to the language so that this declaration: record Record(int i); gets lowered to: class Record { ??? final int i; ?? // automatically generated equals, getters, hashCode, toString and more } apart from the usual information generated for the lowered version, the javac compiler is generating this new attribute in the class file: ??????? Record { ??????????? u2 name_index; ??????????? u4 length; ??????????? u2 num_record_params; ??????????? { ??????????????? u2 param_name_idx;? // [1] ??????????????? u2 param_flag; ??????????????? u2 param_desc; ??????????????? u2 param_signature; ??????????? } record_params[num_record_params]; ??????? } which have a lot in common with the fields information but we don't want to depend on the order of the fields etc. The attached patch provides for parsing this attribute, plus additional helper classes, plus all the pipes needed. As a way to provide a way for users to peek the information contained in the Record attribute, I have added a method to java.lang.Class, Class::getRecordParameters. In the background I'm using JNI to extract the information from the related InstanceKlass in the native world. Method java.lang.Class::getRecordParameters just returns an array of fields but only those that have being defined in the header of the record. For example if the record would have been defined as: record Record(int i) { ??? static final int j = 0;? //no instance fields can be defined in records } then an invocation of java.lang.Class::getRecordParameters will return only field `i` ignoring the static field `j` TIA, Vicente [1] http://hg.openjdk.java.net/amber/amber -------------- next part -------------- A non-text attachment was scrubbed... Name: record.hotspot.patch Type: text/x-patch Size: 34444 bytes Desc: not available URL: From vicente.romero at oracle.com Wed Oct 31 02:55:04 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 31 Oct 2018 02:55:04 +0000 Subject: hg: amber/amber: updating comment in classFileParser.cpp Message-ID: <201810310255.w9V2t5Q0029238@aojmv0008.oracle.com> Changeset: ee2b4eb8a6e7 Author: vromero Date: 2018-10-30 22:54 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/ee2b4eb8a6e7 updating comment in classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.cpp From vicente.romero at oracle.com Wed Oct 31 03:11:18 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 31 Oct 2018 03:11:18 +0000 Subject: hg: amber/amber: adding back else for unknown attribute at ClassFileParser::parse_classfile_attributes Message-ID: <201810310311.w9V3BIj0007056@aojmv0008.oracle.com> Changeset: c9cfa7d5778d Author: vromero Date: 2018-10-30 23:11 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/c9cfa7d5778d adding back else for unknown attribute at ClassFileParser::parse_classfile_attributes ! src/hotspot/share/classfile/classFileParser.cpp From vicente.romero at oracle.com Wed Oct 31 03:21:43 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 30 Oct 2018 23:21:43 -0400 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: References: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> Message-ID: Hi David, Thanks for your comments, I have attached another iteration of the patch. In the mean time I have added another JNI method which is also included in this iteration. Some additional comments below. On 10/30/18 9:57 PM, David Holmes wrote: > Hi Vicente, > > On 31/10/2018 10:59 AM, Vicente Romero wrote: >> Hi all, >> >> I have sent the patch to the hotspot list as this patch is touching >> some native code and I would like to have some feedback from the >> runtime wizards, please let me know if there is a better list for >> that. This > > hotspot-runtime-dev :) removing hotspot-dev and adding hotspot-runtime-dev :) > > A couple of minor comments: > > src/hotspot/share/classfile/classFileParser.cpp > > +? // Set nest members attribute to default sentinel > +? _record_params = Universe::the_empty_short_array(); > > Comment needs updating. right I updated it > > -??????? } else { > -????????? // Unknown attribute > -????????? cfs->skip_u1(attribute_length, CHECK); > +??????? } else if (tag == vmSymbols::tag_record()) { > ... > > You need to insert the new check before the existing else clause but > need to keep the check for an unknown attribute in the given classfile > version. Presumably this will eventually be processed only for some > future classfile version. good catch! > > --- > > src/hotspot/share/oops/instanceKlass.hpp > > +? u2????????????? _record_params_count; > > Do you need a separate count when you can query the array length? yes you need this field because the array is declared as: Array* _record_params and the actual fields are accessed using offsets. I just replicated what is currently being done for fields just to be consistent with the existing code. > > Cheers, > David Thanks! Vicente > >> patch has been pushed the the record branch in amber project [1]. The >> records project is about, well adding data classes to the language so >> that this declaration: >> >> record Record(int i); >> >> gets lowered to: >> >> class Record { >> ???? final int i; >> >> ??? // automatically generated equals, getters, hashCode, toString >> and more >> } >> >> apart from the usual information generated for the lowered version, >> the javac compiler is generating this new attribute in the class file: >> >> ???????? Record { >> ???????????? u2 name_index; >> ???????????? u4 length; >> ???????????? u2 num_record_params; >> ???????????? { >> ???????????????? u2 param_name_idx;? // [1] >> ???????????????? u2 param_flag; >> ???????????????? u2 param_desc; >> ???????????????? u2 param_signature; >> ???????????? } record_params[num_record_params]; >> ???????? } >> >> which have a lot in common with the fields information but we don't >> want to depend on the order of the fields etc. The attached patch >> provides for parsing this attribute, plus additional helper classes, >> plus all the pipes needed. As a way to provide a way for users to >> peek the information contained in the Record attribute, I have added >> a method to java.lang.Class, Class::getRecordParameters. In the >> background I'm using JNI to extract the information from the related >> InstanceKlass in the native world. Method >> java.lang.Class::getRecordParameters just returns an array of fields >> but only those that have being defined in the header of the record. >> For example if the record would have been defined as: >> >> record Record(int i) { >> ???? static final int j = 0;? //no instance fields can be defined in >> records >> } >> >> then an invocation of java.lang.Class::getRecordParameters will >> return only field `i` ignoring the static field `j` >> >> TIA, >> Vicente >> >> [1] http://hg.openjdk.java.net/amber/amber -------------- next part -------------- A non-text attachment was scrubbed... Name: record.hotspot.v2.patch Type: text/x-patch Size: 36119 bytes Desc: not available URL: From francois.green at gmail.com Mon Oct 8 01:17:07 2018 From: francois.green at gmail.com (Francois Green) Date: Mon, 08 Oct 2018 01:17:07 -0000 Subject: Lambda Conversion Exception using records Message-ID: While experimenting with the amber-demo (thank you Aleksey Shipilev!), I came across an exception with this code: > import java.util.stream.Stream; > > public class Shades { > > static String shade(Blue b) -> switch (b) { > case Azure a-> a.shade; > case Royal r -> r.shade; > case IKB i -> i.shade; > default -> "None"; > } > > public static void main(String[] args) { > var colors = Stream.of(new Royal("Medium"), new IKB("Dark"), new Azure( > "Light")); > colors.map(Shades::shade).forEach(System.out::println); > } > } > > interface Blue; > > record Royal(String shade) implements Blue; > record IKB(String shade) implements Blue; > record Azure(String shade) implements Blue; > > Exception in thread "main" java.lang.BootstrapMethodError: bootstrap > method initialization exception > at > java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194) > at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:307) > at > java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:258) > at > java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:248) > at Shades.main(Shades.java:14) > Caused by: java.lang.invoke.LambdaConversionException: Type mismatch for > lambda argument 0: class java.lang.AbstractRecord is not convertible to > interface Blue > at > java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:279) > at > java.base/java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:328) > at > java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:127) > at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:307) > at > java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:258) > at > java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:248) > at Shades.main(Shades.java:14) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:415) > at > jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:192) > at > jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) > The program works if the colors are changed to classes or by adding a type parameter to the shade method. From david.holmes at oracle.com Wed Oct 31 01:57:30 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 31 Oct 2018 11:57:30 +1000 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> References: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> Message-ID: Hi Vicente, On 31/10/2018 10:59 AM, Vicente Romero wrote: > Hi all, > > I have sent the patch to the hotspot list as this patch is touching some > native code and I would like to have some feedback from the runtime > wizards, please let me know if there is a better list for that. This hotspot-runtime-dev :) A couple of minor comments: src/hotspot/share/classfile/classFileParser.cpp + // Set nest members attribute to default sentinel + _record_params = Universe::the_empty_short_array(); Comment needs updating. - } else { - // Unknown attribute - cfs->skip_u1(attribute_length, CHECK); + } else if (tag == vmSymbols::tag_record()) { ... You need to insert the new check before the existing else clause but need to keep the check for an unknown attribute in the given classfile version. Presumably this will eventually be processed only for some future classfile version. --- src/hotspot/share/oops/instanceKlass.hpp + u2 _record_params_count; Do you need a separate count when you can query the array length? Cheers, David > patch has been pushed the the record branch in amber project [1]. The > records project is about, well adding data classes to the language so > that this declaration: > > record Record(int i); > > gets lowered to: > > class Record { > ??? final int i; > > ?? // automatically generated equals, getters, hashCode, toString and more > } > > apart from the usual information generated for the lowered version, the > javac compiler is generating this new attribute in the class file: > > ??????? Record { > ??????????? u2 name_index; > ??????????? u4 length; > ??????????? u2 num_record_params; > ??????????? { > ??????????????? u2 param_name_idx;? // [1] > ??????????????? u2 param_flag; > ??????????????? u2 param_desc; > ??????????????? u2 param_signature; > ??????????? } record_params[num_record_params]; > ??????? } > > which have a lot in common with the fields information but we don't want > to depend on the order of the fields etc. The attached patch provides > for parsing this attribute, plus additional helper classes, plus all the > pipes needed. As a way to provide a way for users to peek the > information contained in the Record attribute, I have added a method to > java.lang.Class, Class::getRecordParameters. In the background I'm using > JNI to extract the information from the related InstanceKlass in the > native world. Method java.lang.Class::getRecordParameters just returns > an array of fields but only those that have being defined in the header > of the record. For example if the record would have been defined as: > > record Record(int i) { > ??? static final int j = 0;? //no instance fields can be defined in > records > } > > then an invocation of java.lang.Class::getRecordParameters will return > only field `i` ignoring the static field `j` > > TIA, > Vicente > > [1] http://hg.openjdk.java.net/amber/amber From david.holmes at oracle.com Wed Oct 31 03:59:04 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 31 Oct 2018 13:59:04 +1000 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: References: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> Message-ID: Hi Vicente, Thanks for the responses. For the JVM_* functions I find it easier to do the primitive/array class checks on the Java side and just assume at the VM level (with suitable assertion) that you're only working with instance classes. But I don't think there's any real consistency in how the labour is divided. Cheers, David On 31/10/2018 1:21 PM, Vicente Romero wrote: > Hi David, > > Thanks for your comments, I have attached another iteration of the > patch. In the mean time I have added another JNI method which is also > included in this iteration. Some additional comments below. > > On 10/30/18 9:57 PM, David Holmes wrote: >> Hi Vicente, >> >> On 31/10/2018 10:59 AM, Vicente Romero wrote: >>> Hi all, >>> >>> I have sent the patch to the hotspot list as this patch is touching >>> some native code and I would like to have some feedback from the >>> runtime wizards, please let me know if there is a better list for >>> that. This >> >> hotspot-runtime-dev :) > > removing hotspot-dev and adding hotspot-runtime-dev :) > >> >> A couple of minor comments: >> >> src/hotspot/share/classfile/classFileParser.cpp >> >> +? // Set nest members attribute to default sentinel >> +? _record_params = Universe::the_empty_short_array(); >> >> Comment needs updating. > > right I updated it > >> >> -??????? } else { >> -????????? // Unknown attribute >> -????????? cfs->skip_u1(attribute_length, CHECK); >> +??????? } else if (tag == vmSymbols::tag_record()) { >> ... >> >> You need to insert the new check before the existing else clause but >> need to keep the check for an unknown attribute in the given classfile >> version. Presumably this will eventually be processed only for some >> future classfile version. > > good catch! > >> >> --- >> >> src/hotspot/share/oops/instanceKlass.hpp >> >> +? u2????????????? _record_params_count; >> >> Do you need a separate count when you can query the array length? > > yes you need this field because the array is declared as: Array* > _record_params and the actual fields are accessed using offsets. I just > replicated what is currently being done for fields just to be consistent > with the existing code. > >> >> Cheers, >> David > > Thanks! > Vicente > >> >>> patch has been pushed the the record branch in amber project [1]. The >>> records project is about, well adding data classes to the language so >>> that this declaration: >>> >>> record Record(int i); >>> >>> gets lowered to: >>> >>> class Record { >>> ???? final int i; >>> >>> ??? // automatically generated equals, getters, hashCode, toString >>> and more >>> } >>> >>> apart from the usual information generated for the lowered version, >>> the javac compiler is generating this new attribute in the class file: >>> >>> ???????? Record { >>> ???????????? u2 name_index; >>> ???????????? u4 length; >>> ???????????? u2 num_record_params; >>> ???????????? { >>> ???????????????? u2 param_name_idx;? // [1] >>> ???????????????? u2 param_flag; >>> ???????????????? u2 param_desc; >>> ???????????????? u2 param_signature; >>> ???????????? } record_params[num_record_params]; >>> ???????? } >>> >>> which have a lot in common with the fields information but we don't >>> want to depend on the order of the fields etc. The attached patch >>> provides for parsing this attribute, plus additional helper classes, >>> plus all the pipes needed. As a way to provide a way for users to >>> peek the information contained in the Record attribute, I have added >>> a method to java.lang.Class, Class::getRecordParameters. In the >>> background I'm using JNI to extract the information from the related >>> InstanceKlass in the native world. Method >>> java.lang.Class::getRecordParameters just returns an array of fields >>> but only those that have being defined in the header of the record. >>> For example if the record would have been defined as: >>> >>> record Record(int i) { >>> ???? static final int j = 0;? //no instance fields can be defined in >>> records >>> } >>> >>> then an invocation of java.lang.Class::getRecordParameters will >>> return only field `i` ignoring the static field `j` >>> >>> TIA, >>> Vicente >>> >>> [1] http://hg.openjdk.java.net/amber/amber > From maurizio.cimadamore at oracle.com Wed Oct 31 08:43:07 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 31 Oct 2018 08:43:07 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810310843.w9V8h8TT005871@aojmv0008.oracle.com> Changeset: 42acc7e03b24 Author: mcimadamore Date: 2018-10-31 09:49 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/42acc7e03b24 Automatic merge with datum From forax at univ-mlv.fr Wed Oct 31 11:03:05 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 31 Oct 2018 12:03:05 +0100 (CET) Subject: Lambda Conversion Exception using records In-Reply-To: References: Message-ID: <1675582935.425975.1540983785727.JavaMail.zimbra@u-pem.fr> Hi Francois, it appears it's not a bug specific to records, see https://bugs.openjdk.java.net/browse/JDK-8213032 I've reported it on your behalf on compiler-dev given it's not specific to records http://mail.openjdk.java.net/pipermail/compiler-dev/2018-October/012571.html cheers, R?mi ----- Mail original ----- > De: "Francois Green" > ?: "amber-dev" > Envoy?: Lundi 8 Octobre 2018 03:16:53 > Objet: Lambda Conversion Exception using records > While experimenting with the amber-demo (thank you Aleksey Shipilev!), I > came across an exception with this code: > >> import java.util.stream.Stream; >> >> public class Shades { >> >> static String shade(Blue b) -> switch (b) { >> case Azure a-> a.shade; >> case Royal r -> r.shade; >> case IKB i -> i.shade; >> default -> "None"; >> } >> >> public static void main(String[] args) { >> var colors = Stream.of(new Royal("Medium"), new IKB("Dark"), new Azure( >> "Light")); >> colors.map(Shades::shade).forEach(System.out::println); >> } >> } >> >> interface Blue; >> >> record Royal(String shade) implements Blue; >> record IKB(String shade) implements Blue; >> record Azure(String shade) implements Blue; >> > > > >> Exception in thread "main" java.lang.BootstrapMethodError: bootstrap >> method initialization exception >> at >> java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194) >> at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:307) >> at >> java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:258) >> at >> java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:248) >> at Shades.main(Shades.java:14) >> Caused by: java.lang.invoke.LambdaConversionException: Type mismatch for >> lambda argument 0: class java.lang.AbstractRecord is not convertible to >> interface Blue >> at >> java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:279) >> at >> java.base/java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:328) >> at >> java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:127) >> at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:307) >> at >> java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:258) >> at >> java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:248) >> at Shades.main(Shades.java:14) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at >> jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:415) >> at >> jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:192) >> at >> jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) >> > > The program works if the colors are changed to classes or by adding a type > parameter to the shade method. From vicente.romero at oracle.com Wed Oct 31 14:12:52 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 31 Oct 2018 10:12:52 -0400 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: References: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> Message-ID: <4abcb6ab-9d5d-d50e-9db0-3ee5c10c9ed7@oracle.com> Hi David, On 10/30/18 11:59 PM, David Holmes wrote: > Hi Vicente, > > Thanks for the responses. > > For the JVM_* functions I find it easier to do the primitive/array > class checks on the Java side and just assume at the VM level (with > suitable assertion) that you're only working with instance classes. > But I don't think there's any real consistency in how the labour is > divided. while I was doing this change I was thinking if the check should be in the VM side just in case it is invoked from a language different to Java. I think that the VM side should be defensive just in case. What do you think? > > Cheers, > David Thanks, Vicente > > On 31/10/2018 1:21 PM, Vicente Romero wrote: >> Hi David, >> >> Thanks for your comments, I have attached another iteration of the >> patch. In the mean time I have added another JNI method which is also >> included in this iteration. Some additional comments below. >> >> On 10/30/18 9:57 PM, David Holmes wrote: >>> Hi Vicente, >>> >>> On 31/10/2018 10:59 AM, Vicente Romero wrote: >>>> Hi all, >>>> >>>> I have sent the patch to the hotspot list as this patch is touching >>>> some native code and I would like to have some feedback from the >>>> runtime wizards, please let me know if there is a better list for >>>> that. This >>> >>> hotspot-runtime-dev :) >> >> removing hotspot-dev and adding hotspot-runtime-dev :) >> >>> >>> A couple of minor comments: >>> >>> src/hotspot/share/classfile/classFileParser.cpp >>> >>> +? // Set nest members attribute to default sentinel >>> +? _record_params = Universe::the_empty_short_array(); >>> >>> Comment needs updating. >> >> right I updated it >> >>> >>> -??????? } else { >>> -????????? // Unknown attribute >>> -????????? cfs->skip_u1(attribute_length, CHECK); >>> +??????? } else if (tag == vmSymbols::tag_record()) { >>> ... >>> >>> You need to insert the new check before the existing else clause but >>> need to keep the check for an unknown attribute in the given >>> classfile version. Presumably this will eventually be processed only >>> for some future classfile version. >> >> good catch! >> >>> >>> --- >>> >>> src/hotspot/share/oops/instanceKlass.hpp >>> >>> +? u2????????????? _record_params_count; >>> >>> Do you need a separate count when you can query the array length? >> >> yes you need this field because the array is declared as: Array* >> _record_params and the actual fields are accessed using offsets. I >> just replicated what is currently being done for fields just to be >> consistent with the existing code. >> >>> >>> Cheers, >>> David >> >> Thanks! >> Vicente >> >>> >>>> patch has been pushed the the record branch in amber project [1]. >>>> The records project is about, well adding data classes to the >>>> language so that this declaration: >>>> >>>> record Record(int i); >>>> >>>> gets lowered to: >>>> >>>> class Record { >>>> ???? final int i; >>>> >>>> ??? // automatically generated equals, getters, hashCode, toString >>>> and more >>>> } >>>> >>>> apart from the usual information generated for the lowered version, >>>> the javac compiler is generating this new attribute in the class file: >>>> >>>> ???????? Record { >>>> ???????????? u2 name_index; >>>> ???????????? u4 length; >>>> ???????????? u2 num_record_params; >>>> ???????????? { >>>> ???????????????? u2 param_name_idx;? // [1] >>>> ???????????????? u2 param_flag; >>>> ???????????????? u2 param_desc; >>>> ???????????????? u2 param_signature; >>>> ???????????? } record_params[num_record_params]; >>>> ???????? } >>>> >>>> which have a lot in common with the fields information but we don't >>>> want to depend on the order of the fields etc. The attached patch >>>> provides for parsing this attribute, plus additional helper >>>> classes, plus all the pipes needed. As a way to provide a way for >>>> users to peek the information contained in the Record attribute, I >>>> have added a method to java.lang.Class, Class::getRecordParameters. >>>> In the background I'm using JNI to extract the information from the >>>> related InstanceKlass in the native world. Method >>>> java.lang.Class::getRecordParameters just returns an array of >>>> fields but only those that have being defined in the header of the >>>> record. For example if the record would have been defined as: >>>> >>>> record Record(int i) { >>>> ???? static final int j = 0;? //no instance fields can be defined >>>> in records >>>> } >>>> >>>> then an invocation of java.lang.Class::getRecordParameters will >>>> return only field `i` ignoring the static field `j` >>>> >>>> TIA, >>>> Vicente >>>> >>>> [1] http://hg.openjdk.java.net/amber/amber >> From james.laskey at oracle.com Wed Oct 31 14:16:44 2018 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Wed, 31 Oct 2018 14:16:44 +0000 Subject: hg: amber/amber: imported patch intrinsics Message-ID: <201810311416.w9VEGiO0013676@aojmv0008.oracle.com> Changeset: cb71f66e8e19 Author: jlaskey Date: 2018-10-31 11:08 -0300 URL: http://hg.openjdk.java.net/amber/amber/rev/cb71f66e8e19 imported patch intrinsics ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/lang/String.java + src/java.base/share/classes/java/lang/compiler/IntrinsicCandidate.java + src/java.base/share/classes/java/lang/invoke/FormatterBootstraps.java + src/java.base/share/classes/java/lang/invoke/IntrinsicFactory.java + src/java.base/share/classes/java/lang/invoke/ObjectsBootstraps.java ! src/java.base/share/classes/java/util/Formatter.java ! src/java.base/share/classes/java/util/Objects.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java + src/jdk.compiler/share/classes/com/sun/tools/javac/comp/IntrinsicsVisitor.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/FormatterProcessorFactory.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/HashProcessorFactory.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/IntrinsicContext.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/IntrinsicProcessor.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/IntrinsicProcessorFactory.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/Intrinsics.java + src/jdk.compiler/share/classes/com/sun/tools/javac/intrinsics/StringProcessorFactory.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/module-info.java ! test/jdk/java/util/Formatter/Basic-X.java.template ! test/jdk/java/util/Formatter/BasicBigDecimal.java ! test/jdk/java/util/Formatter/BasicBigInteger.java ! test/jdk/java/util/Formatter/BasicBoolean.java ! test/jdk/java/util/Formatter/BasicBooleanObject.java ! test/jdk/java/util/Formatter/BasicByte.java ! test/jdk/java/util/Formatter/BasicByteObject.java ! test/jdk/java/util/Formatter/BasicChar.java ! test/jdk/java/util/Formatter/BasicCharObject.java ! test/jdk/java/util/Formatter/BasicDateTime.java ! test/jdk/java/util/Formatter/BasicDouble.java ! test/jdk/java/util/Formatter/BasicDoubleObject.java ! test/jdk/java/util/Formatter/BasicFloat.java ! test/jdk/java/util/Formatter/BasicFloatObject.java ! test/jdk/java/util/Formatter/BasicInt.java ! test/jdk/java/util/Formatter/BasicIntObject.java ! test/jdk/java/util/Formatter/BasicLong.java ! test/jdk/java/util/Formatter/BasicLongObject.java ! test/jdk/java/util/Formatter/BasicShort.java ! test/jdk/java/util/Formatter/BasicShortObject.java ! test/jdk/java/util/Formatter/EncodingTest.java ! test/jdk/java/util/Formatter/FormatLocale.java + test/jdk/java/util/Formatter/JavacIntrinsicsSupport.java ! test/jdk/java/util/Formatter/NullArg.java From brian.goetz at oracle.com Wed Oct 31 17:22:10 2018 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 31 Oct 2018 17:22:10 +0000 Subject: hg: amber/amber: Add support for constant patterns Message-ID: <201810311722.w9VHMB4C013921@aojmv0008.oracle.com> Changeset: 9e4fc2e97fd0 Author: briangoetz Date: 2018-10-31 13:21 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/9e4fc2e97fd0 Add support for constant patterns ! src/java.base/share/classes/java/lang/compiler/Extractor.java ! src/java.base/share/classes/java/lang/compiler/ExtractorImpl.java ! test/jdk/java/lang/compiler/ExtractorTest.java From maurizio.cimadamore at oracle.com Wed Oct 31 17:24:30 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 31 Oct 2018 17:24:30 +0000 Subject: hg: amber/amber: Automatic merge with datum Message-ID: <201810311724.w9VHOUdT016500@aojmv0008.oracle.com> Changeset: aa666a24f362 Author: mcimadamore Date: 2018-10-31 18:30 +0100 URL: http://hg.openjdk.java.net/amber/amber/rev/aa666a24f362 Automatic merge with datum From shade at redhat.com Wed Oct 31 22:15:27 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Oct 2018 23:15:27 +0100 Subject: Branches webrevs Message-ID: <12a3f354-ba7e-ff60-84f5-5e809afb04d8@redhat.com> Hi, In Shenandoah project, we eventually figured that having the automatically-generated webrevs against upstream is a very convenient tool for debugging (figuring what exactly was changed), review (sometimes, accidental changes leak in, and cause head-scratchy bugs), and merges (because you can tell if the change is coming from your code). This is the example for amber-demo branch (among other patches for other projects): https://builds.shipilev.net/patch-openjdk-amber-amber-demo/ If you tell me what other branches are interesting to have, I can add them to the schedule as well. The rule of thumb is to get the more or less stable branches that are slated for merge to upstream at some point. (Technically, webrevs are generated against the first "hg in" changeset's parent, which assumes the linear history in "default" branch, and that all branches get merged from default regularly. I think that is already happening in amber). -Aleksey From david.holmes at oracle.com Wed Oct 31 22:22:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Nov 2018 08:22:08 +1000 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: <4abcb6ab-9d5d-d50e-9db0-3ee5c10c9ed7@oracle.com> References: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> <4abcb6ab-9d5d-d50e-9db0-3ee5c10c9ed7@oracle.com> Message-ID: <2c53fb53-4b5d-4455-283e-8ea2d58e4428@oracle.com> On 1/11/2018 12:12 AM, Vicente Romero wrote: > Hi David, > > On 10/30/18 11:59 PM, David Holmes wrote: >> Hi Vicente, >> >> Thanks for the responses. >> >> For the JVM_* functions I find it easier to do the primitive/array >> class checks on the Java side and just assume at the VM level (with >> suitable assertion) that you're only working with instance classes. >> But I don't think there's any real consistency in how the labour is >> divided. > > while I was doing this change I was thinking if the check should be in > the VM side just in case it is invoked from a language different to > Java. I think that the VM side should be defensive just in case. What do > you think? The JVM_* API is only for the JDK libraries to use. Many functions, rely on the JDK side having established some preconditions and/or invariants. Cheers, David >> >> Cheers, >> David > > Thanks, > Vicente > >> >> On 31/10/2018 1:21 PM, Vicente Romero wrote: >>> Hi David, >>> >>> Thanks for your comments, I have attached another iteration of the >>> patch. In the mean time I have added another JNI method which is also >>> included in this iteration. Some additional comments below. >>> >>> On 10/30/18 9:57 PM, David Holmes wrote: >>>> Hi Vicente, >>>> >>>> On 31/10/2018 10:59 AM, Vicente Romero wrote: >>>>> Hi all, >>>>> >>>>> I have sent the patch to the hotspot list as this patch is touching >>>>> some native code and I would like to have some feedback from the >>>>> runtime wizards, please let me know if there is a better list for >>>>> that. This >>>> >>>> hotspot-runtime-dev :) >>> >>> removing hotspot-dev and adding hotspot-runtime-dev :) >>> >>>> >>>> A couple of minor comments: >>>> >>>> src/hotspot/share/classfile/classFileParser.cpp >>>> >>>> +? // Set nest members attribute to default sentinel >>>> +? _record_params = Universe::the_empty_short_array(); >>>> >>>> Comment needs updating. >>> >>> right I updated it >>> >>>> >>>> -??????? } else { >>>> -????????? // Unknown attribute >>>> -????????? cfs->skip_u1(attribute_length, CHECK); >>>> +??????? } else if (tag == vmSymbols::tag_record()) { >>>> ... >>>> >>>> You need to insert the new check before the existing else clause but >>>> need to keep the check for an unknown attribute in the given >>>> classfile version. Presumably this will eventually be processed only >>>> for some future classfile version. >>> >>> good catch! >>> >>>> >>>> --- >>>> >>>> src/hotspot/share/oops/instanceKlass.hpp >>>> >>>> +? u2????????????? _record_params_count; >>>> >>>> Do you need a separate count when you can query the array length? >>> >>> yes you need this field because the array is declared as: Array* >>> _record_params and the actual fields are accessed using offsets. I >>> just replicated what is currently being done for fields just to be >>> consistent with the existing code. >>> >>>> >>>> Cheers, >>>> David >>> >>> Thanks! >>> Vicente >>> >>>> >>>>> patch has been pushed the the record branch in amber project [1]. >>>>> The records project is about, well adding data classes to the >>>>> language so that this declaration: >>>>> >>>>> record Record(int i); >>>>> >>>>> gets lowered to: >>>>> >>>>> class Record { >>>>> ???? final int i; >>>>> >>>>> ??? // automatically generated equals, getters, hashCode, toString >>>>> and more >>>>> } >>>>> >>>>> apart from the usual information generated for the lowered version, >>>>> the javac compiler is generating this new attribute in the class file: >>>>> >>>>> ???????? Record { >>>>> ???????????? u2 name_index; >>>>> ???????????? u4 length; >>>>> ???????????? u2 num_record_params; >>>>> ???????????? { >>>>> ???????????????? u2 param_name_idx;? // [1] >>>>> ???????????????? u2 param_flag; >>>>> ???????????????? u2 param_desc; >>>>> ???????????????? u2 param_signature; >>>>> ???????????? } record_params[num_record_params]; >>>>> ???????? } >>>>> >>>>> which have a lot in common with the fields information but we don't >>>>> want to depend on the order of the fields etc. The attached patch >>>>> provides for parsing this attribute, plus additional helper >>>>> classes, plus all the pipes needed. As a way to provide a way for >>>>> users to peek the information contained in the Record attribute, I >>>>> have added a method to java.lang.Class, Class::getRecordParameters. >>>>> In the background I'm using JNI to extract the information from the >>>>> related InstanceKlass in the native world. Method >>>>> java.lang.Class::getRecordParameters just returns an array of >>>>> fields but only those that have being defined in the header of the >>>>> record. For example if the record would have been defined as: >>>>> >>>>> record Record(int i) { >>>>> ???? static final int j = 0;? //no instance fields can be defined >>>>> in records >>>>> } >>>>> >>>>> then an invocation of java.lang.Class::getRecordParameters will >>>>> return only field `i` ignoring the static field `j` >>>>> >>>>> TIA, >>>>> Vicente >>>>> >>>>> [1] http://hg.openjdk.java.net/amber/amber >>> > From brian.goetz at oracle.com Wed Oct 31 22:45:13 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 31 Oct 2018 18:45:13 -0400 Subject: Branches webrevs In-Reply-To: <12a3f354-ba7e-ff60-84f5-5e809afb04d8@redhat.com> References: <12a3f354-ba7e-ff60-84f5-5e809afb04d8@redhat.com> Message-ID: <4F1A6ECB-E79C-4AE9-BB8B-5F9441DCCFB2@oracle.com> Cool! The branches that seem to be most approaching something useful are: - jep-334 (already ready to PTT) - patterns-stage-1 - datum - condy-folding - intrinsics-project > On Oct 31, 2018, at 6:15 PM, Aleksey Shipilev wrote: > > Hi, > > In Shenandoah project, we eventually figured that having the automatically-generated webrevs against > upstream is a very convenient tool for debugging (figuring what exactly was changed), review > (sometimes, accidental changes leak in, and cause head-scratchy bugs), and merges (because you can > tell if the change is coming from your code). > > This is the example for amber-demo branch (among other patches for other projects): > https://builds.shipilev.net/patch-openjdk-amber-amber-demo/ > > If you tell me what other branches are interesting to have, I can add them to the schedule as well. > The rule of thumb is to get the more or less stable branches that are slated for merge to upstream > at some point. > > (Technically, webrevs are generated against the first "hg in" changeset's parent, which assumes the > linear history in "default" branch, and that all branches get merged from default regularly. I think > that is already happening in amber). > > -Aleksey > From vicente.romero at oracle.com Wed Oct 31 23:07:37 2018 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 31 Oct 2018 23:07:37 +0000 Subject: hg: amber/amber: moving the check for array and primitive to the java side Message-ID: <201810312307.w9VN7cGE014847@aojmv0008.oracle.com> Changeset: 859f3cb2cd75 Author: vromero Date: 2018-10-31 18:56 -0400 URL: http://hg.openjdk.java.net/amber/amber/rev/859f3cb2cd75 moving the check for array and primitive to the java side ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/native/libjava/Class.c From vicente.romero at oracle.com Wed Oct 31 23:08:45 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 31 Oct 2018 19:08:45 -0400 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: <2c53fb53-4b5d-4455-283e-8ea2d58e4428@oracle.com> References: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> <4abcb6ab-9d5d-d50e-9db0-3ee5c10c9ed7@oracle.com> <2c53fb53-4b5d-4455-283e-8ea2d58e4428@oracle.com> Message-ID: <78029f88-2520-8820-abf5-d64192415e3c@oracle.com> On 10/31/18 6:22 PM, David Holmes wrote: > On 1/11/2018 12:12 AM, Vicente Romero wrote: >> Hi David, >> >> On 10/30/18 11:59 PM, David Holmes wrote: >>> Hi Vicente, >>> >>> Thanks for the responses. >>> >>> For the JVM_* functions I find it easier to do the primitive/array >>> class checks on the Java side and just assume at the VM level (with >>> suitable assertion) that you're only working with instance classes. >>> But I don't think there's any real consistency in how the labour is >>> divided. >> >> while I was doing this change I was thinking if the check should be >> in the VM side just in case it is invoked from a language different >> to Java. I think that the VM side should be defensive just in case. >> What do you think? > > The JVM_* API is only for the JDK libraries to use. Many functions, > rely on the JDK side having established some preconditions and/or > invariants. I see, I have attached another iteration of the patch that moves the checks to the java side > > Cheers, > David Thanks! Vicente > >>> >>> Cheers, >>> David >> >> Thanks, >> Vicente >> >>> >>> On 31/10/2018 1:21 PM, Vicente Romero wrote: >>>> Hi David, >>>> >>>> Thanks for your comments, I have attached another iteration of the >>>> patch. In the mean time I have added another JNI method which is >>>> also included in this iteration. Some additional comments below. >>>> >>>> On 10/30/18 9:57 PM, David Holmes wrote: >>>>> Hi Vicente, >>>>> >>>>> On 31/10/2018 10:59 AM, Vicente Romero wrote: >>>>>> Hi all, >>>>>> >>>>>> I have sent the patch to the hotspot list as this patch is >>>>>> touching some native code and I would like to have some feedback >>>>>> from the runtime wizards, please let me know if there is a better >>>>>> list for that. This >>>>> >>>>> hotspot-runtime-dev :) >>>> >>>> removing hotspot-dev and adding hotspot-runtime-dev :) >>>> >>>>> >>>>> A couple of minor comments: >>>>> >>>>> src/hotspot/share/classfile/classFileParser.cpp >>>>> >>>>> +? // Set nest members attribute to default sentinel >>>>> +? _record_params = Universe::the_empty_short_array(); >>>>> >>>>> Comment needs updating. >>>> >>>> right I updated it >>>> >>>>> >>>>> -??????? } else { >>>>> -????????? // Unknown attribute >>>>> -????????? cfs->skip_u1(attribute_length, CHECK); >>>>> +??????? } else if (tag == vmSymbols::tag_record()) { >>>>> ... >>>>> >>>>> You need to insert the new check before the existing else clause >>>>> but need to keep the check for an unknown attribute in the given >>>>> classfile version. Presumably this will eventually be processed >>>>> only for some future classfile version. >>>> >>>> good catch! >>>> >>>>> >>>>> --- >>>>> >>>>> src/hotspot/share/oops/instanceKlass.hpp >>>>> >>>>> +? u2????????????? _record_params_count; >>>>> >>>>> Do you need a separate count when you can query the array length? >>>> >>>> yes you need this field because the array is declared as: >>>> Array* _record_params and the actual fields are accessed using >>>> offsets. I just replicated what is currently being done for fields >>>> just to be consistent with the existing code. >>>> >>>>> >>>>> Cheers, >>>>> David >>>> >>>> Thanks! >>>> Vicente >>>> >>>>> >>>>>> patch has been pushed the the record branch in amber project [1]. >>>>>> The records project is about, well adding data classes to the >>>>>> language so that this declaration: >>>>>> >>>>>> record Record(int i); >>>>>> >>>>>> gets lowered to: >>>>>> >>>>>> class Record { >>>>>> ???? final int i; >>>>>> >>>>>> ??? // automatically generated equals, getters, hashCode, >>>>>> toString and more >>>>>> } >>>>>> >>>>>> apart from the usual information generated for the lowered >>>>>> version, the javac compiler is generating this new attribute in >>>>>> the class file: >>>>>> >>>>>> ???????? Record { >>>>>> ???????????? u2 name_index; >>>>>> ???????????? u4 length; >>>>>> ???????????? u2 num_record_params; >>>>>> ???????????? { >>>>>> ???????????????? u2 param_name_idx;? // [1] >>>>>> ???????????????? u2 param_flag; >>>>>> ???????????????? u2 param_desc; >>>>>> ???????????????? u2 param_signature; >>>>>> ???????????? } record_params[num_record_params]; >>>>>> ???????? } >>>>>> >>>>>> which have a lot in common with the fields information but we >>>>>> don't want to depend on the order of the fields etc. The attached >>>>>> patch provides for parsing this attribute, plus additional helper >>>>>> classes, plus all the pipes needed. As a way to provide a way for >>>>>> users to peek the information contained in the Record attribute, >>>>>> I have added a method to java.lang.Class, >>>>>> Class::getRecordParameters. In the background I'm using JNI to >>>>>> extract the information from the related InstanceKlass in the >>>>>> native world. Method java.lang.Class::getRecordParameters just >>>>>> returns an array of fields but only those that have being defined >>>>>> in the header of the record. For example if the record would have >>>>>> been defined as: >>>>>> >>>>>> record Record(int i) { >>>>>> ???? static final int j = 0;? //no instance fields can be defined >>>>>> in records >>>>>> } >>>>>> >>>>>> then an invocation of java.lang.Class::getRecordParameters will >>>>>> return only field `i` ignoring the static field `j` >>>>>> >>>>>> TIA, >>>>>> Vicente >>>>>> >>>>>> [1] http://hg.openjdk.java.net/amber/amber >>>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: record.hotspot.v3.patch Type: text/x-patch Size: 35637 bytes Desc: not available URL: From shade at redhat.com Wed Oct 31 23:22:54 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 1 Nov 2018 00:22:54 +0100 Subject: Branches webrevs In-Reply-To: <4F1A6ECB-E79C-4AE9-BB8B-5F9441DCCFB2@oracle.com> References: <12a3f354-ba7e-ff60-84f5-5e809afb04d8@redhat.com> <4F1A6ECB-E79C-4AE9-BB8B-5F9441DCCFB2@oracle.com> Message-ID: <9e894d14-c8fe-4764-4b8f-810322cf3003@redhat.com> On 10/31/18 11:45 PM, Brian Goetz wrote: > Cool! > > The branches that seem to be most approaching something useful are: > - jep-334 (already ready to PTT) > - patterns-stage-1 > - datum > - condy-folding > - intrinsics-project So done: https://builds.shipilev.net/patch-openjdk-amber-condy-folding/ https://builds.shipilev.net/patch-openjdk-amber-datum/ https://builds.shipilev.net/patch-openjdk-amber-intrinsics-project/ https://builds.shipilev.net/patch-openjdk-amber-jep-334/ https://builds.shipilev.net/patch-openjdk-amber-patterns-stage-1/ These update every night. I'll hook them up to rebuild on commit a bit later. -Aleksey From david.holmes at oracle.com Wed Oct 31 23:23:16 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Nov 2018 09:23:16 +1000 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: <78029f88-2520-8820-abf5-d64192415e3c@oracle.com> References: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> <4abcb6ab-9d5d-d50e-9db0-3ee5c10c9ed7@oracle.com> <2c53fb53-4b5d-4455-283e-8ea2d58e4428@oracle.com> <78029f88-2520-8820-abf5-d64192415e3c@oracle.com> Message-ID: <9cc04757-e5a0-f94f-3195-7e265004defc@oracle.com> On 1/11/2018 9:08 AM, Vicente Romero wrote: > On 10/31/18 6:22 PM, David Holmes wrote: >> On 1/11/2018 12:12 AM, Vicente Romero wrote: >>> Hi David, >>> >>> On 10/30/18 11:59 PM, David Holmes wrote: >>>> Hi Vicente, >>>> >>>> Thanks for the responses. >>>> >>>> For the JVM_* functions I find it easier to do the primitive/array >>>> class checks on the Java side and just assume at the VM level (with >>>> suitable assertion) that you're only working with instance classes. >>>> But I don't think there's any real consistency in how the labour is >>>> divided. >>> >>> while I was doing this change I was thinking if the check should be >>> in the VM side just in case it is invoked from a language different >>> to Java. I think that the VM side should be defensive just in case. >>> What do you think? >> >> The JVM_* API is only for the JDK libraries to use. Many functions, >> rely on the JDK side having established some preconditions and/or >> invariants. > > I see, I have attached another iteration of the patch that moves the > checks to the java side There was no need to do that. As I said there is no clear division of labor here. It's just often easier to write these checks and produce empty arrays etc, in Java than C++. Cheers, David > >> >> Cheers, >> David > > Thanks! > Vicente > >> >>>> >>>> Cheers, >>>> David >>> >>> Thanks, >>> Vicente >>> >>>> >>>> On 31/10/2018 1:21 PM, Vicente Romero wrote: >>>>> Hi David, >>>>> >>>>> Thanks for your comments, I have attached another iteration of the >>>>> patch. In the mean time I have added another JNI method which is >>>>> also included in this iteration. Some additional comments below. >>>>> >>>>> On 10/30/18 9:57 PM, David Holmes wrote: >>>>>> Hi Vicente, >>>>>> >>>>>> On 31/10/2018 10:59 AM, Vicente Romero wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I have sent the patch to the hotspot list as this patch is >>>>>>> touching some native code and I would like to have some feedback >>>>>>> from the runtime wizards, please let me know if there is a better >>>>>>> list for that. This >>>>>> >>>>>> hotspot-runtime-dev :) >>>>> >>>>> removing hotspot-dev and adding hotspot-runtime-dev :) >>>>> >>>>>> >>>>>> A couple of minor comments: >>>>>> >>>>>> src/hotspot/share/classfile/classFileParser.cpp >>>>>> >>>>>> +? // Set nest members attribute to default sentinel >>>>>> +? _record_params = Universe::the_empty_short_array(); >>>>>> >>>>>> Comment needs updating. >>>>> >>>>> right I updated it >>>>> >>>>>> >>>>>> -??????? } else { >>>>>> -????????? // Unknown attribute >>>>>> -????????? cfs->skip_u1(attribute_length, CHECK); >>>>>> +??????? } else if (tag == vmSymbols::tag_record()) { >>>>>> ... >>>>>> >>>>>> You need to insert the new check before the existing else clause >>>>>> but need to keep the check for an unknown attribute in the given >>>>>> classfile version. Presumably this will eventually be processed >>>>>> only for some future classfile version. >>>>> >>>>> good catch! >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/hotspot/share/oops/instanceKlass.hpp >>>>>> >>>>>> +? u2????????????? _record_params_count; >>>>>> >>>>>> Do you need a separate count when you can query the array length? >>>>> >>>>> yes you need this field because the array is declared as: >>>>> Array* _record_params and the actual fields are accessed using >>>>> offsets. I just replicated what is currently being done for fields >>>>> just to be consistent with the existing code. >>>>> >>>>>> >>>>>> Cheers, >>>>>> David >>>>> >>>>> Thanks! >>>>> Vicente >>>>> >>>>>> >>>>>>> patch has been pushed the the record branch in amber project [1]. >>>>>>> The records project is about, well adding data classes to the >>>>>>> language so that this declaration: >>>>>>> >>>>>>> record Record(int i); >>>>>>> >>>>>>> gets lowered to: >>>>>>> >>>>>>> class Record { >>>>>>> ???? final int i; >>>>>>> >>>>>>> ??? // automatically generated equals, getters, hashCode, >>>>>>> toString and more >>>>>>> } >>>>>>> >>>>>>> apart from the usual information generated for the lowered >>>>>>> version, the javac compiler is generating this new attribute in >>>>>>> the class file: >>>>>>> >>>>>>> ???????? Record { >>>>>>> ???????????? u2 name_index; >>>>>>> ???????????? u4 length; >>>>>>> ???????????? u2 num_record_params; >>>>>>> ???????????? { >>>>>>> ???????????????? u2 param_name_idx;? // [1] >>>>>>> ???????????????? u2 param_flag; >>>>>>> ???????????????? u2 param_desc; >>>>>>> ???????????????? u2 param_signature; >>>>>>> ???????????? } record_params[num_record_params]; >>>>>>> ???????? } >>>>>>> >>>>>>> which have a lot in common with the fields information but we >>>>>>> don't want to depend on the order of the fields etc. The attached >>>>>>> patch provides for parsing this attribute, plus additional helper >>>>>>> classes, plus all the pipes needed. As a way to provide a way for >>>>>>> users to peek the information contained in the Record attribute, >>>>>>> I have added a method to java.lang.Class, >>>>>>> Class::getRecordParameters. In the background I'm using JNI to >>>>>>> extract the information from the related InstanceKlass in the >>>>>>> native world. Method java.lang.Class::getRecordParameters just >>>>>>> returns an array of fields but only those that have being defined >>>>>>> in the header of the record. For example if the record would have >>>>>>> been defined as: >>>>>>> >>>>>>> record Record(int i) { >>>>>>> ???? static final int j = 0;? //no instance fields can be defined >>>>>>> in records >>>>>>> } >>>>>>> >>>>>>> then an invocation of java.lang.Class::getRecordParameters will >>>>>>> return only field `i` ignoring the static field `j` >>>>>>> >>>>>>> TIA, >>>>>>> Vicente >>>>>>> >>>>>>> [1] http://hg.openjdk.java.net/amber/amber >>>>> >>> > From david.holmes at oracle.com Wed Oct 31 23:30:24 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Nov 2018 09:30:24 +1000 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: <9cc04757-e5a0-f94f-3195-7e265004defc@oracle.com> References: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> <4abcb6ab-9d5d-d50e-9db0-3ee5c10c9ed7@oracle.com> <2c53fb53-4b5d-4455-283e-8ea2d58e4428@oracle.com> <78029f88-2520-8820-abf5-d64192415e3c@oracle.com> <9cc04757-e5a0-f94f-3195-7e265004defc@oracle.com> Message-ID: <4ac9d398-af5c-df16-2dc0-5312ad5d9fba@oracle.com> PS. But if you do the checks on the Java side you should document the expectations on the incoming class. E.g. see JVM_GetNestHost/Members David On 1/11/2018 9:23 AM, David Holmes wrote: > On 1/11/2018 9:08 AM, Vicente Romero wrote: >> On 10/31/18 6:22 PM, David Holmes wrote: >>> On 1/11/2018 12:12 AM, Vicente Romero wrote: >>>> Hi David, >>>> >>>> On 10/30/18 11:59 PM, David Holmes wrote: >>>>> Hi Vicente, >>>>> >>>>> Thanks for the responses. >>>>> >>>>> For the JVM_* functions I find it easier to do the primitive/array >>>>> class checks on the Java side and just assume at the VM level (with >>>>> suitable assertion) that you're only working with instance classes. >>>>> But I don't think there's any real consistency in how the labour is >>>>> divided. >>>> >>>> while I was doing this change I was thinking if the check should be >>>> in the VM side just in case it is invoked from a language different >>>> to Java. I think that the VM side should be defensive just in case. >>>> What do you think? >>> >>> The JVM_* API is only for the JDK libraries to use. Many functions, >>> rely on the JDK side having established some preconditions and/or >>> invariants. >> >> I see, I have attached another iteration of the patch that moves the >> checks to the java side > > There was no need to do that. As I said there is no clear division of > labor here. It's just often easier to write these checks and produce > empty arrays etc, in Java than C++. > > Cheers, > David > >> >>> >>> Cheers, >>> David >> >> Thanks! >> Vicente >> >>> >>>>> >>>>> Cheers, >>>>> David >>>> >>>> Thanks, >>>> Vicente >>>> >>>>> >>>>> On 31/10/2018 1:21 PM, Vicente Romero wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for your comments, I have attached another iteration of the >>>>>> patch. In the mean time I have added another JNI method which is >>>>>> also included in this iteration. Some additional comments below. >>>>>> >>>>>> On 10/30/18 9:57 PM, David Holmes wrote: >>>>>>> Hi Vicente, >>>>>>> >>>>>>> On 31/10/2018 10:59 AM, Vicente Romero wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I have sent the patch to the hotspot list as this patch is >>>>>>>> touching some native code and I would like to have some feedback >>>>>>>> from the runtime wizards, please let me know if there is a >>>>>>>> better list for that. This >>>>>>> >>>>>>> hotspot-runtime-dev :) >>>>>> >>>>>> removing hotspot-dev and adding hotspot-runtime-dev :) >>>>>> >>>>>>> >>>>>>> A couple of minor comments: >>>>>>> >>>>>>> src/hotspot/share/classfile/classFileParser.cpp >>>>>>> >>>>>>> +? // Set nest members attribute to default sentinel >>>>>>> +? _record_params = Universe::the_empty_short_array(); >>>>>>> >>>>>>> Comment needs updating. >>>>>> >>>>>> right I updated it >>>>>> >>>>>>> >>>>>>> -??????? } else { >>>>>>> -????????? // Unknown attribute >>>>>>> -????????? cfs->skip_u1(attribute_length, CHECK); >>>>>>> +??????? } else if (tag == vmSymbols::tag_record()) { >>>>>>> ... >>>>>>> >>>>>>> You need to insert the new check before the existing else clause >>>>>>> but need to keep the check for an unknown attribute in the given >>>>>>> classfile version. Presumably this will eventually be processed >>>>>>> only for some future classfile version. >>>>>> >>>>>> good catch! >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/oops/instanceKlass.hpp >>>>>>> >>>>>>> +? u2????????????? _record_params_count; >>>>>>> >>>>>>> Do you need a separate count when you can query the array length? >>>>>> >>>>>> yes you need this field because the array is declared as: >>>>>> Array* _record_params and the actual fields are accessed using >>>>>> offsets. I just replicated what is currently being done for fields >>>>>> just to be consistent with the existing code. >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>> >>>>>> Thanks! >>>>>> Vicente >>>>>> >>>>>>> >>>>>>>> patch has been pushed the the record branch in amber project >>>>>>>> [1]. The records project is about, well adding data classes to >>>>>>>> the language so that this declaration: >>>>>>>> >>>>>>>> record Record(int i); >>>>>>>> >>>>>>>> gets lowered to: >>>>>>>> >>>>>>>> class Record { >>>>>>>> ???? final int i; >>>>>>>> >>>>>>>> ??? // automatically generated equals, getters, hashCode, >>>>>>>> toString and more >>>>>>>> } >>>>>>>> >>>>>>>> apart from the usual information generated for the lowered >>>>>>>> version, the javac compiler is generating this new attribute in >>>>>>>> the class file: >>>>>>>> >>>>>>>> ???????? Record { >>>>>>>> ???????????? u2 name_index; >>>>>>>> ???????????? u4 length; >>>>>>>> ???????????? u2 num_record_params; >>>>>>>> ???????????? { >>>>>>>> ???????????????? u2 param_name_idx;? // [1] >>>>>>>> ???????????????? u2 param_flag; >>>>>>>> ???????????????? u2 param_desc; >>>>>>>> ???????????????? u2 param_signature; >>>>>>>> ???????????? } record_params[num_record_params]; >>>>>>>> ???????? } >>>>>>>> >>>>>>>> which have a lot in common with the fields information but we >>>>>>>> don't want to depend on the order of the fields etc. The >>>>>>>> attached patch provides for parsing this attribute, plus >>>>>>>> additional helper classes, plus all the pipes needed. As a way >>>>>>>> to provide a way for users to peek the information contained in >>>>>>>> the Record attribute, I have added a method to java.lang.Class, >>>>>>>> Class::getRecordParameters. In the background I'm using JNI to >>>>>>>> extract the information from the related InstanceKlass in the >>>>>>>> native world. Method java.lang.Class::getRecordParameters just >>>>>>>> returns an array of fields but only those that have being >>>>>>>> defined in the header of the record. For example if the record >>>>>>>> would have been defined as: >>>>>>>> >>>>>>>> record Record(int i) { >>>>>>>> ???? static final int j = 0;? //no instance fields can be >>>>>>>> defined in records >>>>>>>> } >>>>>>>> >>>>>>>> then an invocation of java.lang.Class::getRecordParameters will >>>>>>>> return only field `i` ignoring the static field `j` >>>>>>>> >>>>>>>> TIA, >>>>>>>> Vicente >>>>>>>> >>>>>>>> [1] http://hg.openjdk.java.net/amber/amber >>>>>> >>>> >> From vicente.romero at oracle.com Wed Oct 31 23:33:17 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 31 Oct 2018 19:33:17 -0400 Subject: [amber-record] feedback on a Record class attribute implementation In-Reply-To: <9cc04757-e5a0-f94f-3195-7e265004defc@oracle.com> References: <730f6520-1a52-5bb0-cfc4-1827c5dd5564@oracle.com> <4abcb6ab-9d5d-d50e-9db0-3ee5c10c9ed7@oracle.com> <2c53fb53-4b5d-4455-283e-8ea2d58e4428@oracle.com> <78029f88-2520-8820-abf5-d64192415e3c@oracle.com> <9cc04757-e5a0-f94f-3195-7e265004defc@oracle.com> Message-ID: On 10/31/18 7:23 PM, David Holmes wrote: > On 1/11/2018 9:08 AM, Vicente Romero wrote: >> On 10/31/18 6:22 PM, David Holmes wrote: >>> On 1/11/2018 12:12 AM, Vicente Romero wrote: >>>> Hi David, >>>> >>>> On 10/30/18 11:59 PM, David Holmes wrote: >>>>> Hi Vicente, >>>>> >>>>> Thanks for the responses. >>>>> >>>>> For the JVM_* functions I find it easier to do the primitive/array >>>>> class checks on the Java side and just assume at the VM level >>>>> (with suitable assertion) that you're only working with instance >>>>> classes. But I don't think there's any real consistency in how the >>>>> labour is divided. >>>> >>>> while I was doing this change I was thinking if the check should be >>>> in the VM side just in case it is invoked from a language different >>>> to Java. I think that the VM side should be defensive just in case. >>>> What do you think? >>> >>> The JVM_* API is only for the JDK libraries to use. Many functions, >>> rely on the JDK side having established some preconditions and/or >>> invariants. >> >> I see, I have attached another iteration of the patch that moves the >> checks to the java side > > There was no need to do that. As I said there is no clear division of > labor here. It's just often easier to write these checks and produce > empty arrays etc, in Java than C++. yep and that made sense to me, anyways it is done already :) > > Cheers, > David Thanks for your comments, Vicente > >> >>> >>> Cheers, >>> David >> >> Thanks! >> Vicente >> >>> >>>>> >>>>> Cheers, >>>>> David >>>> >>>> Thanks, >>>> Vicente >>>> >>>>> >>>>> On 31/10/2018 1:21 PM, Vicente Romero wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for your comments, I have attached another iteration of >>>>>> the patch. In the mean time I have added another JNI method which >>>>>> is also included in this iteration. Some additional comments below. >>>>>> >>>>>> On 10/30/18 9:57 PM, David Holmes wrote: >>>>>>> Hi Vicente, >>>>>>> >>>>>>> On 31/10/2018 10:59 AM, Vicente Romero wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I have sent the patch to the hotspot list as this patch is >>>>>>>> touching some native code and I would like to have some >>>>>>>> feedback from the runtime wizards, please let me know if there >>>>>>>> is a better list for that. This >>>>>>> >>>>>>> hotspot-runtime-dev :) >>>>>> >>>>>> removing hotspot-dev and adding hotspot-runtime-dev :) >>>>>> >>>>>>> >>>>>>> A couple of minor comments: >>>>>>> >>>>>>> src/hotspot/share/classfile/classFileParser.cpp >>>>>>> >>>>>>> +? // Set nest members attribute to default sentinel >>>>>>> +? _record_params = Universe::the_empty_short_array(); >>>>>>> >>>>>>> Comment needs updating. >>>>>> >>>>>> right I updated it >>>>>> >>>>>>> >>>>>>> -??????? } else { >>>>>>> -????????? // Unknown attribute >>>>>>> -????????? cfs->skip_u1(attribute_length, CHECK); >>>>>>> +??????? } else if (tag == vmSymbols::tag_record()) { >>>>>>> ... >>>>>>> >>>>>>> You need to insert the new check before the existing else clause >>>>>>> but need to keep the check for an unknown attribute in the given >>>>>>> classfile version. Presumably this will eventually be processed >>>>>>> only for some future classfile version. >>>>>> >>>>>> good catch! >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/oops/instanceKlass.hpp >>>>>>> >>>>>>> +? u2????????????? _record_params_count; >>>>>>> >>>>>>> Do you need a separate count when you can query the array length? >>>>>> >>>>>> yes you need this field because the array is declared as: >>>>>> Array* _record_params and the actual fields are accessed >>>>>> using offsets. I just replicated what is currently being done for >>>>>> fields just to be consistent with the existing code. >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>> >>>>>> Thanks! >>>>>> Vicente >>>>>> >>>>>>> >>>>>>>> patch has been pushed the the record branch in amber project >>>>>>>> [1]. The records project is about, well adding data classes to >>>>>>>> the language so that this declaration: >>>>>>>> >>>>>>>> record Record(int i); >>>>>>>> >>>>>>>> gets lowered to: >>>>>>>> >>>>>>>> class Record { >>>>>>>> ???? final int i; >>>>>>>> >>>>>>>> ??? // automatically generated equals, getters, hashCode, >>>>>>>> toString and more >>>>>>>> } >>>>>>>> >>>>>>>> apart from the usual information generated for the lowered >>>>>>>> version, the javac compiler is generating this new attribute in >>>>>>>> the class file: >>>>>>>> >>>>>>>> ???????? Record { >>>>>>>> ???????????? u2 name_index; >>>>>>>> ???????????? u4 length; >>>>>>>> ???????????? u2 num_record_params; >>>>>>>> ???????????? { >>>>>>>> ???????????????? u2 param_name_idx;? // [1] >>>>>>>> ???????????????? u2 param_flag; >>>>>>>> ???????????????? u2 param_desc; >>>>>>>> ???????????????? u2 param_signature; >>>>>>>> ???????????? } record_params[num_record_params]; >>>>>>>> ???????? } >>>>>>>> >>>>>>>> which have a lot in common with the fields information but we >>>>>>>> don't want to depend on the order of the fields etc. The >>>>>>>> attached patch provides for parsing this attribute, plus >>>>>>>> additional helper classes, plus all the pipes needed. As a way >>>>>>>> to provide a way for users to peek the information contained in >>>>>>>> the Record attribute, I have added a method to java.lang.Class, >>>>>>>> Class::getRecordParameters. In the background I'm using JNI to >>>>>>>> extract the information from the related InstanceKlass in the >>>>>>>> native world. Method java.lang.Class::getRecordParameters just >>>>>>>> returns an array of fields but only those that have being >>>>>>>> defined in the header of the record. For example if the record >>>>>>>> would have been defined as: >>>>>>>> >>>>>>>> record Record(int i) { >>>>>>>> ???? static final int j = 0;? //no instance fields can be >>>>>>>> defined in records >>>>>>>> } >>>>>>>> >>>>>>>> then an invocation of java.lang.Class::getRecordParameters will >>>>>>>> return only field `i` ignoring the static field `j` >>>>>>>> >>>>>>>> TIA, >>>>>>>> Vicente >>>>>>>> >>>>>>>> [1] http://hg.openjdk.java.net/amber/amber >>>>>> >>>> >>