From joe.darcy at oracle.com Thu Feb 1 05:42:48 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 31 Jan 2018 21:42:48 -0800 Subject: JDK 11 RFR of 8196551: Update TestSourceVersion.java to be robust across version changes Message-ID: Hello, Please review the patch below to address ??? 8196551: Update TestSourceVersion.java to be robust across version changes As the summary implies, the intention of this change is to avoid the need separately update the test in question when a new SourceVersion value is added and when the version of the JDK is bumped. Until the version is bumped, it is acceptable for latest() to be one release ahead of latestSupported(), as is true of current builds of the JDK 11 line of development which don't have the version increment yet. I thought it was clearer to write the acceptable condition directly rather than apply de Morgan to the whole boolean expression. Thanks, -Joe --- a/test/langtools/tools/javac/processing/model/TestSourceVersion.java Wed Jan 31 15:15:09 2018 -0800 +++ b/test/langtools/tools/javac/processing/model/TestSourceVersion.java Wed Jan 31 21:38:47 2018 -0800 @@ -23,7 +23,7 @@ ?/* ? * @test - * @bug 7025809 8028543 6415644 8028544 8029942 8187951 8193291 + * @bug 7025809 8028543 6415644 8028544 8029942 8187951 8193291 8196551 ? * @summary Test latest, latestSupported, underscore as keyword, etc. ? * @author? Joseph D. Darcy ? * @modules java.compiler @@ -46,11 +46,20 @@ ???? } ???? private static void testLatestSupported() { -??????? if (SourceVersion.latest() != RELEASE_11 || -??????????? SourceVersion.latestSupported() != RELEASE_10) +??????? SourceVersion[] values = SourceVersion.values(); +??????? SourceVersion last = values[values.length - 1]; +??????? SourceVersion latest = SourceVersion.latest(); +??????? SourceVersion latestSupported = SourceVersion.latestSupported(); + +??????? if (latest == last && +??????????? latestSupported == SourceVersion.valueOf("RELEASE_" + Runtime.version().feature()) && +??????????? (latest == latestSupported || (latest.ordinal() - latestSupported.ordinal() == 1)) ) +??????????? return; +??????? else { ???????????? throw new RuntimeException("Unexpected release value(s) found:\n" + -?????????????????????????????????????? "latest:\t" + SourceVersion.latest() + "\n" + -?????????????????????????????????????? "latestSupported:\t" + SourceVersion.latestSupported()); +?????????????????????????????????????? "latest:\t" + latest + "\n" + +?????????????????????????????????????? "latestSupported:\t" + latestSupported); +??????? } ???? } ???? private static void testVersionVaryingKeywords() { From vicente.romero at oracle.com Thu Feb 1 13:57:09 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 1 Feb 2018 08:57:09 -0500 Subject: JDK 11 RFR of 8196551: Update TestSourceVersion.java to be robust across version changes In-Reply-To: References: Message-ID: <5a9d1f3e-8e78-9f93-996c-446bf8e86628@oracle.com> On 02/01/2018 12:42 AM, joe darcy wrote: > Hello, > > Please review the patch below to address > > ??? 8196551: Update TestSourceVersion.java to be robust across version > changes > > As the summary implies, the intention of this change is to avoid the > need separately update the test in question when a new SourceVersion > value is added and when the version of the JDK is bumped. > > Until the version is bumped, it is acceptable for latest() to be one > release ahead of latestSupported(), as is true of current builds of > the JDK 11 line of development which don't have the version increment > yet. > > I thought it was clearer to write the acceptable condition directly > rather than apply de Morgan to the whole boolean expression. yep I agree that readability is more important here, looks good > > Thanks, > > -Joe Vicente > > --- > a/test/langtools/tools/javac/processing/model/TestSourceVersion.java > Wed Jan 31 15:15:09 2018 -0800 > +++ > b/test/langtools/tools/javac/processing/model/TestSourceVersion.java > Wed Jan 31 21:38:47 2018 -0800 > @@ -23,7 +23,7 @@ > > ?/* > ? * @test > - * @bug 7025809 8028543 6415644 8028544 8029942 8187951 8193291 > + * @bug 7025809 8028543 6415644 8028544 8029942 8187951 8193291 8196551 > ? * @summary Test latest, latestSupported, underscore as keyword, etc. > ? * @author? Joseph D. Darcy > ? * @modules java.compiler > @@ -46,11 +46,20 @@ > ???? } > > ???? private static void testLatestSupported() { > -??????? if (SourceVersion.latest() != RELEASE_11 || > -??????????? SourceVersion.latestSupported() != RELEASE_10) > +??????? SourceVersion[] values = SourceVersion.values(); > +??????? SourceVersion last = values[values.length - 1]; > +??????? SourceVersion latest = SourceVersion.latest(); > +??????? SourceVersion latestSupported = SourceVersion.latestSupported(); > + > +??????? if (latest == last && > +??????????? latestSupported == SourceVersion.valueOf("RELEASE_" + > Runtime.version().feature()) && > +??????????? (latest == latestSupported || (latest.ordinal() - > latestSupported.ordinal() == 1)) ) > +??????????? return; > +??????? else { > ???????????? throw new RuntimeException("Unexpected release value(s) > found:\n" + > -?????????????????????????????????????? "latest:\t" + > SourceVersion.latest() + "\n" + > -?????????????????????????????????????? "latestSupported:\t" + > SourceVersion.latestSupported()); > +?????????????????????????????????????? "latest:\t" + latest + "\n" + > +?????????????????????????????????????? "latestSupported:\t" + > latestSupported); > +??????? } > ???? } > > ???? private static void testVersionVaryingKeywords() { > From cushon at google.com Thu Feb 1 18:56:15 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 1 Feb 2018 10:56:15 -0800 Subject: RFR: JDK-8190452: javac should not add MethodParameters attributes to v51 and earlier class files In-Reply-To: References: Message-ID: Bump. I'm happy to implement either of the alternatives I mentioned, but was hoping to get feedback on the approach first. On Wed, Jan 17, 2018 at 11:51 AM, Liam Miller-Cushon wrote: > Please review a fix for JDK-8190452. The change causes javac to not emit MethodParameters > attributes when targeting v51 class files. > > The change implements the suggestion from this thread: > http://mail.openjdk.java.net/pipermail/compiler-dev/2018- > January/011579.html > > There are two related changes that may be worth considering: > * now that -parameters will be ignored when compiling with --release < 8, > should this combination of flags result in a warning if -Xlint:options is > enabled? > * since this wasn't fixed in JDK 9, there are v51 class files in the wild > that contain unexpected MethodParameters attributes. Should > -Xlint:classfile be relaxed to avoid warning on those? > > bug: https://bugs.openjdk.java.net/browse/JDK-8190452 > webrev: http://cr.openjdk.java.net/~cushon/8190452/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu Feb 1 19:06:53 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 1 Feb 2018 11:06:53 -0800 Subject: ordering constraints in TransTypes Message-ID: Hello, We've had a few [1][2][3] previous discussions about issues related to ordering constraints in TransTypes, which cause problems with bridge generation and with the by-file compilation policy. You mentioned in the past that there were some changes to TransTypes in the valhalla branch that helped here. Did any of that make it into 10, and if not is it still on the roadmap? Thanks, [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2016-December/010584.html [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2016-April/010149.html [3] http://mail.openjdk.java.net/pipermail/compiler-dev/2015-July/009712.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Feb 1 19:08:34 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 1 Feb 2018 19:08:34 +0000 Subject: ordering constraints in TransTypes In-Reply-To: References: Message-ID: <1362e40b-0aaf-43ab-13b6-2e3156178c9f@oracle.com> Hi, Vicente was looking into this. Maurizio On 01/02/18 19:06, Liam Miller-Cushon wrote: > Hello, > > We've had a few [1][2][3] previous discussions about issues related to > ordering constraints in TransTypes, which cause problems with bridge > generation and with the by-file compilation policy. > > You mentioned in the past that there were some changes to TransTypes > in the valhalla branch that helped here. Did any of that make it into > 10, and if not is it still on the roadmap? > > Thanks, > > [1] > http://mail.openjdk.java.net/pipermail/compiler-dev/2016-December/010584.html > > [2] > http://mail.openjdk.java.net/pipermail/compiler-dev/2016-April/010149.html > [3] > http://mail.openjdk.java.net/pipermail/compiler-dev/2015-July/009712.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Feb 1 19:21:40 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 1 Feb 2018 14:21:40 -0500 Subject: ordering constraints in TransTypes In-Reply-To: <1362e40b-0aaf-43ab-13b6-2e3156178c9f@oracle.com> References: <1362e40b-0aaf-43ab-13b6-2e3156178c9f@oracle.com> Message-ID: <3b74f357-4224-184c-1368-5091a8edfe98@oracle.com> On 02/01/2018 02:08 PM, Maurizio Cimadamore wrote: > > Hi, > Vicente was looking into this. > yep, this is still in my to-do list, I will check the current state of this task > Maurizio > Vicente > > On 01/02/18 19:06, Liam Miller-Cushon wrote: >> Hello, >> >> We've had a few [1][2][3] previous discussions about issues related >> to ordering constraints in TransTypes, which cause problems with >> bridge generation and with the by-file compilation policy. >> >> You mentioned in the past that there were some changes to TransTypes >> in the valhalla branch that helped here. Did any of that make it into >> 10, and if not is it still on the roadmap? >> >> Thanks, >> >> [1] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-December/010584.html >> >> [2] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-April/010149.html >> [3] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2015-July/009712.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Feb 2 00:42:38 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 1 Feb 2018 16:42:38 -0800 Subject: JDK 11 RFR of JDK-8196623: Update JavaBaseTest.java to be version agnostic Message-ID: <1003cd4e-81e5-c0f0-6c21-a3a6421ac12f@oracle.com> Hello, Hopefully the final langtools test hardening needed before the version upgrade to 11, please review the patch below to address: ??? JDK-8196623: Update JavaBaseTest.java to be version agnostic Instead of explicitly passing "9", "10", and $SPEC_NUMBER of later release, "9" and "10" and used for the --release option and the --release release option is omitted for the current value. For some time, javac defaults to the (roughly) the current release if no -source or --release option is given. Thanks, -Joe diff -r b0a54e2ba484 test/langtools/tools/javac/modules/JavaBaseTest.java --- a/test/langtools/tools/javac/modules/JavaBaseTest.java??? Thu Feb 01 09:16:03 2018 -0800 +++ b/test/langtools/tools/javac/modules/JavaBaseTest.java??? Thu Feb 01 16:40:39 2018 -0800 @@ -23,7 +23,7 @@ ?/** ? * @test - * @bug 8193125 + * @bug 8193125 8196623 ? * @summary test modifiers with java.base ? * @library /tools/lib ? * @modules @@ -66,10 +66,7 @@ ???????? List.of("static", "transitive") ???? ); -??? final String specVersion = System.getProperty("java.specification.version"); -??? final List targets = specVersion.equals("10") -??????????? ? List.of("9", "10") -??????????? : List.of("9", "10", specVersion); +??? final List targets = List.of("9", "10", "current"); ???? enum Mode { SOURCE, CLASS }; @@ -121,13 +118,18 @@ ???????? Path modules = Files.createDirectories(base.resolve("modules")); ???????? boolean expectOK = target.equals("9"); -??????? String log = new JavacTask(tb) -??????????????? .outdir(modules) -??????????????? .options("-XDrawDiagnostics", "--release", target) -??????????????? .files(tb.findJavaFiles(src)) -??????????????? .run(expectOK ? Task.Expect.SUCCESS : Task.Expect.FAIL) -??????????????? .writeAll() -??????????????? .getOutput(Task.OutputKind.DIRECT); +??????? JavacTask jct = new JavacTask(tb) +??????????? .outdir(modules); + +??????? if (target.equals("current")) +??????????? jct.options("-XDrawDiagnostics"); +??????? else +??????????? jct.options("-XDrawDiagnostics", "--release", target); + +??????? String log = jct.files(tb.findJavaFiles(src)) +??????????? .run(expectOK ? Task.Expect.SUCCESS : Task.Expect.FAIL) +??????????? .writeAll() +??????????? .getOutput(Task.OutputKind.DIRECT); ???????? if (!expectOK) { ???????????? boolean foundErrorMessage = false; @@ -189,12 +191,16 @@ ???????????????? "module m { requires java.base; }"); ???????? Path modules1 = Files.createDirectories(base.resolve("interim-modules")); -??????? new JavacTask(tb) -??????????????? .outdir(modules1) -??????????????? .options("--release", target) -??????????????? .files(tb.findJavaFiles(src1)) -??????????????? .run(Task.Expect.SUCCESS) -??????????????? .writeAll(); +??????? JavacTask jct = new JavacTask(tb) +??????????? .outdir(modules1); + +??????? if (!target.equals("current")) { +??????????? jct.options("--release", target); +??????? } + +??????? jct.files(tb.findJavaFiles(src1)) +??????????? .run(Task.Expect.SUCCESS) +??????????? .writeAll(); ???????? ClassFile cf1 = ClassFile.read(modules1.resolve("module-info.class")); From joe.darcy at oracle.com Fri Feb 2 01:47:32 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 1 Feb 2018 17:47:32 -0800 Subject: JDK 11 RFR of JDK-8196627: Update MultiReleaseJarAwareSJFM.java to be version agnostic Message-ID: <3036b43a-a21c-0fa7-98ba-43485c5bb3d8@oracle.com> Hello, This really should be the last review related to updating langtools tests before the JDK 10 -> 11 version update. A multi-release jar file test had a mismatch of a fixed version of version and querying the current version from the runtime. Please review the patch below to reconcile this difference and thereby address: ??? ??? JDK-8196627: Update MultiReleaseJarAwareSJFM.java to be version agnostic Thanks, -Joe --- a/test/langtools/tools/javac/file/MultiReleaseJar/MultiReleaseJarAwareSJFM.java Thu Feb 01 09:16:03 2018 -0800 +++ b/test/langtools/tools/javac/file/MultiReleaseJar/MultiReleaseJarAwareSJFM.java Thu Feb 01 17:46:16 2018 -0800 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -23,7 +23,7 @@ ?/* ? * @test - * @bug 8149757 8144062 + * @bug 8149757 8144062 8196627 ? * @summary Test that StandardJavaFileManager uses the correct version of a ? * class from a multi-release jar on classpath ? * @library /tools/lib @@ -56,6 +56,7 @@ ?import toolbox.ToolBox; ?public class MultiReleaseJarAwareSJFM { +??? private static final int CURRENT_VERSION = Runtime.version().major(); ???? private final String version8 = ???????????? "package version;\n" + @@ -86,12 +87,12 @@ ???????????? "??? }\n" + ???????????? "}\n"; -??? private final String version10 = +??? private final String versionCurrent = ???????????? "package version;\n" + ???????????? "\n" + ???????????? "public class Version {\n" + ???????????? "??? public int getVersion() {\n" + -??????????? "??????? return 10;\n" + +??????????? "??????? return " + CURRENT_VERSION +";\n" + ???????????? "??? }\n" + ???????????? "}\n"; @@ -116,7 +117,7 @@ ???? public void setup() throws Exception { ???????? tb.createDirectories("classes", ???????????????? "classes/META-INF/versions/9", -??????????????? "classes/META-INF/versions/10"); +??????????????? "classes/META-INF/versions/" + CURRENT_VERSION); ???????? new JavacTask(tb) ???????????????? .outdir("classes") ???????????????? .sources(version8) @@ -126,8 +127,8 @@ ???????????????? .sources(version9, packagePrivate) ???????????????? .run(); ???????? new JavacTask(tb) -??????????????? .outdir("classes/META-INF/versions/10") -??????????????? .sources(version10) +??????????????? .outdir("classes/META-INF/versions/" + CURRENT_VERSION) +??????????????? .sources(versionCurrent) ???????????????? .run(); ???????? new JarTask(tb, "multi-release.jar") ???????????????? .manifest(manifest) @@ -135,16 +136,16 @@ ???????????????? .files("version/Version.class", "META-INF/versions/9/version/Version.class", "META-INF/versions/9/version/PackagePrivate.class", - "META-INF/versions/10/version/Version.class") +??????????????????????? "META-INF/versions/" + CURRENT_VERSION + "/version/Version.class") ???????????????? .run(); ???? } ???? @AfterClass ???? public void teardown() throws Exception { ???????? tb.deleteFiles( - "classes/META-INF/versions/10/version/Version.class", -??????????????? "classes/META-INF/versions/10/version", -??????????????? "classes/META-INF/versions/10/", +??????????????? "classes/META-INF/versions/" + CURRENT_VERSION + "/version/Version.class", +??????????????? "classes/META-INF/versions/" + CURRENT_VERSION + "/version", +??????????????? "classes/META-INF/versions/" + CURRENT_VERSION, "classes/META-INF/versions/9/version/Version.class", "classes/META-INF/versions/9/version/PackagePrivate.class", ???????????????? "classes/META-INF/versions/9/version", From srinivas.dama at oracle.com Fri Feb 2 05:41:58 2018 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Thu, 1 Feb 2018 21:41:58 -0800 (PST) Subject: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum In-Reply-To: References: <96910f02-a090-41b6-b7e9-53bfc18935f1@default> Message-ID: Hi Maurizio, Thank you for the comments. Please review the revised webrev at http://cr.openjdk.java.net/~sdama/8152616/webrev.01/ . >* why the logic for printing the enum constant constructor type arguments? It is not possible to specify explicit constructor arguments on enum constants. (Funnily, javac attempts to parse them, but the attempt fails because the parser mode is wrong, so an >error is generated). The spec has no place for them in the grammar: Yes- no need to print enum constant constructor type arguments, earlier I have taken this from existing "visitNewClass" method which is doing so but missed to remove that. >I believe your end of block comment is misplaced, and it skips enum constructor arguments - that is, I see that '*/' is put AFTER the constructor arguments and before the '{' if any. Now, that doesn't affect your test, because the constants in the test don't >have constructor arguments, but I believe there's bug lurking in here? Yes - there is a bug hidden here.Fixed and modified the test case as well. Regards, Srinivas From: Maurizio Cimadamore Sent: Thursday, January 25, 2018 4:48 PM To: Srinivas Dama ; compiler-dev at openjdk.java.net Subject: Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum Hi Srinivas, two comments: * why the logic for printing the enum constant constructor type arguments? It is not possible to specify explicit constructor arguments on enum constants. (Funnily, javac attempts to parse them, but the attempt fails because the parser mode is wrong, so an error is generated). The spec has no place for them in the grammar: https://docs.oracle.com/javase/specs/jls/se9/html/jls-8.html#jls-8.9.1 * I believe your end of block comment is misplaced, and it skips enum constructor arguments - that is, I see that '*/' is put AFTER the constructor arguments and before the '{' if any. Now, that doesn't affect your test, because the constants in the test don't have constructor arguments, but I believe there's bug lurking in here? Cheers Maurizio On 25/01/18 08:19, Srinivas Dama wrote: Hi, Please review HYPERLINK "http://cr.openjdk.java.net/%7Esdama/8152616/webrev.00/"http://cr.openjdk.java.net/~sdama/8152616/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8152616 Regards, Srinivas -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Feb 2 09:06:51 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 2 Feb 2018 09:06:51 +0000 Subject: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum In-Reply-To: References: <96910f02-a090-41b6-b7e9-53bfc18935f1@default> Message-ID: <2b2ed95e-875a-a769-c3f2-ed20d37927ec@oracle.com> Looks good, thanks! Maurizio On 02/02/18 05:41, Srinivas Dama wrote: > > Hi Maurizio, > > Thank you for the comments. > > Please review the revised webrev at > http://cr.openjdk.java.net/~sdama/8152616/webrev.01/ > . > > />* why the logic for printing the enum constant constructor type > arguments? It is not possible to specify explicit constructor > arguments on enum constants. (Funnily, javac attempts to parse them, > but the attempt fails because the parser mode is wrong, so an >error > is generated). The spec has no place for them in the grammar:/ > > Yes- no need to print enum constant constructor type arguments, > earlier I have taken this from existing ??visitNewClass? method which > is doing so but missed to remove that. > > >/I believe your end of block comment is misplaced, and it skips enum > constructor arguments - that is, I see that '*/' is put AFTER the > constructor arguments and before the '{' if any. Now, that doesn't > affect your test, because the constants in the test don't >have > constructor arguments, but I believe there's bug lurking in here?/ > > Yes ? there is a bug hidden here.Fixed and modified the? test case as > well. > > Regards, > > Srinivas > > *From:*Maurizio Cimadamore > *Sent:* Thursday, January 25, 2018 4:48 PM > *To:* Srinivas Dama ; > compiler-dev at openjdk.java.net > *Subject:* Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates > nested comments for enum > > Hi Srinivas, > two comments: > > * why the logic for printing the enum constant constructor type > arguments? It is not possible to specify explicit constructor > arguments on enum constants. (Funnily, javac attempts to parse them, > but the attempt fails because the parser mode is wrong, so an error is > generated). The spec has no place for them in the grammar: > > https://docs.oracle.com/javase/specs/jls/se9/html/jls-8.html#jls-8.9.1 > > * I believe your end of block comment is misplaced, and it skips enum > constructor arguments - that is, I see that '*/' is put AFTER the > constructor arguments and before the '{' if any. Now, that doesn't > affect your test, because the constants in the test don't have > constructor arguments, but I believe there's bug lurking in here? > > Cheers > Maurizio > > On 25/01/18 08:19, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8152616/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8152616 > > Regards, > > Srinivas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Feb 2 13:13:16 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 2 Feb 2018 08:13:16 -0500 Subject: JDK 11 RFR of JDK-8196623: Update JavaBaseTest.java to be version agnostic In-Reply-To: <1003cd4e-81e5-c0f0-6c21-a3a6421ac12f@oracle.com> References: <1003cd4e-81e5-c0f0-6c21-a3a6421ac12f@oracle.com> Message-ID: <7a2f84ce-c98d-0266-2c0c-e5d6cf32bb46@oracle.com> nit: On 02/01/2018 07:42 PM, joe darcy wrote: > jct.files(tb.findJavaFiles(src1)) > +??????????? .run(Task.Expect.SUCCESS) > +??????????? .writeAll(); I think that you can remove the invocation to the writeAll method in this case as the output won't be used. Apart from that looks good Vicente From vicente.romero at oracle.com Fri Feb 2 13:15:46 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 2 Feb 2018 08:15:46 -0500 Subject: JDK 11 RFR of JDK-8196627: Update MultiReleaseJarAwareSJFM.java to be version agnostic In-Reply-To: <3036b43a-a21c-0fa7-98ba-43485c5bb3d8@oracle.com> References: <3036b43a-a21c-0fa7-98ba-43485c5bb3d8@oracle.com> Message-ID: <60db0054-463a-0b30-0b5a-0aef3079a5f0@oracle.com> looks good, Vicente On 02/01/2018 08:47 PM, joe darcy wrote: > Hello, > > This really should be the last review related to updating langtools > tests before the JDK 10 -> 11 version update. A multi-release jar file > test had a mismatch of a fixed version of version and querying the > current version from the runtime. Please review the patch below to > reconcile this difference and thereby address: > > ??? ??? JDK-8196627: Update MultiReleaseJarAwareSJFM.java to be > version agnostic > > Thanks, > > -Joe > > --- > a/test/langtools/tools/javac/file/MultiReleaseJar/MultiReleaseJarAwareSJFM.java > Thu Feb 01 09:16:03 2018 -0800 > +++ > b/test/langtools/tools/javac/file/MultiReleaseJar/MultiReleaseJarAwareSJFM.java > Thu Feb 01 17:46:16 2018 -0800 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -23,7 +23,7 @@ > > ?/* > ? * @test > - * @bug 8149757 8144062 > + * @bug 8149757 8144062 8196627 > ? * @summary Test that StandardJavaFileManager uses the correct > version of a > ? * class from a multi-release jar on classpath > ? * @library /tools/lib > @@ -56,6 +56,7 @@ > ?import toolbox.ToolBox; > > ?public class MultiReleaseJarAwareSJFM { > +??? private static final int CURRENT_VERSION = > Runtime.version().major(); > > ???? private final String version8 = > ???????????? "package version;\n" + > @@ -86,12 +87,12 @@ > ???????????? "??? }\n" + > ???????????? "}\n"; > > -??? private final String version10 = > +??? private final String versionCurrent = > ???????????? "package version;\n" + > ???????????? "\n" + > ???????????? "public class Version {\n" + > ???????????? "??? public int getVersion() {\n" + > -??????????? "??????? return 10;\n" + > +??????????? "??????? return " + CURRENT_VERSION +";\n" + > ???????????? "??? }\n" + > ???????????? "}\n"; > > @@ -116,7 +117,7 @@ > ???? public void setup() throws Exception { > ???????? tb.createDirectories("classes", > ???????????????? "classes/META-INF/versions/9", > -??????????????? "classes/META-INF/versions/10"); > +??????????????? "classes/META-INF/versions/" + CURRENT_VERSION); > ???????? new JavacTask(tb) > ???????????????? .outdir("classes") > ???????????????? .sources(version8) > @@ -126,8 +127,8 @@ > ???????????????? .sources(version9, packagePrivate) > ???????????????? .run(); > ???????? new JavacTask(tb) > -??????????????? .outdir("classes/META-INF/versions/10") > -??????????????? .sources(version10) > +??????????????? .outdir("classes/META-INF/versions/" + CURRENT_VERSION) > +??????????????? .sources(versionCurrent) > ???????????????? .run(); > ???????? new JarTask(tb, "multi-release.jar") > ???????????????? .manifest(manifest) > @@ -135,16 +136,16 @@ > ???????????????? .files("version/Version.class", > "META-INF/versions/9/version/Version.class", > "META-INF/versions/9/version/PackagePrivate.class", > - "META-INF/versions/10/version/Version.class") > +??????????????????????? "META-INF/versions/" + CURRENT_VERSION + > "/version/Version.class") > ???????????????? .run(); > ???? } > > ???? @AfterClass > ???? public void teardown() throws Exception { > ???????? tb.deleteFiles( > - "classes/META-INF/versions/10/version/Version.class", > -??????????????? "classes/META-INF/versions/10/version", > -??????????????? "classes/META-INF/versions/10/", > +??????????????? "classes/META-INF/versions/" + CURRENT_VERSION + > "/version/Version.class", > +??????????????? "classes/META-INF/versions/" + CURRENT_VERSION + > "/version", > +??????????????? "classes/META-INF/versions/" + CURRENT_VERSION, > "classes/META-INF/versions/9/version/Version.class", > "classes/META-INF/versions/9/version/PackagePrivate.class", > ???????????????? "classes/META-INF/versions/9/version", > From vicente.romero at oracle.com Fri Feb 2 14:17:52 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 2 Feb 2018 09:17:52 -0500 Subject: RFR: JDK-8190452: javac should not add MethodParameters attributes to v51 and earlier class files In-Reply-To: References: Message-ID: <5bc5efb2-7ee5-0a2f-6772-765cd67a4b7f@oracle.com> Hi Liam, The fix looks OK, regarding the test, I don't see the need for the two golden files as they can be constants in the test per se. In addition, the whole test could be self contained in only one class that compiles the Lib.java source. Regarding your questions about what to do with the -Xlint:X options. I don't have any opinion on one way or the other, is there any reason to change them? Thanks, Vicente On 02/01/2018 01:56 PM, Liam Miller-Cushon wrote: > Bump. I'm happy to implement either of the alternatives I mentioned, > but was hoping to get feedback on the approach first. > > On Wed, Jan 17, 2018 at 11:51 AM, Liam Miller-Cushon > > wrote: > > Please review a fix for JDK-8190452. The change causes javac to > not emit MethodParameters attributes when targeting v51 class files. > > The change implements the suggestion from this thread: > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-January/011579.html > > > There are two related changes that may be worth considering: > * now that -parameters will be ignored when compiling with > --release < 8, should this combination of flags result in a > warning if -Xlint:options is enabled? > * since this wasn't fixed in JDK 9, there are v51 class files in > the wild that contain unexpected MethodParameters attributes. > Should -Xlint:classfile be relaxed to avoid warning on those? > > bug: https://bugs.openjdk.java.net/browse/JDK-8190452 > > webrev: http://cr.openjdk.java.net/~cushon/8190452/webrev.00/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Feb 2 18:53:12 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 2 Feb 2018 10:53:12 -0800 Subject: JDK 11 RFR of JDK-8196623: Update JavaBaseTest.java to be version agnostic In-Reply-To: <7a2f84ce-c98d-0266-2c0c-e5d6cf32bb46@oracle.com> References: <1003cd4e-81e5-c0f0-6c21-a3a6421ac12f@oracle.com> <7a2f84ce-c98d-0266-2c0c-e5d6cf32bb46@oracle.com> Message-ID: <3a1a2e02-711b-fc2c-7c8b-ade70a6f3232@oracle.com> Pushed with suggested change; thanks, -Joe On 2/2/2018 5:13 AM, Vicente Romero wrote: > nit: > > On 02/01/2018 07:42 PM, joe darcy wrote: >> jct.files(tb.findJavaFiles(src1)) >> +??????????? .run(Task.Expect.SUCCESS) >> +??????????? .writeAll(); > > I think that you can remove the invocation to the writeAll method in > this case as the output won't be used. Apart from that looks good > > Vicente > From cushon at google.com Sat Feb 3 05:37:58 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 2 Feb 2018 21:37:58 -0800 Subject: RFR: JDK-8190452: javac should not add MethodParameters attributes to v51 and earlier class files In-Reply-To: <5bc5efb2-7ee5-0a2f-6772-765cd67a4b7f@oracle.com> References: <5bc5efb2-7ee5-0a2f-6772-765cd67a4b7f@oracle.com> Message-ID: Hi Vicente, thanks for the review! I inlined the golden files into the test class. I don't think inlining Lib.java works with the current approach of using `@compile --release 7/8` and reflection to access the parameter names, because the reflective APIs were added in 8. I could rewrite the test to use class reading instead of reflection if you prefer. Here's the updated webrev: http://cr.openjdk.java.net/~cushon/8190452/webrev.01/ > Regarding your questions about what to do with the -Xlint:X options. I don't have any opinion on one way or the other, is there any reason to change them? I thought it was potentially surprising that -parameters will now be silently ignored for Java 7 and earlier language levels. Warning about that flag combination would make the new behaviour more discoverable. Since the bug shipped in 9 and 10 there are some wrote: > Hi Liam, > > The fix looks OK, regarding the test, I don't see the need for the two > golden files as they can be constants in the test per se. In addition, the > whole test could be self contained in only one class that compiles the > Lib.java source. Regarding your questions about what to do with the > -Xlint:X options. I don't have any opinion on one way or the other, is > there any reason to change them? > > Thanks, > Vicente > > > On 02/01/2018 01:56 PM, Liam Miller-Cushon wrote: > > Bump. I'm happy to implement either of the alternatives I mentioned, but > was hoping to get feedback on the approach first. > > On Wed, Jan 17, 2018 at 11:51 AM, Liam Miller-Cushon > wrote: > >> Please review a fix for JDK-8190452. The change causes javac to not emit MethodParameters >> attributes when targeting v51 class files. >> >> The change implements the suggestion from this thread: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-Jan >> uary/011579.html >> >> There are two related changes that may be worth considering: >> * now that -parameters will be ignored when compiling with --release < 8, >> should this combination of flags result in a warning if -Xlint:options is >> enabled? >> * since this wasn't fixed in JDK 9, there are v51 class files in the wild >> that contain unexpected MethodParameters attributes. Should >> -Xlint:classfile be relaxed to avoid warning on those? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8190452 >> webrev: http://cr.openjdk.java.net/~cushon/8190452/webrev.00/ >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Sat Feb 3 18:39:08 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 3 Feb 2018 13:39:08 -0500 Subject: RFR: JDK-8190452: javac should not add MethodParameters attributes to v51 and earlier class files In-Reply-To: References: <5bc5efb2-7ee5-0a2f-6772-765cd67a4b7f@oracle.com> Message-ID: <945c27fc-cd66-9051-ed58-4fa9754f2090@oracle.com> On 02/03/2018 12:37 AM, Liam Miller-Cushon wrote: > Hi Vicente, thanks for the review! > > I inlined the golden files into the test class. I don't think inlining > Lib.java works with the current approach of using `@compile --release > 7/8` and reflection to access the parameter names, because the > reflective APIs were added in 8. I could rewrite the test to use class > reading instead of reflection if you prefer. yes I was thinking about class reading but I'm OK with the current version of the patch > > Here's the updated webrev: > http://cr.openjdk.java.net/~cushon/8190452/webrev.01/ > > > > Regarding your questions about what to do with the -Xlint:X options. > I don't have any opinion on one way or the other, is there any reason > to change them? > > I thought it was potentially surprising that -parameters will now be > silently ignored for Java 7 and earlier language levels. Warning about > that flag combination would make the new behaviour more discoverable. > > Since the bug shipped in 9 and 10 there are some MethodParameters in the wild, and I've seen cases where it broke > builds using -Xlint:classfile and -Werror. > > I don't think either of those are common problems. If you think we > should leave the -Xlint handling as-is that sounds good to me. as discussed off-line with Jon, yes please add the warning, but feel free to do it as part of this bug or in a different one. Vicente > > On Fri, Feb 2, 2018 at 6:17 AM, Vicente Romero > > wrote: > > Hi Liam, > > The fix looks OK, regarding the test, I don't see the need for the > two golden files as they can be constants in the test per se. In > addition, the whole test could be self contained in only one class > that compiles the Lib.java source. Regarding your questions about > what to do with the -Xlint:X options. I don't have any opinion on > one way or the other, is there any reason to change them? > > Thanks, > Vicente > > > On 02/01/2018 01:56 PM, Liam Miller-Cushon wrote: >> Bump. I'm happy to implement either of the alternatives I >> mentioned, but was hoping to get feedback on the approach first. >> >> On Wed, Jan 17, 2018 at 11:51 AM, Liam Miller-Cushon >> > wrote: >> >> Please review a fix for JDK-8190452. The change causes javac >> to not emit MethodParameters attributes when targeting v51 >> class files. >> >> The change implements the suggestion from this thread: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-January/011579.html >> >> >> There are two related changes that may be worth considering: >> * now that -parameters will be ignored when compiling with >> --release < 8, should this combination of flags result in a >> warning if -Xlint:options is enabled? >> * since this wasn't fixed in JDK 9, there are v51 class files >> in the wild that contain unexpected MethodParameters >> attributes. Should -Xlint:classfile be relaxed to avoid >> warning on those? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8190452 >> >> webrev: http://cr.openjdk.java.net/~cushon/8190452/webrev.00/ >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Sun Feb 4 02:27:03 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Sat, 3 Feb 2018 18:27:03 -0800 Subject: RFR: JDK-8190452: javac should not add MethodParameters attributes to v51 and earlier class files In-Reply-To: <945c27fc-cd66-9051-ed58-4fa9754f2090@oracle.com> References: <5bc5efb2-7ee5-0a2f-6772-765cd67a4b7f@oracle.com> <945c27fc-cd66-9051-ed58-4fa9754f2090@oracle.com> Message-ID: I reworked the test to use class reading, and added the -Xlint:option warning. Here's the updated patch: http://cr.openjdk.java.net/~cushon/8190452/webrev.02/ On Sat, Feb 3, 2018 at 10:39 AM, Vicente Romero wrote: > > > On 02/03/2018 12:37 AM, Liam Miller-Cushon wrote: > > Hi Vicente, thanks for the review! > > I inlined the golden files into the test class. I don't think inlining > Lib.java works with the current approach of using `@compile --release 7/8` > and reflection to access the parameter names, because the reflective APIs > were added in 8. I could rewrite the test to use class reading instead of > reflection if you prefer. > > > yes I was thinking about class reading but I'm OK with the current version > of the patch > > > Here's the updated webrev: http://cr.openjdk.java.net/~cushon/8190452/ > webrev.01/ > > > Regarding your questions about what to do with the -Xlint:X options. I > don't have any opinion on one way or the other, is there any reason to > change them? > > I thought it was potentially surprising that -parameters will now be > silently ignored for Java 7 and earlier language levels. Warning about that > flag combination would make the new behaviour more discoverable. > > Since the bug shipped in 9 and 10 there are some MethodParameters in the wild, and I've seen cases where it broke builds > using -Xlint:classfile and -Werror. > > I don't think either of those are common problems. If you think we should > leave the -Xlint handling as-is that sounds good to me. > > > as discussed off-line with Jon, yes please add the warning, but feel free > to do it as part of this bug or in a different one. > > Vicente > > > On Fri, Feb 2, 2018 at 6:17 AM, Vicente Romero > wrote: > >> Hi Liam, >> >> The fix looks OK, regarding the test, I don't see the need for the two >> golden files as they can be constants in the test per se. In addition, the >> whole test could be self contained in only one class that compiles the >> Lib.java source. Regarding your questions about what to do with the >> -Xlint:X options. I don't have any opinion on one way or the other, is >> there any reason to change them? >> >> Thanks, >> Vicente >> >> >> On 02/01/2018 01:56 PM, Liam Miller-Cushon wrote: >> >> Bump. I'm happy to implement either of the alternatives I mentioned, but >> was hoping to get feedback on the approach first. >> >> On Wed, Jan 17, 2018 at 11:51 AM, Liam Miller-Cushon >> wrote: >> >>> Please review a fix for JDK-8190452. The change causes javac to not >>> emit MethodParameters attributes when targeting v51 class files. >>> >>> The change implements the suggestion from this thread: >>> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-Jan >>> uary/011579.html >>> >>> There are two related changes that may be worth considering: >>> * now that -parameters will be ignored when compiling with --release < >>> 8, should this combination of flags result in a warning if -Xlint:options >>> is enabled? >>> * since this wasn't fixed in JDK 9, there are v51 class files in the >>> wild that contain unexpected MethodParameters attributes. Should >>> -Xlint:classfile be relaxed to avoid warning on those? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8190452 >>> webrev: http://cr.openjdk.java.net/~cushon/8190452/webrev.00/ >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sun Feb 4 04:59:34 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 3 Feb 2018 20:59:34 -0800 Subject: RFR: JDK-8190452: javac should not add MethodParameters attributes to v51 and earlier class files In-Reply-To: References: <5bc5efb2-7ee5-0a2f-6772-765cd67a4b7f@oracle.com> <945c27fc-cd66-9051-ed58-4fa9754f2090@oracle.com> Message-ID: Liam, From a minor stylistic point of view, we generally place the test description (the comment beginning @test) after the legal header, and before any code like package and import statements -- Jon On 2/3/18 6:27 PM, Liam Miller-Cushon wrote: > I reworked the test to use class reading, and added the -Xlint:option > warning. > > Here's the updated patch: > http://cr.openjdk.java.net/~cushon/8190452/webrev.02/ > > > On Sat, Feb 3, 2018 at 10:39 AM, Vicente Romero > > wrote: > > > > On 02/03/2018 12:37 AM, Liam Miller-Cushon wrote: >> Hi Vicente, thanks for the review! >> >> I inlined the golden files into the test class. I don't think >> inlining Lib.java works with the current approach of using >> `@compile --release 7/8` and reflection to access the parameter >> names, because the reflective APIs were added in 8. I could >> rewrite the test to use class reading instead of reflection if >> you prefer. > > yes I was thinking about class reading but I'm OK with the current > version of the patch > >> >> Here's the updated webrev: >> http://cr.openjdk.java.net/~cushon/8190452/webrev.01/ >> >> >> > Regarding your questions about what to do with the -Xlint:X >> options. I don't have any opinion on one way or the other, is >> there any reason to change them? >> >> I thought it was potentially surprising that -parameters will now >> be silently ignored for Java 7 and earlier language levels. >> Warning about that flag combination would make the new behaviour >> more discoverable. >> >> Since the bug shipped in 9 and 10 there are some > with MethodParameters in the wild, and I've seen cases where it >> broke builds using -Xlint:classfile and -Werror. >> >> I don't think either of those are common problems. If you think >> we should leave the -Xlint handling as-is that sounds good to me. > > as discussed off-line with Jon, yes please add the warning, but > feel free to do it as part of this bug or in a different one. > > Vicente > >> >> On Fri, Feb 2, 2018 at 6:17 AM, Vicente Romero >> > wrote: >> >> Hi Liam, >> >> The fix looks OK, regarding the test, I don't see the need >> for the two golden files as they can be constants in the test >> per se. In addition, the whole test could be self contained >> in only one class that compiles the Lib.java source. >> Regarding your questions about what to do with the -Xlint:X >> options. I don't have any opinion on one way or the other, is >> there any reason to change them? >> >> Thanks, >> Vicente >> >> >> On 02/01/2018 01:56 PM, Liam Miller-Cushon wrote: >>> Bump. I'm happy to implement either of the alternatives I >>> mentioned, but was hoping to get feedback on the approach first. >>> >>> On Wed, Jan 17, 2018 at 11:51 AM, Liam Miller-Cushon >>> > wrote: >>> >>> Please review a fix for JDK-8190452. The change causes >>> javac to not emit MethodParameters attributes when >>> targeting v51 class files. >>> >>> The change implements the suggestion from this thread: >>> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-January/011579.html >>> >>> >>> There are two related changes that may be worth considering: >>> * now that -parameters will be ignored when compiling >>> with --release < 8, should this combination of flags >>> result in a warning if -Xlint:options is enabled? >>> * since this wasn't fixed in JDK 9, there are v51 class >>> files in the wild that contain unexpected >>> MethodParameters attributes. Should -Xlint:classfile be >>> relaxed to avoid warning on those? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8190452 >>> >>> webrev: >>> http://cr.openjdk.java.net/~cushon/8190452/webrev.00/ >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Sun Feb 4 06:27:08 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Sat, 3 Feb 2018 22:27:08 -0800 Subject: RFR: JDK-8190452: javac should not add MethodParameters attributes to v51 and earlier class files In-Reply-To: References: <5bc5efb2-7ee5-0a2f-6772-765cd67a4b7f@oracle.com> <945c27fc-cd66-9051-ed58-4fa9754f2090@oracle.com> Message-ID: Thanks for the reminder, done: http://cr.openjdk.java.net/~cushon/8190452/webrev.03/ On Sat, Feb 3, 2018 at 8:59 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Liam, > > From a minor stylistic point of view, we generally place the test > description (the comment beginning @test) after the legal header, and > before any code like package and import statements > -- Jon > > > On 2/3/18 6:27 PM, Liam Miller-Cushon wrote: > > I reworked the test to use class reading, and added the -Xlint:option > warning. > > Here's the updated patch: http://cr.openjdk.java. > net/~cushon/8190452/webrev.02/ > > On Sat, Feb 3, 2018 at 10:39 AM, Vicente Romero > wrote: > >> >> >> On 02/03/2018 12:37 AM, Liam Miller-Cushon wrote: >> >> Hi Vicente, thanks for the review! >> >> I inlined the golden files into the test class. I don't think inlining >> Lib.java works with the current approach of using `@compile --release 7/8` >> and reflection to access the parameter names, because the reflective APIs >> were added in 8. I could rewrite the test to use class reading instead of >> reflection if you prefer. >> >> >> yes I was thinking about class reading but I'm OK with the current >> version of the patch >> >> >> Here's the updated webrev: http://cr.openjdk.java >> .net/~cushon/8190452/webrev.01/ >> >> > Regarding your questions about what to do with the -Xlint:X options. I >> don't have any opinion on one way or the other, is there any reason to >> change them? >> >> I thought it was potentially surprising that -parameters will now be >> silently ignored for Java 7 and earlier language levels. Warning about that >> flag combination would make the new behaviour more discoverable. >> >> Since the bug shipped in 9 and 10 there are some > MethodParameters in the wild, and I've seen cases where it broke builds >> using -Xlint:classfile and -Werror. >> >> I don't think either of those are common problems. If you think we should >> leave the -Xlint handling as-is that sounds good to me. >> >> >> as discussed off-line with Jon, yes please add the warning, but feel free >> to do it as part of this bug or in a different one. >> >> Vicente >> >> >> On Fri, Feb 2, 2018 at 6:17 AM, Vicente Romero > > wrote: >> >>> Hi Liam, >>> >>> The fix looks OK, regarding the test, I don't see the need for the two >>> golden files as they can be constants in the test per se. In addition, the >>> whole test could be self contained in only one class that compiles the >>> Lib.java source. Regarding your questions about what to do with the >>> -Xlint:X options. I don't have any opinion on one way or the other, is >>> there any reason to change them? >>> >>> Thanks, >>> Vicente >>> >>> >>> On 02/01/2018 01:56 PM, Liam Miller-Cushon wrote: >>> >>> Bump. I'm happy to implement either of the alternatives I mentioned, but >>> was hoping to get feedback on the approach first. >>> >>> On Wed, Jan 17, 2018 at 11:51 AM, Liam Miller-Cushon >>> wrote: >>> >>>> Please review a fix for JDK-8190452. The change causes javac to not >>>> emit MethodParameters attributes when targeting v51 class files. >>>> >>>> The change implements the suggestion from this thread: >>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-Jan >>>> uary/011579.html >>>> >>>> There are two related changes that may be worth considering: >>>> * now that -parameters will be ignored when compiling with --release < >>>> 8, should this combination of flags result in a warning if -Xlint:options >>>> is enabled? >>>> * since this wasn't fixed in JDK 9, there are v51 class files in the >>>> wild that contain unexpected MethodParameters attributes. Should >>>> -Xlint:classfile be relaxed to avoid warning on those? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8190452 >>>> webrev: http://cr.openjdk.java.net/~cushon/8190452/webrev.00/ >>>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivas.dama at oracle.com Mon Feb 5 09:39:27 2018 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Mon, 5 Feb 2018 01:39:27 -0800 (PST) Subject: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum Message-ID: <96fd262c-39bc-4020-a146-486ddf18f8d7@default> Hi, May I have second review for this to push. Regards, Srinivas ----- Original Message ----- From: maurizio.cimadamore at oracle.com To: srinivas.dama at oracle.com, compiler-dev at openjdk.java.net Sent: Friday, February 2, 2018 2:37:00 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum Looks good, thanks! Maurizio On 02/02/18 05:41, Srinivas Dama wrote: Hi Maurizio, Thank you for the comments. Please review the revised webrev at http://cr.openjdk.java.net/~sdama/8152616/webrev.01/ . > * why the logic for printing the enum constant constructor type arguments? It is not possible to specify explicit constructor arguments on enum constants. (Funnily, javac attempts to parse them, but the attempt fails because the parser mode is wrong, so an >error is generated). The spec has no place for them in the grammar: Yes- no need to print enum constant constructor type arguments, earlier I have taken this from existing ?visitNewClass? method which is doing so but missed to remove that. > I believe your end of block comment is misplaced, and it skips enum constructor arguments - that is, I see that '*/' is put AFTER the constructor arguments and before the '{' if any. Now, that doesn't affect your test, because the constants in the test don't >have constructor arguments, but I believe there's bug lurking in here? Yes ? there is a bug hidden here.Fixed and modified the test case as well. Regards, Srinivas From: Maurizio Cimadamore Sent: Thursday, January 25, 2018 4:48 PM To: Srinivas Dama ; compiler-dev at openjdk.java.net Subject: Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum Hi Srinivas, two comments: * why the logic for printing the enum constant constructor type arguments? It is not possible to specify explicit constructor arguments on enum constants. (Funnily, javac attempts to parse them, but the attempt fails because the parser mode is wrong, so an error is generated). The spec has no place for them in the grammar: https://docs.oracle.com/javase/specs/jls/se9/html/jls-8.html#jls-8.9.1 * I believe your end of block comment is misplaced, and it skips enum constructor arguments - that is, I see that '*/' is put AFTER the constructor arguments and before the '{' if any. Now, that doesn't affect your test, because the constants in the test don't have constructor arguments, but I believe there's bug lurking in here? Cheers Maurizio On 25/01/18 08:19, Srinivas Dama wrote: Hi, Please review http://cr.openjdk.java.net/~sdama/8152616/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8152616 Regards, Srinivas -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Feb 5 14:30:41 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 5 Feb 2018 09:30:41 -0500 Subject: RFR: JDK-8190452: javac should not add MethodParameters attributes to v51 and earlier class files In-Reply-To: References: <5bc5efb2-7ee5-0a2f-6772-765cd67a4b7f@oracle.com> <945c27fc-cd66-9051-ed58-4fa9754f2090@oracle.com> Message-ID: <4aa42036-66c2-497b-f097-f04d53916186@oracle.com> looks good, I will push it, Thanks! Vicente On 02/04/2018 01:27 AM, Liam Miller-Cushon wrote: > Thanks for the reminder, done: > http://cr.openjdk.java.net/~cushon/8190452/webrev.03/ > > > On Sat, Feb 3, 2018 at 8:59 PM, Jonathan Gibbons > > wrote: > > Liam, > > From a minor stylistic point of view, we generally place the test > description (the comment beginning @test) after the legal header, > and before any code like package and import statements > > -- Jon > > > On 2/3/18 6:27 PM, Liam Miller-Cushon wrote: >> I reworked the test to use class reading, and added the >> -Xlint:option warning. >> >> Here's the updated patch: >> http://cr.openjdk.java.net/~cushon/8190452/webrev.02/ >> >> >> On Sat, Feb 3, 2018 at 10:39 AM, Vicente Romero >> > wrote: >> >> >> >> On 02/03/2018 12:37 AM, Liam Miller-Cushon wrote: >>> Hi Vicente, thanks for the review! >>> >>> I inlined the golden files into the test class. I don't >>> think inlining Lib.java works with the current approach of >>> using `@compile --release 7/8` and reflection to access the >>> parameter names, because the reflective APIs were added in >>> 8. I could rewrite the test to use class reading instead of >>> reflection if you prefer. >> >> yes I was thinking about class reading but I'm OK with the >> current version of the patch >> >>> >>> Here's the updated webrev: >>> http://cr.openjdk.java.net/~cushon/8190452/webrev.01/ >>> >>> >>> > Regarding your questions about what to do with the -Xlint:X >>> options. I don't have any opinion on one way or the other, >>> is there any reason to change them? >>> >>> I thought it was potentially surprising that -parameters >>> will now be silently ignored for Java 7 and earlier language >>> levels. Warning about that flag combination would make the >>> new behaviour more discoverable. >>> >>> Since the bug shipped in 9 and 10 there are some >> files with MethodParameters in the wild, and I've seen cases >>> where it broke builds using -Xlint:classfile and -Werror. >>> >>> I don't think either of those are common problems. If you >>> think we should leave the -Xlint handling as-is that sounds >>> good to me. >> >> as discussed off-line with Jon, yes please add the warning, >> but feel free to do it as part of this bug or in a different one. >> >> Vicente >> >>> >>> On Fri, Feb 2, 2018 at 6:17 AM, Vicente Romero >>> >> > wrote: >>> >>> Hi Liam, >>> >>> The fix looks OK, regarding the test, I don't see the >>> need for the two golden files as they can be constants >>> in the test per se. In addition, the whole test could be >>> self contained in only one class that compiles the >>> Lib.java source. Regarding your questions about what to >>> do with the -Xlint:X options. I don't have any opinion >>> on one way or the other, is there any reason to change them? >>> >>> Thanks, >>> Vicente >>> >>> >>> On 02/01/2018 01:56 PM, Liam Miller-Cushon wrote: >>>> Bump. I'm happy to implement either of the alternatives >>>> I mentioned, but was hoping to get feedback on the >>>> approach first. >>>> >>>> On Wed, Jan 17, 2018 at 11:51 AM, Liam Miller-Cushon >>>> > wrote: >>>> >>>> Please review a fix for JDK-8190452. The change >>>> causes javac to not emit MethodParameters >>>> attributes when targeting v51 class files. >>>> >>>> The change implements the suggestion from this thread: >>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-January/011579.html >>>> >>>> >>>> There are two related changes that may be worth >>>> considering: >>>> * now that -parameters will be ignored when >>>> compiling with --release < 8, should this >>>> combination of flags result in a warning if >>>> -Xlint:options is enabled? >>>> * since this wasn't fixed in JDK 9, there are v51 >>>> class files in the wild that contain unexpected >>>> MethodParameters attributes. Should >>>> -Xlint:classfile be relaxed to avoid warning on those? >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8190452 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~cushon/8190452/webrev.00/ >>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivas.dama at oracle.com Mon Feb 5 17:04:07 2018 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Mon, 5 Feb 2018 09:04:07 -0800 (PST) Subject: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum Message-ID: <1eff39f5-2440-469c-a605-8ce7a67f233e@default> Sorry, no more reviews are required. Regards, Srinivas ----- Original Message ----- From: srinivas.dama at oracle.com To: compiler-dev at openjdk.java.net Sent: Monday, February 5, 2018 3:09:44 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum Hi, May I have second review for this to push. Regards, Srinivas ----- Original Message ----- From: maurizio.cimadamore at oracle.com To: srinivas.dama at oracle.com, compiler-dev at openjdk.java.net Sent: Friday, February 2, 2018 2:37:00 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum Looks good, thanks! Maurizio On 02/02/18 05:41, Srinivas Dama wrote: Hi Maurizio, Thank you for the comments. Please review the revised webrev at http://cr.openjdk.java.net/~sdama/8152616/webrev.01/ . > * why the logic for printing the enum constant constructor type arguments? It is not possible to specify explicit constructor arguments on enum constants. (Funnily, javac attempts to parse them, but the attempt fails because the parser mode is wrong, so an >error is generated). The spec has no place for them in the grammar: Yes- no need to print enum constant constructor type arguments, earlier I have taken this from existing ?visitNewClass? method which is doing so but missed to remove that. > I believe your end of block comment is misplaced, and it skips enum constructor arguments - that is, I see that '*/' is put AFTER the constructor arguments and before the '{' if any. Now, that doesn't affect your test, because the constants in the test don't >have constructor arguments, but I believe there's bug lurking in here? Yes ? there is a bug hidden here.Fixed and modified the test case as well. Regards, Srinivas From: Maurizio Cimadamore Sent: Thursday, January 25, 2018 4:48 PM To: Srinivas Dama ; compiler-dev at openjdk.java.net Subject: Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum Hi Srinivas, two comments: * why the logic for printing the enum constant constructor type arguments? It is not possible to specify explicit constructor arguments on enum constants. (Funnily, javac attempts to parse them, but the attempt fails because the parser mode is wrong, so an error is generated). The spec has no place for them in the grammar: https://docs.oracle.com/javase/specs/jls/se9/html/jls-8.html#jls-8.9.1 * I believe your end of block comment is misplaced, and it skips enum constructor arguments - that is, I see that '*/' is put AFTER the constructor arguments and before the '{' if any. Now, that doesn't affect your test, because the constants in the test don't have constructor arguments, but I believe there's bug lurking in here? Cheers Maurizio On 25/01/18 08:19, Srinivas Dama wrote: Hi, Please review http://cr.openjdk.java.net/~sdama/8152616/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8152616 Regards, Srinivas -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Feb 5 17:29:30 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 5 Feb 2018 17:29:30 +0000 Subject: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum In-Reply-To: <1eff39f5-2440-469c-a605-8ce7a67f233e@default> References: <1eff39f5-2440-469c-a605-8ce7a67f233e@default> Message-ID: <8d44848a-f54f-ee91-9af8-7320f2daa64d@oracle.com> No worries! Thanks Maurizio On 05/02/18 17:04, Srinivas Dama wrote: > Sorry, no more reviews are required. > > Regards, > Srinivas > ----- Original Message ----- > From: srinivas.dama at oracle.com > To: compiler-dev at openjdk.java.net > Sent: Monday, February 5, 2018 3:09:44 PM GMT +05:30 Chennai, Kolkata, > Mumbai, New Delhi > Subject: Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates > nested comments for enum > > Hi, > > May I have second review for this to push. > > Regards, > Srinivas > ----- Original Message ----- > From: maurizio.cimadamore at oracle.com > To: srinivas.dama at oracle.com, compiler-dev at openjdk.java.net > Sent: Friday, February 2, 2018 2:37:00 PM GMT +05:30 Chennai, Kolkata, > Mumbai, New Delhi > Subject: Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty generates > nested comments for enum > > Looks good, thanks! > > Maurizio > > > On 02/02/18 05:41, Srinivas Dama wrote: > > Hi Maurizio, > > Thank you for the comments. > > Please review the revised webrev at > http://cr.openjdk.java.net/~sdama/8152616/webrev.01/ > . > > />* why the logic for printing the enum constant constructor type > arguments? It is not possible to specify explicit constructor > arguments on enum constants. (Funnily, javac attempts to parse > them, but the attempt fails because the parser mode is wrong, so > an >error is generated). The spec has no place for them in the > grammar:/ > > Yes- no need to print enum constant constructor type arguments, > earlier I have taken this from existing ??visitNewClass? method > which is doing so but missed to remove that. > > >/I believe your end of block comment is misplaced, and it skips > enum constructor arguments - that is, I see that '*/' is put AFTER > the constructor arguments and before the '{' if any. Now, that > doesn't affect your test, because the constants in the test don't > >have constructor arguments, but I believe there's bug lurking in > here?/ > > Yes ? there is a bug hidden here.Fixed and modified the? test case > as well. > > Regards, > > Srinivas > > *From:*Maurizio Cimadamore > *Sent:* Thursday, January 25, 2018 4:48 PM > *To:* Srinivas Dama ; > compiler-dev at openjdk.java.net > *Subject:* Re: RFR: 8152616: com.sun.tools.javac.tree.Pretty > generates nested comments for enum > > Hi Srinivas, > two comments: > > * why the logic for printing the enum constant constructor type > arguments? It is not possible to specify explicit constructor > arguments on enum constants. (Funnily, javac attempts to parse > them, but the attempt fails because the parser mode is wrong, so > an error is generated). The spec has no place for them in the grammar: > > https://docs.oracle.com/javase/specs/jls/se9/html/jls-8.html#jls-8.9.1 > > * I believe your end of block comment is misplaced, and it skips > enum constructor arguments - that is, I see that '*/' is put AFTER > the constructor arguments and before the '{' if any. Now, that > doesn't affect your test, because the constants in the test don't > have constructor arguments, but I believe there's bug lurking in here? > > Cheers > Maurizio > > On 25/01/18 08:19, Srinivas Dama wrote: > > Hi, > > Please review > http://cr.openjdk.java.net/~sdama/8152616/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8152616 > > Regards, > > Srinivas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Thu Feb 8 02:49:18 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 8 Feb 2018 09:49:18 +0700 Subject: Final field update in unreachable for loop update section Message-ID: Hello! Consider two code samples: public class Sample1 { final int x; Sample1() { for(;;x=1) { x=2; break; } } } This cannot be compiled via javac 9.0.1: Sample1.java:6: error: variable x might be assigned in loop x=2; ^ 1 error The message looks misleading, because if I remove "x=1" assignment, the compilation goes fine. It's also interesting that if I move x=2 out of the loop, the compilation goes fine as well: public class Sample2 { final int x; Sample2() { x=2; for(;;x=1) { break; } } } Though the behavior of the constructor is the same. I feel that Sample1 should be compilable if Sample2 is compilable. Does implementation follows spec here or is it a compiler bug? With best regards, Tagir Valeev. From jonathan.gibbons at oracle.com Thu Feb 8 23:18:35 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Feb 2018 15:18:35 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs Message-ID: <5A7CDACB.50103@oracle.com> This draft JEP contains a proposal to enhance the |java| launcher to support running a program supplied as a single file of Java source code. The program will be compiled and run, without the need to explicit invoke javac, or to package up a jar file. For more details, see: http://openjdk.java.net/jeps/8192920 -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Feb 9 09:31:38 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 9 Feb 2018 10:31:38 +0100 Subject: RFR : JDK-8197439,,Crash with -XDfind=lambda for anonymous class in anonymous class. Message-ID: <5A7D6A7A.2040505@oracle.com> Hi, For certain classes -XDfind=lambda will crash javac (please see the bug for details): --- public class AnonymousInAnonymous { static void s(I1 i) {} static { s( new I1() { public I2 get() { return new I2() { }; } }); } public static interface I1 { public static class I2 { } public I2 get(); } } --- The reason is that: - -XDfind=lambda will try to replace "new I1() {...}" with a lambda and attribute that -but this will make I2 unresolvable -so Attr.visitNewClass will not (currently) attribute the inside of the "new I2() {}". -so Attr.PostAttrAnalyzer will try to fill in Symbols and Types, but "Attr.PostAttrAnalyzer.dummyMethodType" will dereference MethodTree.restype, which is null for constructors (in this case an automatically generated constructor). A part of the proposed fix is to enhance PostAttrAnalyzer.dummyMethodType to handle constructors. But attributing the body of an unresolvable anonymous class does not seem difficult, and would help API clients like JShell, so the proposed fix is doing that as well. One of the changes to do that also removes follow up errors that appear to be unnecessary (an error has already been reported to the anonymous class' "clazz", so unnecessary to report errors that relate to the anonymous class' constructor). Bug: https://bugs.openjdk.java.net/browse/JDK-8197439 Webrev: http://cr.openjdk.java.net/~jlahoda/8197439/webrev.00/ How does this look? Thanks, Jan From volker.simonis at gmail.com Fri Feb 9 10:51:23 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 9 Feb 2018 11:51:23 +0100 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: Hi Jonathan, that's an interesting proposal. It is just unfortunate that a Java source file starting with "shebang" won't be a legal Java file according to the Java Language Specification. Or do you plan to change the JLS to allow (and ignore) "shebang" in the first line? Thanks, Volker On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the java launcher to support > running a > program supplied as a single file of Java source code. The program will be > compiled > and run, without the need to explicit invoke javac, or to package up a jar > file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 > > -- Jon From jonathan.gibbons at oracle.com Fri Feb 9 18:30:29 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Feb 2018 10:30:29 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <844742E5-4749-438A-A082-D3D8FBBB3440@cinnober.com> References: <5A7CDACB.50103@oracle.com> <844742E5-4749-438A-A082-D3D8FBBB3440@cinnober.com> Message-ID: On 2/9/18 4:32 AM, Lennart B?rjeson wrote: >> 9 feb. 2018 kl. 00:18 skrev Jonathan Gibbons : >> >> This draft JEP contains a proposal to enhance the |java| launcher to >> support running a >> program supplied as a single file of Java source code. The program will >> be compiled >> and run, without the need to explicit invoke javac, or to package up a >> jar file. >> >> For more details, see: >> >> http://openjdk.java.net/jeps/8192920 >> >> -- Jon > Most welcome! > > One comment, though: As a linux/unix user, I'd expect the jshell executable to be the processor for jshell scripts, not the compiler ("java"). This would tie in with the established pattern of other shell script processors/repl, e.g. groovysh, or even plain bash. > > Best regards, > > /Lennart Lennart, The content of a source file supported by this feature is the source code for a normal Java class containing a normal "public static void main(String[])" method.? It is not the same as the input you might give to jshell, which is a combination of "snippets" of Java code and commands for the JShell tool, which are designed for use in an interactive environment. -- Jon From brian.goetz at oracle.com Fri Feb 9 19:06:59 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 9 Feb 2018 14:06:59 -0500 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <844742E5-4749-438A-A082-D3D8FBBB3440@cinnober.com> References: <5A7CDACB.50103@oracle.com> <844742E5-4749-438A-A082-D3D8FBBB3440@cinnober.com> Message-ID: <5eac3bd5-2ddf-97bf-f4d2-4a800b56697e@oracle.com> This is a natural (and common) thought, but it turns out to not be the best answer.? The design of JShell is heavily influenced by the goal of offering a good interactive experience.? When we were first designing JShell, we considered whether we also wanted to ask it to do double-duty as a batch runner (i.e., this was our first thought too), and went through the process of enumerating some of the tradeoffs that would entail -- and concluded that doing so risked compromising the primary (interactive) mission. And, we already have a means of running whole Java programs -- the launcher -- which can already accept its input in multiple forms (single classfile, JAR file, module).? Better to teach it how to accept one more variant input.? New users can run programs with ??? java HelloWorld.java and can later learn that if they want to amortize compilation cost over multiple runs, they can do ??? javac HelloWorld.java ??? java HelloWorld On 2/9/2018 7:32 AM, Lennart B?rjeson wrote: > One comment, though: As a linux/unix user, I'd expect the jshell executable to be the processor for jshell scripts, not the compiler ("java"). This would tie in with the established pattern of other shell script processors/repl, e.g. groovysh, or even plain bash. From jonathan.gibbons at oracle.com Sat Feb 10 16:59:31 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 10 Feb 2018 08:59:31 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: <1217fb22-ae77-4b75-dbe9-6b2bd03dd0ae@oracle.com> Volker, I don't see a compelling need to change the JLS to accommodate "shebang" files. Most Java source files don't need the `#!` line, including any source file passed to an explicit invocation of the Java launcher. The line is only needed when the file is set up to be directly executed by the "shebang" mechanism, in which case the line can be thought of as a "wrapper" supported by the host system to enable such use. If the feature is sufficiently popular, it may even be that editors will recognize and support the use of such lines, in the same way that some editors recognize and support the manipulation of javadoc comments, which are also not defined in the JLS (beyond the basic definition of a comment in JLS 3.7). -- Jon On 2/9/18 2:51 AM, Volker Simonis wrote: > Hi Jonathan, > > that's an interesting proposal. It is just unfortunate that a Java > source file starting with "shebang" won't be a legal Java file > according to the Java Language Specification. Or do you plan to change > the JLS to allow (and ignore) "shebang" in the first line? > > Thanks, > Volker > > On Fri, Feb 9, 2018 at 12:18 AM, Jonathan Gibbons > wrote: >> This draft JEP contains a proposal to enhance the java launcher to support >> running a >> program supplied as a single file of Java source code. The program will be >> compiled >> and run, without the need to explicit invoke javac, or to package up a jar >> file. >> >> For more details, see: >> >> http://openjdk.java.net/jeps/8192920 >> >> -- Jon From magnus.ihse.bursie at oracle.com Mon Feb 12 11:22:41 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Feb 2018 12:22:41 +0100 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: <2ca8b9bd-c10b-911a-362a-17d28460e093@oracle.com> Jon, Looks awesome! :) /Magnus On 2018-02-09 00:18, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the |java| launcher to > support running a > program supplied as a single file of Java source code. The program > will be compiled > and run, without the need to explicit invoke javac, or to package up a > jar file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 > > -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Feb 12 12:43:24 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 12 Feb 2018 13:43:24 +0100 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. Message-ID: <5A818BEC.5010204@oracle.com> Hi, Currently, when a calling some API methods, the client (e.g. TaskListener, an annotation Processor or a JavacTask client) may get a CompletionFailure, if the given Symbol was not completed yet. This is not only problematic for the clients, but if the client catches and ignores the exception, the javac may be unable to report an appropriate error. The proposed patch here: -separates "user " and "javac" modes, in which CompletionFailure handling differs a bit -in javac mode, CompletionFailures should be handled as they are currently -in user (code) mode, when a CompletionFailure is thrown (and would go outside of an API method), the API method will suppress the exception, and the Symbol's state (completer, kind, type) will be restored to original when the mode is switched back to javac mode. If the Symbol is then completed again inside javac, the CompletionFailure is thrown again and the appropriate errors are reported. Bug: https://bugs.openjdk.java.net/browse/JDK-8187950 Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/ How does this look? Thanks, Jan From cushon at google.com Mon Feb 12 18:50:01 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 12 Feb 2018 10:50:01 -0800 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: <5A818BEC.5010204@oracle.com> References: <5A818BEC.5010204@oracle.com> Message-ID: Hi Jan, I've run into the same problem a few times, and made some half-baked experiments around not caching completion failures [1]. The approach you describe sounds good to me. Also, * this will fix JDK-8177436 [2] too * there's a minor typo in the javadoc for DeferredCompletionFailureHandler - "throw the the client code" [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017 -March/010883.html [2] https://bugs.openjdk.java.net/browse/JDK-8177436 On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda wrote: > Hi, > > Currently, when a calling some API methods, the client (e.g. TaskListener, > an annotation Processor or a JavacTask client) may get a CompletionFailure, > if the given Symbol was not completed yet. This is not only problematic for > the clients, but if the client catches and ignores the exception, the javac > may be unable to report an appropriate error. > > The proposed patch here: > -separates "user " and "javac" modes, in which CompletionFailure handling > differs a bit > -in javac mode, CompletionFailures should be handled as they are currently > -in user (code) mode, when a CompletionFailure is thrown (and would go > outside of an API method), the API method will suppress the exception, and > the Symbol's state (completer, kind, type) will be restored to original > when the mode is switched back to javac mode. If the Symbol is then > completed again inside javac, the CompletionFailure is thrown again and the > appropriate errors are reported. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187950 > Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/ > > How does this look? > > Thanks, > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Mon Feb 12 19:43:37 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 12 Feb 2018 13:43:37 -0600 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: On Thu, Feb 8, 2018 at 5:18 PM, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the java launcher to support > running a > program supplied as a single file of Java source code. The program will be > compiled > and run, without the need to explicit invoke javac, or to package up a jar > file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 Sorry if I just missed this somehow, but how would one set the Java source version in use? This seems like it would be necessary in order to ensure forwards-compatibility. Other scripting languages that launch in this way allow for printing (or disabling) compilation warnings, so maybe that should also be a consideration? I assume that the annotation processing pipeline would explicitly be excluded in this mode? Also I'm finding it really hard to avoid saying "Java script". /me slaps self briskly -- - DML From cushon at google.com Mon Feb 12 20:26:12 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 12 Feb 2018 12:26:12 -0800 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: References: <5A818BEC.5010204@oracle.com> Message-ID: Another thing - I think the patch needs to set the deferred completion failure handler before calling processor.init (in the constructor for ProcessorState). I'm seeing unhandled CompletionFailures with stack traces like the following. (I was testing the patch on JDK 9 so the line numbers are a little off.) java.lang.RuntimeException: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for android.view.View not found at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:163) ... Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for android.view.View not found at jdk.compiler/com.sun.tools.javac.code.ClassFinder.newCompletionFailure(ClassFinder.java:386) ... at jdk.compiler/com.sun.tools.javac.model.JavacElements.getTypeElement(JavacElements.java:84) ... at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.(JavacProcessingEnvironment.java:679) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:778) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:873) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2200(JavacProcessingEnvironment.java:110) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1213) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1322) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1225) ... On Mon, Feb 12, 2018 at 10:50 AM, Liam Miller-Cushon wrote: > Hi Jan, > > I've run into the same problem a few times, and made some half-baked > experiments around not caching completion failures [1]. The approach you > describe sounds good to me. Also, > * this will fix JDK-8177436 [2] too > * there's a minor typo in the javadoc for DeferredCompletionFailureHandler > - "throw the the client code" > > [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017 > -March/010883.html > [2] https://bugs.openjdk.java.net/browse/JDK-8177436 > > On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda wrote: > >> Hi, >> >> Currently, when a calling some API methods, the client (e.g. >> TaskListener, an annotation Processor or a JavacTask client) may get a >> CompletionFailure, if the given Symbol was not completed yet. This is not >> only problematic for the clients, but if the client catches and ignores the >> exception, the javac may be unable to report an appropriate error. >> >> The proposed patch here: >> -separates "user " and "javac" modes, in which CompletionFailure handling >> differs a bit >> -in javac mode, CompletionFailures should be handled as they are currently >> -in user (code) mode, when a CompletionFailure is thrown (and would go >> outside of an API method), the API method will suppress the exception, and >> the Symbol's state (completer, kind, type) will be restored to original >> when the mode is switched back to javac mode. If the Symbol is then >> completed again inside javac, the CompletionFailure is thrown again and the >> appropriate errors are reported. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8187950 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/ >> >> How does this look? >> >> Thanks, >> Jan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Feb 12 20:26:42 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Feb 2018 12:26:42 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: <5A81F882.70004@oracle.com> On 02/12/2018 11:43 AM, David Lloyd wrote: > On Thu, Feb 8, 2018 at 5:18 PM, Jonathan Gibbons > wrote: >> This draft JEP contains a proposal to enhance the java launcher to support >> running a >> program supplied as a single file of Java source code. The program will be >> compiled >> and run, without the need to explicit invoke javac, or to package up a jar >> file. >> >> For more details, see: >> >> http://openjdk.java.net/jeps/8192920 > Sorry if I just missed this somehow, but how would one set the Java > source version in use? This seems like it would be necessary in order > to ensure forwards-compatibility. This would only be an issue for shebang files; if you are using the Java launcher explicitly, the source version would be the default version for the Java launcher. For shebang files, it is normal practice to put an absolute pathname for the executable. If you are concerned about long term compatibility, you could use the path for a specific version of JDK. > > Other scripting languages that launch in this way allow for printing > (or disabling) compilation warnings, so maybe that should also be a > consideration? It's an interesting issue that merits discussion. JLS does mandate that warnings should be generated in some circumstances, but allows them to be suppressed with @SuppressWarnings. javac does generate some warnings that cannot be suppressed with @SuppressWarnings, but in all such cases, it is possible to change the source code to avoid the warning without changing the underlying functionality. The bottom line is that it should always be possible to compile a program without warnings, and so there should be no need to provide any extra mechanisms in this area in the Java launcher. > > I assume that the annotation processing pipeline would explicitly be > excluded in this mode? It is not clear to me that there is an inherent need to disable the annotation processing pipeline, but it is true that if it is not disabled, its use would be severely restricted, not least by the inability to specify any custom options for annotation processing. Performing annotation processing would seem to be way beyond the anticipated use cases, and so it may end up being desirable, for simplicity, to disable annotation processing in this mode. The general rule here is, if you need to pass options to the compiler, you should be invoking the compiler directly, in the standard manner. > > Also I'm finding it really hard to avoid saying "Java script". /me > slaps self briskly > From david.lloyd at redhat.com Mon Feb 12 20:59:42 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 12 Feb 2018 14:59:42 -0600 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A81F882.70004@oracle.com> References: <5A7CDACB.50103@oracle.com> <5A81F882.70004@oracle.com> Message-ID: On Mon, Feb 12, 2018 at 2:26 PM, Jonathan Gibbons wrote: > On 02/12/2018 11:43 AM, David Lloyd wrote: >> Sorry if I just missed this somehow, but how would one set the Java >> source version in use? This seems like it would be necessary in order >> to ensure forwards-compatibility. > > This would only be an issue for shebang files; if you are using the Java > launcher explicitly, the source version would be the default version > for the Java launcher. For shebang files, it is normal practice to put > an absolute pathname for the executable. If you are concerned about > long term compatibility, you could use the path for a specific version > of JDK. I don't think you can really assume that specific versions of the JDK will always be present at specific locations on most operating systems and installations. Probably what is going to happen in reality is that there will be scripts out there, and some hapless user will upgrade their OS JDK, and everything will break. I think that specifying a source version will probably be necessary. -- - DML From blackdrag at gmx.org Mon Feb 12 21:19:33 2018 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 12 Feb 2018 22:19:33 +0100 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: <2bbd0b52-3332-3f18-6759-b2190c5348cf@gmx.org> On 09.02.2018 00:18, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the |java| launcher to > support running a > program supplied as a single file of Java source code. The program will > be compiled > and run, without the need to explicit invoke javac, or to package up a > jar file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 Why was -cs (or -checksource) removed then from the java command? bye Jochen From david.lloyd at redhat.com Mon Feb 12 21:37:45 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 12 Feb 2018 15:37:45 -0600 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: On Thu, Feb 8, 2018 at 5:18 PM, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the java launcher to support > running a > program supplied as a single file of Java source code. The program will be > compiled > and run, without the need to explicit invoke javac, or to package up a jar > file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 It was pointed out on IRC that it would seem almost more fitting to fit this in to javax.script as a ScriptEngine, using the existing jrunscript as a launcher instead of java. Weird but also not weird at all! It would be worth explaining why this shouldn't be the case in the JEP (if indeed it shouldn't be the case). -- - DML From aph at redhat.com Tue Feb 13 09:12:24 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Feb 2018 09:12:24 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: There looks like an omission in the proposal. In files launched with a shebang, the first line shouldn't be ignored: it should be parsed as arguments. But the proposal doesn't explicitly say that. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jan.lahoda at oracle.com Tue Feb 13 12:18:03 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 13 Feb 2018 13:18:03 +0100 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: References: <5A818BEC.5010204@oracle.com> Message-ID: <5A82D77B.1040401@oracle.com> On 12.2.2018 21:26, Liam Miller-Cushon wrote: > Another thing - I think the patch needs to set the deferred completion > failure handler before calling processor.init (in the constructor > for ProcessorState). Oops, right. Updated webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01/ Thanks for the feedback, Jan > > I'm seeing unhandled CompletionFailures with stack traces like the > following. (I was testing the patch on JDK 9 so the line numbers are a > little off.) > > java.lang.RuntimeException: > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for > android.view.View not found > at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:163) > ... > Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class file > for android.view.View not found > at > jdk.compiler/com.sun.tools.javac.code.ClassFinder.newCompletionFailure(ClassFinder.java:386) > ... > at > jdk.compiler/com.sun.tools.javac.model.JavacElements.getTypeElement(JavacElements.java:84) > ... > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.(JavacProcessingEnvironment.java:679) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:778) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:873) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2200(JavacProcessingEnvironment.java:110) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1213) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1322) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1225) > ... > > On Mon, Feb 12, 2018 at 10:50 AM, Liam Miller-Cushon > wrote: > > Hi Jan, > > I've run into the same problem a few times, and made some half-baked > experiments around not caching completion failures [1]. The approach > you describe sounds good to me. Also, > * this will fix JDK-8177436 [2] too > * there's a minor typo in the javadoc > for DeferredCompletionFailureHandler - "throw the the client code" > > [1] > http://mail.openjdk.java.net/pipermail/compiler-dev/2017-March/010883.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8177436 > > > On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda > wrote: > > Hi, > > Currently, when a calling some API methods, the client (e.g. > TaskListener, an annotation Processor or a JavacTask client) may > get a CompletionFailure, if the given Symbol was not completed > yet. This is not only problematic for the clients, but if the > client catches and ignores the exception, the javac may be > unable to report an appropriate error. > > The proposed patch here: > -separates "user " and "javac" modes, in which CompletionFailure > handling differs a bit > -in javac mode, CompletionFailures should be handled as they are > currently > -in user (code) mode, when a CompletionFailure is thrown (and > would go outside of an API method), the API method will suppress > the exception, and the Symbol's state (completer, kind, type) > will be restored to original when the mode is switched back to > javac mode. If the Symbol is then completed again inside javac, > the CompletionFailure is thrown again and the appropriate errors > are reported. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187950 > > Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/ > > > How does this look? > > Thanks, > Jan > > > From jan.lahoda at oracle.com Tue Feb 13 12:26:27 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 13 Feb 2018 13:26:27 +0100 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: References: <5A818BEC.5010204@oracle.com> Message-ID: <5A82D973.3040404@oracle.com> On 12.2.2018 19:50, Liam Miller-Cushon wrote: > Hi Jan, > > I've run into the same problem a few times, and made some half-baked > experiments around not caching completion failures [1]. The approach you > describe sounds good to me. Also, Thanks. > * this will fix JDK-8177436 [2] too I double-checked, and it indeed fixes that. > * there's a minor typo in the javadoc > for DeferredCompletionFailureHandler - "throw the the client code" Fixed in the updated webrev. Thanks for the feedback, Jan > > [1] > http://mail.openjdk.java.net/pipermail/compiler-dev/2017-March/010883.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8177436 > > > On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda > wrote: > > Hi, > > Currently, when a calling some API methods, the client (e.g. > TaskListener, an annotation Processor or a JavacTask client) may get > a CompletionFailure, if the given Symbol was not completed yet. This > is not only problematic for the clients, but if the client catches > and ignores the exception, the javac may be unable to report an > appropriate error. > > The proposed patch here: > -separates "user " and "javac" modes, in which CompletionFailure > handling differs a bit > -in javac mode, CompletionFailures should be handled as they are > currently > -in user (code) mode, when a CompletionFailure is thrown (and would > go outside of an API method), the API method will suppress the > exception, and the Symbol's state (completer, kind, type) will be > restored to original when the mode is switched back to javac mode. > If the Symbol is then completed again inside javac, the > CompletionFailure is thrown again and the appropriate errors are > reported. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187950 > > Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/ > > > How does this look? > > Thanks, > Jan > > From david.lloyd at redhat.com Tue Feb 13 13:24:00 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 13 Feb 2018 07:24:00 -0600 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: I think the shell takes care of that bit... though it does seem to pass in the entire argument string as one big argument, so in this case the arguments will have to be re-parsed out of that. On Tue, Feb 13, 2018 at 3:12 AM, Andrew Haley wrote: > There looks like an omission in the proposal. In files launched > with a shebang, the first line shouldn't be ignored: it should be > parsed as arguments. But the proposal doesn't explicitly say that. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- - DML From aph at redhat.com Tue Feb 13 14:48:05 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Feb 2018 14:48:05 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: References: <5A7CDACB.50103@oracle.com> Message-ID: <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> On 13/02/18 13:24, David Lloyd wrote: > I think the shell takes care of that bit... It does, but we do need to say what gets passed. jvm arguments, in particular, would be very useful. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Michael.Rasmussen at roguewave.com Tue Feb 13 16:33:43 2018 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Tue, 13 Feb 2018 16:33:43 +0000 Subject: Class invoking method which exists as default on interface and private on super Message-ID: Hi If I try to invoke a method that has a default implementation on an implementing interface, and a private implementation on the super class, the compilation passes, yet at runtime running the code produces an IllegalAccessError, trying to invoke the private method. In the code below, the first line of Test.run compiles into an invokeinterface, and the second compiles into invokevirtual. (javac from 8u152, 9.0.1 and 10-ea43 all produce that). Running the code (on the Oracle builds listed above) those throws an IllegalAccessError when running the invokeinterface; presumably trying to invoke the private method on C. Similarly, if commenting out the first line, the invokevirtual call fails with a similar IllegalAccessError. For comparison, compiling it with IBM J9 8.0.5.5, it produces the same bytecode, but at runtime, the invokeinterface calls the default interface method, and the invokevirtual call fails with IllegalAccessError. Seeing that the code compiles without warning, yet fails at runtime, I don't know if this should have been a compiler error instead? Or in case this is an issue with the method lookup at runtime, which list would be appropriate to forward this to? Kind regards Michael Rasmussen // -- app1/pkg/C.java package app1.pkg; public class C { private void foo() { System.out.println("C.foo"); } } // -- app1/pkg/I.java package app1.pkg; public interface I { public default void foo() { System.out.println("I.foo"); } } // -- app1/pkg/Test.java package app1.pkg; public class Test extends C implements I { public void run() { ((I)this).foo(); foo(); } public static void main(String[] args) { new Test().run(); } } From jonathan.gibbons at oracle.com Tue Feb 13 17:56:45 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 13 Feb 2018 09:56:45 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> References: <5A7CDACB.50103@oracle.com> <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> Message-ID: <803b44d8-d7bc-8c24-280f-3c90d0e15e25@oracle.com> On 2/13/18 6:48 AM, Andrew Haley wrote: > On 13/02/18 13:24, David Lloyd wrote: >> I think the shell takes care of that bit... > It does, but we do need to say what gets passed. jvm arguments, > in particular, would be very useful. > The problem here is that it seems that shells are inconsistent with how they handle arguments on the first line. This is specifically called out as a portability problem in [1]. That makes it difficult for the main Java launcher to handle these arguments. It would be wrong to make a general change to the Java launcher to reparse arguments containing spaces as individual options. -- Jon [1] https://en.wikipedia.org/wiki/Shebang_(Unix) From aph at redhat.com Tue Feb 13 18:42:23 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Feb 2018 18:42:23 +0000 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <803b44d8-d7bc-8c24-280f-3c90d0e15e25@oracle.com> References: <5A7CDACB.50103@oracle.com> <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> <803b44d8-d7bc-8c24-280f-3c90d0e15e25@oracle.com> Message-ID: <1e1017ef-f595-0d09-310f-2233e4dccd97@redhat.com> On 13/02/18 17:56, Jonathan Gibbons wrote: > > > On 2/13/18 6:48 AM, Andrew Haley wrote: >> On 13/02/18 13:24, David Lloyd wrote: >>> I think the shell takes care of that bit... >> It does, but we do need to say what gets passed. jvm arguments, >> in particular, would be very useful. > > The problem here is that it seems that shells are inconsistent with how > they handle arguments on the first line. This is specifically called out > as a portability problem in [1]. > > That makes it difficult for the main Java launcher to handle these > arguments. It would be wrong to make a general change to the Java > launcher to reparse arguments containing spaces as individual options. OK, I see what you mean. I had thought that Python did this properly, but I just tried it and it doesn't work. Well, it works kinda-sorta but exactly one argument can be passed on the command line. Eww. :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vicente.romero at oracle.com Tue Feb 13 20:49:28 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 13 Feb 2018 15:49:28 -0500 Subject: RFR: JDK 8194892: add compiler support for local-variable syntax for lambda parameters Message-ID: Please review the implementation for JEP 323: Local-Variable Syntax for Lambda Parameters [1]. The specification has been made public at [2]. The current implementation for the spec can be found at [3]. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8193259 [2] http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-February/000268.html [3] http://cr.openjdk.java.net/~vromero/8194892/webrev.00/ From john.r.rose at oracle.com Tue Feb 13 22:37:23 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 13 Feb 2018 14:37:23 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <1e1017ef-f595-0d09-310f-2233e4dccd97@redhat.com> References: <5A7CDACB.50103@oracle.com> <7c6aabbb-3b53-e6c2-86bf-757be4736203@redhat.com> <803b44d8-d7bc-8c24-280f-3c90d0e15e25@oracle.com> <1e1017ef-f595-0d09-310f-2233e4dccd97@redhat.com> Message-ID: On Feb 13, 2018, at 10:42 AM, Andrew Haley wrote: > > OK, I see what you mean. I had thought that Python did this properly, > but I just tried it and it doesn't work. Well, it works kinda-sorta > but exactly one argument can be passed on the command line. Eww. :-) It's not Python's fault! The OS gets in there and launches python with the required arguments. The rules are very narrow. The OS doesn't do command line parsing at that level. See http://man7.org/linux/man-pages/man2/execve.2.html Here's what it says about parsing the shebang line: > A maximum line length of 127 characters is allowed for the first line > in an interpreter script. > > The semantics of the optional-arg argument of an interpreter script > vary across implementations. On Linux, the entire string following > the interpreter name is passed as a single argument to the > interpreter, and this string can include white space. However, > behavior differs on some other systems. Some systems use the first > white space to terminate optional-arg. On some systems, an > interpreter script can have multiple arguments, and white spaces in > optional-arg are used to delimit the arguments. Yum! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Feb 13 23:00:11 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 13 Feb 2018 15:00:11 -0800 Subject: Class invoking method which exists as default on interface and private on super In-Reply-To: References: Message-ID: <5A836DFB.2070705@oracle.com> On 2/13/2018 8:33 AM, Michael Rasmussen wrote: > If I try to invoke a method that has a default implementation on an > implementing interface, and a private implementation on the super > class, the compilation passes, yet at runtime running the code > produces an IllegalAccessError, trying to invoke the private method. You are right to be surprised by this. If code can be compiled together without error, then it should link and execute without error -- that's basically the guarantee from JLS 15.12.4.4. However, as you've seen, a private method in the class hierarchy can throw a spanner in the works. Finessing the JLS guarantee is an open issue, tracked by https://bugs.openjdk.java.net/browse/JDK-8021581. For the rest of this mail, I'll add light commentary to your example. > In the code below, the first line of Test.run compiles into an > invokeinterface, and the second compiles into invokevirtual. (javac > from 8u152, 9.0.1 and 10-ea43 all produce that). As expected. > Running the code (on the Oracle builds listed above) those throws an > IllegalAccessError when running the invokeinterface; presumably > trying to invoke the private method on C. Similarly, if commenting > out the first line, the invokevirtual call fails with a similar > IllegalAccessError. As expected. Taking the calls in reverse order: - For the invokevirtual, the method to be resolved is Test::foo, and the first matching method found is C::foo, and thus resolution fails because C::foo is inaccessible to Test. Nothing more to say. - For the invokeinterface, the method to be resolved is I::foo, and it is resolved successfully. Then, invokeinterface selects the method C::foo (because superclasses are searched before superinterfaces), and fails because C::foo is not public. That's invokeinterface in Java SE 8/9/10. In Java SE 11, we plan to relax its must-be-public check in order to regularize the invoke* instructions and prepare them for further evolution. See https://bugs.openjdk.java.net/browse/JDK-8024806. Under the SE 11 behavior, the private C::foo method would be skipped because it doesn't override the I::foo method which was resolved. invokeinterface would end up selecting the I::foo method for execution, which is apparently what J9 8.0.5.5 does already. While that was a neat prediction of the future by J9, it's not compliant with SE 8. (I'm assuming the 8.0.5.5 version string indicates an implementation of SE 8.) Alex > For comparison, compiling it with IBM J9 8.0.5.5, it produces the > same bytecode, but at runtime, the invokeinterface calls the default > interface method, and the invokevirtual call fails with > IllegalAccessError. > > Seeing that the code compiles without warning, yet fails at runtime, > I don't know if this should have been a compiler error instead? > > Or in case this is an issue with the method lookup at runtime, which > list would be appropriate to forward this to? > > Kind regards Michael Rasmussen > > // -- app1/pkg/C.java package app1.pkg; > > public class C { private void foo() { System.out.println("C.foo"); } > } > > // -- app1/pkg/I.java package app1.pkg; > > public interface I { public default void foo() { > System.out.println("I.foo"); } } > > // -- app1/pkg/Test.java package app1.pkg; > > public class Test extends C implements I { public void run() { > ((I)this).foo(); foo(); } > > public static void main(String[] args) { new Test().run(); } } > From Michael.Rasmussen at roguewave.com Tue Feb 13 23:43:04 2018 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Tue, 13 Feb 2018 23:43:04 +0000 Subject: Class invoking method which exists as default on interface and private on super In-Reply-To: <5A836DFB.2070705@oracle.com> References: , <5A836DFB.2070705@oracle.com> Message-ID: > (I'm assuming the 8.0.5.5 version string indicates an implementation of SE 8.) Yes. SE 8. > - For the invokevirtual, the method to be resolved is Test::foo, and the > first matching method found is C::foo, and thus resolution fails because > C::foo is inaccessible to Test. Nothing more to say. A follow-up question to that. If I change C::foo to be static instead, it still compiles to the same (invokeinterface and invokevirtual). When running, invokeinterface now calls I::foo, but the invokevirtual tries to call the static C::foo, and gets access error because it's private. (tested on 10-ea+43) so the static C::foo is now no longer a valid candidate for invokeinterface, but still is for invokevirtual? /Michael From alex.buckley at oracle.com Wed Feb 14 00:21:02 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 13 Feb 2018 16:21:02 -0800 Subject: Class invoking method which exists as default on interface and private on super In-Reply-To: References: , <5A836DFB.2070705@oracle.com> Message-ID: <5A8380EE.90104@oracle.com> On 2/13/2018 3:43 PM, Michael Rasmussen wrote: >> (I'm assuming the 8.0.5.5 version string indicates an >> implementation of SE 8.) > Yes. SE 8. Good to know, thanks. Of course, no-one from J9 is on this list. >> - For the invokevirtual, the method to be resolved is Test::foo, >> and the first matching method found is C::foo, and thus resolution >> fails because C::foo is inaccessible to Test. Nothing more to say. > > A follow-up question to that. > > If I change C::foo to be static instead, it still compiles to the > same (invokeinterface and invokevirtual). When running, > invokeinterface now calls I::foo, but the invokevirtual tries to call > the static C::foo, and gets access error because it's private. > (tested on 10-ea+43) > > so the static C::foo is now no longer a valid candidate for > invokeinterface, but still is for invokevirtual? Talking about who "calls" who is not precise enough: - For invokeinterface I::foo, invokeinterface resolves the foo method in interface I without issue, then proceeds to select an instance method. Thus, invokeinterface skips the static C::foo in the superclass hierarchy and moves on to the superinterface hierarchy. This is consistent across SE 8/9/10/11 and explained in detail in JVMS ch.6. - OTOH, for invokevirtual Test::foo, invokevirtual can't even get as far as resolving Test::foo. Per JVMS 5.4.3.3, there is no method called foo in Test, and the one in C is rejected for inaccessibility. Alex From cushon at google.com Wed Feb 14 06:52:39 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 13 Feb 2018 22:52:39 -0800 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: <5A82D973.3040404@oracle.com> References: <5A818BEC.5010204@oracle.com> <5A82D973.3040404@oracle.com> Message-ID: I did some more testing and am seeing regressions with a few existing annotation processors. In some cases the processors relied on a completion failure being thrown, and adding explicit checks for error types fixes them. There was another example I'm less sure about, where a compilation that previously failed with a 'class file not found' error now succeeds but the processor sees incorrect information. In the example below the class file for the interface B is missing, and its element kind is reported as CLASS. === L.java class A {} interface B {} class L extends A implements B {} === T.java class T {} === P.java import java.util.Set; import javax.annotation.processing.*; import javax.lang.model.*; import javax.lang.model.element.*; import javax.lang.model.type.*; @SupportedAnnotationTypes("*") public class P extends AbstractProcessor { @Override public SourceVersion getSupportedSourceVersion() { return SourceVersion.latest(); } @Override public boolean process(Set annotations, RoundEnvironment roundEnv) { for (TypeMirror st : processingEnv .getTypeUtils() .directSupertypes(processingEnv.getElementUtils( ).getTypeElement("L").asType())) { System.err.println(st.getKind() + ": " + st); Element te = ((DeclaredType) st).asElement(); System.err.println(" " + te.getKind() + ": " + te); } return false; } } === $ javac *.java && rm B.class # with JDK 10+43 $ javac -fullversion -implicit:none -sourcepath : -processor P T.java javac full version "10+43" DECLARED: A CLASS: A DECLARED: B error: cannot access B class file for B not found Consult the following stack trace for details. com.sun.tools.javac.code.Symbol$CompletionFailure: class file for B not found ... $ echo $? 1 # with http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01/ $ javac -implicit:none -sourcepath : -processor P T.java DECLARED: A CLASS: A DECLARED: B CLASS: B ... $ echo $? 0 On Tue, Feb 13, 2018 at 4:26 AM, Jan Lahoda wrote: > On 12.2.2018 19:50, Liam Miller-Cushon wrote: > >> Hi Jan, >> >> I've run into the same problem a few times, and made some half-baked >> experiments around not caching completion failures [1]. The approach you >> describe sounds good to me. Also, >> > > Thanks. > > * this will fix JDK-8177436 [2] too >> > > I double-checked, and it indeed fixes that. > > * there's a minor typo in the javadoc >> for DeferredCompletionFailureHandler - "throw the the client code" >> > > Fixed in the updated webrev. > > Thanks for the feedback, > Jan > > >> [1] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2017-Mar >> ch/010883.html >> > rch/010883.html> >> [2] https://bugs.openjdk.java.net/browse/JDK-8177436 >> >> >> On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda > > wrote: >> >> Hi, >> >> Currently, when a calling some API methods, the client (e.g. >> TaskListener, an annotation Processor or a JavacTask client) may get >> a CompletionFailure, if the given Symbol was not completed yet. This >> is not only problematic for the clients, but if the client catches >> and ignores the exception, the javac may be unable to report an >> appropriate error. >> >> The proposed patch here: >> -separates "user " and "javac" modes, in which CompletionFailure >> handling differs a bit >> -in javac mode, CompletionFailures should be handled as they are >> currently >> -in user (code) mode, when a CompletionFailure is thrown (and would >> go outside of an API method), the API method will suppress the >> exception, and the Symbol's state (completer, kind, type) will be >> restored to original when the mode is switched back to javac mode. >> If the Symbol is then completed again inside javac, the >> CompletionFailure is thrown again and the appropriate errors are >> reported. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8187950 >> >> Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/ >> >> >> How does this look? >> >> Thanks, >> Jan >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vparfinenko at excelsior-usa.com Wed Feb 14 08:16:29 2018 From: vparfinenko at excelsior-usa.com (Vladimir Parfinenko) Date: Wed, 14 Feb 2018 15:16:29 +0700 Subject: Bug: no line number for invokedynamic Message-ID: Hi all, I think I have found a minor bug. There is no line number information for invokedynamic instructions generated for method handle or lambda function. The problem can be reproduced using the example below and running it like this: $ javac Test.java $ rm A.class $ java Test Exception in thread "main" java.lang.NoClassDefFoundError: A at Test.main(Test.java:6) Caused by: java.lang.ClassNotFoundException: A ... The correct line number for this stack trace element would be 7. The line number table is missing an entry for invokedynamic: Code: stack=2, locals=2, args_size=1 0: invokestatic #2 // Method fortyTwo:()I 3: invokedynamic #3, 0 // InvokeDynamic #0:apply:()Ljava/util/function/Function; 8: invokestatic #4 // Method foo:(ILjava/util/function/Function;)Ljava/lang/Object; 11: astore_1 12: return LineNumberTable: line 6: 0 line 5: 8 line 9: 12 Regards, Vladimir Parfinenko -- Test.java // line 1 public class Test { public static void main(String[] args) { Object res = foo( fortyTwo(), // line 6 A::sqr // line 7 ); } public static Object foo(int x, java.util.function.Function f) { return null; } public static int fortyTwo() { return 42; } } class A { public static int sqr(int x) { return x * x; } } From maurizio.cimadamore at oracle.com Wed Feb 14 10:59:06 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 14 Feb 2018 10:59:06 +0000 Subject: RFR: JDK 8194892: add compiler support for local-variable syntax for lambda parameters In-Reply-To: References: Message-ID: <4c0cda15-2660-b48c-9909-6561c1cab7b3@oracle.com> Looks good; minor quibbles: * Changes in ParserFactory and JavacParser (for adding diagnostic factory) seem unnecessary? * the diagnostic say 'explicitly-typed parameters' which is a term that also appear in the spec, so good! But they say 'implicit parameters' - which is inconsistent both with the other fragment and with the spec. I suggest replacing with 'implicitly-typed' parameters. Would also help to have some snapshot of the new diagnostics being emitted. Cheers Maurizio On 13/02/18 20:49, Vicente Romero wrote: > Please review the implementation for JEP 323: Local-Variable Syntax > for Lambda Parameters [1]. > The specification has been made public at [2]. The current > implementation for the spec can be found at [3]. > > Thanks, > Vicente > > > [1] https://bugs.openjdk.java.net/browse/JDK-8193259 > [2] > http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-February/000268.html > [3] http://cr.openjdk.java.net/~vromero/8194892/webrev.00/ From bsrbnd at gmail.com Wed Feb 14 15:26:46 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 14 Feb 2018 16:26:46 +0100 Subject: Bug: no line number for invokedynamic In-Reply-To: References: Message-ID: The line number is deliberately not emitted for dynamic callsites (but I don't know why?), see below. I hope this helps, Bernard diff -r b3a833c9c6e9 src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java Mon Feb 12 09:12:41 2018 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java Wed Feb 14 16:14:17 2018 +0100 @@ -1649,9 +1649,9 @@ MethodSymbol msym = (MethodSymbol)TreeInfo.symbol(tree.meth); genArgs(tree.args, msym.externalType(types).getParameterTypes()); - if (!msym.isDynamic()) { +// if (!msym.isDynamic()) { code.statBegin(tree.pos); - } +// } result = m.invoke(); } On 14 February 2018 at 09:16, Vladimir Parfinenko wrote: > Hi all, > > I think I have found a minor bug. There is no line number information > for invokedynamic instructions generated for method handle or lambda > function. > > The problem can be reproduced using the example below and running it > like this: > > $ javac Test.java > $ rm A.class > $ java Test > Exception in thread "main" java.lang.NoClassDefFoundError: A > at Test.main(Test.java:6) > Caused by: java.lang.ClassNotFoundException: A > ... > > The correct line number for this stack trace element would be 7. > > The line number table is missing an entry for invokedynamic: > > Code: > stack=2, locals=2, args_size=1 > 0: invokestatic #2 // Method fortyTwo:()I > 3: invokedynamic #3, 0 // InvokeDynamic > #0:apply:()Ljava/util/function/Function; > 8: invokestatic #4 // Method > foo:(ILjava/util/function/Function;)Ljava/lang/Object; > 11: astore_1 > 12: return > LineNumberTable: > line 6: 0 > line 5: 8 > line 9: 12 > > > Regards, > Vladimir Parfinenko > > > > -- Test.java > > // line 1 > public class Test { > public static void main(String[] args) { > Object res = > foo( > fortyTwo(), // line 6 > A::sqr // line 7 > ); > } > > public static Object foo(int x, java.util.function.Function Integer> f) { > return null; > } > > public static int fortyTwo() { > return 42; > } > } > > class A { > public static int sqr(int x) { > return x * x; > } > } > > From vicente.romero at oracle.com Wed Feb 14 15:31:46 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 14 Feb 2018 10:31:46 -0500 Subject: RFR: JDK 8194892: add compiler support for local-variable syntax for lambda parameters In-Reply-To: <4c0cda15-2660-b48c-9909-6561c1cab7b3@oracle.com> References: <4c0cda15-2660-b48c-9909-6561c1cab7b3@oracle.com> Message-ID: <34fee518-6417-f8df-2504-e6dc97fc980f@oracle.com> Hi Maurizio, Thanks for the comments. I have updated the webrev after the modifications you proposed plus the snapshot of the diagnotics: http://cr.openjdk.java.net/~vromero/8194892/webrev.02/ Thanks, Vicente On 02/14/2018 05:59 AM, Maurizio Cimadamore wrote: > Looks good; minor quibbles: > > * Changes in ParserFactory and JavacParser (for adding diagnostic > factory) seem unnecessary? > > * the diagnostic say 'explicitly-typed parameters' which is a term > that also appear in the spec, so good! But they say 'implicit > parameters' - which is inconsistent both with the other fragment and > with the spec. I suggest replacing with 'implicitly-typed' parameters. > > Would also help to have some snapshot of the new diagnostics being > emitted. > > Cheers > Maurizio > > > On 13/02/18 20:49, Vicente Romero wrote: >> Please review the implementation for JEP 323: Local-Variable Syntax >> for Lambda Parameters [1]. >> The specification has been made public at [2]. The current >> implementation for the spec can be found at [3]. >> >> Thanks, >> Vicente >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8193259 >> [2] >> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-February/000268.html >> [3] http://cr.openjdk.java.net/~vromero/8194892/webrev.00/ > From jan.lahoda at oracle.com Wed Feb 14 15:33:59 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 14 Feb 2018 16:33:59 +0100 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: References: <5A818BEC.5010204@oracle.com> <5A82D973.3040404@oracle.com> Message-ID: <5A8456E7.2020707@oracle.com> On 14.2.2018 07:52, Liam Miller-Cushon wrote: > I did some more testing and am seeing regressions with a few existing > annotation processors. In some cases the processors relied on a > completion failure being thrown, and adding explicit checks for error > types fixes them. > > There was another example I'm less sure about, where a compilation that > previously failed with a 'class file not found' error now succeeds but > the processor sees incorrect information. In the example below the class > file for the interface B is missing, and its element kind is reported as > CLASS. One thing I'd like to point out is that this can (AFAIK) happen even now - if the interface B is completed in a way that will throw away the CompletionFailure (e.g. Elements.getTypeElement), then the subsequent code will AFAIK see the same state as this AP sees. So it seemed somewhat acceptable to let the behavior be similar in case where the CompletionFailure would be thrown, esp. since I didn't see a good way to do better. Today, I got an idea that might solve this issue without too much hassle, sketched here: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01-ext/ Will need more testing, but possibly could work. Any opinions/ideas? Thanks for the feedback, Jan > > === L.java > class A {} > interface B {} > class L extends A implements B {} > === T.java > class T {} > === P.java > import java.util.Set; > import javax.annotation.processing.*; > import javax.lang.model.*; > import javax.lang.model.element.*; > import javax.lang.model.type.*; > > @SupportedAnnotationTypes("*") > public class P extends AbstractProcessor { > > @Override > public SourceVersion getSupportedSourceVersion() { > return SourceVersion.latest(); > } > > @Override > public boolean process(Set annotations, > RoundEnvironment roundEnv) { > for (TypeMirror st : > processingEnv > .getTypeUtils() > > .directSupertypes(processingEnv.getElementUtils().getTypeElement("L").asType())) > { > System.err.println(st.getKind() + ": " + st); > Element te = ((DeclaredType) st).asElement(); > System.err.println(" " + te.getKind() + ": " + te); > } > return false; > } > } > === > > $ javac *.java && rm B.class > # with JDK 10+43 > $ javac -fullversion -implicit:none -sourcepath : -processor P T.java > javac full version "10+43" > DECLARED: A > CLASS: A > DECLARED: B > error: cannot access B > class file for B not found > Consult the following stack trace for details. > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for B > not found > ... > $ echo $? > 1 > > # with http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01/ > > $ javac -implicit:none -sourcepath : -processor P T.java > DECLARED: A > CLASS: A > DECLARED: B > CLASS: B > ... > $ echo $? > 0 > > On Tue, Feb 13, 2018 at 4:26 AM, Jan Lahoda > wrote: > > On 12.2.2018 19:50, Liam Miller-Cushon wrote: > > Hi Jan, > > I've run into the same problem a few times, and made some half-baked > experiments around not caching completion failures [1]. The > approach you > describe sounds good to me. Also, > > > Thanks. > > * this will fix JDK-8177436 [2] too > > > I double-checked, and it indeed fixes that. > > * there's a minor typo in the javadoc > for DeferredCompletionFailureHandler - "throw the the client code" > > > Fixed in the updated webrev. > > Thanks for the feedback, > Jan > > > [1] > http://mail.openjdk.java.net/pipermail/compiler-dev/2017-March/010883.html > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8177436 > > > > > On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda > > >> > wrote: > > Hi, > > Currently, when a calling some API methods, the client (e.g. > TaskListener, an annotation Processor or a JavacTask > client) may get > a CompletionFailure, if the given Symbol was not completed > yet. This > is not only problematic for the clients, but if the client > catches > and ignores the exception, the javac may be unable to report an > appropriate error. > > The proposed patch here: > -separates "user " and "javac" modes, in which > CompletionFailure > handling differs a bit > -in javac mode, CompletionFailures should be handled as > they are > currently > -in user (code) mode, when a CompletionFailure is thrown > (and would > go outside of an API method), the API method will suppress the > exception, and the Symbol's state (completer, kind, type) > will be > restored to original when the mode is switched back to > javac mode. > If the Symbol is then completed again inside javac, the > CompletionFailure is thrown again and the appropriate > errors are > reported. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187950 > > > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/ > > > > > How does this look? > > Thanks, > Jan > > > From maurizio.cimadamore at oracle.com Wed Feb 14 15:38:41 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 14 Feb 2018 15:38:41 +0000 Subject: RFR: JDK 8194892: add compiler support for local-variable syntax for lambda parameters In-Reply-To: <34fee518-6417-f8df-2504-e6dc97fc980f@oracle.com> References: <4c0cda15-2660-b48c-9909-6561c1cab7b3@oracle.com> <34fee518-6417-f8df-2504-e6dc97fc980f@oracle.com> Message-ID: <247d32aa-8e1b-7f80-ec37-65982e941963@oracle.com> Looks great, Thanks Maurizio On 14/02/18 15:31, Vicente Romero wrote: > Hi Maurizio, > > Thanks for the comments. I have updated the webrev after the > modifications you proposed plus the snapshot of the diagnotics: > > http://cr.openjdk.java.net/~vromero/8194892/webrev.02/ > > Thanks, > Vicente > > On 02/14/2018 05:59 AM, Maurizio Cimadamore wrote: >> Looks good; minor quibbles: >> >> * Changes in ParserFactory and JavacParser (for adding diagnostic >> factory) seem unnecessary? >> >> * the diagnostic say 'explicitly-typed parameters' which is a term >> that also appear in the spec, so good! But they say 'implicit >> parameters' - which is inconsistent both with the other fragment and >> with the spec. I suggest replacing with 'implicitly-typed' parameters. >> >> Would also help to have some snapshot of the new diagnostics being >> emitted. >> >> Cheers >> Maurizio >> >> >> On 13/02/18 20:49, Vicente Romero wrote: >>> Please review the implementation for JEP 323: Local-Variable Syntax >>> for Lambda Parameters [1]. >>> The specification has been made public at [2]. The current >>> implementation for the spec can be found at [3]. >>> >>> Thanks, >>> Vicente >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8193259 >>> [2] >>> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-February/000268.html >>> [3] http://cr.openjdk.java.net/~vromero/8194892/webrev.00/ >> > From vicente.romero at oracle.com Wed Feb 14 16:31:12 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 14 Feb 2018 11:31:12 -0500 Subject: RFR: JDK 8194892: add compiler support for local-variable syntax for lambda parameters In-Reply-To: <247d32aa-8e1b-7f80-ec37-65982e941963@oracle.com> References: <4c0cda15-2660-b48c-9909-6561c1cab7b3@oracle.com> <34fee518-6417-f8df-2504-e6dc97fc980f@oracle.com> <247d32aa-8e1b-7f80-ec37-65982e941963@oracle.com> Message-ID: <93e244e4-ebbb-aacf-17d1-380325ce6ef9@oracle.com> thanks! Vicente On 02/14/2018 10:38 AM, Maurizio Cimadamore wrote: > Looks great, > Thanks > > Maurizio > > > On 14/02/18 15:31, Vicente Romero wrote: >> Hi Maurizio, >> >> Thanks for the comments. I have updated the webrev after the >> modifications you proposed plus the snapshot of the diagnotics: >> >> http://cr.openjdk.java.net/~vromero/8194892/webrev.02/ >> >> Thanks, >> Vicente >> >> On 02/14/2018 05:59 AM, Maurizio Cimadamore wrote: >>> Looks good; minor quibbles: >>> >>> * Changes in ParserFactory and JavacParser (for adding diagnostic >>> factory) seem unnecessary? >>> >>> * the diagnostic say 'explicitly-typed parameters' which is a term >>> that also appear in the spec, so good! But they say 'implicit >>> parameters' - which is inconsistent both with the other fragment and >>> with the spec. I suggest replacing with 'implicitly-typed' parameters. >>> >>> Would also help to have some snapshot of the new diagnostics being >>> emitted. >>> >>> Cheers >>> Maurizio >>> >>> >>> On 13/02/18 20:49, Vicente Romero wrote: >>>> Please review the implementation for JEP 323: Local-Variable Syntax >>>> for Lambda Parameters [1]. >>>> The specification has been made public at [2]. The current >>>> implementation for the spec can be found at [3]. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8193259 >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-February/000268.html >>>> [3] http://cr.openjdk.java.net/~vromero/8194892/webrev.00/ >>> >> > From cushon at google.com Wed Feb 14 17:04:08 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 14 Feb 2018 09:04:08 -0800 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: <5A8456E7.2020707@oracle.com> References: <5A818BEC.5010204@oracle.com> <5A82D973.3040404@oracle.com> <5A8456E7.2020707@oracle.com> Message-ID: On Wed, Feb 14, 2018 at 7:33 AM, Jan Lahoda wrote: > Today, I got an idea that might solve this issue without too much hassle, > sketched here: > http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01-ext/ > > Will need more testing, but possibly could work. Any opinions/ideas? Thanks - that fixed the first two regressions I saw. I'm not sure whether getKind() was the only instance of this problem, but I'm running more tests and will report back. One thing I'd like to point out is that this can (AFAIK) happen even now - > if the interface B is completed in a way that will throw away the > CompletionFailure (e.g. Elements.getTypeElement), then the subsequent code > will AFAIK see the same state as this AP sees. So it seemed somewhat > acceptable to let the behavior be similar in case where the > CompletionFailure would be thrown, esp. since I didn't see a good way to do > better. > Good point. I guess I've seen more issues around processors catching completion failures and leaving the model in a bad state for other processors (or javac), than around the completion failure itself causing problems. It's important that processors can detect when they're seeing invalid input. If they end up needing to be more vigilant about checking for error types that's a slightly incompatible change. There was some discussion in JDK-8187950 about declaring an exception in the API contract for methods that currently throw completion failures. Did you consider taking that approach, and having the completion failure be rethrown to ensure other processors and javac see it if they try to complete the same symbol? Maybe JDK-8190054 answers that question - it sounds like there's a preference for returning error objects instead of throwing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Feb 14 17:58:32 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 14 Feb 2018 18:58:32 +0100 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: References: <5A818BEC.5010204@oracle.com> <5A82D973.3040404@oracle.com> <5A8456E7.2020707@oracle.com> Message-ID: <5A8478C8.4030306@oracle.com> On 14.2.2018 18:04, Liam Miller-Cushon wrote: > On Wed, Feb 14, 2018 at 7:33 AM, Jan Lahoda > wrote: > > Today, I got an idea that might solve this issue without too much > hassle, sketched here: > http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01-ext/ > > > Will need more testing, but possibly could work. Any opinions/ideas? > > > Thanks - that fixed the first two regressions I saw. I'm not sure > whether getKind() was the only instance of this problem, but I'm running > more tests and will report back. Cool, thanks! > > One thing I'd like to point out is that this can (AFAIK) happen even > now - if the interface B is completed in a way that will throw away > the CompletionFailure (e.g. Elements.getTypeElement), then the > subsequent code will AFAIK see the same state as this AP sees. So it > seemed somewhat acceptable to let the behavior be similar in case > where the CompletionFailure would be thrown, esp. since I didn't see > a good way to do better. > > > Good point. I guess I've seen more issues around processors catching > completion failures and leaving the model in a bad state for other > processors (or javac), than around the completion failure itself causing > problems. It's important that processors can detect when they're seeing > invalid input. If they end up needing to be more vigilant about checking FWIW, in the current state, it is possible to check DeclaredType.asElement().asType().getKind() == TypeKind.ERROR to see if the type's symbol is broken. (I agree it is quite cumbersome.) > for error types that's a slightly incompatible change. AFAIK, doing TypeElement.getSuperclass() may currently lead to several results depending on the exact circumstances: 1) a DECLARED type, that will throw a CompletionFailure (once) at some point if used 2) a DECLARED type that will not throw a CompletionFailure (because it was already thrown) 3) an ERROR type (if the TypeElement originates in the source code, and its superclass is missing) So eliminating any of these is probably a slightly incompatible change (which will need a CSR), but I personally think it is better than having different behaviors. OTOH, I suspect many APs already deal with these in some ways, so eliminating some shouldn't hopefully be that disruptive. > > There was some discussion in JDK-8187950 about declaring an exception in > the API contract for methods that currently throw completion failures. > Did you consider taking that approach, and having the completion failure > be rethrown to ensure other processors and javac see it if they try to > complete the same symbol? Maybe JDK-8190054 answers that question - it > sounds like there's a preference for returning error objects instead of > throwing? I was thinking of that, but I personally: -think the model is cleaner without the exceptions -am not convinced that it would be much simpler if we tried to change the implementation to more consistently throw the exception Thanks for your feedback, Jan From maurizio.cimadamore at oracle.com Wed Feb 14 20:47:46 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 14 Feb 2018 20:47:46 +0000 Subject: Bug: no line number for invokedynamic In-Reply-To: References: Message-ID: <2d1d22d3-c981-a03e-1fc8-6eb19808446a@oracle.com> This comes from here: https://bugs.openjdk.java.net/browse/JDK-8010404 Back when developing JDK 8 - we had a feeling that having the debugger stop at lambda capture sites would be confusing - and so we disabled it. I agree that in the stack trace case this decision seems to backfire a bit. Maurizio On 14/02/18 15:26, B. Blaser wrote: > The line number is deliberately not emitted for dynamic callsites (but > I don't know why?), see below. > I hope this helps, > Bernard > > diff -r b3a833c9c6e9 > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java > Mon Feb 12 09:12:41 2018 +0100 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java > Wed Feb 14 16:14:17 2018 +0100 > @@ -1649,9 +1649,9 @@ > MethodSymbol msym = (MethodSymbol)TreeInfo.symbol(tree.meth); > genArgs(tree.args, > msym.externalType(types).getParameterTypes()); > - if (!msym.isDynamic()) { > +// if (!msym.isDynamic()) { > code.statBegin(tree.pos); > - } > +// } > result = m.invoke(); > } > > > On 14 February 2018 at 09:16, Vladimir Parfinenko > wrote: >> Hi all, >> >> I think I have found a minor bug. There is no line number information >> for invokedynamic instructions generated for method handle or lambda >> function. >> >> The problem can be reproduced using the example below and running it >> like this: >> >> $ javac Test.java >> $ rm A.class >> $ java Test >> Exception in thread "main" java.lang.NoClassDefFoundError: A >> at Test.main(Test.java:6) >> Caused by: java.lang.ClassNotFoundException: A >> ... >> >> The correct line number for this stack trace element would be 7. >> >> The line number table is missing an entry for invokedynamic: >> >> Code: >> stack=2, locals=2, args_size=1 >> 0: invokestatic #2 // Method fortyTwo:()I >> 3: invokedynamic #3, 0 // InvokeDynamic >> #0:apply:()Ljava/util/function/Function; >> 8: invokestatic #4 // Method >> foo:(ILjava/util/function/Function;)Ljava/lang/Object; >> 11: astore_1 >> 12: return >> LineNumberTable: >> line 6: 0 >> line 5: 8 >> line 9: 12 >> >> >> Regards, >> Vladimir Parfinenko >> >> >> >> -- Test.java >> >> // line 1 >> public class Test { >> public static void main(String[] args) { >> Object res = >> foo( >> fortyTwo(), // line 6 >> A::sqr // line 7 >> ); >> } >> >> public static Object foo(int x, java.util.function.Function> Integer> f) { >> return null; >> } >> >> public static int fortyTwo() { >> return 42; >> } >> } >> >> class A { >> public static int sqr(int x) { >> return x * x; >> } >> } >> >> From bsrbnd at gmail.com Wed Feb 14 22:24:49 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 14 Feb 2018 23:24:49 +0100 Subject: Bug: no line number for invokedynamic In-Reply-To: <2d1d22d3-c981-a03e-1fc8-6eb19808446a@oracle.com> References: <2d1d22d3-c981-a03e-1fc8-6eb19808446a@oracle.com> Message-ID: This is also somewhat related to JDK-8019486 associated test which should probably be updated as next if we want to re-enable this feature to have a clean stack trace. Cheers, Bernard diff -r b3a833c9c6e9 test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java --- a/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java Mon Feb 12 09:12:41 2018 +0100 +++ b/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java Wed Feb 14 22:56:43 2018 +0100 @@ -107,6 +107,8 @@ static final int[][] deserializeExpectedLNT = { // {line-number, start-pc}, {05, 0}, //number -> number / 1 + {21, 137}, //number -> number / 1 + {05, 142}, //number -> number / 1 }; static final int[][] lambdaBridgeExpectedLNT = { @@ -123,6 +125,8 @@ static final int[][] callExpectedLNT = { // {line-number, start-pc}, {29, 0}, //number -> number / 1 + {30, 2}, //number -> number / 1 + {29, 7}, //number -> number / 1 {31, 10}, //number -> number / 1 }; On 14 February 2018 at 21:47, Maurizio Cimadamore wrote: > This comes from here: > > https://bugs.openjdk.java.net/browse/JDK-8010404 > > Back when developing JDK 8 - we had a feeling that having the debugger stop > at lambda capture sites would be confusing - and so we disabled it. > > I agree that in the stack trace case this decision seems to backfire a bit. > > Maurizio > > > > On 14/02/18 15:26, B. Blaser wrote: >> >> The line number is deliberately not emitted for dynamic callsites (but >> I don't know why?), see below. >> I hope this helps, >> Bernard >> >> diff -r b3a833c9c6e9 >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >> Mon Feb 12 09:12:41 2018 +0100 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >> Wed Feb 14 16:14:17 2018 +0100 >> @@ -1649,9 +1649,9 @@ >> MethodSymbol msym = (MethodSymbol)TreeInfo.symbol(tree.meth); >> genArgs(tree.args, >> msym.externalType(types).getParameterTypes()); >> - if (!msym.isDynamic()) { >> +// if (!msym.isDynamic()) { >> code.statBegin(tree.pos); >> - } >> +// } >> result = m.invoke(); >> } >> >> >> On 14 February 2018 at 09:16, Vladimir Parfinenko >> wrote: >>> >>> Hi all, >>> >>> I think I have found a minor bug. There is no line number information >>> for invokedynamic instructions generated for method handle or lambda >>> function. >>> >>> The problem can be reproduced using the example below and running it >>> like this: >>> >>> $ javac Test.java >>> $ rm A.class >>> $ java Test >>> Exception in thread "main" java.lang.NoClassDefFoundError: A >>> at Test.main(Test.java:6) >>> Caused by: java.lang.ClassNotFoundException: A >>> ... >>> >>> The correct line number for this stack trace element would be 7. >>> >>> The line number table is missing an entry for invokedynamic: >>> >>> Code: >>> stack=2, locals=2, args_size=1 >>> 0: invokestatic #2 // Method fortyTwo:()I >>> 3: invokedynamic #3, 0 // InvokeDynamic >>> #0:apply:()Ljava/util/function/Function; >>> 8: invokestatic #4 // Method >>> foo:(ILjava/util/function/Function;)Ljava/lang/Object; >>> 11: astore_1 >>> 12: return >>> LineNumberTable: >>> line 6: 0 >>> line 5: 8 >>> line 9: 12 >>> >>> >>> Regards, >>> Vladimir Parfinenko >>> >>> >>> >>> -- Test.java >>> >>> // line 1 >>> public class Test { >>> public static void main(String[] args) { >>> Object res = >>> foo( >>> fortyTwo(), // line 6 >>> A::sqr // line 7 >>> ); >>> } >>> >>> public static Object foo(int x, java.util.function.Function>> Integer> f) { >>> return null; >>> } >>> >>> public static int fortyTwo() { >>> return 42; >>> } >>> } >>> >>> class A { >>> public static int sqr(int x) { >>> return x * x; >>> } >>> } >>> >>> > From vparfinenko at excelsior-usa.com Thu Feb 15 05:29:22 2018 From: vparfinenko at excelsior-usa.com (Vladimir Parfinenko) Date: Thu, 15 Feb 2018 12:29:22 +0700 Subject: Bug: no line number for invokedynamic References: <2d1d22d3-c981-a03e-1fc8-6eb19808446a@oracle.com> Message-ID: Precision of stack traces is more important for me. However I see the original motivation of this "feature" now. Thank you. Regards, Vladimir Parfinenko -----Original Message----- From: B. Blaser [mailto:bsrbnd at gmail.com] Sent: Thursday, February 15, 2018 5:25 AM This is also somewhat related to JDK-8019486 associated test which should probably be updated as next if we want to re-enable this feature to have a clean stack trace. Cheers, Bernard diff -r b3a833c9c6e9 test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java --- a/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java Mon Feb 12 09:12:41 2018 +0100 +++ b/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java Wed Feb 14 22:56:43 2018 +0100 @@ -107,6 +107,8 @@ static final int[][] deserializeExpectedLNT = { // {line-number, start-pc}, {05, 0}, //number -> number / 1 + {21, 137}, //number -> number / 1 + {05, 142}, //number -> number / 1 }; static final int[][] lambdaBridgeExpectedLNT = { @@ -123,6 +125,8 @@ static final int[][] callExpectedLNT = { // {line-number, start-pc}, {29, 0}, //number -> number / 1 + {30, 2}, //number -> number / 1 + {29, 7}, //number -> number / 1 {31, 10}, //number -> number / 1 }; On 14 February 2018 at 21:47, Maurizio Cimadamore wrote: > This comes from here: > > https://bugs.openjdk.java.net/browse/JDK-8010404 > > Back when developing JDK 8 - we had a feeling that having the debugger stop > at lambda capture sites would be confusing - and so we disabled it. > > I agree that in the stack trace case this decision seems to backfire a bit. > > Maurizio > > > > On 14/02/18 15:26, B. Blaser wrote: >> >> The line number is deliberately not emitted for dynamic callsites (but >> I don't know why?), see below. >> I hope this helps, >> Bernard >> >> diff -r b3a833c9c6e9 >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >> Mon Feb 12 09:12:41 2018 +0100 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >> Wed Feb 14 16:14:17 2018 +0100 >> @@ -1649,9 +1649,9 @@ >> MethodSymbol msym = (MethodSymbol)TreeInfo.symbol(tree.meth); >> genArgs(tree.args, >> msym.externalType(types).getParameterTypes()); >> - if (!msym.isDynamic()) { >> +// if (!msym.isDynamic()) { >> code.statBegin(tree.pos); >> - } >> +// } >> result = m.invoke(); >> } >> >> >> On 14 February 2018 at 09:16, Vladimir Parfinenko >> wrote: >>> >>> Hi all, >>> >>> I think I have found a minor bug. There is no line number information >>> for invokedynamic instructions generated for method handle or lambda >>> function. >>> >>> The problem can be reproduced using the example below and running it >>> like this: >>> >>> $ javac Test.java >>> $ rm A.class >>> $ java Test >>> Exception in thread "main" java.lang.NoClassDefFoundError: A >>> at Test.main(Test.java:6) >>> Caused by: java.lang.ClassNotFoundException: A >>> ... >>> >>> The correct line number for this stack trace element would be 7. >>> >>> The line number table is missing an entry for invokedynamic: >>> >>> Code: >>> stack=2, locals=2, args_size=1 >>> 0: invokestatic #2 // Method fortyTwo:()I >>> 3: invokedynamic #3, 0 // InvokeDynamic >>> #0:apply:()Ljava/util/function/Function; >>> 8: invokestatic #4 // Method >>> foo:(ILjava/util/function/Function;)Ljava/lang/Object; >>> 11: astore_1 >>> 12: return >>> LineNumberTable: >>> line 6: 0 >>> line 5: 8 >>> line 9: 12 >>> >>> >>> Regards, >>> Vladimir Parfinenko >>> >>> >>> >>> -- Test.java >>> >>> // line 1 >>> public class Test { >>> public static void main(String[] args) { >>> Object res = >>> foo( >>> fortyTwo(), // line 6 >>> A::sqr // line 7 >>> ); >>> } >>> >>> public static Object foo(int x, java.util.function.Function>> Integer> f) { >>> return null; >>> } >>> >>> public static int fortyTwo() { >>> return 42; >>> } >>> } >>> >>> class A { >>> public static int sqr(int x) { >>> return x * x; >>> } >>> } >>> >>> > From vicente.romero at oracle.com Thu Feb 15 17:19:08 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 15 Feb 2018 12:19:08 -0500 Subject: Bug: no line number for invokedynamic In-Reply-To: References: <2d1d22d3-c981-a03e-1fc8-6eb19808446a@oracle.com> Message-ID: <8ed9468e-e211-792d-aa1a-b8219ae15ff6@oracle.com> On 02/14/2018 05:24 PM, B. Blaser wrote: > This is also somewhat related to JDK-8019486 associated test which > should probably be updated as next if we want to re-enable this > feature to have a clean stack trace. right if we were introduce any change in this area the test below would start failing > > Cheers, > Bernard Vicente > > > diff -r b3a833c9c6e9 > test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java > --- a/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java > Mon Feb 12 09:12:41 2018 +0100 > +++ b/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java > Wed Feb 14 22:56:43 2018 +0100 > @@ -107,6 +107,8 @@ > static final int[][] deserializeExpectedLNT = { > // {line-number, start-pc}, > {05, 0}, //number -> number / 1 > + {21, 137}, //number -> number / 1 > + {05, 142}, //number -> number / 1 > }; > > static final int[][] lambdaBridgeExpectedLNT = { > @@ -123,6 +125,8 @@ > static final int[][] callExpectedLNT = { > // {line-number, start-pc}, > {29, 0}, //number -> number / 1 > + {30, 2}, //number -> number / 1 > + {29, 7}, //number -> number / 1 > {31, 10}, //number -> number / 1 > }; > > > On 14 February 2018 at 21:47, Maurizio Cimadamore > wrote: >> This comes from here: >> >> https://bugs.openjdk.java.net/browse/JDK-8010404 >> >> Back when developing JDK 8 - we had a feeling that having the debugger stop >> at lambda capture sites would be confusing - and so we disabled it. >> >> I agree that in the stack trace case this decision seems to backfire a bit. >> >> Maurizio >> >> >> >> On 14/02/18 15:26, B. Blaser wrote: >>> The line number is deliberately not emitted for dynamic callsites (but >>> I don't know why?), see below. >>> I hope this helps, >>> Bernard >>> >>> diff -r b3a833c9c6e9 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>> Mon Feb 12 09:12:41 2018 +0100 >>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>> Wed Feb 14 16:14:17 2018 +0100 >>> @@ -1649,9 +1649,9 @@ >>> MethodSymbol msym = (MethodSymbol)TreeInfo.symbol(tree.meth); >>> genArgs(tree.args, >>> msym.externalType(types).getParameterTypes()); >>> - if (!msym.isDynamic()) { >>> +// if (!msym.isDynamic()) { >>> code.statBegin(tree.pos); >>> - } >>> +// } >>> result = m.invoke(); >>> } >>> >>> >>> On 14 February 2018 at 09:16, Vladimir Parfinenko >>> wrote: >>>> Hi all, >>>> >>>> I think I have found a minor bug. There is no line number information >>>> for invokedynamic instructions generated for method handle or lambda >>>> function. >>>> >>>> The problem can be reproduced using the example below and running it >>>> like this: >>>> >>>> $ javac Test.java >>>> $ rm A.class >>>> $ java Test >>>> Exception in thread "main" java.lang.NoClassDefFoundError: A >>>> at Test.main(Test.java:6) >>>> Caused by: java.lang.ClassNotFoundException: A >>>> ... >>>> >>>> The correct line number for this stack trace element would be 7. >>>> >>>> The line number table is missing an entry for invokedynamic: >>>> >>>> Code: >>>> stack=2, locals=2, args_size=1 >>>> 0: invokestatic #2 // Method fortyTwo:()I >>>> 3: invokedynamic #3, 0 // InvokeDynamic >>>> #0:apply:()Ljava/util/function/Function; >>>> 8: invokestatic #4 // Method >>>> foo:(ILjava/util/function/Function;)Ljava/lang/Object; >>>> 11: astore_1 >>>> 12: return >>>> LineNumberTable: >>>> line 6: 0 >>>> line 5: 8 >>>> line 9: 12 >>>> >>>> >>>> Regards, >>>> Vladimir Parfinenko >>>> >>>> >>>> >>>> -- Test.java >>>> >>>> // line 1 >>>> public class Test { >>>> public static void main(String[] args) { >>>> Object res = >>>> foo( >>>> fortyTwo(), // line 6 >>>> A::sqr // line 7 >>>> ); >>>> } >>>> >>>> public static Object foo(int x, java.util.function.Function>>> Integer> f) { >>>> return null; >>>> } >>>> >>>> public static int fortyTwo() { >>>> return 42; >>>> } >>>> } >>>> >>>> class A { >>>> public static int sqr(int x) { >>>> return x * x; >>>> } >>>> } >>>> >>>> From daniel.smith at oracle.com Thu Feb 15 20:16:04 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 15 Feb 2018 13:16:04 -0700 Subject: Final field update in unreachable for loop update section In-Reply-To: References: Message-ID: <453EE1A6-308B-43C0-A163-7F02FAA29698@oracle.com> Thanks for the interesting test case. You're pushing on this part of the language spec: https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.12 https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.13 > On Feb 7, 2018, at 7:49 PM, Tagir Valeev wrote: > > public class Sample1 { > final int x; > > Sample1() { > for(;;x=1) { > x=2; > break; > } > } > } An error should only occur if 'x' is assigned to where it is definitely unassigned ("DU"). The rules say that: - x is DU before the for loop - x is DU after the (empty) initialization - assuming x is DU before the (empty) condition: - x is DU before the loop body* - x is DU after the 'break' (because this is unreachable) - x is DU after the loop body - thus, x is DU before the (empty) condition - x is DU before 'x=2' - x is DU after the 'break' - x is DU after the loop body - x is DU before the incrementation statement - x is DU before 'x=1' (*The connection between the start of the condition and the start of the loop body is a little confusing in the spec, because when the condition is empty, it refers to the initialization instead. But you get the same answer either way.) So, the compiler is wrong: there is no error in Sample1. > public class Sample2 { > final int x; > > Sample2() { > x=2; > for(;;x=1) { > break; > } > } > } No error here, which is fine. 'x=1' is unreachable, so it doesn't matter that it performs an assignment. (You get the same behavior if you do 'if (false) x = 1'.) ?Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Feb 15 20:39:04 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 15 Feb 2018 15:39:04 -0500 Subject: Final field update in unreachable for loop update section In-Reply-To: <453EE1A6-308B-43C0-A163-7F02FAA29698@oracle.com> References: <453EE1A6-308B-43C0-A163-7F02FAA29698@oracle.com> Message-ID: <843a3a5f-6b5e-8e40-de86-a3fb45a1b790@oracle.com> Thanks Dan for evaluating this one, certainly this set of rules is tricky to follow. I have created bug [1] to track this issue, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8198245 On 02/15/2018 03:16 PM, Dan Smith wrote: > Thanks for the interesting test case. > > You're pushing on this part of the language spec: > https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.12 > > https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.13 > >> On Feb 7, 2018, at 7:49 PM, Tagir Valeev > > wrote: >> >> public class Sample1 { >> ?final int x; >> >> ?Sample1() { >> ???for(;;x=1) { >> ?????x=2; >> ?????break; >> ???} >> ?} >> } > > An error should only occur if 'x' is assigned to where it is > definitely unassigned ("DU"). > > The rules say that: > > - x is DU before the for loop > > - x is DU after the (empty) initialization > > - assuming x is DU before the (empty) condition: > - x is DU before the loop body* > - x is DU after the 'break' (because this is unreachable) > - x is DU after the loop body > > - thus, x is DU before the (empty) condition > > - x is DU before 'x=2' > > - x is DU after the 'break' > > - x is DU after the loop body > > - x is DU before the incrementation statement > > - x is DU before 'x=1' > > (*The connection between the start of the condition and the start of > the loop body is a little confusing in the spec, because when the > condition is empty, it refers to the initialization instead. But you > get the same answer either way.) > > So, the compiler is wrong: there is no error in Sample1. > >> public class Sample2 { >> ?final int x; >> >> ?Sample2() { >> ???x=2; >> ???for(;;x=1) { >> ?????break; >> ???} >> ?} >> } > > No error here, which is fine. 'x=1' is unreachable, so it doesn't > matter that it performs an assignment. > > (You get the same behavior if you do 'if (false) x = 1'.) > > ?Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Fri Feb 16 10:26:06 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 16 Feb 2018 17:26:06 +0700 Subject: Final field update in unreachable for loop update section In-Reply-To: <843a3a5f-6b5e-8e40-de86-a3fb45a1b790@oracle.com> References: <453EE1A6-308B-43C0-A163-7F02FAA29698@oracle.com> <843a3a5f-6b5e-8e40-de86-a3fb45a1b790@oracle.com> Message-ID: Hello! Thank you for investigating this. On a second look the javac behavior looks somewhat logical. The for loop execution looks like this: /-----------------------------> (next statement) | initialization --> condition --> body -X-> incrementation ^ | \-----------------------/ Having a "break" statement we removed an edge marked with X. However there's still an "incrementation->condition->body" chain, even though the incrementation is unreachable. So javac likely goes along this path and finds that "x=2" (body) is possible after "x=1" (increment). To my understanding, usually spec works like this: unreachable statements are still analyzed. The x is not DU after increment, thus it should not be DU before empty condition, thus it should not be DU before body. 16.2.12 says: V is definitely unassigned before the condition part of the for statement iff all of the following are true: - V is definitely unassigned after the initialization part of the for statement. - Assuming V is definitely unassigned before the condition part of the for statement, V is definitely unassigned after the contained statement. - Assuming V is definitely unassigned before the contained statement, V is definitely unassigned before every continue statement for which the for statement is the continue target. This would be perfectly logical were condition part executed either after initialization or after body (or continue statement within the body). However actually it's executed either after initialization or after the incrementation. Probably this part should be reformulated in the following way: V is definitely unassigned before the condition part of the for statement iff all of the following are true: - V is definitely unassigned after the initialization part of the for statement. - Assuming V is definitely unassigned before the condition part of the for statement, V is definitely unassigned after the incrementation part. This way it would be aligned with javac implementation and sound more logical. Am I missing something? Regards, Tagir Valeev. On Fri, Feb 16, 2018 at 3:39 AM, Vicente Romero wrote: > Thanks Dan for evaluating this one, certainly this set of rules is tricky > to follow. I have created bug [1] to track this issue, > > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8198245 > > > On 02/15/2018 03:16 PM, Dan Smith wrote: > > Thanks for the interesting test case. > > You're pushing on this part of the language spec: > https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.12 > > https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.13 > > On Feb 7, 2018, at 7:49 PM, Tagir Valeev wrote: > > public class Sample1 { > final int x; > > Sample1() { > for(;;x=1) { > x=2; > break; > } > } > } > > > An error should only occur if 'x' is assigned to where it is definitely > unassigned ("DU"). > > The rules say that: > > - x is DU before the for loop > > - x is DU after the (empty) initialization > > - assuming x is DU before the (empty) condition: > - x is DU before the loop body* > - x is DU after the 'break' (because this is unreachable) > - x is DU after the loop body > > - thus, x is DU before the (empty) condition > > - x is DU before 'x=2' > > - x is DU after the 'break' > > - x is DU after the loop body > > - x is DU before the incrementation statement > > - x is DU before 'x=1' > > (*The connection between the start of the condition and the start of the > loop body is a little confusing in the spec, because when the condition is > empty, it refers to the initialization instead. But you get the same answer > either way.) > > So, the compiler is wrong: there is no error in Sample1. > > public class Sample2 { > final int x; > > Sample2() { > x=2; > for(;;x=1) { > break; > } > } > } > > > No error here, which is fine. 'x=1' is unreachable, so it doesn't matter > that it performs an assignment. > > (You get the same behavior if you do 'if (false) x = 1'.) > > ?Dan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Fri Feb 16 11:43:58 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 16 Feb 2018 12:43:58 +0100 Subject: Bug: no line number for invokedynamic In-Reply-To: <8ed9468e-e211-792d-aa1a-b8219ae15ff6@oracle.com> References: <2d1d22d3-c981-a03e-1fc8-6eb19808446a@oracle.com> <8ed9468e-e211-792d-aa1a-b8219ae15ff6@oracle.com> Message-ID: On 15 February 2018 at 18:19, Vicente Romero wrote: > > > On 02/14/2018 05:24 PM, B. Blaser wrote: >> >> This is also somewhat related to JDK-8019486 associated test which >> should probably be updated as next if we want to re-enable this >> feature to have a clean stack trace. > > > right if we were introduce any change in this area the test below would > start failing I tried some stepping with 'jdb' on the examples present in this test case with the patch I suggested two days ago: - if (!msym.isDynamic()) { +// if (!msym.isDynamic()) { code.statBegin(tree.pos); - } +// } It appeared to me smooth enough and the stack trace for the initial example is right (line 7 instead of 6). Are we going in this direction? Is there any open JBS issue for that? Bernard > >> >> Cheers, >> Bernard > > > Vicente > > >> >> >> diff -r b3a833c9c6e9 >> test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >> --- a/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >> Mon Feb 12 09:12:41 2018 +0100 >> +++ b/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >> Wed Feb 14 22:56:43 2018 +0100 >> @@ -107,6 +107,8 @@ >> static final int[][] deserializeExpectedLNT = { >> // {line-number, start-pc}, >> {05, 0}, //number -> number / 1 >> + {21, 137}, //number -> number / 1 >> + {05, 142}, //number -> number / 1 >> }; >> >> static final int[][] lambdaBridgeExpectedLNT = { >> @@ -123,6 +125,8 @@ >> static final int[][] callExpectedLNT = { >> // {line-number, start-pc}, >> {29, 0}, //number -> number / 1 >> + {30, 2}, //number -> number / 1 >> + {29, 7}, //number -> number / 1 >> {31, 10}, //number -> number / 1 >> }; >> >> >> On 14 February 2018 at 21:47, Maurizio Cimadamore >> wrote: >>> >>> This comes from here: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8010404 >>> >>> Back when developing JDK 8 - we had a feeling that having the debugger >>> stop >>> at lambda capture sites would be confusing - and so we disabled it. >>> >>> I agree that in the stack trace case this decision seems to backfire a >>> bit. >>> >>> Maurizio >>> >>> >>> >>> On 14/02/18 15:26, B. Blaser wrote: >>>> >>>> The line number is deliberately not emitted for dynamic callsites (but >>>> I don't know why?), see below. >>>> I hope this helps, >>>> Bernard >>>> >>>> diff -r b3a833c9c6e9 >>>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>> Mon Feb 12 09:12:41 2018 +0100 >>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>> Wed Feb 14 16:14:17 2018 +0100 >>>> @@ -1649,9 +1649,9 @@ >>>> MethodSymbol msym = (MethodSymbol)TreeInfo.symbol(tree.meth); >>>> genArgs(tree.args, >>>> msym.externalType(types).getParameterTypes()); >>>> - if (!msym.isDynamic()) { >>>> +// if (!msym.isDynamic()) { >>>> code.statBegin(tree.pos); >>>> - } >>>> +// } >>>> result = m.invoke(); >>>> } >>>> >>>> >>>> On 14 February 2018 at 09:16, Vladimir Parfinenko >>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I think I have found a minor bug. There is no line number information >>>>> for invokedynamic instructions generated for method handle or lambda >>>>> function. >>>>> >>>>> The problem can be reproduced using the example below and running it >>>>> like this: >>>>> >>>>> $ javac Test.java >>>>> $ rm A.class >>>>> $ java Test >>>>> Exception in thread "main" java.lang.NoClassDefFoundError: A >>>>> at Test.main(Test.java:6) >>>>> Caused by: java.lang.ClassNotFoundException: A >>>>> ... >>>>> >>>>> The correct line number for this stack trace element would be 7. >>>>> >>>>> The line number table is missing an entry for invokedynamic: >>>>> >>>>> Code: >>>>> stack=2, locals=2, args_size=1 >>>>> 0: invokestatic #2 // Method fortyTwo:()I >>>>> 3: invokedynamic #3, 0 // InvokeDynamic >>>>> #0:apply:()Ljava/util/function/Function; >>>>> 8: invokestatic #4 // Method >>>>> foo:(ILjava/util/function/Function;)Ljava/lang/Object; >>>>> 11: astore_1 >>>>> 12: return >>>>> LineNumberTable: >>>>> line 6: 0 >>>>> line 5: 8 >>>>> line 9: 12 >>>>> >>>>> >>>>> Regards, >>>>> Vladimir Parfinenko >>>>> >>>>> >>>>> >>>>> -- Test.java >>>>> >>>>> // line 1 >>>>> public class Test { >>>>> public static void main(String[] args) { >>>>> Object res = >>>>> foo( >>>>> fortyTwo(), // line 6 >>>>> A::sqr // line 7 >>>>> ); >>>>> } >>>>> >>>>> public static Object foo(int x, >>>>> java.util.function.Function>>>> Integer> f) { >>>>> return null; >>>>> } >>>>> >>>>> public static int fortyTwo() { >>>>> return 42; >>>>> } >>>>> } >>>>> >>>>> class A { >>>>> public static int sqr(int x) { >>>>> return x * x; >>>>> } >>>>> } >>>>> >>>>> > From vicente.romero at oracle.com Fri Feb 16 14:45:44 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 16 Feb 2018 09:45:44 -0500 Subject: Final field update in unreachable for loop update section In-Reply-To: References: <453EE1A6-308B-43C0-A163-7F02FAA29698@oracle.com> <843a3a5f-6b5e-8e40-de86-a3fb45a1b790@oracle.com> Message-ID: Hi Tagir, What you are saying is very sensible. We were discussing yesterday about this same thing internally, as you observed javac and the spec are not sync in this area. We will get back to you later, thanks for the discussion, Vicente On 02/16/2018 05:26 AM, Tagir Valeev wrote: > Hello! Thank you for investigating this. On a second look the javac > behavior looks somewhat logical. > The for loop execution looks like this: > > > ?/-----------------------------> (next statement) > ? ? ? ? ? ? ? ? ? ? ? ?| > initialization --> condition --> body -X-> incrementation > ? ? ? ? ? ? ? ? ? ? ? ?^ ? ? ? ? ? ? ? ? ? ? ?| > ?\-----------------------/ > > Having a "break" statement we removed an edge marked with X. However > there's still an "incrementation->condition->body" chain, even though > the incrementation is unreachable. So javac likely goes along this > path and finds that "x=2" (body) is possible after "x=1" (increment). > To my understanding, usually spec works like this: unreachable > statements are still analyzed. The x is not DU?after increment, thus > it should not be DU before empty condition, thus it should not be DU > before body. 16.2.12 says: > > Vis definitely unassigned before the condition part of > the|for|statement iff all of the following are true: > > * > > Vis definitely unassigned after the initialization part of > the|for|statement. > > * > > AssumingVis definitely unassigned before the condition part of > the|for|statement,Vis definitely unassigned after the contained > statement. > > * > > AssumingVis definitely unassigned before the contained > statement,Vis definitely unassigned before > every|continue|statement for which the|for|statement is the > continue target. > > > This would be perfectly logical were condition part executed either > after initialization or after body (or continue statement within the > body). However actually it's executed either after initialization or > after the incrementation. Probably this part should be reformulated in > the following way: > > Vis definitely unassigned before the condition part of > the|for|statement iff all of the following are true: > > * > > Vis definitely unassigned after the initialization part of > the|for|statement. > > * > > AssumingVis definitely unassigned before the condition part of > the|for|statement,Vis definitely unassigned after the > incrementation part. > > This way it would be aligned with javac implementation and sound more > logical. > > Am I missing something? > > Regards, > Tagir Valeev. > > On Fri, Feb 16, 2018 at 3:39 AM, Vicente Romero > > wrote: > > Thanks Dan for evaluating this one, certainly this set of rules is > tricky to follow. I have created bug [1] to track this issue, > > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8198245 > > > > On 02/15/2018 03:16 PM, Dan Smith wrote: >> Thanks for the interesting test case. >> >> You're pushing on this part of the language spec: >> https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.12 >> >> https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.13 >> >> >>> On Feb 7, 2018, at 7:49 PM, Tagir Valeev >> > wrote: >>> >>> public class Sample1 { >>> ?final int x; >>> >>> ?Sample1() { >>> ???for(;;x=1) { >>> ?????x=2; >>> ?????break; >>> ???} >>> ?} >>> } >> >> An error should only occur if 'x' is assigned to where it is >> definitely unassigned ("DU"). >> >> The rules say that: >> >> - x is DU before the for loop >> >> - x is DU after the (empty) initialization >> >> - assuming x is DU before the (empty) condition: >> - x is DU before the loop body* >> - x is DU after the 'break' (because this is unreachable) >> - x is DU after the loop body >> >> - thus, x is DU before the (empty) condition >> >> - x is DU before 'x=2' >> >> - x is DU after the 'break' >> >> - x is DU after the loop body >> >> - x is DU before the incrementation statement >> >> - x is DU before 'x=1' >> >> (*The connection between the start of the condition and the start >> of the loop body is a little confusing in the spec, because when >> the condition is empty, it refers to the initialization instead. >> But you get the same answer either way.) >> >> So, the compiler is wrong: there is no error in Sample1. >> >>> public class Sample2 { >>> ?final int x; >>> >>> ?Sample2() { >>> ???x=2; >>> ???for(;;x=1) { >>> ?????break; >>> ???} >>> ?} >>> } >> >> No error here, which is fine. 'x=1' is unreachable, so it doesn't >> matter that it performs an assignment. >> >> (You get the same behavior if you do 'if (false) x = 1'.) >> >> ?Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Fri Feb 16 19:20:00 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 16 Feb 2018 12:20:00 -0700 Subject: Final field update in unreachable for loop update section In-Reply-To: References: <453EE1A6-308B-43C0-A163-7F02FAA29698@oracle.com> <843a3a5f-6b5e-8e40-de86-a3fb45a1b790@oracle.com> Message-ID: <14304DD1-B844-42B0-862F-3126C036395F@oracle.com> Yep, I came to the same conclusion independently. Glad you landed there, too! There's an old spec bug I was looking at that raised this issue, too. https://bugs.openjdk.java.net/browse/JDK-4660984 I've closed the javac bug, and proposed some spec changes in JDK-4660984. ?Dan > On Feb 16, 2018, at 3:26 AM, Tagir Valeev wrote: > > Hello! Thank you for investigating this. On a second look the javac behavior looks somewhat logical. > The for loop execution looks like this: > > > /-----------------------------> (next statement) > | > initialization --> condition --> body -X-> incrementation > ^ | > \-----------------------/ > > Having a "break" statement we removed an edge marked with X. However there's still an "incrementation->condition->body" chain, even though the incrementation is unreachable. So javac likely goes along this path and finds that "x=2" (body) is possible after "x=1" (increment). To my understanding, usually spec works like this: unreachable statements are still analyzed. The x is not DU after increment, thus it should not be DU before empty condition, thus it should not be DU before body. 16.2.12 says: > > V is definitely unassigned before the condition part of the for statement iff all of the following are true: > > <>V is definitely unassigned after the initialization part of the for statement. > > <>Assuming V is definitely unassigned before the condition part of the for statement, V is definitely unassigned after the contained statement. > > <>Assuming V is definitely unassigned before the contained statement, V is definitely unassigned before every continue statement for which the for statement is the continue target. > > > This would be perfectly logical were condition part executed either after initialization or after body (or continue statement within the body). However actually it's executed either after initialization or after the incrementation. Probably this part should be reformulated in the following way: > > V is definitely unassigned before the condition part of the for statement iff all of the following are true: > > <>V is definitely unassigned after the initialization part of the for statement. > > <>Assuming V is definitely unassigned before the condition part of the for statement, V is definitely unassigned after the incrementation part. > > This way it would be aligned with javac implementation and sound more logical. > > Am I missing something? > > Regards, > Tagir Valeev. > > On Fri, Feb 16, 2018 at 3:39 AM, Vicente Romero > wrote: > Thanks Dan for evaluating this one, certainly this set of rules is tricky to follow. I have created bug [1] to track this issue, > > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8198245 > > > On 02/15/2018 03:16 PM, Dan Smith wrote: >> Thanks for the interesting test case. >> >> You're pushing on this part of the language spec: >> https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.12 >> https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.13 >> >>> On Feb 7, 2018, at 7:49 PM, Tagir Valeev > wrote: >>> >>> public class Sample1 { >>> final int x; >>> >>> Sample1() { >>> for(;;x=1) { >>> x=2; >>> break; >>> } >>> } >>> } >> >> >> An error should only occur if 'x' is assigned to where it is definitely unassigned ("DU"). >> >> The rules say that: >> >> - x is DU before the for loop >> >> - x is DU after the (empty) initialization >> >> - assuming x is DU before the (empty) condition: >> - x is DU before the loop body* >> - x is DU after the 'break' (because this is unreachable) >> - x is DU after the loop body >> >> - thus, x is DU before the (empty) condition >> >> - x is DU before 'x=2' >> >> - x is DU after the 'break' >> >> - x is DU after the loop body >> >> - x is DU before the incrementation statement >> >> - x is DU before 'x=1' >> >> (*The connection between the start of the condition and the start of the loop body is a little confusing in the spec, because when the condition is empty, it refers to the initialization instead. But you get the same answer either way.) >> >> So, the compiler is wrong: there is no error in Sample1. >> >>> public class Sample2 { >>> final int x; >>> >>> Sample2() { >>> x=2; >>> for(;;x=1) { >>> break; >>> } >>> } >>> } >> >> No error here, which is fine. 'x=1' is unreachable, so it doesn't matter that it performs an assignment. >> >> (You get the same behavior if you do 'if (false) x = 1'.) >> >> ?Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Sat Feb 17 02:58:25 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 17 Feb 2018 09:58:25 +0700 Subject: Final field update in unreachable for loop update section In-Reply-To: <14304DD1-B844-42B0-862F-3126C036395F@oracle.com> References: <453EE1A6-308B-43C0-A163-7F02FAA29698@oracle.com> <843a3a5f-6b5e-8e40-de86-a3fb45a1b790@oracle.com> <14304DD1-B844-42B0-862F-3126C036395F@oracle.com> Message-ID: Wow, it's so old story! Thanks! Tagir. 17 ????. 2018 ?. 2:20 AM ???????????? "Dan Smith" ???????: Yep, I came to the same conclusion independently. Glad you landed there, too! There's an old spec bug I was looking at that raised this issue, too. https://bugs.openjdk.java.net/browse/JDK-4660984 I've closed the javac bug, and proposed some spec changes in JDK-4660984. ?Dan On Feb 16, 2018, at 3:26 AM, Tagir Valeev wrote: Hello! Thank you for investigating this. On a second look the javac behavior looks somewhat logical. The for loop execution looks like this: /-----------------------------> (next statement) | initialization --> condition --> body -X-> incrementation ^ | \-----------------------/ Having a "break" statement we removed an edge marked with X. However there's still an "incrementation->condition->body" chain, even though the incrementation is unreachable. So javac likely goes along this path and finds that "x=2" (body) is possible after "x=1" (increment). To my understanding, usually spec works like this: unreachable statements are still analyzed. The x is not DU after increment, thus it should not be DU before empty condition, thus it should not be DU before body. 16.2.12 says: V is definitely unassigned before the condition part of the for statement iff all of the following are true: - V is definitely unassigned after the initialization part of the for statement. - Assuming V is definitely unassigned before the condition part of the for statement, V is definitely unassigned after the contained statement. - Assuming V is definitely unassigned before the contained statement, V is definitely unassigned before every continue statement for which the for statement is the continue target. This would be perfectly logical were condition part executed either after initialization or after body (or continue statement within the body). However actually it's executed either after initialization or after the incrementation. Probably this part should be reformulated in the following way: V is definitely unassigned before the condition part of the for statement iff all of the following are true: - V is definitely unassigned after the initialization part of the for statement. - Assuming V is definitely unassigned before the condition part of the for statement, V is definitely unassigned after the incrementation part. This way it would be aligned with javac implementation and sound more logical. Am I missing something? Regards, Tagir Valeev. On Fri, Feb 16, 2018 at 3:39 AM, Vicente Romero wrote: > Thanks Dan for evaluating this one, certainly this set of rules is tricky > to follow. I have created bug [1] to track this issue, > > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8198245 > > > On 02/15/2018 03:16 PM, Dan Smith wrote: > > Thanks for the interesting test case. > > You're pushing on this part of the language spec: > https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.12 > > https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.html#jls-16.2.13 > > On Feb 7, 2018, at 7:49 PM, Tagir Valeev wrote: > > public class Sample1 { > final int x; > > Sample1() { > for(;;x=1) { > x=2; > break; > } > } > } > > > An error should only occur if 'x' is assigned to where it is definitely > unassigned ("DU"). > > The rules say that: > > - x is DU before the for loop > > - x is DU after the (empty) initialization > > - assuming x is DU before the (empty) condition: > - x is DU before the loop body* > - x is DU after the 'break' (because this is unreachable) > - x is DU after the loop body > > - thus, x is DU before the (empty) condition > > - x is DU before 'x=2' > > - x is DU after the 'break' > > - x is DU after the loop body > > - x is DU before the incrementation statement > > - x is DU before 'x=1' > > (*The connection between the start of the condition and the start of the > loop body is a little confusing in the spec, because when the condition is > empty, it refers to the initialization instead. But you get the same answer > either way.) > > So, the compiler is wrong: there is no error in Sample1. > > public class Sample2 { > final int x; > > Sample2() { > x=2; > for(;;x=1) { > break; > } > } > } > > > No error here, which is fine. 'x=1' is unreachable, so it doesn't matter > that it performs an assignment. > > (You get the same behavior if you do 'if (false) x = 1'.) > > ?Dan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sun Feb 18 23:42:05 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 19 Feb 2018 00:42:05 +0100 Subject: JDK-8189335: NPE in Lower due to class name clash Message-ID: Hi, As explained in JDK-8189335, the following example crashes javac with a NPE in Lower: class R { private class R$1 {} void f() { new R$1(); } } class R$1 {} This seems to be due to the fact that javac wrongly concludes that the constructor of 'R$1' needs private access and then generates an anonymous class 'R$1' (see Lower.accessConstructor()) which conflicts with the top level class using the same name. The following fix gives access to inner class constructors the same way as for local class constructors (needs to be well tested). What do you think? Thanks, Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java @@ -1008,7 +1008,7 @@ boolean needsPrivateAccess(Symbol sym) { if ((sym.flags() & PRIVATE) == 0 || sym.owner == currentClass) { return false; - } else if (sym.name == names.init && sym.owner.isLocal()) { + } else if (sym.name == names.init && (sym.owner.isLocal() || sym.owner.isEnclosedBy(currentClass))) { // private constructor in local class: relax protection sym.flags_field &= ~PRIVATE; return false; From maurizio.cimadamore at oracle.com Mon Feb 19 12:04:25 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 19 Feb 2018 12:04:25 +0000 Subject: Bug: no line number for invokedynamic In-Reply-To: References: <2d1d22d3-c981-a03e-1fc8-6eb19808446a@oracle.com> <8ed9468e-e211-792d-aa1a-b8219ae15ff6@oracle.com> Message-ID: On 16/02/18 11:43, B. Blaser wrote: > On 15 February 2018 at 18:19, Vicente Romero wrote: >> >> On 02/14/2018 05:24 PM, B. Blaser wrote: >>> This is also somewhat related to JDK-8019486 associated test which >>> should probably be updated as next if we want to re-enable this >>> feature to have a clean stack trace. >> >> right if we were introduce any change in this area the test below would >> start failing > I tried some stepping with 'jdb' on the examples present in this test > case with the patch I suggested two days ago: > - if (!msym.isDynamic()) { > +// if (!msym.isDynamic()) { > code.statBegin(tree.pos); > - } > +// } > > It appeared to me smooth enough and the stack trace for the initial > example is right (line 7 instead of 6). I wonder if this could depend on the IDE? The big we were referring to was created very early in JDK 8 lifetime. I wonder if IDEs have gotten better at ignoring indys during debugging? Would be very helpful if some IDE people with experience in debuggers could chime in here? Maurizio > Are we going in this direction? Is there any open JBS issue for that? > > Bernard > >>> Cheers, >>> Bernard >> >> Vicente >> >> >>> >>> diff -r b3a833c9c6e9 >>> test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >>> --- a/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >>> Mon Feb 12 09:12:41 2018 +0100 >>> +++ b/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >>> Wed Feb 14 22:56:43 2018 +0100 >>> @@ -107,6 +107,8 @@ >>> static final int[][] deserializeExpectedLNT = { >>> // {line-number, start-pc}, >>> {05, 0}, //number -> number / 1 >>> + {21, 137}, //number -> number / 1 >>> + {05, 142}, //number -> number / 1 >>> }; >>> >>> static final int[][] lambdaBridgeExpectedLNT = { >>> @@ -123,6 +125,8 @@ >>> static final int[][] callExpectedLNT = { >>> // {line-number, start-pc}, >>> {29, 0}, //number -> number / 1 >>> + {30, 2}, //number -> number / 1 >>> + {29, 7}, //number -> number / 1 >>> {31, 10}, //number -> number / 1 >>> }; >>> >>> >>> On 14 February 2018 at 21:47, Maurizio Cimadamore >>> wrote: >>>> This comes from here: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8010404 >>>> >>>> Back when developing JDK 8 - we had a feeling that having the debugger >>>> stop >>>> at lambda capture sites would be confusing - and so we disabled it. >>>> >>>> I agree that in the stack trace case this decision seems to backfire a >>>> bit. >>>> >>>> Maurizio >>>> >>>> >>>> >>>> On 14/02/18 15:26, B. Blaser wrote: >>>>> The line number is deliberately not emitted for dynamic callsites (but >>>>> I don't know why?), see below. >>>>> I hope this helps, >>>>> Bernard >>>>> >>>>> diff -r b3a833c9c6e9 >>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>>> Mon Feb 12 09:12:41 2018 +0100 >>>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>>> Wed Feb 14 16:14:17 2018 +0100 >>>>> @@ -1649,9 +1649,9 @@ >>>>> MethodSymbol msym = (MethodSymbol)TreeInfo.symbol(tree.meth); >>>>> genArgs(tree.args, >>>>> msym.externalType(types).getParameterTypes()); >>>>> - if (!msym.isDynamic()) { >>>>> +// if (!msym.isDynamic()) { >>>>> code.statBegin(tree.pos); >>>>> - } >>>>> +// } >>>>> result = m.invoke(); >>>>> } >>>>> >>>>> >>>>> On 14 February 2018 at 09:16, Vladimir Parfinenko >>>>> wrote: >>>>>> Hi all, >>>>>> >>>>>> I think I have found a minor bug. There is no line number information >>>>>> for invokedynamic instructions generated for method handle or lambda >>>>>> function. >>>>>> >>>>>> The problem can be reproduced using the example below and running it >>>>>> like this: >>>>>> >>>>>> $ javac Test.java >>>>>> $ rm A.class >>>>>> $ java Test >>>>>> Exception in thread "main" java.lang.NoClassDefFoundError: A >>>>>> at Test.main(Test.java:6) >>>>>> Caused by: java.lang.ClassNotFoundException: A >>>>>> ... >>>>>> >>>>>> The correct line number for this stack trace element would be 7. >>>>>> >>>>>> The line number table is missing an entry for invokedynamic: >>>>>> >>>>>> Code: >>>>>> stack=2, locals=2, args_size=1 >>>>>> 0: invokestatic #2 // Method fortyTwo:()I >>>>>> 3: invokedynamic #3, 0 // InvokeDynamic >>>>>> #0:apply:()Ljava/util/function/Function; >>>>>> 8: invokestatic #4 // Method >>>>>> foo:(ILjava/util/function/Function;)Ljava/lang/Object; >>>>>> 11: astore_1 >>>>>> 12: return >>>>>> LineNumberTable: >>>>>> line 6: 0 >>>>>> line 5: 8 >>>>>> line 9: 12 >>>>>> >>>>>> >>>>>> Regards, >>>>>> Vladimir Parfinenko >>>>>> >>>>>> >>>>>> >>>>>> -- Test.java >>>>>> >>>>>> // line 1 >>>>>> public class Test { >>>>>> public static void main(String[] args) { >>>>>> Object res = >>>>>> foo( >>>>>> fortyTwo(), // line 6 >>>>>> A::sqr // line 7 >>>>>> ); >>>>>> } >>>>>> >>>>>> public static Object foo(int x, >>>>>> java.util.function.Function>>>>> Integer> f) { >>>>>> return null; >>>>>> } >>>>>> >>>>>> public static int fortyTwo() { >>>>>> return 42; >>>>>> } >>>>>> } >>>>>> >>>>>> class A { >>>>>> public static int sqr(int x) { >>>>>> return x * x; >>>>>> } >>>>>> } >>>>>> >>>>>> From bsrbnd at gmail.com Mon Feb 19 14:53:02 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 19 Feb 2018 15:53:02 +0100 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: References: Message-ID: On 19 February 2018 at 00:42, B. Blaser wrote: > Hi, > > As explained in JDK-8189335, the following example crashes javac with > a NPE in Lower: > > class R { > private class R$1 {} > void f() { > new R$1(); > } > } > class R$1 {} > > This seems to be due to the fact that javac wrongly concludes that the > constructor of 'R$1' needs private access and then generates an > anonymous class 'R$1' (see Lower.accessConstructor()) which conflicts > with the top level class using the same name. Another simpler solution would be to create an anonymous class if the existing one isn't anonymous... as next. Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java @@ -1236,7 +1236,7 @@ target.syntheticNameChar() + "1"); ClassSymbol ctag = chk.getCompiled(topModle, flatname); - if (ctag == null) + if (ctag == null || !ctag.isAnonymous()) ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; // keep a record of all tags, to verify that all are generated as required accessConstrTags = accessConstrTags.prepend(ctag); From jan.lahoda at oracle.com Mon Feb 19 18:57:59 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 19 Feb 2018 19:57:59 +0100 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: <5A8478C8.4030306@oracle.com> References: <5A818BEC.5010204@oracle.com> <5A82D973.3040404@oracle.com> <5A8456E7.2020707@oracle.com> <5A8478C8.4030306@oracle.com> Message-ID: <5A8B1E37.7080407@oracle.com> Hi, I was testing the webrev.01-ext, and so far it seems OK, so I added that to the patch. One thing I've noticed is that com.sun.source.tree.Scope.getLocalElements() may still cause the CompletionFailure to be thrown to the client code, so I've fixed that. Updated webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.02/ There are two bugs related to this (JDK-8177068 and JDK-8198378, both already existing) on which I plan to work separately. Are there any comments/feedback on the patch? Thanks, Jan On 14.2.2018 18:58, Jan Lahoda wrote: > On 14.2.2018 18:04, Liam Miller-Cushon wrote: >> On Wed, Feb 14, 2018 at 7:33 AM, Jan Lahoda > > wrote: >> >> Today, I got an idea that might solve this issue without too much >> hassle, sketched here: >> http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01-ext/ >> >> >> Will need more testing, but possibly could work. Any opinions/ideas? >> >> >> Thanks - that fixed the first two regressions I saw. I'm not sure >> whether getKind() was the only instance of this problem, but I'm running >> more tests and will report back. > > Cool, thanks! > >> >> One thing I'd like to point out is that this can (AFAIK) happen even >> now - if the interface B is completed in a way that will throw away >> the CompletionFailure (e.g. Elements.getTypeElement), then the >> subsequent code will AFAIK see the same state as this AP sees. So it >> seemed somewhat acceptable to let the behavior be similar in case >> where the CompletionFailure would be thrown, esp. since I didn't see >> a good way to do better. >> >> >> Good point. I guess I've seen more issues around processors catching >> completion failures and leaving the model in a bad state for other >> processors (or javac), than around the completion failure itself causing >> problems. It's important that processors can detect when they're seeing >> invalid input. If they end up needing to be more vigilant about checking > > FWIW, in the current state, it is possible to check > DeclaredType.asElement().asType().getKind() == TypeKind.ERROR to see if > the type's symbol is broken. (I agree it is quite cumbersome.) > >> for error types that's a slightly incompatible change. > > AFAIK, doing TypeElement.getSuperclass() may currently lead to several > results depending on the exact circumstances: > 1) a DECLARED type, that will throw a CompletionFailure (once) at some > point if used > 2) a DECLARED type that will not throw a CompletionFailure (because it > was already thrown) > 3) an ERROR type (if the TypeElement originates in the source code, and > its superclass is missing) > > So eliminating any of these is probably a slightly incompatible change > (which will need a CSR), but I personally think it is better than having > different behaviors. OTOH, I suspect many APs already deal with these in > some ways, so eliminating some shouldn't hopefully be that disruptive. > >> >> There was some discussion in JDK-8187950 about declaring an exception in >> the API contract for methods that currently throw completion failures. >> Did you consider taking that approach, and having the completion failure >> be rethrown to ensure other processors and javac see it if they try to >> complete the same symbol? Maybe JDK-8190054 answers that question - it >> sounds like there's a preference for returning error objects instead of >> throwing? > > I was thinking of that, but I personally: > -think the model is cleaner without the exceptions > -am not convinced that it would be much simpler if we tried to change > the implementation to more consistently throw the exception > > Thanks for your feedback, > Jan From srikanth.adayapalam at oracle.com Tue Feb 20 09:29:35 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 20 Feb 2018 14:59:35 +0530 Subject: RFR : JDK-8197439, , Crash with -XDfind=lambda for anonymous class in anonymous class. In-Reply-To: <5A7D6A7A.2040505@oracle.com> References: <5A7D6A7A.2040505@oracle.com> Message-ID: <37ec475f-9e42-a0a0-055d-72f2386c6866@oracle.com> On Friday 09 February 2018 03:01 PM, Jan Lahoda wrote: > Hi, > > For certain classes -XDfind=lambda will crash javac (please see the > bug for details): > [...] > --- > > The reason is that: > - -XDfind=lambda will try to replace "new I1() {...}" with a lambda > and attribute that > -but this will make I2 unresolvable > -so Attr.visitNewClass will not (currently) attribute the inside of > the "new I2() {}". > -so Attr.PostAttrAnalyzer will try to fill in Symbols and Types, but > "Attr.PostAttrAnalyzer.dummyMethodType" will dereference > MethodTree.restype, which is null for constructors (in this case an > automatically generated constructor). > > A part of the proposed fix is to enhance > PostAttrAnalyzer.dummyMethodType to handle constructors. This part looks good. > But attributing the body of an unresolvable anonymous class does not > seem difficult, and would help API clients like JShell, so the > proposed fix is doing that as well. Not being a regular user of jshell, I am not able to form an assessment as to how important this is - my lay person's opinion is that it is not, but I will defer to your judgment. But the relevant changes in Attr look reasonable. AnonymousInAnonymous.java: (1) FWIW, it may be a better idea to capture the diagnostic issued by XDfind=lambda and prepare a golden file ?? (2) @module directive unnecessary here ? Overall, I am fine with this patch, Sorry for the delayed response, Thanks! Srikanth From jan.lahoda at oracle.com Tue Feb 20 14:11:34 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 20 Feb 2018 15:11:34 +0100 Subject: RFR : JDK-8197439, , Crash with -XDfind=lambda for anonymous class in anonymous class. In-Reply-To: <37ec475f-9e42-a0a0-055d-72f2386c6866@oracle.com> References: <5A7D6A7A.2040505@oracle.com> <37ec475f-9e42-a0a0-055d-72f2386c6866@oracle.com> Message-ID: <5A8C2C96.2020803@oracle.com> On 20.2.2018 10:29, Srikanth wrote: > > > On Friday 09 February 2018 03:01 PM, Jan Lahoda wrote: >> Hi, >> >> For certain classes -XDfind=lambda will crash javac (please see the >> bug for details): >> > [...] > >> --- >> >> The reason is that: >> - -XDfind=lambda will try to replace "new I1() {...}" with a lambda >> and attribute that >> -but this will make I2 unresolvable >> -so Attr.visitNewClass will not (currently) attribute the inside of >> the "new I2() {}". >> -so Attr.PostAttrAnalyzer will try to fill in Symbols and Types, but >> "Attr.PostAttrAnalyzer.dummyMethodType" will dereference >> MethodTree.restype, which is null for constructors (in this case an >> automatically generated constructor). >> >> A part of the proposed fix is to enhance >> PostAttrAnalyzer.dummyMethodType to handle constructors. > > This part looks good. > >> But attributing the body of an unresolvable anonymous class does not >> seem difficult, and would help API clients like JShell, so the >> proposed fix is doing that as well. > > Not being a regular user of jshell, I am not able to form an assessment > as to how important this is - my lay person's opinion is that it is not, > but I will defer to your judgment. But the relevant changes in Attr look > reasonable. I think it is nicer for the users of the API to have the anonymous classes attributed, even if it may not be very important. > > AnonymousInAnonymous.java: > > (1) FWIW, it may be a better idea to capture the diagnostic issued by > XDfind=lambda and prepare a golden file ?? Oops, yes, done. > (2) @module directive unnecessary here ? Not really sure, removed. Updated webrev: http://cr.openjdk.java.net/~jlahoda/8197439/webrev.01/ Thanks for the comments so far! Jan > > Overall, I am fine with this patch, > > Sorry for the delayed response, > Thanks! > Srikanth > > > From cushon at google.com Tue Feb 20 17:30:09 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 20 Feb 2018 09:30:09 -0800 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: <5A8B1E37.7080407@oracle.com> References: <5A818BEC.5010204@oracle.com> <5A82D973.3040404@oracle.com> <5A8456E7.2020707@oracle.com> <5A8478C8.4030306@oracle.com> <5A8B1E37.7080407@oracle.com> Message-ID: I did some more testing and found a handful of annotation processors affected by the change. For the most part they were already checking for error types, and adding some missing error handling fixed them. So from what I saw the compatibility impact is fairly minor. I still think there might be advantages to handling these errors with exceptions instead of error types, and it might be interesting to consider ways to add that to the API (perhaps as optional behaviour for processors that want it, to preserve compatibility). But as you said, this change makes the existing behaviour more consistent and brings it in line with the current spec, both of which are good things. So, this looks good to me. Thanks for the discussion! On Mon, Feb 19, 2018 at 10:57 AM, Jan Lahoda wrote: > Hi, > > I was testing the webrev.01-ext, and so far it seems OK, so I added that > to the patch. > > One thing I've noticed is that com.sun.source.tree.Scope.getLocalElements() > may still cause the CompletionFailure to be thrown to the client code, so > I've fixed that. > > Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8187950/webrev.02/ > > There are two bugs related to this (JDK-8177068 and JDK-8198378, both > already existing) on which I plan to work separately. > > Are there any comments/feedback on the patch? > > Thanks, > Jan > > > On 14.2.2018 18:58, Jan Lahoda wrote: > >> On 14.2.2018 18:04, Liam Miller-Cushon wrote: >> >>> On Wed, Feb 14, 2018 at 7:33 AM, Jan Lahoda >> > wrote: >>> >>> Today, I got an idea that might solve this issue without too much >>> hassle, sketched here: >>> http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01-ext/ >>> >>> >>> Will need more testing, but possibly could work. Any opinions/ideas? >>> >>> >>> Thanks - that fixed the first two regressions I saw. I'm not sure >>> whether getKind() was the only instance of this problem, but I'm running >>> more tests and will report back. >>> >> >> Cool, thanks! >> >> >>> One thing I'd like to point out is that this can (AFAIK) happen even >>> now - if the interface B is completed in a way that will throw away >>> the CompletionFailure (e.g. Elements.getTypeElement), then the >>> subsequent code will AFAIK see the same state as this AP sees. So it >>> seemed somewhat acceptable to let the behavior be similar in case >>> where the CompletionFailure would be thrown, esp. since I didn't see >>> a good way to do better. >>> >>> >>> Good point. I guess I've seen more issues around processors catching >>> completion failures and leaving the model in a bad state for other >>> processors (or javac), than around the completion failure itself causing >>> problems. It's important that processors can detect when they're seeing >>> invalid input. If they end up needing to be more vigilant about checking >>> >> >> FWIW, in the current state, it is possible to check >> DeclaredType.asElement().asType().getKind() == TypeKind.ERROR to see if >> the type's symbol is broken. (I agree it is quite cumbersome.) >> >> for error types that's a slightly incompatible change. >>> >> >> AFAIK, doing TypeElement.getSuperclass() may currently lead to several >> results depending on the exact circumstances: >> 1) a DECLARED type, that will throw a CompletionFailure (once) at some >> point if used >> 2) a DECLARED type that will not throw a CompletionFailure (because it >> was already thrown) >> 3) an ERROR type (if the TypeElement originates in the source code, and >> its superclass is missing) >> >> So eliminating any of these is probably a slightly incompatible change >> (which will need a CSR), but I personally think it is better than having >> different behaviors. OTOH, I suspect many APs already deal with these in >> some ways, so eliminating some shouldn't hopefully be that disruptive. >> >> >>> There was some discussion in JDK-8187950 about declaring an exception in >>> the API contract for methods that currently throw completion failures. >>> Did you consider taking that approach, and having the completion failure >>> be rethrown to ensure other processors and javac see it if they try to >>> complete the same symbol? Maybe JDK-8190054 answers that question - it >>> sounds like there's a preference for returning error objects instead of >>> throwing? >>> >> >> I was thinking of that, but I personally: >> -think the model is cleaner without the exceptions >> -am not convinced that it would be much simpler if we tried to change >> the implementation to more consistently throw the exception >> >> Thanks for your feedback, >> Jan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Tue Feb 20 20:32:19 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 20 Feb 2018 12:32:19 -0800 Subject: java.util.concurrent jtreg tests no longer compile after 8194892: add compiler support for local-variable syntax for lambda parameters Message-ID: It looks like this changeset has broken jtreg tests, e.g. test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java changeset: 48920:916690b5edc9 user: vromero date: 2018-02-20 11:45 -0500 8194892: add compiler support for local-variable syntax for lambda parameters Reviewed-by: mcimadamore the breakages seem bogus, or at least I don't know how to fix them. It's as if javac no longer knows how to handle typed single-parameter lambda argument lists. E.g. /home/martin/ws/jdk/test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java:643: error: invalid lambda parameter declaration m.forEachEntry(Long.MAX_VALUE, (Map.Entry e) -> adder.add(e.getKey().longValue() + e.getValue().longValue())); ^ (cannot mix implicitly-typed and explicitly-typed parameters) /home/martin/ws/jdk/test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java:643: error: not a statement m.forEachEntry(Long.MAX_VALUE, (Map.Entry e) -> adder.add(e.getKey().longValue() + e.getValue().longValue())); ^ /home/martin/ws/jdk/test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java:643: error: ';' expected m.forEachEntry(Long.MAX_VALUE, (Map.Entry e) -> adder.add(e.getKey().longValue() + e.getValue().longValue())); ^ /home/martin/ws/jdk/test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java:683: error: invalid lambda parameter declaration m.forEachEntry(1L, (Map.Entry e) -> adder.add(e.getKey().longValue() + e.getValue().longValue())); ^ (cannot mix implicitly-typed and explicitly-typed parameters) -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Wed Feb 21 05:13:16 2018 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Wed, 21 Feb 2018 10:43:16 +0530 Subject: RFR : JDK-8197439, , Crash with -XDfind=lambda for anonymous class in anonymous class. In-Reply-To: <5A8C2C96.2020803@oracle.com> References: <5A7D6A7A.2040505@oracle.com> <37ec475f-9e42-a0a0-055d-72f2386c6866@oracle.com> <5A8C2C96.2020803@oracle.com> Message-ID: <86cccd6d-bddd-5f51-b1e7-d185fed5b951@oracle.com> Hi Jan, If the only changes in this revision are what were called out in the earlier review, I am fine with the XDfind=lambda fix. FYI. Thanks! Srikanth On Tuesday 20 February 2018 07:41 PM, Jan Lahoda wrote: > On 20.2.2018 10:29, Srikanth wrote: >> >> >> On Friday 09 February 2018 03:01 PM, Jan Lahoda wrote: >>> Hi, >>> >>> For certain classes -XDfind=lambda will crash javac (please see the >>> bug for details): >>> >> [...] >> >>> --- >>> >>> The reason is that: >>> - -XDfind=lambda will try to replace "new I1() {...}" with a lambda >>> and attribute that >>> -but this will make I2 unresolvable >>> -so Attr.visitNewClass will not (currently) attribute the inside of >>> the "new I2() {}". >>> -so Attr.PostAttrAnalyzer will try to fill in Symbols and Types, but >>> "Attr.PostAttrAnalyzer.dummyMethodType" will dereference >>> MethodTree.restype, which is null for constructors (in this case an >>> automatically generated constructor). >>> >>> A part of the proposed fix is to enhance >>> PostAttrAnalyzer.dummyMethodType to handle constructors. >> >> This part looks good. >> >>> But attributing the body of an unresolvable anonymous class does not >>> seem difficult, and would help API clients like JShell, so the >>> proposed fix is doing that as well. >> >> Not being a regular user of jshell, I am not able to form an assessment >> as to how important this is - my lay person's opinion is that it is not, >> but I will defer to your judgment. But the relevant changes in Attr look >> reasonable. > > I think it is nicer for the users of the API to have the anonymous > classes attributed, even if it may not be very important. > >> >> AnonymousInAnonymous.java: >> >> (1) FWIW, it may be a better idea to capture the diagnostic issued by >> XDfind=lambda and prepare a golden file ?? > > Oops, yes, done. > >> (2) @module directive unnecessary here ? > > Not really sure, removed. > > Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8197439/webrev.01/ > > Thanks for the comments so far! > > Jan > >> >> Overall, I am fine with this patch, >> >> Sorry for the delayed response, >> Thanks! >> Srikanth >> >> >> From bsrbnd at gmail.com Wed Feb 21 11:59:16 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 21 Feb 2018 12:59:16 +0100 Subject: Bug: no line number for invokedynamic In-Reply-To: References: <2d1d22d3-c981-a03e-1fc8-6eb19808446a@oracle.com> <8ed9468e-e211-792d-aa1a-b8219ae15ff6@oracle.com> Message-ID: On 19 February 2018 at 13:04, Maurizio Cimadamore wrote: > > > On 16/02/18 11:43, B. Blaser wrote: >> >> On 15 February 2018 at 18:19, Vicente Romero >> wrote: >>> >>> >>> On 02/14/2018 05:24 PM, B. Blaser wrote: >>>> >>>> This is also somewhat related to JDK-8019486 associated test which >>>> should probably be updated as next if we want to re-enable this >>>> feature to have a clean stack trace. >>> >>> >>> right if we were introduce any change in this area the test below would >>> start failing >> >> I tried some stepping with 'jdb' on the examples present in this test >> case with the patch I suggested two days ago: >> - if (!msym.isDynamic()) { >> +// if (!msym.isDynamic()) { >> code.statBegin(tree.pos); >> - } >> +// } >> >> It appeared to me smooth enough and the stack trace for the initial >> example is right (line 7 instead of 6). > > I wonder if this could depend on the IDE? The big we were referring to was > created very early in JDK 8 lifetime. I wonder if IDEs have gotten better at > ignoring indys during debugging? So, not emitting the line number looks more like an old javac tweak to help debuggers being smooth at the early days of invokedynamic... Another thing I can note is that if we'd like to step into the bootstrap method, it'd be right to stop first on the dynamic call site. In such a situation, having the indy line number would be necessary too. Bernard > Would be very helpful if some IDE people > with experience in debuggers could chime in here? > > Maurizio > > >> Are we going in this direction? Is there any open JBS issue for that? >> >> Bernard >> >>>> Cheers, >>>> Bernard >>> >>> >>> Vicente >>> >>> >>>> >>>> diff -r b3a833c9c6e9 >>>> test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >>>> --- a/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >>>> Mon Feb 12 09:12:41 2018 +0100 >>>> +++ b/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >>>> Wed Feb 14 22:56:43 2018 +0100 >>>> @@ -107,6 +107,8 @@ >>>> static final int[][] deserializeExpectedLNT = { >>>> // {line-number, start-pc}, >>>> {05, 0}, //number -> number / 1 >>>> + {21, 137}, //number -> number / 1 >>>> + {05, 142}, //number -> number / 1 >>>> }; >>>> >>>> static final int[][] lambdaBridgeExpectedLNT = { >>>> @@ -123,6 +125,8 @@ >>>> static final int[][] callExpectedLNT = { >>>> // {line-number, start-pc}, >>>> {29, 0}, //number -> number / 1 >>>> + {30, 2}, //number -> number / 1 >>>> + {29, 7}, //number -> number / 1 >>>> {31, 10}, //number -> number / 1 >>>> }; >>>> >>>> >>>> On 14 February 2018 at 21:47, Maurizio Cimadamore >>>> wrote: >>>>> >>>>> This comes from here: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8010404 >>>>> >>>>> Back when developing JDK 8 - we had a feeling that having the debugger >>>>> stop >>>>> at lambda capture sites would be confusing - and so we disabled it. >>>>> >>>>> I agree that in the stack trace case this decision seems to backfire a >>>>> bit. >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> >>>>> On 14/02/18 15:26, B. Blaser wrote: >>>>>> >>>>>> The line number is deliberately not emitted for dynamic callsites (but >>>>>> I don't know why?), see below. >>>>>> I hope this helps, >>>>>> Bernard >>>>>> >>>>>> diff -r b3a833c9c6e9 >>>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>>>> Mon Feb 12 09:12:41 2018 +0100 >>>>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>>>> Wed Feb 14 16:14:17 2018 +0100 >>>>>> @@ -1649,9 +1649,9 @@ >>>>>> MethodSymbol msym = >>>>>> (MethodSymbol)TreeInfo.symbol(tree.meth); >>>>>> genArgs(tree.args, >>>>>> msym.externalType(types).getParameterTypes()); >>>>>> - if (!msym.isDynamic()) { >>>>>> +// if (!msym.isDynamic()) { >>>>>> code.statBegin(tree.pos); >>>>>> - } >>>>>> +// } >>>>>> result = m.invoke(); >>>>>> } >>>>>> >>>>>> >>>>>> On 14 February 2018 at 09:16, Vladimir Parfinenko >>>>>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I think I have found a minor bug. There is no line number information >>>>>>> for invokedynamic instructions generated for method handle or lambda >>>>>>> function. >>>>>>> >>>>>>> The problem can be reproduced using the example below and running it >>>>>>> like this: >>>>>>> >>>>>>> $ javac Test.java >>>>>>> $ rm A.class >>>>>>> $ java Test >>>>>>> Exception in thread "main" java.lang.NoClassDefFoundError: A >>>>>>> at Test.main(Test.java:6) >>>>>>> Caused by: java.lang.ClassNotFoundException: A >>>>>>> ... >>>>>>> >>>>>>> The correct line number for this stack trace element would be 7. >>>>>>> >>>>>>> The line number table is missing an entry for invokedynamic: >>>>>>> >>>>>>> Code: >>>>>>> stack=2, locals=2, args_size=1 >>>>>>> 0: invokestatic #2 // Method >>>>>>> fortyTwo:()I >>>>>>> 3: invokedynamic #3, 0 // InvokeDynamic >>>>>>> #0:apply:()Ljava/util/function/Function; >>>>>>> 8: invokestatic #4 // Method >>>>>>> foo:(ILjava/util/function/Function;)Ljava/lang/Object; >>>>>>> 11: astore_1 >>>>>>> 12: return >>>>>>> LineNumberTable: >>>>>>> line 6: 0 >>>>>>> line 5: 8 >>>>>>> line 9: 12 >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Vladimir Parfinenko >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Test.java >>>>>>> >>>>>>> // line 1 >>>>>>> public class Test { >>>>>>> public static void main(String[] args) { >>>>>>> Object res = >>>>>>> foo( >>>>>>> fortyTwo(), // line 6 >>>>>>> A::sqr // line 7 >>>>>>> ); >>>>>>> } >>>>>>> >>>>>>> public static Object foo(int x, >>>>>>> java.util.function.Function>>>>>> Integer> f) { >>>>>>> return null; >>>>>>> } >>>>>>> >>>>>>> public static int fortyTwo() { >>>>>>> return 42; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> class A { >>>>>>> public static int sqr(int x) { >>>>>>> return x * x; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> > From vicente.romero at oracle.com Wed Feb 21 13:30:00 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 21 Feb 2018 08:30:00 -0500 Subject: java.util.concurrent jtreg tests no longer compile after 8194892: add compiler support for local-variable syntax for lambda parameters In-Reply-To: References: Message-ID: <5ca428a3-df08-bdbc-7bca-5bbb65990c45@oracle.com> Hi Martin, Right the offending changeset was delta applied. We are working on a fix for the bug, Thanks, Vicente On 02/20/2018 03:32 PM, Martin Buchholz wrote: > It looks like this changeset has broken jtreg tests, > e.g.?test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java > > changeset:? ?48920:916690b5edc9 > user:? ? ? ? vromero > date:? ? ? ? 2018-02-20 11:45 -0500 > 8194892: add compiler support for local-variable syntax for lambda > parameters > Reviewed-by: mcimadamore > > the breakages seem bogus, or at least I don't know how to fix them.? > It's as if javac no longer knows how to handle typed single-parameter > lambda argument lists. > > E.g. > > /home/martin/ws/jdk/test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java:643: > error: invalid lambda parameter declaration > ? ? ? ? m.forEachEntry(Long.MAX_VALUE, (Map.Entry e) -> > adder.add(e.getKey().longValue() + e.getValue().longValue())); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ > ? (cannot mix implicitly-typed and explicitly-typed parameters) > /home/martin/ws/jdk/test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java:643: > error: not a statement > ? ? ? ? m.forEachEntry(Long.MAX_VALUE, (Map.Entry e) -> > adder.add(e.getKey().longValue() + e.getValue().longValue())); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ > /home/martin/ws/jdk/test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java:643: > error: ';' expected > ? ? ? ? m.forEachEntry(Long.MAX_VALUE, (Map.Entry e) -> > adder.add(e.getKey().longValue() + e.getValue().longValue())); > ? ? ? ? ^ > /home/martin/ws/jdk/test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java:683: > error: invalid lambda parameter declaration > ? ? ? ? m.forEachEntry(1L, (Map.Entry e) -> > adder.add(e.getKey().longValue() + e.getValue().longValue())); > ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ > ? (cannot mix implicitly-typed and explicitly-typed parameters) > > > From bsrbnd at gmail.com Wed Feb 21 15:58:34 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 21 Feb 2018 16:58:34 +0100 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: References: Message-ID: On 19 February 2018 at 15:53, B. Blaser wrote: > On 19 February 2018 at 00:42, B. Blaser wrote: >> Hi, >> >> As explained in JDK-8189335, the following example crashes javac with >> a NPE in Lower: >> >> class R { >> private class R$1 {} >> void f() { >> new R$1(); >> } >> } >> class R$1 {} Some precisions related to my laconic explanation about the problem and the fix. All starts in 'Lower.accessConstructorTag()' when searching for the anonymous class 'R$1': http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1238 The top level class 'R$1' (not anonymous) is found and wrongly added to 'accessConstrTags'. Then, when checking the access constructor tags in 'Lower.checkAccessConstructorTags()', the 'outermostClass()' of the top level class 'R$1' is requested: http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l778 'R$1' being a top level class, its outermost class doesn't exist, causing the NPE in 'Lower.makeEmptyClass()'. The fix I suggested two days ago (here under) is then quite straightforward. If a class 'R$1' exists but isn't anonymous, it has to be skipped and a fresh anonymous class 'R$2' has to be created as access constructor tag: http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1239 Nothing seems to be broken and the provided example compiles successfully. What do you think (I hope this is clearer)? Thanks, Bernard > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > @@ -1236,7 +1236,7 @@ > target.syntheticNameChar() + > "1"); > ClassSymbol ctag = chk.getCompiled(topModle, flatname); > - if (ctag == null) > + if (ctag == null || !ctag.isAnonymous()) > ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; > // keep a record of all tags, to verify that all are > generated as required > accessConstrTags = accessConstrTags.prepend(ctag); From maurizio.cimadamore at oracle.com Wed Feb 21 18:05:37 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Feb 2018 18:05:37 +0000 Subject: RFR : JDK-8197439, , Crash with -XDfind=lambda for anonymous class in anonymous class. In-Reply-To: <5A7D6A7A.2040505@oracle.com> References: <5A7D6A7A.2040505@oracle.com> Message-ID: <2824b322-9abb-e1a0-4134-b86755d9c834@oracle.com> Looks good - I'm mildly worried that attributing things inside a class w/o supertype might lead to issues - but as we chatted offline, that doesn't seem to be the case, so I'm approving. Cheers Maurizio On 09/02/18 09:31, Jan Lahoda wrote: > Hi, > > For certain classes -XDfind=lambda will crash javac (please see the > bug for details): > --- > public class AnonymousInAnonymous { > ??? static void s(I1 i) {} > ??? static { > ??????? s( > ??????????? new I1() { > ??????????????? public I2 get() { > ??????????????????? return new I2() { > ??????????????????? }; > ??????????????? } > ??????????? }); > ??? } > ??? public static interface I1 { > ??????? public static class I2 { } > ??????? public I2 get(); > ??? } > } > --- > > The reason is that: > - -XDfind=lambda will try to replace "new I1() {...}" with a lambda > and attribute that > -but this will make I2 unresolvable > -so Attr.visitNewClass will not (currently) attribute the inside of > the "new I2() {}". > -so Attr.PostAttrAnalyzer will try to fill in Symbols and Types, but > "Attr.PostAttrAnalyzer.dummyMethodType" will dereference > MethodTree.restype, which is null for constructors (in this case an > automatically generated constructor). > > A part of the proposed fix is to enhance > PostAttrAnalyzer.dummyMethodType to handle constructors. But > attributing the body of an unresolvable anonymous class does not seem > difficult, and would help API clients like JShell, so the proposed fix > is doing that as well. One of the changes to do that also removes > follow up errors that appear to be unnecessary (an error has already > been reported to the anonymous class' "clazz", so unnecessary to > report errors that relate to the anonymous class' constructor). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8197439 > Webrev: http://cr.openjdk.java.net/~jlahoda/8197439/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From cushon at google.com Wed Feb 21 22:34:20 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 21 Feb 2018 14:34:20 -0800 Subject: spec clarification: type annotations on static nested types In-Reply-To: References: <5A53D7C6.1070809@oracle.com> Message-ID: I confirmed that the intent of jsr308 matches javac's current behaviour, so this is a reflection bug. I filed https://bugs.openjdk. java.net/browse/JDK-8198526 and have a fix out for review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051658.html I'm now reading "nested type" as meaning a type that is nested inside an *annotatable* type. i.e. in A.B where B is a non-static inner class, A is an annotatable enclosing instance type, so a type path is needed to indicate that in `A. at Foo B` the annotation is on B. However in A.B where B is a static member class, A is a 'scoping construct' rather than an annotatable type, so no type path is needed for `A. at Foo B` since B is the only annotatable type. Is that reading correct? If it is, I think it would be helpful to clarify the distinction between nested types and nested classes in the spec. On Mon, Jan 22, 2018 at 1:30 PM, Liam Miller-Cushon wrote: > I double-checked that the type paths in the class file javac emits are: > > void f(@A One x) {} > ... > type_path_length 1 > type path entry [0]: type_path_kind: 1, type_path_index: 0 > > void g(@A Two x) {} > ... > type_path_length 0 > > My understanding is still that javac uses type_path_kind=1 to step in to > (non-static) inner classes, and reflection interprets type_path_kind=1 as > stepping in to member classes (both non-static and static). > Is this a javac bug, or a reflection bug, or am I confused? > > Thanks, > > On Mon, Jan 8, 2018 at 2:25 PM, Liam Miller-Cushon > wrote: > >> Thanks! I have some follow-up questions inline - >> >> On Mon, Jan 8, 2018 at 12:42 PM, Alex Buckley >> wrote: >> >>> A type annotation can apply to a type that's nested (i.e. deeper) in a >>> *static* type though. Adapting an example from JLS 9.7.4: >>> ... >> >> In the second case, the nested type which is being annotated is "C . D". >>> The D part denotes a non-static nested type, yes, but the first type that >>> we hit when stepping through the path -- C -- is static. The storage of >>> @Foo thus involves a type_path that descends "deeper in a nested type" -- >>> mentioning anything about static here would be wrong. As a separate issue, >>> the location where we ultimately find @Foo is, in fact, a non-static member >>> type, so javap helpfully shows that location as INNER_TYPE: >>> >> >> I didn't express what I was thinking, sorry. I agree we're not interested >> in the static-ness of the outer type. >> >> I think javac currently emits type_path_kind=1 steps only when descending >> in to a member type that is non-static, and that the >> "location=[INNER_TYPE]" bit of javap's output corresponds directly to the >> type_path structure in the class file. >> >> Is that accurate, and if so is it to spec? >> >> My understanding of the `@Foo C . D x;` example was that no type_path is >> necessary even though C is a member of Test, because C is a static member >> and Test is 'scoping construct' that is not a valid type annotation target. >> >> I don't like how @A has been bounced out of the nested type "T . Two" so >>> that it allegedly applies to the type of the formal parameter as a whole. >>> @A actually applies to the type of the static member Two that is declared >>> by T. >>> >> >> Similar to the other example, isn't "@A actually applies to the type of >> the static member Two" the only interpretation for a type annotation >> attribute that applies to `T . Two`, since T is a scoping construct and is >> not a valid type annotation target? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed Feb 21 22:43:27 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 21 Feb 2018 14:43:27 -0800 Subject: spec clarification: type annotations on static nested types In-Reply-To: References: <5A53D7C6.1070809@oracle.com> Message-ID: <5A8DF60F.7040002@oracle.com> On 2/21/2018 2:34 PM, Liam Miller-Cushon wrote: > I'm now reading "nested type" as meaning a type that is nested inside an > *annotatable* type. > i.e. in A.B where B is a non-static inner class, A is an annotatable > enclosing instance type, so a type path is needed to indicate that in > `A. at Foo B` the annotation is on B. > However in A.B where B is a static member class, A is a 'scoping > construct' rather than an annotatable type, so no type path is needed > for `A. at Foo B` since B is the only annotatable type. That sounds plausible -- the "scoping construct" concept tunneled itself fairly deeply into the JLS -- but I don't especially recall that "nested type" in JVMS 4.7.20.2 meant to represent only non-static members. I can only suggest more digging on type-annotations-spec-experts, sorry. Alex > Is that reading correct? If it is, I think it would be helpful to > clarify the distinction between nested types and nested classes in the spec. > > On Mon, Jan 22, 2018 at 1:30 PM, Liam Miller-Cushon > wrote: > > I double-checked that the type paths in the class file javac emits are: > > void f(@A One x) {} > ... > type_path_length 1 > type path entry [0]: type_path_kind: 1, type_path_index: 0 > > void g(@A Two x) {} > ... > type_path_length 0 > > My understanding is still that javac uses type_path_kind=1 to step > in to (non-static) inner classes, and reflection interprets > type_path_kind=1 as stepping in to member classes (both non-static > and static). > Is this a javac bug, or a reflection bug, or am I confused? > > Thanks, > > On Mon, Jan 8, 2018 at 2:25 PM, Liam Miller-Cushon > > wrote: > > Thanks! I have some follow-up questions inline - > > On Mon, Jan 8, 2018 at 12:42 PM, Alex Buckley > > wrote: > > A type annotation can apply to a type that's nested (i.e. > deeper) in a *static* type though. Adapting an example from > JLS 9.7.4: > ... > > In the second case, the nested type which is being annotated > is "C . D". The D part denotes a non-static nested type, > yes, but the first type that we hit when stepping through > the path -- C -- is static. The storage of @Foo thus > involves a type_path that descends "deeper in a nested type" > -- mentioning anything about static here would be wrong. As > a separate issue, the location where we ultimately find @Foo > is, in fact, a non-static member type, so javap helpfully > shows that location as INNER_TYPE: > > > I didn't express what I was thinking, sorry. I agree we're not > interested in the static-ness of the outer type. > > I think javac currently emits type_path_kind=1 steps only when > descending in to a member type that is non-static, and that the > "location=[INNER_TYPE]" bit of javap's output corresponds > directly to the type_path structure in the class file. > > Is that accurate, and if so is it to spec? > > My understanding of the `@Foo C . D x;` example was that no > type_path is necessary even though C is a member of Test, > because C is a static member and Test is 'scoping construct' > that is not a valid type annotation target. > > I don't like how @A has been bounced out of the nested type > "T . Two" so that it allegedly applies to the type of the > formal parameter as a whole. @A actually applies to the type > of the static member Two that is declared by T. > > > Similar to the other example, isn't "@A actually applies to the > type of the static member Two" the only interpretation for a > type annotation attribute that applies to `T . Two`, since T is > a scoping construct and is not a valid type annotation target? > > > From jonathan.gibbons at oracle.com Thu Feb 22 07:03:01 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 21 Feb 2018 23:03:01 -0800 Subject: RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. In-Reply-To: <5A8B1E37.7080407@oracle.com> References: <5A818BEC.5010204@oracle.com> <5A82D973.3040404@oracle.com> <5A8456E7.2020707@oracle.com> <5A8478C8.4030306@oracle.com> <5A8B1E37.7080407@oracle.com> Message-ID: <36fb8904-8bfc-62d0-805f-db6acb7d4b51@oracle.com> Looks OK to me, -- Jon On 2/19/18 10:57 AM, Jan Lahoda wrote: > Hi, > > I was testing the webrev.01-ext, and so far it seems OK, so I added > that to the patch. > > One thing I've noticed is that > com.sun.source.tree.Scope.getLocalElements() may still cause the > CompletionFailure to be thrown to the client code, so I've fixed that. > > Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8187950/webrev.02/ > > There are two bugs related to this (JDK-8177068 and JDK-8198378, both > already existing) on which I plan to work separately. > > Are there any comments/feedback on the patch? > > Thanks, > ??? Jan > > On 14.2.2018 18:58, Jan Lahoda wrote: >> On 14.2.2018 18:04, Liam Miller-Cushon wrote: >>> On Wed, Feb 14, 2018 at 7:33 AM, Jan Lahoda >> > wrote: >>> >>> ??? Today, I got an idea that might solve this issue without too much >>> ??? hassle, sketched here: >>> ??? http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01-ext/ >>> >>> >>> ??? Will need more testing, but possibly could work. Any >>> opinions/ideas? >>> >>> >>> Thanks - that fixed the first two regressions I saw. I'm not sure >>> whether getKind() was the only instance of this problem, but I'm >>> running >>> more tests and will report back. >> >> Cool, thanks! >> >>> >>> ??? One thing I'd like to point out is that this can (AFAIK) happen >>> even >>> ??? now - if the interface B is completed in a way that will throw away >>> ??? the CompletionFailure (e.g. Elements.getTypeElement), then the >>> ??? subsequent code will AFAIK see the same state as this AP sees. >>> So it >>> ??? seemed somewhat acceptable to let the behavior be similar in case >>> ??? where the CompletionFailure would be thrown, esp. since I didn't >>> see >>> ??? a good way to do better. >>> >>> >>> Good point. I guess I've seen more issues around processors catching >>> completion failures and leaving the model in a bad state for other >>> processors (or javac), than around the completion failure itself >>> causing >>> problems. It's important that processors can detect when they're seeing >>> invalid input. If they end up needing to be more vigilant about >>> checking >> >> FWIW, in the current state, it is possible to check >> DeclaredType.asElement().asType().getKind() == TypeKind.ERROR to see if >> the type's symbol is broken. (I agree it is quite cumbersome.) >> >>> for error types that's a slightly incompatible change. >> >> AFAIK, doing TypeElement.getSuperclass() may currently lead to several >> results depending on the exact circumstances: >> 1) a DECLARED type, that will throw a CompletionFailure (once) at some >> point if used >> 2) a DECLARED type that will not throw a CompletionFailure (because it >> was already thrown) >> 3) an ERROR type (if the TypeElement originates in the source code, and >> its superclass is missing) >> >> So eliminating any of these is probably a slightly incompatible change >> (which will need a CSR), but I personally think it is better than having >> different behaviors. OTOH, I suspect many APs already deal with these in >> some ways, so eliminating some shouldn't hopefully be that disruptive. >> >>> >>> There was some discussion in JDK-8187950 about declaring an >>> exception in >>> the API contract for methods that currently throw completion failures. >>> Did you consider taking that approach, and having the completion >>> failure >>> be rethrown to ensure other processors and javac see it if they try to >>> complete the same symbol? Maybe JDK-8190054 answers that question - it >>> sounds like there's a preference for returning error objects instead of >>> throwing? >> >> I was thinking of that, but I personally: >> -think the model is cleaner without the exceptions >> -am not convinced that it would be much simpler if we tried to change >> the implementation to more consistently throw the exception >> >> Thanks for your feedback, >> ???? Jan From srinivas.dama at oracle.com Thu Feb 22 11:20:49 2018 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Thu, 22 Feb 2018 03:20:49 -0800 (PST) Subject: RFR: 8198502(Exception at runtime due to lambda analyzer reattributes live AST) Message-ID: Hi, Please review http://cr.openjdk.java.net/~sdama/8198502/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8198502 Regards, Srinivas From maurizio.cimadamore at oracle.com Thu Feb 22 11:47:19 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 22 Feb 2018 11:47:19 +0000 Subject: RFR: 8198502(Exception at runtime due to lambda analyzer reattributes live AST) In-Reply-To: References: Message-ID: Looks good to me! Maurizio On 22/02/18 11:20, Srinivas Dama wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8198502/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8198502 > > Regards, > Srinivas From vicente.romero at oracle.com Thu Feb 22 13:46:27 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 22 Feb 2018 08:46:27 -0500 Subject: RFR: 8198502(Exception at runtime due to lambda analyzer reattributes live AST) In-Reply-To: References: Message-ID: <3f3afdd5-58ca-618b-cdc1-d2d7a05833e4@oracle.com> minor at the test case: interface Base { public abstract void run(); } could be: interface Base { void run(); } Thanks, Vicente On 02/22/2018 06:20 AM, Srinivas Dama wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8198502/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8198502 > > Regards, > Srinivas From srinivas.dama at oracle.com Thu Feb 22 14:27:31 2018 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Thu, 22 Feb 2018 06:27:31 -0800 (PST) Subject: RFR: 8198502(Exception at runtime due to lambda analyzer reattributes live AST) Message-ID: <75ee8210-f6ee-49c2-bc50-448c6e7527ff@default> Hi, Thank you for the comments. Please find revised webrev with small change in test at http://cr.openjdk.java.net/~sdama/8198502/webrev.01/ I am going to push this. Regards, Srinivas ----- Original Message ----- From: vicente.romero at oracle.com To: srinivas.dama at oracle.com, compiler-dev at openjdk.java.net Sent: Thursday, February 22, 2018 7:16:29 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: RFR: 8198502(Exception at runtime due to lambda analyzer reattributes live AST) minor at the test case: interface Base { public abstract void run(); } could be: interface Base { void run(); } Thanks, Vicente On 02/22/2018 06:20 AM, Srinivas Dama wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8198502/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8198502 > > Regards, > Srinivas From vicente.romero at oracle.com Thu Feb 22 16:43:37 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 22 Feb 2018 11:43:37 -0500 Subject: RFR: 8198502(Exception at runtime due to lambda analyzer reattributes live AST) In-Reply-To: <75ee8210-f6ee-49c2-bc50-448c6e7527ff@default> References: <75ee8210-f6ee-49c2-bc50-448c6e7527ff@default> Message-ID: On 02/22/2018 09:27 AM, Srinivas Dama wrote: > Hi, > Thank you for the comments. > > Please find revised webrev with small change in test at http://cr.openjdk.java.net/~sdama/8198502/webrev.01/ > I am going to push this. looks good, Vicente > > Regards, > Srinivas > > ----- Original Message ----- > From: vicente.romero at oracle.com > To: srinivas.dama at oracle.com, compiler-dev at openjdk.java.net > Sent: Thursday, February 22, 2018 7:16:29 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi > Subject: Re: RFR: 8198502(Exception at runtime due to lambda analyzer reattributes live AST) > > minor at the test case: > > interface Base { > public abstract void run(); > } > > could be: > > interface Base { > void run(); > } > > > Thanks, > Vicente > > On 02/22/2018 06:20 AM, Srinivas Dama wrote: >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8198502/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8198502 >> >> Regards, >> Srinivas From cushon at google.com Thu Feb 22 19:23:43 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 22 Feb 2018 11:23:43 -0800 Subject: spec clarification: type annotations on static nested types In-Reply-To: <5A8DF60F.7040002@oracle.com> References: <5A53D7C6.1070809@oracle.com> <5A8DF60F.7040002@oracle.com> Message-ID: On Wed, Feb 21, 2018 at 2:43 PM, Alex Buckley wrote: > On 2/21/2018 2:34 PM, Liam Miller-Cushon wrote: > >> I'm now reading "nested type" as meaning a type that is nested inside an >> *annotatable* type. >> i.e. in A.B where B is a non-static inner class, A is an annotatable >> enclosing instance type, so a type path is needed to indicate that in >> `A. at Foo B` the annotation is on B. >> However in A.B where B is a static member class, A is a 'scoping >> construct' rather than an annotatable type, so no type path is needed >> for `A. at Foo B` since B is the only annotatable type. >> > > That sounds plausible -- the "scoping construct" concept tunneled itself > fairly deeply into the JLS -- but I don't especially recall that "nested > type" in JVMS 4.7.20.2 meant to represent only non-static members. I can > only suggest more digging on type-annotations-spec-experts, sorry. I understand that to have been the intent of at least one member of the EG, and will try to get additional clarification on this point. I didn't find anything conclusive in type-annotations-spec-experts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Thu Feb 22 20:09:35 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 22 Feb 2018 21:09:35 +0100 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: References: Message-ID: On 21 February 2018 at 16:58, B. Blaser wrote: > On 19 February 2018 at 15:53, B. Blaser wrote: >> On 19 February 2018 at 00:42, B. Blaser wrote: >>> Hi, >>> >>> As explained in JDK-8189335, the following example crashes javac with >>> a NPE in Lower: >>> >>> class R { >>> private class R$1 {} >>> void f() { >>> new R$1(); >>> } >>> } >>> class R$1 {} > > Some precisions related to my laconic explanation about the problem and the fix. > > All starts in 'Lower.accessConstructorTag()' when searching for the > anonymous class 'R$1': > > http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1238 > > The top level class 'R$1' (not anonymous) is found and wrongly added > to 'accessConstrTags'. > > Then, when checking the access constructor tags in > 'Lower.checkAccessConstructorTags()', the 'outermostClass()' of the > top level class 'R$1' is requested: > > http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l778 > > 'R$1' being a top level class, its outermost class doesn't exist, > causing the NPE in 'Lower.makeEmptyClass()'. Errata: 'R$1' being a top level class, its outermost class definition ('R$1') doesn't exist within 'R', causing the NPE in 'Lower.makeEmptyClass()': http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l658 > The fix I suggested two days ago (here under) is then quite > straightforward. If a class 'R$1' exists but isn't anonymous, it has > to be skipped and a fresh anonymous class 'R$2' has to be created as > access constructor tag: > > http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1239 > > Nothing seems to be broken and the provided example compiles successfully. Here is a small variant of the previous patch that makes sure to reuse the same tag when multiple private constructors are present and 'R$1' isn't anonymous, for example: class R { private class A {} private class B {} void f() { new A(); new B(); } } class R$1{} Any comment or review is welcome! Cheers, Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java @@ -1232,15 +1232,19 @@ ClassSymbol accessConstructorTag() { ClassSymbol topClass = currentClass.outermostClass(); ModuleSymbol topModle = topClass.packge().modle; - Name flatname = names.fromString("" + topClass.getQualifiedName() + - target.syntheticNameChar() + - "1"); - ClassSymbol ctag = chk.getCompiled(topModle, flatname); - if (ctag == null) - ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; - // keep a record of all tags, to verify that all are generated as required - accessConstrTags = accessConstrTags.prepend(ctag); - return ctag; + for (int i = 1; ; i++) { + Name flatname = names.fromString("" + topClass.getQualifiedName() + + target.syntheticNameChar() + + i); + ClassSymbol ctag = chk.getCompiled(topModle, flatname); + if (ctag == null) + ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; + else if (!ctag.isAnonymous()) + continue; + // keep a record of all tags, to verify that all are generated as required + accessConstrTags = accessConstrTags.prepend(ctag); + return ctag; + } } /** Add all required access methods for a private symbol to enclosing class. > What do you think (I hope this is clearer)? > > Thanks, > Bernard > > >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >> @@ -1236,7 +1236,7 @@ >> target.syntheticNameChar() + >> "1"); >> ClassSymbol ctag = chk.getCompiled(topModle, flatname); >> - if (ctag == null) >> + if (ctag == null || !ctag.isAnonymous()) >> ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >> // keep a record of all tags, to verify that all are >> generated as required >> accessConstrTags = accessConstrTags.prepend(ctag); From jonathan.gibbons at oracle.com Fri Feb 23 00:37:47 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 22 Feb 2018 16:37:47 -0800 Subject: RFR: JDK-8186688 javax.lang.model.util.Elements.hides does not work correctly with interfaces Message-ID: <5A8F625B.70908@oracle.com> Please review a simple fix to Symbol, to provide the ability to see if an element is accessible in a subtype, as distinct from being inherited. This is needed by JavacElements.hides. The test was provided by Kumar, in the original bug report. JBS: https://bugs.openjdk.java.net/browse/JDK-8186688 Webrev: http://cr.openjdk.java.net/~jjg/8186688/webrev.00/ -- Jon From maurizio.cimadamore at oracle.com Fri Feb 23 00:59:20 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 23 Feb 2018 00:59:20 +0000 Subject: RFR: JDK-8186688 javax.lang.model.util.Elements.hides does not work correctly with interfaces In-Reply-To: <5A8F625B.70908@oracle.com> References: <5A8F625B.70908@oracle.com> Message-ID: <61c4107f-b3cf-bda2-e1cd-d140cfac46b2@oracle.com> If I'm correct this fix doesn't really change anything in terms of the implementation - the main goal is to give Symbol.isInheritedIn a 'fresh' name so that the overridden version in MethodSymbol is never called? Seems a tad subtle :-) I suggest making the new method 'final' to avoid possibilities of similar issues in the future (e.g. if an override of 'isAccessibleIn' is added, things will be broken again). Also, minor nit, the javadoc of the two sibling methods are slighty off sync ("of the given class" vs. "of given class"); copyright headers in tests could also use a refresh. Cheers Maurizio On 23/02/18 00:37, Jonathan Gibbons wrote: > Please review a simple fix to Symbol, to provide the ability to see if > an element is accessible in a subtype, as distinct from being > inherited.? This is needed by JavacElements.hides. > > The test was provided by Kumar, in the original bug report. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8186688 > Webrev: http://cr.openjdk.java.net/~jjg/8186688/webrev.00/ > > -- Jon From jan.lahoda at oracle.com Fri Feb 23 11:46:56 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 23 Feb 2018 12:46:56 +0100 Subject: RFR : JDK-8198552: Multiple javac plugins do not work at the same time. Message-ID: <5A8FFF30.7010902@oracle.com> Hi, When specifying multiple javac plugins using -Xplugin:, only one of them is run. The primary reason is that an incorrect (originally, there was only this one) method is overridden in Option.PLUGIN. I've found two more options that have the same problem ("-Xdoclint:" and "-Xdoclint/packages:"), I tried to fix those as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8198552 Webrev: http://cr.openjdk.java.net/~jlahoda/8198552/webrev.00/ How does this look? Thanks, Jan From jonathan.gibbons at oracle.com Fri Feb 23 15:32:46 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 23 Feb 2018 07:32:46 -0800 Subject: RFR: JDK-8186688 javax.lang.model.util.Elements.hides does not work correctly with interfaces In-Reply-To: <61c4107f-b3cf-bda2-e1cd-d140cfac46b2@oracle.com> References: <5A8F625B.70908@oracle.com> <61c4107f-b3cf-bda2-e1cd-d140cfac46b2@oracle.com> Message-ID: <124211cb-b7fa-9245-8775-e636ee5dc99e@oracle.com> Maurizio, Thanks for the review. Yes, the intent was not to change the behavior of any existing uses of isInheritedIn in javac, except for the one problem case in JavacElements, where even the existing comment hinted that the method being used seemed inappropriate, even though it originally had the desired functionality. I'll make the new method final and update the doc comments. I generally defer updating copyright headers to minimize trivia in the webrev. -- Jon On 2/22/18 4:59 PM, Maurizio Cimadamore wrote: > If I'm correct this fix doesn't really change anything in terms of the > implementation - the main goal is to give Symbol.isInheritedIn a > 'fresh' name so that the overridden version in MethodSymbol is never > called? Seems a tad subtle :-) > > I suggest making the new method 'final' to avoid possibilities of > similar issues in the future (e.g. if an override of 'isAccessibleIn' > is added, things will be broken again). > > Also, minor nit, the javadoc of the two sibling methods are slighty > off sync ("of the given class" vs. "of given class"); copyright > headers in tests could also use a refresh. > > Cheers > Maurizio > > > On 23/02/18 00:37, Jonathan Gibbons wrote: >> Please review a simple fix to Symbol, to provide the ability to see >> if an element is accessible in a subtype, as distinct from being >> inherited.? This is needed by JavacElements.hides. >> >> The test was provided by Kumar, in the original bug report. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8186688 >> Webrev: http://cr.openjdk.java.net/~jjg/8186688/webrev.00/ >> >> -- Jon > From jonathan.gibbons at oracle.com Fri Feb 23 20:02:48 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 23 Feb 2018 12:02:48 -0800 Subject: RFR: JDK-8186688 javax.lang.model.util.Elements.hides does not work correctly with interfaces In-Reply-To: <124211cb-b7fa-9245-8775-e636ee5dc99e@oracle.com> References: <5A8F625B.70908@oracle.com> <61c4107f-b3cf-bda2-e1cd-d140cfac46b2@oracle.com> <124211cb-b7fa-9245-8775-e636ee5dc99e@oracle.com> Message-ID: <5A907368.8090306@oracle.com> Updated webrev. Made new method final, and fixed comment. Copyright in test files was correct, and corresponds to when the test was written and published, albeit in JBS. Updated webrev: http://cr.openjdk.java.net/~jjg/8186688/webrev.01 -- Jon On 02/23/2018 07:32 AM, Jonathan Gibbons wrote: > Maurizio, > > Thanks for the review. > > Yes, the intent was not to change the behavior of any existing uses of > isInheritedIn in javac, except for the one problem case in > JavacElements, where even the existing comment hinted that the method > being used seemed inappropriate, even though it originally had the > desired functionality. > > I'll make the new method final and update the doc comments. I > generally defer updating copyright headers to minimize trivia in the > webrev. > > -- Jon > > On 2/22/18 4:59 PM, Maurizio Cimadamore wrote: >> If I'm correct this fix doesn't really change anything in terms of >> the implementation - the main goal is to give Symbol.isInheritedIn a >> 'fresh' name so that the overridden version in MethodSymbol is never >> called? Seems a tad subtle :-) >> >> I suggest making the new method 'final' to avoid possibilities of >> similar issues in the future (e.g. if an override of 'isAccessibleIn' >> is added, things will be broken again). >> >> Also, minor nit, the javadoc of the two sibling methods are slighty >> off sync ("of the given class" vs. "of given class"); copyright >> headers in tests could also use a refresh. >> >> Cheers >> Maurizio >> >> >> On 23/02/18 00:37, Jonathan Gibbons wrote: >>> Please review a simple fix to Symbol, to provide the ability to see >>> if an element is accessible in a subtype, as distinct from being >>> inherited. This is needed by JavacElements.hides. >>> >>> The test was provided by Kumar, in the original bug report. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186688 >>> Webrev: http://cr.openjdk.java.net/~jjg/8186688/webrev.00/ >>> >>> -- Jon >> > From vicente.romero at oracle.com Fri Feb 23 21:06:28 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 23 Feb 2018 16:06:28 -0500 Subject: RFR: JDK-8186688 javax.lang.model.util.Elements.hides does not work correctly with interfaces In-Reply-To: <5A907368.8090306@oracle.com> References: <5A8F625B.70908@oracle.com> <61c4107f-b3cf-bda2-e1cd-d140cfac46b2@oracle.com> <124211cb-b7fa-9245-8775-e636ee5dc99e@oracle.com> <5A907368.8090306@oracle.com> Message-ID: <50c199da-7600-3696-cb54-f0cdedaca1ed@oracle.com> looks good to me, Vicente On 02/23/2018 03:02 PM, Jonathan Gibbons wrote: > Updated webrev.? Made new method final, and fixed comment. > > Copyright in test files was correct, and corresponds to when the test > was written and published, albeit in JBS. > > Updated webrev: http://cr.openjdk.java.net/~jjg/8186688/webrev.01 > > -- Jon > > On 02/23/2018 07:32 AM, Jonathan Gibbons wrote: >> Maurizio, >> >> Thanks for the review. >> >> Yes, the intent was not to change the behavior of any existing uses >> of isInheritedIn in javac, except for the one problem case in >> JavacElements, where even the existing comment hinted that the method >> being used seemed inappropriate, even though it originally had the >> desired functionality. >> >> I'll make the new method final and update the doc comments. I >> generally defer updating copyright headers to minimize trivia in the >> webrev. >> >> -- Jon >> >> On 2/22/18 4:59 PM, Maurizio Cimadamore wrote: >>> If I'm correct this fix doesn't really change anything in terms of >>> the implementation - the main goal is to give Symbol.isInheritedIn a >>> 'fresh' name so that the overridden version in MethodSymbol is never >>> called? Seems a tad subtle :-) >>> >>> I suggest making the new method 'final' to avoid possibilities of >>> similar issues in the future (e.g. if an override of >>> 'isAccessibleIn' is added, things will be broken again). >>> >>> Also, minor nit, the javadoc of the two sibling methods are slighty >>> off sync ("of the given class" vs. "of given class"); copyright >>> headers in tests could also use a refresh. >>> >>> Cheers >>> Maurizio >>> >>> >>> On 23/02/18 00:37, Jonathan Gibbons wrote: >>>> Please review a simple fix to Symbol, to provide the ability to see >>>> if an element is accessible in a subtype, as distinct from being >>>> inherited.? This is needed by JavacElements.hides. >>>> >>>> The test was provided by Kumar, in the original bug report. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186688 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8186688/webrev.00/ >>>> >>>> -- Jon >>> >> > From vicente.romero at oracle.com Fri Feb 23 21:14:34 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 23 Feb 2018 16:14:34 -0500 Subject: RFR : JDK-8198552: Multiple javac plugins do not work at the same time. In-Reply-To: <5A8FFF30.7010902@oracle.com> References: <5A8FFF30.7010902@oracle.com> Message-ID: I think that for completeness we should test the case when the plugin(s) are defined inside a module, Thanks, Vicente On 02/23/2018 06:46 AM, Jan Lahoda wrote: > Hi, > > When specifying multiple javac plugins using -Xplugin:, only one of > them is run. The primary reason is that an incorrect (originally, > there was only this one) method is overridden in Option.PLUGIN. I've > found two more options that have the same problem ("-Xdoclint:" and > "-Xdoclint/packages:"), I tried to fix those as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198552 > Webrev: > http://cr.openjdk.java.net/~jlahoda/8198552/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Fri Feb 23 21:24:45 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 23 Feb 2018 16:24:45 -0500 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: References: Message-ID: <3407c6b8-2f83-813a-09e3-7efa0cd8e92b@oracle.com> Hi Bernard, Usually when we touch this area of the compiler we do the following test: build the whole JDK, another big corpus could make it too, with and without the fix applied and then we compare the class files obtained, if no new tag classes are generated for cases where they shouldn't and if there are no unjustified changes to the rest of the classes, then we are more confident about the fix. Thanks, Vicente On 02/22/2018 03:09 PM, B. Blaser wrote: > On 21 February 2018 at 16:58, B. Blaser wrote: >> On 19 February 2018 at 15:53, B. Blaser wrote: >>> On 19 February 2018 at 00:42, B. Blaser wrote: >>>> Hi, >>>> >>>> As explained in JDK-8189335, the following example crashes javac with >>>> a NPE in Lower: >>>> >>>> class R { >>>> private class R$1 {} >>>> void f() { >>>> new R$1(); >>>> } >>>> } >>>> class R$1 {} >> Some precisions related to my laconic explanation about the problem and the fix. >> >> All starts in 'Lower.accessConstructorTag()' when searching for the >> anonymous class 'R$1': >> >> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1238 >> >> The top level class 'R$1' (not anonymous) is found and wrongly added >> to 'accessConstrTags'. >> >> Then, when checking the access constructor tags in >> 'Lower.checkAccessConstructorTags()', the 'outermostClass()' of the >> top level class 'R$1' is requested: >> >> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l778 >> >> 'R$1' being a top level class, its outermost class doesn't exist, >> causing the NPE in 'Lower.makeEmptyClass()'. > Errata: 'R$1' being a top level class, its outermost class definition > ('R$1') doesn't exist within 'R', causing the NPE in > 'Lower.makeEmptyClass()': > > http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l658 > >> The fix I suggested two days ago (here under) is then quite >> straightforward. If a class 'R$1' exists but isn't anonymous, it has >> to be skipped and a fresh anonymous class 'R$2' has to be created as >> access constructor tag: >> >> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1239 >> >> Nothing seems to be broken and the provided example compiles successfully. > Here is a small variant of the previous patch that makes sure to reuse > the same tag when multiple private constructors are present and 'R$1' > isn't anonymous, for example: > > class R { > private class A {} > private class B {} > void f() { > new A(); > new B(); > } > } > class R$1{} > > Any comment or review is welcome! > > Cheers, > Bernard > > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > @@ -1232,15 +1232,19 @@ > ClassSymbol accessConstructorTag() { > ClassSymbol topClass = currentClass.outermostClass(); > ModuleSymbol topModle = topClass.packge().modle; > - Name flatname = names.fromString("" + topClass.getQualifiedName() + > - target.syntheticNameChar() + > - "1"); > - ClassSymbol ctag = chk.getCompiled(topModle, flatname); > - if (ctag == null) > - ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; > - // keep a record of all tags, to verify that all are > generated as required > - accessConstrTags = accessConstrTags.prepend(ctag); > - return ctag; > + for (int i = 1; ; i++) { > + Name flatname = names.fromString("" + topClass.getQualifiedName() + > + target.syntheticNameChar() + > + i); > + ClassSymbol ctag = chk.getCompiled(topModle, flatname); > + if (ctag == null) > + ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; > + else if (!ctag.isAnonymous()) > + continue; > + // keep a record of all tags, to verify that all are > generated as required > + accessConstrTags = accessConstrTags.prepend(ctag); > + return ctag; > + } > } > > /** Add all required access methods for a private symbol to > enclosing class. > >> What do you think (I hope this is clearer)? >> >> Thanks, >> Bernard >> >> >>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> @@ -1236,7 +1236,7 @@ >>> target.syntheticNameChar() + >>> "1"); >>> ClassSymbol ctag = chk.getCompiled(topModle, flatname); >>> - if (ctag == null) >>> + if (ctag == null || !ctag.isAnonymous()) >>> ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >>> // keep a record of all tags, to verify that all are >>> generated as required >>> accessConstrTags = accessConstrTags.prepend(ctag); From bsrbnd at gmail.com Sat Feb 24 20:39:17 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 24 Feb 2018 21:39:17 +0100 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: <3407c6b8-2f83-813a-09e3-7efa0cd8e92b@oracle.com> References: <3407c6b8-2f83-813a-09e3-7efa0cd8e92b@oracle.com> Message-ID: Hi Vicente, Thanks for your answer. On 23 February 2018 at 22:24, Vicente Romero wrote: > Hi Bernard, > > Usually when we touch this area of the compiler we do the following test: > build the whole JDK, another big corpus could make it too, with and without > the fix applied and then we compare the class files obtained, if no new tag > classes are generated for cases where they shouldn't and if there are no > unjustified changes to the rest of the classes, then we are more confident > about the fix. You're right, this would be a very good test but I probably won't have time to do that soon. I also know that all jdk tests have to pass successfully and I only ran javac tests, sorry... However, I hope my work will still be helpful. Bernard > Thanks, > Vicente > > > On 02/22/2018 03:09 PM, B. Blaser wrote: >> >> On 21 February 2018 at 16:58, B. Blaser wrote: >>> >>> On 19 February 2018 at 15:53, B. Blaser wrote: >>>> >>>> On 19 February 2018 at 00:42, B. Blaser wrote: >>>>> >>>>> Hi, >>>>> >>>>> As explained in JDK-8189335, the following example crashes javac with >>>>> a NPE in Lower: >>>>> >>>>> class R { >>>>> private class R$1 {} >>>>> void f() { >>>>> new R$1(); >>>>> } >>>>> } >>>>> class R$1 {} >>> >>> Some precisions related to my laconic explanation about the problem and >>> the fix. >>> >>> All starts in 'Lower.accessConstructorTag()' when searching for the >>> anonymous class 'R$1': >>> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1238 >>> >>> The top level class 'R$1' (not anonymous) is found and wrongly added >>> to 'accessConstrTags'. >>> >>> Then, when checking the access constructor tags in >>> 'Lower.checkAccessConstructorTags()', the 'outermostClass()' of the >>> top level class 'R$1' is requested: >>> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l778 >>> >>> 'R$1' being a top level class, its outermost class doesn't exist, >>> causing the NPE in 'Lower.makeEmptyClass()'. >> >> Errata: 'R$1' being a top level class, its outermost class definition >> ('R$1') doesn't exist within 'R', causing the NPE in >> 'Lower.makeEmptyClass()': >> >> >> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l658 >> >>> The fix I suggested two days ago (here under) is then quite >>> straightforward. If a class 'R$1' exists but isn't anonymous, it has >>> to be skipped and a fresh anonymous class 'R$2' has to be created as >>> access constructor tag: >>> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1239 >>> >>> Nothing seems to be broken and the provided example compiles >>> successfully. >> >> Here is a small variant of the previous patch that makes sure to reuse >> the same tag when multiple private constructors are present and 'R$1' >> isn't anonymous, for example: >> >> class R { >> private class A {} >> private class B {} >> void f() { >> new A(); >> new B(); >> } >> } >> class R$1{} >> >> Any comment or review is welcome! >> >> Cheers, >> Bernard >> >> >> diff --git >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >> @@ -1232,15 +1232,19 @@ >> ClassSymbol accessConstructorTag() { >> ClassSymbol topClass = currentClass.outermostClass(); >> ModuleSymbol topModle = topClass.packge().modle; >> - Name flatname = names.fromString("" + topClass.getQualifiedName() >> + >> - target.syntheticNameChar() + >> - "1"); >> - ClassSymbol ctag = chk.getCompiled(topModle, flatname); >> - if (ctag == null) >> - ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >> - // keep a record of all tags, to verify that all are >> generated as required >> - accessConstrTags = accessConstrTags.prepend(ctag); >> - return ctag; >> + for (int i = 1; ; i++) { >> + Name flatname = names.fromString("" + >> topClass.getQualifiedName() + >> + target.syntheticNameChar() + >> + i); >> + ClassSymbol ctag = chk.getCompiled(topModle, flatname); >> + if (ctag == null) >> + ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >> + else if (!ctag.isAnonymous()) >> + continue; >> + // keep a record of all tags, to verify that all are >> generated as required >> + accessConstrTags = accessConstrTags.prepend(ctag); >> + return ctag; >> + } >> } >> >> /** Add all required access methods for a private symbol to >> enclosing class. >> >>> What do you think (I hope this is clearer)? >>> >>> Thanks, >>> Bernard >>> >>> >>>> diff --git >>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>> @@ -1236,7 +1236,7 @@ >>>> target.syntheticNameChar() + >>>> "1"); >>>> ClassSymbol ctag = chk.getCompiled(topModle, flatname); >>>> - if (ctag == null) >>>> + if (ctag == null || !ctag.isAnonymous()) >>>> ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >>>> // keep a record of all tags, to verify that all are >>>> generated as required >>>> accessConstrTags = accessConstrTags.prepend(ctag); > > From bsrbnd at gmail.com Sun Feb 25 12:50:08 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 25 Feb 2018 13:50:08 +0100 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: References: <3407c6b8-2f83-813a-09e3-7efa0cd8e92b@oracle.com> Message-ID: On 24 February 2018 at 21:39, B. Blaser wrote: > Hi Vicente, > > Thanks for your answer. > > On 23 February 2018 at 22:24, Vicente Romero wrote: >> Hi Bernard, >> >> Usually when we touch this area of the compiler we do the following test: >> build the whole JDK, another big corpus could make it too, with and without >> the fix applied and then we compare the class files obtained, if no new tag >> classes are generated for cases where they shouldn't and if there are no >> unjustified changes to the rest of the classes, then we are more confident >> about the fix. > > You're right, this would be a very good test but I probably won't have > time to do that soon. > I also know that all jdk tests have to pass successfully and I only > ran javac tests, sorry... > However, I hope my work will still be helpful. Moreover, I note that several existing javac issues & tests are largely covering this area which make me rather confident about the fix, especially: https://bugs.openjdk.java.net/browse/JDK-6917288 test/langtools/tools/javac/6917288/GraphicalInstallerTest.java test/langtools/tools/javac/6917288/T6917288.java https://bugs.openjdk.java.net/browse/JDK-7199823 test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java https://bugs.openjdk.java.net/browse/JDK-8040129 test/langtools/tools/javac/classfiles/attributes/SourceFile/SyntheticClassTest.java https://bugs.openjdk.java.net/browse/JDK-8044537 http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java#l39 test/langtools/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java https://bugs.openjdk.java.net/browse/JDK-8042251 test/langtools/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerClassTest.java test/langtools/tools/javac/classfiles/attributes/innerclasses/InnerClassesInInnerEnumTest.java test/langtools/tools/javac/classfiles/attributes/innerclasses/InnerClassesTest.java Bernard > Bernard > >> Thanks, >> Vicente >> >> >> On 02/22/2018 03:09 PM, B. Blaser wrote: >>> >>> On 21 February 2018 at 16:58, B. Blaser wrote: >>>> >>>> On 19 February 2018 at 15:53, B. Blaser wrote: >>>>> >>>>> On 19 February 2018 at 00:42, B. Blaser wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> As explained in JDK-8189335, the following example crashes javac with >>>>>> a NPE in Lower: >>>>>> >>>>>> class R { >>>>>> private class R$1 {} >>>>>> void f() { >>>>>> new R$1(); >>>>>> } >>>>>> } >>>>>> class R$1 {} >>>> >>>> Some precisions related to my laconic explanation about the problem and >>>> the fix. >>>> >>>> All starts in 'Lower.accessConstructorTag()' when searching for the >>>> anonymous class 'R$1': >>>> >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1238 >>>> >>>> The top level class 'R$1' (not anonymous) is found and wrongly added >>>> to 'accessConstrTags'. >>>> >>>> Then, when checking the access constructor tags in >>>> 'Lower.checkAccessConstructorTags()', the 'outermostClass()' of the >>>> top level class 'R$1' is requested: >>>> >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l778 >>>> >>>> 'R$1' being a top level class, its outermost class doesn't exist, >>>> causing the NPE in 'Lower.makeEmptyClass()'. >>> >>> Errata: 'R$1' being a top level class, its outermost class definition >>> ('R$1') doesn't exist within 'R', causing the NPE in >>> 'Lower.makeEmptyClass()': >>> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l658 >>> >>>> The fix I suggested two days ago (here under) is then quite >>>> straightforward. If a class 'R$1' exists but isn't anonymous, it has >>>> to be skipped and a fresh anonymous class 'R$2' has to be created as >>>> access constructor tag: >>>> >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1239 >>>> >>>> Nothing seems to be broken and the provided example compiles >>>> successfully. >>> >>> Here is a small variant of the previous patch that makes sure to reuse >>> the same tag when multiple private constructors are present and 'R$1' >>> isn't anonymous, for example: >>> >>> class R { >>> private class A {} >>> private class B {} >>> void f() { >>> new A(); >>> new B(); >>> } >>> } >>> class R$1{} >>> >>> Any comment or review is welcome! >>> >>> Cheers, >>> Bernard >>> >>> >>> diff --git >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> @@ -1232,15 +1232,19 @@ >>> ClassSymbol accessConstructorTag() { >>> ClassSymbol topClass = currentClass.outermostClass(); >>> ModuleSymbol topModle = topClass.packge().modle; >>> - Name flatname = names.fromString("" + topClass.getQualifiedName() >>> + >>> - target.syntheticNameChar() + >>> - "1"); >>> - ClassSymbol ctag = chk.getCompiled(topModle, flatname); >>> - if (ctag == null) >>> - ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >>> - // keep a record of all tags, to verify that all are >>> generated as required >>> - accessConstrTags = accessConstrTags.prepend(ctag); >>> - return ctag; >>> + for (int i = 1; ; i++) { >>> + Name flatname = names.fromString("" + >>> topClass.getQualifiedName() + >>> + target.syntheticNameChar() + >>> + i); >>> + ClassSymbol ctag = chk.getCompiled(topModle, flatname); >>> + if (ctag == null) >>> + ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >>> + else if (!ctag.isAnonymous()) >>> + continue; >>> + // keep a record of all tags, to verify that all are >>> generated as required >>> + accessConstrTags = accessConstrTags.prepend(ctag); >>> + return ctag; >>> + } >>> } >>> >>> /** Add all required access methods for a private symbol to >>> enclosing class. >>> >>>> What do you think (I hope this is clearer)? >>>> >>>> Thanks, >>>> Bernard >>>> >>>> >>>>> diff --git >>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>>> @@ -1236,7 +1236,7 @@ >>>>> target.syntheticNameChar() + >>>>> "1"); >>>>> ClassSymbol ctag = chk.getCompiled(topModle, flatname); >>>>> - if (ctag == null) >>>>> + if (ctag == null || !ctag.isAnonymous()) >>>>> ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >>>>> // keep a record of all tags, to verify that all are >>>>> generated as required >>>>> accessConstrTags = accessConstrTags.prepend(ctag); >> >> From vicente.romero at oracle.com Mon Feb 26 17:35:51 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 26 Feb 2018 12:35:51 -0500 Subject: JDK-8189335: NPE in Lower due to class name clash In-Reply-To: References: <3407c6b8-2f83-813a-09e3-7efa0cd8e92b@oracle.com> Message-ID: <1820b494-3fbf-53f8-716d-9a0667a16c79@oracle.com> On 02/24/2018 03:39 PM, B. Blaser wrote: > Hi Vicente, > > Thanks for your answer. > > On 23 February 2018 at 22:24, Vicente Romero wrote: >> Hi Bernard, >> >> Usually when we touch this area of the compiler we do the following test: >> build the whole JDK, another big corpus could make it too, with and without >> the fix applied and then we compare the class files obtained, if no new tag >> classes are generated for cases where they shouldn't and if there are no >> unjustified changes to the rest of the classes, then we are more confident >> about the fix. > You're right, this would be a very good test but I probably won't have > time to do that soon. > I also know that all jdk tests have to pass successfully and I only > ran javac tests, sorry... > However, I hope my work will still be helpful. sure, I understand, I will take care of it. And yes your work is very helpful, Thanks, Vicente > > Bernard > >> Thanks, >> Vicente >> >> >> On 02/22/2018 03:09 PM, B. Blaser wrote: >>> On 21 February 2018 at 16:58, B. Blaser wrote: >>>> On 19 February 2018 at 15:53, B. Blaser wrote: >>>>> On 19 February 2018 at 00:42, B. Blaser wrote: >>>>>> Hi, >>>>>> >>>>>> As explained in JDK-8189335, the following example crashes javac with >>>>>> a NPE in Lower: >>>>>> >>>>>> class R { >>>>>> private class R$1 {} >>>>>> void f() { >>>>>> new R$1(); >>>>>> } >>>>>> } >>>>>> class R$1 {} >>>> Some precisions related to my laconic explanation about the problem and >>>> the fix. >>>> >>>> All starts in 'Lower.accessConstructorTag()' when searching for the >>>> anonymous class 'R$1': >>>> >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1238 >>>> >>>> The top level class 'R$1' (not anonymous) is found and wrongly added >>>> to 'accessConstrTags'. >>>> >>>> Then, when checking the access constructor tags in >>>> 'Lower.checkAccessConstructorTags()', the 'outermostClass()' of the >>>> top level class 'R$1' is requested: >>>> >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l778 >>>> >>>> 'R$1' being a top level class, its outermost class doesn't exist, >>>> causing the NPE in 'Lower.makeEmptyClass()'. >>> Errata: 'R$1' being a top level class, its outermost class definition >>> ('R$1') doesn't exist within 'R', causing the NPE in >>> 'Lower.makeEmptyClass()': >>> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l658 >>> >>>> The fix I suggested two days ago (here under) is then quite >>>> straightforward. If a class 'R$1' exists but isn't anonymous, it has >>>> to be skipped and a fresh anonymous class 'R$2' has to be created as >>>> access constructor tag: >>>> >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/02404e27d356/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l1239 >>>> >>>> Nothing seems to be broken and the provided example compiles >>>> successfully. >>> Here is a small variant of the previous patch that makes sure to reuse >>> the same tag when multiple private constructors are present and 'R$1' >>> isn't anonymous, for example: >>> >>> class R { >>> private class A {} >>> private class B {} >>> void f() { >>> new A(); >>> new B(); >>> } >>> } >>> class R$1{} >>> >>> Any comment or review is welcome! >>> >>> Cheers, >>> Bernard >>> >>> >>> diff --git >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>> @@ -1232,15 +1232,19 @@ >>> ClassSymbol accessConstructorTag() { >>> ClassSymbol topClass = currentClass.outermostClass(); >>> ModuleSymbol topModle = topClass.packge().modle; >>> - Name flatname = names.fromString("" + topClass.getQualifiedName() >>> + >>> - target.syntheticNameChar() + >>> - "1"); >>> - ClassSymbol ctag = chk.getCompiled(topModle, flatname); >>> - if (ctag == null) >>> - ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >>> - // keep a record of all tags, to verify that all are >>> generated as required >>> - accessConstrTags = accessConstrTags.prepend(ctag); >>> - return ctag; >>> + for (int i = 1; ; i++) { >>> + Name flatname = names.fromString("" + >>> topClass.getQualifiedName() + >>> + target.syntheticNameChar() + >>> + i); >>> + ClassSymbol ctag = chk.getCompiled(topModle, flatname); >>> + if (ctag == null) >>> + ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >>> + else if (!ctag.isAnonymous()) >>> + continue; >>> + // keep a record of all tags, to verify that all are >>> generated as required >>> + accessConstrTags = accessConstrTags.prepend(ctag); >>> + return ctag; >>> + } >>> } >>> >>> /** Add all required access methods for a private symbol to >>> enclosing class. >>> >>>> What do you think (I hope this is clearer)? >>>> >>>> Thanks, >>>> Bernard >>>> >>>> >>>>> diff --git >>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java >>>>> @@ -1236,7 +1236,7 @@ >>>>> target.syntheticNameChar() + >>>>> "1"); >>>>> ClassSymbol ctag = chk.getCompiled(topModle, flatname); >>>>> - if (ctag == null) >>>>> + if (ctag == null || !ctag.isAnonymous()) >>>>> ctag = makeEmptyClass(STATIC | SYNTHETIC, topClass).sym; >>>>> // keep a record of all tags, to verify that all are >>>>> generated as required >>>>> accessConstrTags = accessConstrTags.prepend(ctag); >> From maurizio.cimadamore at oracle.com Mon Feb 26 23:32:50 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 26 Feb 2018 23:32:50 +0000 Subject: Bug: no line number for invokedynamic In-Reply-To: References: <2d1d22d3-c981-a03e-1fc8-6eb19808446a@oracle.com> <8ed9468e-e211-792d-aa1a-b8219ae15ff6@oracle.com> Message-ID: <89272c3c-7c4b-2189-c2bf-17abe77e2f5d@oracle.com> On 21/02/18 11:59, B. Blaser wrote: > On 19 February 2018 at 13:04, Maurizio Cimadamore > wrote: >> >> On 16/02/18 11:43, B. Blaser wrote: >>> On 15 February 2018 at 18:19, Vicente Romero >>> wrote: >>>> >>>> On 02/14/2018 05:24 PM, B. Blaser wrote: >>>>> This is also somewhat related to JDK-8019486 associated test which >>>>> should probably be updated as next if we want to re-enable this >>>>> feature to have a clean stack trace. >>>> >>>> right if we were introduce any change in this area the test below would >>>> start failing >>> I tried some stepping with 'jdb' on the examples present in this test >>> case with the patch I suggested two days ago: >>> - if (!msym.isDynamic()) { >>> +// if (!msym.isDynamic()) { >>> code.statBegin(tree.pos); >>> - } >>> +// } >>> >>> It appeared to me smooth enough and the stack trace for the initial >>> example is right (line 7 instead of 6). >> I wonder if this could depend on the IDE? The big we were referring to was >> created very early in JDK 8 lifetime. I wonder if IDEs have gotten better at >> ignoring indys during debugging? > So, not emitting the line number looks more like an old javac tweak to > help debuggers being smooth at the early days of invokedynamic... Well, thats what's the hack was for - but honestly I believe IDEs are still not skipping indys when debugging - so they kind of rely on what compilers do here. Maurizio > > Another thing I can note is that if we'd like to step into the > bootstrap method, it'd be right to stop first on the dynamic call > site. In such a situation, having the indy line number would be > necessary too. > > Bernard > > >> Would be very helpful if some IDE people >> with experience in debuggers could chime in here? >> >> Maurizio >> >> >>> Are we going in this direction? Is there any open JBS issue for that? >>> >>> Bernard >>> >>>>> Cheers, >>>>> Bernard >>>> >>>> Vicente >>>> >>>> >>>>> diff -r b3a833c9c6e9 >>>>> test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >>>>> --- a/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >>>>> Mon Feb 12 09:12:41 2018 +0100 >>>>> +++ b/test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java >>>>> Wed Feb 14 22:56:43 2018 +0100 >>>>> @@ -107,6 +107,8 @@ >>>>> static final int[][] deserializeExpectedLNT = { >>>>> // {line-number, start-pc}, >>>>> {05, 0}, //number -> number / 1 >>>>> + {21, 137}, //number -> number / 1 >>>>> + {05, 142}, //number -> number / 1 >>>>> }; >>>>> >>>>> static final int[][] lambdaBridgeExpectedLNT = { >>>>> @@ -123,6 +125,8 @@ >>>>> static final int[][] callExpectedLNT = { >>>>> // {line-number, start-pc}, >>>>> {29, 0}, //number -> number / 1 >>>>> + {30, 2}, //number -> number / 1 >>>>> + {29, 7}, //number -> number / 1 >>>>> {31, 10}, //number -> number / 1 >>>>> }; >>>>> >>>>> >>>>> On 14 February 2018 at 21:47, Maurizio Cimadamore >>>>> wrote: >>>>>> This comes from here: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8010404 >>>>>> >>>>>> Back when developing JDK 8 - we had a feeling that having the debugger >>>>>> stop >>>>>> at lambda capture sites would be confusing - and so we disabled it. >>>>>> >>>>>> I agree that in the stack trace case this decision seems to backfire a >>>>>> bit. >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>>>> >>>>>> On 14/02/18 15:26, B. Blaser wrote: >>>>>>> The line number is deliberately not emitted for dynamic callsites (but >>>>>>> I don't know why?), see below. >>>>>>> I hope this helps, >>>>>>> Bernard >>>>>>> >>>>>>> diff -r b3a833c9c6e9 >>>>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>>>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>>>>> Mon Feb 12 09:12:41 2018 +0100 >>>>>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java >>>>>>> Wed Feb 14 16:14:17 2018 +0100 >>>>>>> @@ -1649,9 +1649,9 @@ >>>>>>> MethodSymbol msym = >>>>>>> (MethodSymbol)TreeInfo.symbol(tree.meth); >>>>>>> genArgs(tree.args, >>>>>>> msym.externalType(types).getParameterTypes()); >>>>>>> - if (!msym.isDynamic()) { >>>>>>> +// if (!msym.isDynamic()) { >>>>>>> code.statBegin(tree.pos); >>>>>>> - } >>>>>>> +// } >>>>>>> result = m.invoke(); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> On 14 February 2018 at 09:16, Vladimir Parfinenko >>>>>>> wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I think I have found a minor bug. There is no line number information >>>>>>>> for invokedynamic instructions generated for method handle or lambda >>>>>>>> function. >>>>>>>> >>>>>>>> The problem can be reproduced using the example below and running it >>>>>>>> like this: >>>>>>>> >>>>>>>> $ javac Test.java >>>>>>>> $ rm A.class >>>>>>>> $ java Test >>>>>>>> Exception in thread "main" java.lang.NoClassDefFoundError: A >>>>>>>> at Test.main(Test.java:6) >>>>>>>> Caused by: java.lang.ClassNotFoundException: A >>>>>>>> ... >>>>>>>> >>>>>>>> The correct line number for this stack trace element would be 7. >>>>>>>> >>>>>>>> The line number table is missing an entry for invokedynamic: >>>>>>>> >>>>>>>> Code: >>>>>>>> stack=2, locals=2, args_size=1 >>>>>>>> 0: invokestatic #2 // Method >>>>>>>> fortyTwo:()I >>>>>>>> 3: invokedynamic #3, 0 // InvokeDynamic >>>>>>>> #0:apply:()Ljava/util/function/Function; >>>>>>>> 8: invokestatic #4 // Method >>>>>>>> foo:(ILjava/util/function/Function;)Ljava/lang/Object; >>>>>>>> 11: astore_1 >>>>>>>> 12: return >>>>>>>> LineNumberTable: >>>>>>>> line 6: 0 >>>>>>>> line 5: 8 >>>>>>>> line 9: 12 >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Vladimir Parfinenko >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Test.java >>>>>>>> >>>>>>>> // line 1 >>>>>>>> public class Test { >>>>>>>> public static void main(String[] args) { >>>>>>>> Object res = >>>>>>>> foo( >>>>>>>> fortyTwo(), // line 6 >>>>>>>> A::sqr // line 7 >>>>>>>> ); >>>>>>>> } >>>>>>>> >>>>>>>> public static Object foo(int x, >>>>>>>> java.util.function.Function>>>>>>> Integer> f) { >>>>>>>> return null; >>>>>>>> } >>>>>>>> >>>>>>>> public static int fortyTwo() { >>>>>>>> return 42; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> class A { >>>>>>>> public static int sqr(int x) { >>>>>>>> return x * x; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>>