From magnus.ihse.bursie at oracle.com Thu Dec 1 08:36:45 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 1 Dec 2016 09:36:45 +0100 Subject: RFR: JDK-8168607: langtools/test/Makefile should set -retain:fail,error by default In-Reply-To: <432cecad-691a-f3d0-b6b3-ef54df6a779b@oracle.com> References: <432cecad-691a-f3d0-b6b3-ef54df6a779b@oracle.com> Message-ID: On 2016-11-30 15:30, Erik Joelsson wrote: > This patch moves the langtools/test/Makefile one step closer being > alignmened with the rest of the test/*/Makefiles by adding the > -retain:fail,error jtreg option. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168607 > > Patch: > > diff -r ab39653a1e6d test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -161,6 +161,9 @@ > JTREG_TESTVM_MEMORY_OPTION = -vmoption:-Xmx768m > JTREG_OPTIONS += $(JTREG_TESTVM_MEMORY_OPTION) > > +# Retain all files for failing tests > +JTREG_OPTIONS += -retain:fail,error > + > ifdef EXTRA_JTREG_OPTIONS > JTREG_OPTIONS += $(EXTRA_JTREG_OPTIONS) > endif Looks good to me. > > > /Erik > From cushon at google.com Fri Dec 2 01:52:15 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 1 Dec 2016 17:52:15 -0800 Subject: RFR 8155674: Move javac towards a "by-file" compilation policy Message-ID: Hello, As discussed here: http://mail.openjdk.java.net/pipermail/compiler-dev/2016-April/010142.html desugar requires supertypes to be translated before subtypes, which causes classes to be translated separately from their compilation units when 'by file' is enabled. The proposed fix is for desugar to translate the entire compilation unit of any supertypes it encounters. Bug: https://bugs.openjdk.java.net/browse/JDK-8155674 Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8155674.patch Type: text/x-patch Size: 16601 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Fri Dec 2 02:06:23 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 01 Dec 2016 18:06:23 -0800 Subject: RFR 8155674: Move javac towards a "by-file" compilation policy In-Reply-To: References: Message-ID: <5840D71F.3020106@oracle.com> On 12/01/2016 05:52 PM, Liam Miller-Cushon wrote: > Hello, > > As discussed here: > http://mail.openjdk.java.net/pipermail/compiler-dev/2016-April/010142.html > > desugar requires supertypes to be translated before subtypes, which causes > classes to be translated separately from their compilation units when > 'by file' is enabled. > > The proposed fix is for desugar to translate the entire compilation > unit of > any supertypes it encounters. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155674 > > Thanks, > > Liam Liam, Does this address the potential problem with cycles that you mentioned in the original email? -- Jon From cushon at google.com Fri Dec 2 02:09:50 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 1 Dec 2016 18:09:50 -0800 Subject: MethodParameters class reading bug Message-ID: I think I found a MethodParameters class reading bug that affects annotation processing. If MethodParameters attributes are not available parameter names are inferred from the LVT, which uses two slots for doubles and longs. The logic for skipping the extra slot is used even if the data was read from a MethodParameters attribute, where the indices are always contiguous. So if javac sees a parameter of type double or long it skips the next entry in the MethodParameters table. There's a simple fix: diff -r 775a385c4af6 src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java Thu Dec 01 17:25:45 2016 -0800 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java Thu Dec 01 18:05:14 2016 -0800 @@ -2321,7 +2321,7 @@ ? parameterNameIndices[index] : 0); Name name = nameIdx == 0 ? names.empty : readName(nameIdx); paramNames = paramNames.prepend(name); - index += Code.width(t); + index += sawMethodParameters ? 1 : Code.width(t); } sym.savedParameterNames = paramNames.reverse(); } If my diagnosis sounds correct, I can clean up the patch and add a test. Here's the full repro: === Lib.java class Lib { void f(int a, long b, int c, int d) {} } === Test.java @Deprecated class Test {} === ParameterProcessor.java import java.util.Set; import javax.annotation.processing.*; import javax.lang.model.SourceVersion; import javax.lang.model.element.*; @SupportedAnnotationTypes("*") public class ParameterProcessor extends AbstractProcessor { @Override public boolean process(Set annotations, RoundEnvironment roundEnv) { if (roundEnv.processingOver()) { return false; } TypeElement s = processingEnv.getElementUtils().getTypeElement("Lib"); for (Element e : s.getEnclosedElements()) { if (e instanceof ExecutableElement) { for (VariableElement v : ((ExecutableElement) e).getParameters()) { System.err.printf(" %s %s\n", v.asType(), v.getSimpleName()); } } } return false; } @Override public SourceVersion getSupportedSourceVersion() { return SourceVersion.latest(); } } $ javac -parameters Lib.java $ javac ParameterProcessor.java $ javac -processor ParameterProcessor Test.java int a long b int d int arg3 Note that the third parameter is given the fourth parameter's name, and the fourth parameter's name is unknown. Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Fri Dec 2 02:18:31 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 1 Dec 2016 18:18:31 -0800 Subject: RFR 8155674: Move javac towards a "by-file" compilation policy In-Reply-To: <5840D71F.3020106@oracle.com> References: <5840D71F.3020106@oracle.com> Message-ID: On Thu, Dec 1, 2016 at 6:06 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Does this address the potential problem with cycles that you mentioned in > the original email? > Not fully. It improves the current behaviour by ensuring files always go through attr and flow as a unit, but classes may still be desugared separately from their compilation unit. One of the test cases has compilation units [One, Two] and [Three, Four], where Two extends Four, and Three extends One. There's no way to linearize that so supertypes are desugared first and files are desugared as a unit. Are there still plans to remove the ordering constraint in TransTypes? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Dec 2 11:22:23 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 2 Dec 2016 12:22:23 +0100 Subject: JDK-8147527: Wrong code generated for postfix unary operators In-Reply-To: References: <58382299.4010103@oracle.com> Message-ID: <5841596F.4060705@oracle.com> Hi, I've added these comments: //Need to use the "lhs" at two places, once on the future left hand side //and once in the future binary operator. But further processing may change //the components of the tree in place (see visitSelect for e.g. .super.), //so cloning the tree to avoid interference between the uses: //"tmp1" and "tmp2" may be the same instance //(for e.g. .super.). But further processing may //change the components of the tree in place (see visitSelect), //so cloning the tree to avoid interference between the two uses: Webrev: http://cr.openjdk.java.net/~jlahoda/8147527/webrev.01/ How does this look? Thanks! Jan On 29.11.2016 22:07, B. Blaser wrote: > Hi, > > 2016-11-29 16:28 GMT+01:00 Maurizio Cimadamore : >> Looks good to me. Use of shallow clone looks a tad odd - but I understand >> why it's the way it is - maybe worth adding a comment? >> >> Maurizio > > I agree that a short comment might be helpful, something like: > > // Shallow clone shall fit JDK-8147527 requirements, according to > related threads. > > Bernard > >> On 25/11/16 11:38, Jan Lahoda wrote: >>> >>> Hello, >>> >>> As noted here: >>> >>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010452.html >>> >>> javac sometimes generates code incorrectly, as discussed further in the >>> thread. >>> >>> The proposed fix is to not reuse the AST nodes on multiple places. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147527 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8147527/webrev.00/ >>> >>> Any feedback is welcome. >>> >>> Thanks to Bernard for his work on this. >>> >>> Jan >> >> From jan.lahoda at oracle.com Fri Dec 2 13:31:52 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 2 Dec 2016 14:31:52 +0100 Subject: MethodParameters class reading bug In-Reply-To: References: Message-ID: <584177C8.1050803@oracle.com> Hi Liam, Thanks for the report and patch, I've filled: https://bugs.openjdk.java.net/browse/JDK-8170667 I think you are right about the problem, and the fix seems very reasonable to me. Jan On 2.12.2016 03:09, Liam Miller-Cushon wrote: > I think I found a MethodParameters class reading bug that affects > annotation processing. > > If MethodParameters attributes are not available parameter names are > inferred from the LVT, which uses two slots for doubles and longs. The > logic for skipping the extra slot is used even if the data was read from > a MethodParameters attribute, where the indices are always contiguous. > So if javac sees a parameter of type double or long it skips the next > entry in the MethodParameters table. > > There's a simple fix: > > diff -r 775a385c4af6 > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.javaThu > Dec 01 17:25:45 2016 -0800 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.javaThu > Dec 01 18:05:14 2016 -0800 > @@ -2321,7 +2321,7 @@ > ? parameterNameIndices[index] : 0); > Name name = nameIdx == 0 ? names.empty : readName(nameIdx); > paramNames = paramNames.prepend(name); > - index += Code.width(t); > + index += sawMethodParameters ? 1 : Code.width(t); > } > sym.savedParameterNames = paramNames.reverse(); > } > > If my diagnosis sounds correct, I can clean up the patch and add a test. > > Here's the full repro: > > === Lib.java > class Lib { > void f(int a, long b, int c, int d) {} > } > === Test.java > @Deprecated > class Test {} > === ParameterProcessor.java > import java.util.Set; > import javax.annotation.processing.*; > import javax.lang.model.SourceVersion; > import javax.lang.model.element.*; > > @SupportedAnnotationTypes("*") > public class ParameterProcessor extends AbstractProcessor { > @Override > public boolean process(Set annotations, > RoundEnvironment roundEnv) { > if (roundEnv.processingOver()) { > return false; > } > TypeElement s = processingEnv.getElementUtils().getTypeElement("Lib"); > for (Element e : s.getEnclosedElements()) { > if (e instanceof ExecutableElement) { > for (VariableElement v : ((ExecutableElement) e).getParameters()) { > System.err.printf(" %s %s\n", v.asType(), v.getSimpleName()); > } > } > } > return false; > } > > @Override > public SourceVersion getSupportedSourceVersion() { > return SourceVersion.latest(); > } > } > > $ javac -parameters Lib.java > $ javac ParameterProcessor.java > $ javac -processor ParameterProcessor Test.java > int a > long b > int d > int arg3 > > Note that the third parameter is given the fourth parameter's name, and > the fourth parameter's name is unknown. > > Thanks, > > Liam From cushon at google.com Fri Dec 2 16:41:32 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 2 Dec 2016 08:41:32 -0800 Subject: RFR 8170667: ClassReader assigns method parameters from MethodParameters incorrectly when long/double parameters are present Message-ID: Thanks Jan, I've attached the full patch with a test. On Fri, Dec 2, 2016 at 5:31 AM, Jan Lahoda wrote: > Hi Liam, > > Thanks for the report and patch, I've filled: > https://bugs.openjdk.java.net/browse/JDK-8170667 > > I think you are right about the problem, and the fix seems very reasonable > to me. > > Jan > > > On 2.12.2016 03:09, Liam Miller-Cushon wrote: > >> I think I found a MethodParameters class reading bug that affects >> annotation processing. >> >> If MethodParameters attributes are not available parameter names are >> inferred from the LVT, which uses two slots for doubles and longs. The >> logic for skipping the extra slot is used even if the data was read from >> a MethodParameters attribute, where the indices are always contiguous. >> So if javac sees a parameter of type double or long it skips the next >> entry in the MethodParameters table. >> >> There's a simple fix: >> >> diff -r 775a385c4af6 >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ >> ClassReader.javaThu >> Dec 01 17:25:45 2016 -0800 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ >> ClassReader.javaThu >> Dec 01 18:05:14 2016 -0800 >> @@ -2321,7 +2321,7 @@ >> ? parameterNameIndices[index] : 0); >> Name name = nameIdx == 0 ? names.empty : readName(nameIdx); >> paramNames = paramNames.prepend(name); >> - index += Code.width(t); >> + index += sawMethodParameters ? 1 : Code.width(t); >> } >> sym.savedParameterNames = paramNames.reverse(); >> } >> >> If my diagnosis sounds correct, I can clean up the patch and add a test. >> >> Here's the full repro: >> >> === Lib.java >> class Lib { >> void f(int a, long b, int c, int d) {} >> } >> === Test.java >> @Deprecated >> class Test {} >> === ParameterProcessor.java >> import java.util.Set; >> import javax.annotation.processing.*; >> import javax.lang.model.SourceVersion; >> import javax.lang.model.element.*; >> >> @SupportedAnnotationTypes("*") >> public class ParameterProcessor extends AbstractProcessor { >> @Override >> public boolean process(Set annotations, >> RoundEnvironment roundEnv) { >> if (roundEnv.processingOver()) { >> return false; >> } >> TypeElement s = processingEnv.getElementUtils( >> ).getTypeElement("Lib"); >> for (Element e : s.getEnclosedElements()) { >> if (e instanceof ExecutableElement) { >> for (VariableElement v : ((ExecutableElement) >> e).getParameters()) { >> System.err.printf(" %s %s\n", v.asType(), v.getSimpleName()); >> } >> } >> } >> return false; >> } >> >> @Override >> public SourceVersion getSupportedSourceVersion() { >> return SourceVersion.latest(); >> } >> } >> >> $ javac -parameters Lib.java >> $ javac ParameterProcessor.java >> $ javac -processor ParameterProcessor Test.java >> int a >> long b >> int d >> int arg3 >> >> Note that the third parameter is given the fourth parameter's name, and >> the fourth parameter's name is unknown. >> >> Thanks, >> >> Liam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8170667.patch Type: application/octet-stream Size: 11092 bytes Desc: not available URL: From bsrbnd at gmail.com Sat Dec 3 12:07:28 2016 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 3 Dec 2016 13:07:28 +0100 Subject: JDK-8147527: Wrong code generated for postfix unary operators In-Reply-To: <5841596F.4060705@oracle.com> References: <58382299.4010103@oracle.com> <5841596F.4060705@oracle.com> Message-ID: Hi Jan, 2016-12-02 12:22 GMT+01:00 Jan Lahoda : > Hi, > > I've added these comments: > //Need to use the "lhs" at two places, once on the future left hand side > //and once in the future binary operator. But further processing may change > //the components of the tree in place (see visitSelect for e.g. > .super.), > //so cloning the tree to avoid interference between the uses: > Marvellous! > //"tmp1" and "tmp2" may be the same instance > //(for e.g. .super.). But further processing may > //change the components of the tree in place (see visitSelect), > //so cloning the tree to avoid interference between the two uses: > Ok ("tmp2 may refer to the instance held in tmp1", to be exact). > Webrev: > http://cr.openjdk.java.net/~jlahoda/8147527/webrev.01/ > > How does this look? > Perfect to me. I've also noticed that the desugared test probably misses a "qualified this" example (C.this.i++). This isn't really necessary but almost interesting as it involves the correct handling of "this$n" without any accessor generation (in opposition to "C.super.i++" which needs them), as shown below. > Thanks! > > Jan > That's all, thank you! Bernard diff -u test/tools/javac/desugar/BoxingAndSuper.java.rev01 test/tools/javac/desugar/BoxingAndSuper.java --- test/tools/javac/desugar/BoxingAndSuper.java.rev01 2016-12-03 10:45:22.803874916 +0100 +++ test/tools/javac/desugar/BoxingAndSuper.java 2016-12-03 12:12:16.246333070 +0100 @@ -204,6 +204,25 @@ " (let /*synthetic*/ final Integer $le2 = (Integer)this.i in (let /*synthetic*/ final Integer $le3 = this.i = Integer.valueOf((int)(this.i.intValue() + 1)) in $le2));\n" + "}\n"; runTest(code, expected); + //qualified this: + runTest("public class Test {\n" + + " Integer i;\n" + + " class Inner1 {\n" + + " class Inner2 {\n" + + " private Integer dump() {\n" + + " return Test.this.i++;\n" + + " }\n" + + " }\n" + + " }\n" + + "}", + "Test.Inner1.Inner2.dump()java.lang.Integer\n" + + "{\n" + + " return (let /*synthetic*/ final Integer $le0 = (Integer)this$1.this$0.i" + + " in (let /*synthetic*/ final Integer $le1 = this$1.this$0.i = " + + "Integer.valueOf((int)(this$1.this$0.i.intValue() + 1))" + + " in $le0));\n" + + "}\n" + ); } private final ToolBox tb = new ToolBox(); > > On 29.11.2016 22:07, B. Blaser wrote: >> >> Hi, >> >> 2016-11-29 16:28 GMT+01:00 Maurizio Cimadamore >> : >>> >>> Looks good to me. Use of shallow clone looks a tad odd - but I understand >>> why it's the way it is - maybe worth adding a comment? >>> >>> Maurizio >> >> >> I agree that a short comment might be helpful, something like: >> >> // Shallow clone shall fit JDK-8147527 requirements, according to >> related threads. >> >> Bernard >> >>> On 25/11/16 11:38, Jan Lahoda wrote: >>>> >>>> >>>> Hello, >>>> >>>> As noted here: >>>> >>>> >>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010452.html >>>> >>>> javac sometimes generates code incorrectly, as discussed further in the >>>> thread. >>>> >>>> The proposed fix is to not reuse the AST nodes on multiple places. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147527 >>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8147527/webrev.00/ >>>> >>>> Any feedback is welcome. >>>> >>>> Thanks to Bernard for his work on this. >>>> >>>> Jan >>> >>> >>> > From maurizio.cimadamore at oracle.com Sun Dec 4 22:11:32 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sun, 4 Dec 2016 22:11:32 +0000 Subject: RFR 8155674: Move javac towards a "by-file" compilation policy In-Reply-To: References: <5840D71F.3020106@oracle.com> Message-ID: <8cd56ef1-2d56-760d-6fd8-98f1648ddac3@oracle.com> Also don't forget that the cycle problem is temporary - as discussed in that thread, the fix here is to actually get rid of erasure (which is something we did already in an experimental patch in Valhalla) which then removes the ordering problems with supertypes/subtypes. We plan to do further experiments with this in the Valhalla repo and move this code to 10 when ready. Maurizio On 02/12/16 02:18, Liam Miller-Cushon wrote: > On Thu, Dec 1, 2016 at 6:06 PM, Jonathan Gibbons > > wrote: > > Does this address the potential problem with cycles that you > mentioned in > the original email? > > > Not fully. It improves the current behaviour by ensuring files always > go through attr and flow as a unit, but classes may still be desugared > separately from their compilation unit. > > One of the test cases has compilation units [One, Two] and [Three, > Four], where Two extends Four, and Three extends One. There's no way > to linearize that so supertypes are desugared first and files are > desugared as a unit. > > Are there still plans to removethe ordering constraint in TransTypes? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Dec 5 06:49:28 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 5 Dec 2016 07:49:28 +0100 Subject: JDK-8147527: Wrong code generated for postfix unary operators In-Reply-To: References: <58382299.4010103@oracle.com> <5841596F.4060705@oracle.com> Message-ID: <58450DF8.3050601@oracle.com> Hi, Thanks for your cvomments. Updated webrev: http://cr.openjdk.java.net/~jlahoda/8147527/webrev.02/ I changed the second comment to: //"tmp1" and "tmp2" may refer to the same instance //(for e.g. .super.). But further processing may //change the components of the tree in place (see visitSelect), //so cloning the tree to avoid interference between the two uses: and added your testcase. Any comments are welcome! Jan On 3.12.2016 13:07, B. Blaser wrote: > Hi Jan, > > 2016-12-02 12:22 GMT+01:00 Jan Lahoda : >> Hi, >> >> I've added these comments: >> //Need to use the "lhs" at two places, once on the future left hand side >> //and once in the future binary operator. But further processing may change >> //the components of the tree in place (see visitSelect for e.g. >> .super.), >> //so cloning the tree to avoid interference between the uses: >> > Marvellous! > >> //"tmp1" and "tmp2" may be the same instance >> //(for e.g. .super.). But further processing may >> //change the components of the tree in place (see visitSelect), >> //so cloning the tree to avoid interference between the two uses: >> > Ok ("tmp2 may refer to the instance held in tmp1", to be exact). > >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8147527/webrev.01/ >> >> How does this look? >> > Perfect to me. > > I've also noticed that the desugared test probably misses a "qualified > this" example (C.this.i++). > This isn't really necessary but almost interesting as it involves the > correct handling of "this$n" without any accessor generation (in > opposition to "C.super.i++" which needs them), as shown below. > >> Thanks! >> >> Jan >> > That's all, thank you! > > Bernard > > diff -u test/tools/javac/desugar/BoxingAndSuper.java.rev01 > test/tools/javac/desugar/BoxingAndSuper.java > --- test/tools/javac/desugar/BoxingAndSuper.java.rev01 2016-12-03 > 10:45:22.803874916 +0100 > +++ test/tools/javac/desugar/BoxingAndSuper.java 2016-12-03 > 12:12:16.246333070 +0100 > @@ -204,6 +204,25 @@ > " (let /*synthetic*/ final Integer $le2 = > (Integer)this.i in (let /*synthetic*/ final Integer $le3 = this.i = > Integer.valueOf((int)(this.i.intValue() + 1)) in $le2));\n" + > "}\n"; > runTest(code, expected); > + //qualified this: > + runTest("public class Test {\n" + > + " Integer i;\n" + > + " class Inner1 {\n" + > + " class Inner2 {\n" + > + " private Integer dump() {\n" + > + " return Test.this.i++;\n" + > + " }\n" + > + " }\n" + > + " }\n" + > + "}", > + "Test.Inner1.Inner2.dump()java.lang.Integer\n" + > + "{\n" + > + " return (let /*synthetic*/ final Integer $le0 = > (Integer)this$1.this$0.i" + > + " in (let /*synthetic*/ final Integer $le1 = > this$1.this$0.i = " + > + > "Integer.valueOf((int)(this$1.this$0.i.intValue() + 1))" + > + " in $le0));\n" + > + "}\n" > + ); > } > > private final ToolBox tb = new ToolBox(); > >> >> On 29.11.2016 22:07, B. Blaser wrote: >>> >>> Hi, >>> >>> 2016-11-29 16:28 GMT+01:00 Maurizio Cimadamore >>> : >>>> >>>> Looks good to me. Use of shallow clone looks a tad odd - but I understand >>>> why it's the way it is - maybe worth adding a comment? >>>> >>>> Maurizio >>> >>> >>> I agree that a short comment might be helpful, something like: >>> >>> // Shallow clone shall fit JDK-8147527 requirements, according to >>> related threads. >>> >>> Bernard >>> >>>> On 25/11/16 11:38, Jan Lahoda wrote: >>>>> >>>>> >>>>> Hello, >>>>> >>>>> As noted here: >>>>> >>>>> >>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010452.html >>>>> >>>>> javac sometimes generates code incorrectly, as discussed further in the >>>>> thread. >>>>> >>>>> The proposed fix is to not reuse the AST nodes on multiple places. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147527 >>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8147527/webrev.00/ >>>>> >>>>> Any feedback is welcome. >>>>> >>>>> Thanks to Bernard for his work on this. >>>>> >>>>> Jan >>>> >>>> >>>> >> From bsrbnd at gmail.com Mon Dec 5 11:56:20 2016 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 5 Dec 2016 12:56:20 +0100 Subject: JDK-8147527: Wrong code generated for postfix unary operators In-Reply-To: <58450DF8.3050601@oracle.com> References: <58382299.4010103@oracle.com> <5841596F.4060705@oracle.com> <58450DF8.3050601@oracle.com> Message-ID: Hi, 2016-12-05 7:49 GMT+01:00 Jan Lahoda : > Hi, > > Thanks for your cvomments. Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8147527/webrev.02/ > > I changed the second comment to: > //"tmp1" and "tmp2" may refer to the same instance > //(for e.g. .super.). But further processing may > //change the components of the tree in place (see visitSelect), > //so cloning the tree to avoid interference between the two uses: > > and added your testcase. > Wonderful! > Any comments are welcome! > > Jan > Ok for me, Bernard > > On 3.12.2016 13:07, B. Blaser wrote: >> >> Hi Jan, >> >> 2016-12-02 12:22 GMT+01:00 Jan Lahoda : >>> >>> Hi, >>> >>> I've added these comments: >>> //Need to use the "lhs" at two places, once on the future left hand side >>> //and once in the future binary operator. But further processing may >>> change >>> //the components of the tree in place (see visitSelect for e.g. >>> .super.), >>> //so cloning the tree to avoid interference between the uses: >>> >> Marvellous! >> >>> //"tmp1" and "tmp2" may be the same instance >>> //(for e.g. .super.). But further processing may >>> //change the components of the tree in place (see visitSelect), >>> //so cloning the tree to avoid interference between the two uses: >>> >> Ok ("tmp2 may refer to the instance held in tmp1", to be exact). >> >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8147527/webrev.01/ >>> >>> How does this look? >>> >> Perfect to me. >> >> I've also noticed that the desugared test probably misses a "qualified >> this" example (C.this.i++). >> This isn't really necessary but almost interesting as it involves the >> correct handling of "this$n" without any accessor generation (in >> opposition to "C.super.i++" which needs them), as shown below. >> >>> Thanks! >>> >>> Jan >>> >> That's all, thank you! >> >> Bernard >> >> diff -u test/tools/javac/desugar/BoxingAndSuper.java.rev01 >> test/tools/javac/desugar/BoxingAndSuper.java >> --- test/tools/javac/desugar/BoxingAndSuper.java.rev01 2016-12-03 >> 10:45:22.803874916 +0100 >> +++ test/tools/javac/desugar/BoxingAndSuper.java 2016-12-03 >> 12:12:16.246333070 +0100 >> @@ -204,6 +204,25 @@ >> " (let /*synthetic*/ final Integer $le2 = >> (Integer)this.i in (let /*synthetic*/ final Integer $le3 = this.i = >> Integer.valueOf((int)(this.i.intValue() + 1)) in $le2));\n" + >> "}\n"; >> runTest(code, expected); >> + //qualified this: >> + runTest("public class Test {\n" + >> + " Integer i;\n" + >> + " class Inner1 {\n" + >> + " class Inner2 {\n" + >> + " private Integer dump() {\n" + >> + " return Test.this.i++;\n" + >> + " }\n" + >> + " }\n" + >> + " }\n" + >> + "}", >> + "Test.Inner1.Inner2.dump()java.lang.Integer\n" + >> + "{\n" + >> + " return (let /*synthetic*/ final Integer $le0 = >> (Integer)this$1.this$0.i" + >> + " in (let /*synthetic*/ final Integer $le1 = >> this$1.this$0.i = " + >> + >> "Integer.valueOf((int)(this$1.this$0.i.intValue() + 1))" + >> + " in $le0));\n" + >> + "}\n" >> + ); >> } >> >> private final ToolBox tb = new ToolBox(); >> >>> >>> On 29.11.2016 22:07, B. Blaser wrote: >>>> >>>> >>>> Hi, >>>> >>>> 2016-11-29 16:28 GMT+01:00 Maurizio Cimadamore >>>> : >>>>> >>>>> >>>>> Looks good to me. Use of shallow clone looks a tad odd - but I >>>>> understand >>>>> why it's the way it is - maybe worth adding a comment? >>>>> >>>>> Maurizio >>>> >>>> >>>> >>>> I agree that a short comment might be helpful, something like: >>>> >>>> // Shallow clone shall fit JDK-8147527 requirements, according to >>>> related threads. >>>> >>>> Bernard >>>> >>>>> On 25/11/16 11:38, Jan Lahoda wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> As noted here: >>>>>> >>>>>> >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010452.html >>>>>> >>>>>> javac sometimes generates code incorrectly, as discussed further in >>>>>> the >>>>>> thread. >>>>>> >>>>>> The proposed fix is to not reuse the AST nodes on multiple places. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147527 >>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8147527/webrev.00/ >>>>>> >>>>>> Any feedback is welcome. >>>>>> >>>>>> Thanks to Bernard for his work on this. >>>>>> >>>>>> Jan >>>>> >>>>> >>>>> >>>>> >>> > From maurizio.cimadamore at oracle.com Mon Dec 5 12:43:33 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 5 Dec 2016 12:43:33 +0000 Subject: JDK-8147527: Wrong code generated for postfix unary operators In-Reply-To: <58450DF8.3050601@oracle.com> References: <58382299.4010103@oracle.com> <5841596F.4060705@oracle.com> <58450DF8.3050601@oracle.com> Message-ID: Looks good Thanks Maurizio On 05/12/16 06:49, Jan Lahoda wrote: > Hi, > > Thanks for your cvomments. Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8147527/webrev.02/ > > I changed the second comment to: > //"tmp1" and "tmp2" may refer to the same instance > //(for e.g. .super.). But further processing may > //change the components of the tree in place (see visitSelect), > //so cloning the tree to avoid interference between the two uses: > > and added your testcase. > > Any comments are welcome! > > Jan > > On 3.12.2016 13:07, B. Blaser wrote: >> Hi Jan, >> >> 2016-12-02 12:22 GMT+01:00 Jan Lahoda : >>> Hi, >>> >>> I've added these comments: >>> //Need to use the "lhs" at two places, once on the future left hand >>> side >>> //and once in the future binary operator. But further processing may >>> change >>> //the components of the tree in place (see visitSelect for e.g. >>> .super.), >>> //so cloning the tree to avoid interference between the uses: >>> >> Marvellous! >> >>> //"tmp1" and "tmp2" may be the same instance >>> //(for e.g. .super.). But further processing may >>> //change the components of the tree in place (see visitSelect), >>> //so cloning the tree to avoid interference between the two uses: >>> >> Ok ("tmp2 may refer to the instance held in tmp1", to be exact). >> >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8147527/webrev.01/ >>> >>> How does this look? >>> >> Perfect to me. >> >> I've also noticed that the desugared test probably misses a "qualified >> this" example (C.this.i++). >> This isn't really necessary but almost interesting as it involves the >> correct handling of "this$n" without any accessor generation (in >> opposition to "C.super.i++" which needs them), as shown below. >> >>> Thanks! >>> >>> Jan >>> >> That's all, thank you! >> >> Bernard >> >> diff -u test/tools/javac/desugar/BoxingAndSuper.java.rev01 >> test/tools/javac/desugar/BoxingAndSuper.java >> --- test/tools/javac/desugar/BoxingAndSuper.java.rev01 2016-12-03 >> 10:45:22.803874916 +0100 >> +++ test/tools/javac/desugar/BoxingAndSuper.java 2016-12-03 >> 12:12:16.246333070 +0100 >> @@ -204,6 +204,25 @@ >> " (let /*synthetic*/ final Integer $le2 = >> (Integer)this.i in (let /*synthetic*/ final Integer $le3 = this.i = >> Integer.valueOf((int)(this.i.intValue() + 1)) in $le2));\n" + >> "}\n"; >> runTest(code, expected); >> + //qualified this: >> + runTest("public class Test {\n" + >> + " Integer i;\n" + >> + " class Inner1 {\n" + >> + " class Inner2 {\n" + >> + " private Integer dump() {\n" + >> + " return Test.this.i++;\n" + >> + " }\n" + >> + " }\n" + >> + " }\n" + >> + "}", >> + "Test.Inner1.Inner2.dump()java.lang.Integer\n" + >> + "{\n" + >> + " return (let /*synthetic*/ final Integer $le0 = >> (Integer)this$1.this$0.i" + >> + " in (let /*synthetic*/ final Integer $le1 = >> this$1.this$0.i = " + >> + >> "Integer.valueOf((int)(this$1.this$0.i.intValue() + 1))" + >> + " in $le0));\n" + >> + "}\n" >> + ); >> } >> >> private final ToolBox tb = new ToolBox(); >> >>> >>> On 29.11.2016 22:07, B. Blaser wrote: >>>> >>>> Hi, >>>> >>>> 2016-11-29 16:28 GMT+01:00 Maurizio Cimadamore >>>> : >>>>> >>>>> Looks good to me. Use of shallow clone looks a tad odd - but I >>>>> understand >>>>> why it's the way it is - maybe worth adding a comment? >>>>> >>>>> Maurizio >>>> >>>> >>>> I agree that a short comment might be helpful, something like: >>>> >>>> // Shallow clone shall fit JDK-8147527 requirements, according to >>>> related threads. >>>> >>>> Bernard >>>> >>>>> On 25/11/16 11:38, Jan Lahoda wrote: >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> As noted here: >>>>>> >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010452.html >>>>>> >>>>>> >>>>>> javac sometimes generates code incorrectly, as discussed further >>>>>> in the >>>>>> thread. >>>>>> >>>>>> The proposed fix is to not reuse the AST nodes on multiple places. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147527 >>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8147527/webrev.00/ >>>>>> >>>>>> Any feedback is welcome. >>>>>> >>>>>> Thanks to Bernard for his work on this. >>>>>> >>>>>> Jan >>>>> >>>>> >>>>> >>> From vicente.romero at oracle.com Mon Dec 5 23:36:51 2016 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 5 Dec 2016 18:36:51 -0500 Subject: RFR 8170667: ClassReader assigns method parameters from MethodParameters incorrectly when long/double parameters are present In-Reply-To: References: Message-ID: <10bd1a1d-0be6-10f9-fb9a-dcae27cc3ece@oracle.com> Hi Liam, Thanks for the patch. It's probably a question of style but it seems to me like the number of classes used could be reduced. For example, the annotation processor could define the annotated methods that it will later discover and process. This is just a suggestion. Also regarding indentation, it's preferable to use 4 spaces instead of 2. Thanks, Vicente On 12/02/2016 11:41 AM, Liam Miller-Cushon wrote: > Thanks Jan, I've attached the full patch with a test. > > On Fri, Dec 2, 2016 at 5:31 AM, Jan Lahoda > wrote: > > Hi Liam, > > Thanks for the report and patch, I've filled: > https://bugs.openjdk.java.net/browse/JDK-8170667 > > > I think you are right about the problem, and the fix seems very > reasonable to me. > > Jan > > > On 2.12.2016 03:09, Liam Miller-Cushon wrote: > > I think I found a MethodParameters class reading bug that affects > annotation processing. > > If MethodParameters attributes are not available parameter > names are > inferred from the LVT, which uses two slots for doubles and > longs. The > logic for skipping the extra slot is used even if the data was > read from > a MethodParameters attribute, where the indices are always > contiguous. > So if javac sees a parameter of type double or long it skips > the next > entry in the MethodParameters table. > > There's a simple fix: > > diff -r 775a385c4af6 > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.javaThu > Dec 01 17:25:45 2016 -0800 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.javaThu > Dec 01 18:05:14 2016 -0800 > @@ -2321,7 +2321,7 @@ > ? parameterNameIndices[index] : 0); > Name name = nameIdx == 0 ? names.empty : > readName(nameIdx); > paramNames = paramNames.prepend(name); > - index += Code.width(t); > + index += sawMethodParameters ? 1 : Code.width(t); > } > sym.savedParameterNames = paramNames.reverse(); > } > > If my diagnosis sounds correct, I can clean up the patch and > add a test. > > Here's the full repro: > > === Lib.java > class Lib { > void f(int a, long b, int c, int d) {} > } > === Test.java > @Deprecated > class Test {} > === ParameterProcessor.java > import java.util.Set; > import javax.annotation.processing.*; > import javax.lang.model.SourceVersion; > import javax.lang.model.element.*; > > @SupportedAnnotationTypes("*") > public class ParameterProcessor extends AbstractProcessor { > @Override > public boolean process(Set annotations, > RoundEnvironment roundEnv) { > if (roundEnv.processingOver()) { > return false; > } > TypeElement s = > processingEnv.getElementUtils().getTypeElement("Lib"); > for (Element e : s.getEnclosedElements()) { > if (e instanceof ExecutableElement) { > for (VariableElement v : ((ExecutableElement) > e).getParameters()) { > System.err.printf(" %s %s\n", v.asType(), > v.getSimpleName()); > } > } > } > return false; > } > > @Override > public SourceVersion getSupportedSourceVersion() { > return SourceVersion.latest(); > } > } > > $ javac -parameters Lib.java > $ javac ParameterProcessor.java > $ javac -processor ParameterProcessor Test.java > int a > long b > int d > int arg3 > > Note that the third parameter is given the fourth parameter's > name, and > the fourth parameter's name is unknown. > > Thanks, > > Liam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Dec 7 20:10:37 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 7 Dec 2016 12:10:37 -0800 Subject: RFR 8170667: ClassReader assigns method parameters from MethodParameters incorrectly when long/double parameters are present In-Reply-To: <10bd1a1d-0be6-10f9-fb9a-dcae27cc3ece@oracle.com> References: <10bd1a1d-0be6-10f9-fb9a-dcae27cc3ece@oracle.com> Message-ID: Thanks for the review! I moved the entire test into one file, and fixed the style issues. On Mon, Dec 5, 2016 at 3:36 PM, Vicente Romero wrote: > Hi Liam, > > Thanks for the patch. It's probably a question of style but it seems to me > like the number of classes used could be reduced. For example, the > annotation processor could define the annotated methods that it will later > discover and process. This is just a suggestion. Also regarding > indentation, it's preferable to use 4 spaces instead of 2. > > Thanks, > Vicente > > > On 12/02/2016 11:41 AM, Liam Miller-Cushon wrote: > > Thanks Jan, I've attached the full patch with a test. > > On Fri, Dec 2, 2016 at 5:31 AM, Jan Lahoda wrote: > >> Hi Liam, >> >> Thanks for the report and patch, I've filled: >> https://bugs.openjdk.java.net/browse/JDK-8170667 >> >> I think you are right about the problem, and the fix seems very >> reasonable to me. >> >> Jan >> >> >> On 2.12.2016 03:09, Liam Miller-Cushon wrote: >> >>> I think I found a MethodParameters class reading bug that affects >>> annotation processing. >>> >>> If MethodParameters attributes are not available parameter names are >>> inferred from the LVT, which uses two slots for doubles and longs. The >>> logic for skipping the extra slot is used even if the data was read from >>> a MethodParameters attribute, where the indices are always contiguous. >>> So if javac sees a parameter of type double or long it skips the next >>> entry in the MethodParameters table. >>> >>> There's a simple fix: >>> >>> diff -r 775a385c4af6 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java >>> --- >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Cla >>> ssReader.javaThu >>> Dec 01 17:25:45 2016 -0800 >>> +++ >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Cla >>> ssReader.javaThu >>> Dec 01 18:05:14 2016 -0800 >>> @@ -2321,7 +2321,7 @@ >>> ? parameterNameIndices[index] : 0); >>> Name name = nameIdx == 0 ? names.empty : readName(nameIdx); >>> paramNames = paramNames.prepend(name); >>> - index += Code.width(t); >>> + index += sawMethodParameters ? 1 : Code.width(t); >>> } >>> sym.savedParameterNames = paramNames.reverse(); >>> } >>> >>> If my diagnosis sounds correct, I can clean up the patch and add a test. >>> >>> Here's the full repro: >>> >>> === Lib.java >>> class Lib { >>> void f(int a, long b, int c, int d) {} >>> } >>> === Test.java >>> @Deprecated >>> class Test {} >>> === ParameterProcessor.java >>> import java.util.Set; >>> import javax.annotation.processing.*; >>> import javax.lang.model.SourceVersion; >>> import javax.lang.model.element.*; >>> >>> @SupportedAnnotationTypes("*") >>> public class ParameterProcessor extends AbstractProcessor { >>> @Override >>> public boolean process(Set annotations, >>> RoundEnvironment roundEnv) { >>> if (roundEnv.processingOver()) { >>> return false; >>> } >>> TypeElement s = processingEnv.getElementUtils( >>> ).getTypeElement("Lib"); >>> for (Element e : s.getEnclosedElements()) { >>> if (e instanceof ExecutableElement) { >>> for (VariableElement v : ((ExecutableElement) >>> e).getParameters()) { >>> System.err.printf(" %s %s\n", v.asType(), v.getSimpleName()); >>> } >>> } >>> } >>> return false; >>> } >>> >>> @Override >>> public SourceVersion getSupportedSourceVersion() { >>> return SourceVersion.latest(); >>> } >>> } >>> >>> $ javac -parameters Lib.java >>> $ javac ParameterProcessor.java >>> $ javac -processor ParameterProcessor Test.java >>> int a >>> long b >>> int d >>> int arg3 >>> >>> Note that the third parameter is given the fourth parameter's name, and >>> the fourth parameter's name is unknown. >>> >>> Thanks, >>> >>> Liam >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8170667.2.patch Type: application/octet-stream Size: 4688 bytes Desc: not available URL: From cushon at google.com Wed Dec 7 20:19:57 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 7 Dec 2016 12:19:57 -0800 Subject: RFR 8155674: Move javac towards a "by-file" compilation policy In-Reply-To: <8cd56ef1-2d56-760d-6fd8-98f1648ddac3@oracle.com> References: <5840D71F.3020106@oracle.com> <8cd56ef1-2d56-760d-6fd8-98f1648ddac3@oracle.com> Message-ID: What do you think about pursuing this as an interim fix? It solves a problem we were seeing trying to analyze entire compilation units after flow, and it's harder to observe whether by-file is followed correctly after that. Or would you rather just wait for the ordering constraint to be removed in 10? On Sun, Dec 4, 2016 at 2:11 PM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Also don't forget that the cycle problem is temporary - as discussed in > that thread, the fix here is to actually get rid of erasure (which is > something we did already in an experimental patch in Valhalla) which then > removes the ordering problems with supertypes/subtypes. We plan to do > further experiments with this in the Valhalla repo and move this code to 10 > when ready. > > Maurizio > > On 02/12/16 02:18, Liam Miller-Cushon wrote: > > On Thu, Dec 1, 2016 at 6:06 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> Does this address the potential problem with cycles that you mentioned in >> the original email? >> > > Not fully. It improves the current behaviour by ensuring files always go > through attr and flow as a unit, but classes may still be desugared > separately from their compilation unit. > > One of the test cases has compilation units [One, Two] and [Three, Four], > where Two extends Four, and Three extends One. There's no way to linearize > that so supertypes are desugared first and files are desugared as a unit. > > Are there still plans to remove the ordering constraint in TransTypes? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Dec 7 20:36:19 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 7 Dec 2016 12:36:19 -0800 Subject: question about symlink handling Message-ID: This is somewhat related to: http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010544.html Starting in 9, javac uses canonical paths in isNameCompatible. So if a source file is a symlink, it reports errors if the symlink target (rather than the user-supplied path) doesn't match the public class name: $ echo 'public class Hello {}' > SOURCE $ ln -s SOURCE Hello.java $ javac Hello.java Hello.java:1: error: class Hello is public, should be declared in a file named Hello.java The diagnostic is confusing because it still uses the user-supplied path, but I'm more interested in whether isNameCompatible should be using canonical paths. For what it's worth I prefer the previous behaviour, because our build system uses symlinks extensively and the symlink target is a hash of the content instead of a valid Java file name. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Dec 7 21:53:13 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 7 Dec 2016 21:53:13 +0000 Subject: RFR 8155674: Move javac towards a "by-file" compilation policy In-Reply-To: References: <5840D71F.3020106@oracle.com> <8cd56ef1-2d56-760d-6fd8-98f1648ddac3@oracle.com> Message-ID: <41ca9df4-5ec5-2df0-96d7-1babeaa5846a@oracle.com> On 07/12/16 20:19, Liam Miller-Cushon wrote: > What do you think about pursuing this as an interim fix? It solves a > problem we were seeing trying to analyze entire compilation units > after flow, and it's harder to observe whether by-file is followed > correctly after that. Or would you rather just wait for the ordering > constraint to be removed in 10? I think it's very possible that the ordering constraint will go away early in 10, so perhaps it's not a long wait - after all I think this patch would presumably be considered to risky to pursue at this stage in 9? Maurizio > > On Sun, Dec 4, 2016 at 2:11 PM, Maurizio Cimadamore > > wrote: > > Also don't forget that the cycle problem is temporary - as > discussed in that thread, the fix here is to actually get rid of > erasure (which is something we did already in an experimental > patch in Valhalla) which then removes the ordering problems with > supertypes/subtypes. We plan to do further experiments with this > in the Valhalla repo and move this code to 10 when ready. > > Maurizio > > > On 02/12/16 02:18, Liam Miller-Cushon wrote: >> On Thu, Dec 1, 2016 at 6:06 PM, Jonathan Gibbons >> > > wrote: >> >> Does this address the potential problem with cycles that you >> mentioned in >> the original email? >> >> >> Not fully. It improves the current behaviour by ensuring files >> always go through attr and flow as a unit, but classes may still >> be desugared separately from their compilation unit. >> >> One of the test cases has compilation units [One, Two] and >> [Three, Four], where Two extends Four, and Three extends One. >> There's no way to linearize that so supertypes are desugared >> first and files are desugared as a unit. >> >> Are there still plans to removethe ordering constraint in TransTypes? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Dec 9 00:48:21 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Dec 2016 16:48:21 -0800 Subject: RFR: 8170953: CheckResourceKeys tests should declare the resource package to be open Message-ID: <5849FF55.1020006@oracle.com> Simple change to add update tests examining resources to open the packages. JBS: https://bugs.openjdk.java.net/browse/JDK-8170953 Webrev: http://cr.openjdk.java.net/~jjg/8170953/webrev.00 -- Jon From mandy.chung at oracle.com Fri Dec 9 00:50:56 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Dec 2016 16:50:56 -0800 Subject: RFR: 8170953: CheckResourceKeys tests should declare the resource package to be open In-Reply-To: <5849FF55.1020006@oracle.com> References: <5849FF55.1020006@oracle.com> Message-ID: <587290AD-895C-45AD-8D08-E86E4853EFD8@oracle.com> > On Dec 8, 2016, at 4:48 PM, Jonathan Gibbons wrote: > > Simple change to add update tests examining resources to open the packages. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8170953 > Webrev: http://cr.openjdk.java.net/~jjg/8170953/webrev.00 Looks good. Thanks for fixing it. Mandy From jan.lahoda at oracle.com Fri Dec 9 17:13:24 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 9 Dec 2016 18:13:24 +0100 Subject: RFR 8170667: ClassReader assigns method parameters from MethodParameters incorrectly when long/double parameters are present In-Reply-To: References: <10bd1a1d-0be6-10f9-fb9a-dcae27cc3ece@oracle.com> Message-ID: <584AE634.7070002@oracle.com> Thanks Liam, Vicente! Pushed: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/5d43af61155b Jan On 7.12.2016 21:10, Liam Miller-Cushon wrote: > Thanks for the review! I moved the entire test into one file, and fixed > the style issues. > > On Mon, Dec 5, 2016 at 3:36 PM, Vicente Romero > > wrote: > > Hi Liam, > > Thanks for the patch. It's probably a question of style but it seems > to me like the number of classes used could be reduced. For example, > the annotation processor could define the annotated methods that it > will later discover and process. This is just a suggestion. Also > regarding indentation, it's preferable to use 4 spaces instead of 2. > > Thanks, > Vicente > > > On 12/02/2016 11:41 AM, Liam Miller-Cushon wrote: >> Thanks Jan, I've attached the full patch with a test. >> >> On Fri, Dec 2, 2016 at 5:31 AM, Jan Lahoda > > wrote: >> >> Hi Liam, >> >> Thanks for the report and patch, I've filled: >> https://bugs.openjdk.java.net/browse/JDK-8170667 >> >> >> I think you are right about the problem, and the fix seems >> very reasonable to me. >> >> Jan >> >> >> On 2.12.2016 03:09, Liam Miller-Cushon wrote: >> >> I think I found a MethodParameters class reading bug that >> affects >> annotation processing. >> >> If MethodParameters attributes are not available parameter >> names are >> inferred from the LVT, which uses two slots for doubles >> and longs. The >> logic for skipping the extra slot is used even if the data >> was read from >> a MethodParameters attribute, where the indices are always >> contiguous. >> So if javac sees a parameter of type double or long it >> skips the next >> entry in the MethodParameters table. >> >> There's a simple fix: >> >> diff -r 775a385c4af6 >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.javaThu >> Dec 01 17:25:45 2016 -0800 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.javaThu >> Dec 01 18:05:14 2016 -0800 >> @@ -2321,7 +2321,7 @@ >> ? parameterNameIndices[index] : 0); >> Name name = nameIdx == 0 ? names.empty : >> readName(nameIdx); >> paramNames = paramNames.prepend(name); >> - index += Code.width(t); >> + index += sawMethodParameters ? 1 : Code.width(t); >> } >> sym.savedParameterNames = paramNames.reverse(); >> } >> >> If my diagnosis sounds correct, I can clean up the patch >> and add a test. >> >> Here's the full repro: >> >> === Lib.java >> class Lib { >> void f(int a, long b, int c, int d) {} >> } >> === Test.java >> @Deprecated >> class Test {} >> === ParameterProcessor.java >> import java.util.Set; >> import javax.annotation.processing.*; >> import javax.lang.model.SourceVersion; >> import javax.lang.model.element.*; >> >> @SupportedAnnotationTypes("*") >> public class ParameterProcessor extends AbstractProcessor { >> @Override >> public boolean process(Set >> annotations, >> RoundEnvironment roundEnv) { >> if (roundEnv.processingOver()) { >> return false; >> } >> TypeElement s = >> processingEnv.getElementUtils().getTypeElement("Lib"); >> for (Element e : s.getEnclosedElements()) { >> if (e instanceof ExecutableElement) { >> for (VariableElement v : ((ExecutableElement) >> e).getParameters()) { >> System.err.printf(" %s %s\n", v.asType(), >> v.getSimpleName()); >> } >> } >> } >> return false; >> } >> >> @Override >> public SourceVersion getSupportedSourceVersion() { >> return SourceVersion.latest(); >> } >> } >> >> $ javac -parameters Lib.java >> $ javac ParameterProcessor.java >> $ javac -processor ParameterProcessor Test.java >> int a >> long b >> int d >> int arg3 >> >> Note that the third parameter is given the fourth >> parameter's name, and >> the fourth parameter's name is unknown. >> >> Thanks, >> >> Liam >> >> > > From vicente.romero at oracle.com Fri Dec 9 17:48:52 2016 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 9 Dec 2016 12:48:52 -0500 Subject: RFR 8170667: ClassReader assigns method parameters from MethodParameters incorrectly when long/double parameters are present In-Reply-To: <584AE634.7070002@oracle.com> References: <10bd1a1d-0be6-10f9-fb9a-dcae27cc3ece@oracle.com> <584AE634.7070002@oracle.com> Message-ID: <7a616ed3-3a63-2e48-8dee-6a66ae12a9f0@oracle.com> On 12/09/2016 12:13 PM, Jan Lahoda wrote: > Thanks Liam, Vicente! > > Pushed: > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/5d43af61155b > > Jan thank you, Vicente > > On 7.12.2016 21:10, Liam Miller-Cushon wrote: >> Thanks for the review! I moved the entire test into one file, and fixed >> the style issues. >> >> On Mon, Dec 5, 2016 at 3:36 PM, Vicente Romero >> > wrote: >> >> Hi Liam, >> >> Thanks for the patch. It's probably a question of style but it seems >> to me like the number of classes used could be reduced. For example, >> the annotation processor could define the annotated methods that it >> will later discover and process. This is just a suggestion. Also >> regarding indentation, it's preferable to use 4 spaces instead of 2. >> >> Thanks, >> Vicente >> >> >> On 12/02/2016 11:41 AM, Liam Miller-Cushon wrote: >>> Thanks Jan, I've attached the full patch with a test. >>> >>> On Fri, Dec 2, 2016 at 5:31 AM, Jan Lahoda >> > wrote: >>> >>> Hi Liam, >>> >>> Thanks for the report and patch, I've filled: >>> https://bugs.openjdk.java.net/browse/JDK-8170667 >>> >>> >>> I think you are right about the problem, and the fix seems >>> very reasonable to me. >>> >>> Jan >>> >>> >>> On 2.12.2016 03:09, Liam Miller-Cushon wrote: >>> >>> I think I found a MethodParameters class reading bug that >>> affects >>> annotation processing. >>> >>> If MethodParameters attributes are not available parameter >>> names are >>> inferred from the LVT, which uses two slots for doubles >>> and longs. The >>> logic for skipping the extra slot is used even if the data >>> was read from >>> a MethodParameters attribute, where the indices are always >>> contiguous. >>> So if javac sees a parameter of type double or long it >>> skips the next >>> entry in the MethodParameters table. >>> >>> There's a simple fix: >>> >>> diff -r 775a385c4af6 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java >>> --- >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.javaThu >>> Dec 01 17:25:45 2016 -0800 >>> +++ >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.javaThu >>> Dec 01 18:05:14 2016 -0800 >>> @@ -2321,7 +2321,7 @@ >>> ? parameterNameIndices[index] : 0); >>> Name name = nameIdx == 0 ? names.empty : >>> readName(nameIdx); >>> paramNames = paramNames.prepend(name); >>> - index += Code.width(t); >>> + index += sawMethodParameters ? 1 : >>> Code.width(t); >>> } >>> sym.savedParameterNames = paramNames.reverse(); >>> } >>> >>> If my diagnosis sounds correct, I can clean up the patch >>> and add a test. >>> >>> Here's the full repro: >>> >>> === Lib.java >>> class Lib { >>> void f(int a, long b, int c, int d) {} >>> } >>> === Test.java >>> @Deprecated >>> class Test {} >>> === ParameterProcessor.java >>> import java.util.Set; >>> import javax.annotation.processing.*; >>> import javax.lang.model.SourceVersion; >>> import javax.lang.model.element.*; >>> >>> @SupportedAnnotationTypes("*") >>> public class ParameterProcessor extends AbstractProcessor { >>> @Override >>> public boolean process(Set >>> annotations, >>> RoundEnvironment roundEnv) { >>> if (roundEnv.processingOver()) { >>> return false; >>> } >>> TypeElement s = >>> processingEnv.getElementUtils().getTypeElement("Lib"); >>> for (Element e : s.getEnclosedElements()) { >>> if (e instanceof ExecutableElement) { >>> for (VariableElement v : ((ExecutableElement) >>> e).getParameters()) { >>> System.err.printf(" %s %s\n", v.asType(), >>> v.getSimpleName()); >>> } >>> } >>> } >>> return false; >>> } >>> >>> @Override >>> public SourceVersion getSupportedSourceVersion() { >>> return SourceVersion.latest(); >>> } >>> } >>> >>> $ javac -parameters Lib.java >>> $ javac ParameterProcessor.java >>> $ javac -processor ParameterProcessor Test.java >>> int a >>> long b >>> int d >>> int arg3 >>> >>> Note that the third parameter is given the fourth >>> parameter's name, and >>> the fourth parameter's name is unknown. >>> >>> Thanks, >>> >>> Liam >>> >>> >> >> From jonathan.gibbons at oracle.com Sat Dec 10 00:06:39 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 09 Dec 2016 16:06:39 -0800 Subject: RFR: 8170251: Add javax.tools.Tool.name() Message-ID: <584B470F.1000800@oracle.com> Please review this small fix to add a new default method to javax.tools.Tool to get the name of the tool, and implement that method for the javac and javadoc tools. Also, declare javac and javadoc to "provide" javax.tools.Tool. JBS: https://bugs.openjdk.java.net/browse/JDK-8170251 Webrev: http://cr.openjdk.java.net/~jjg/8170251/webrev.00/ -- Jon From joe.darcy at oracle.com Sat Dec 10 00:07:57 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 09 Dec 2016 16:07:57 -0800 Subject: RFR: 8170251: Add javax.tools.Tool.name() In-Reply-To: <584B470F.1000800@oracle.com> References: <584B470F.1000800@oracle.com> Message-ID: <584B475D.6080604@oracle.com> Looks good; cheers, -Joe On 12/9/2016 4:06 PM, Jonathan Gibbons wrote: > Please review this small fix to add a new default method to > javax.tools.Tool > to get the name of the tool, and implement that method for the javac and > javadoc tools. Also, declare javac and javadoc to "provide" > javax.tools.Tool. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8170251 > Webrev: http://cr.openjdk.java.net/~jjg/8170251/webrev.00/ > > -- Jon From mandy.chung at oracle.com Sat Dec 10 00:16:44 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Dec 2016 16:16:44 -0800 Subject: RFR: 8170251: Add javax.tools.Tool.name() In-Reply-To: <584B470F.1000800@oracle.com> References: <584B470F.1000800@oracle.com> Message-ID: <8C41679B-19B9-4D29-A388-7AEFE023EF2C@oracle.com> Looks good. Mandy > On Dec 9, 2016, at 4:06 PM, Jonathan Gibbons wrote: > > Please review this small fix to add a new default method to javax.tools.Tool > to get the name of the tool, and implement that method for the javac and > javadoc tools. Also, declare javac and javadoc to "provide" javax.tools.Tool. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8170251 > Webrev: http://cr.openjdk.java.net/~jjg/8170251/webrev.00/ > > -- Jon From eirbjo at gmail.com Sun Dec 11 19:12:15 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Sun, 11 Dec 2016 20:12:15 +0100 Subject: AssertionError in c.s.t.jc.comp.Modules.enter(..) Message-ID: Hi, I'm getting the following AssertionError from javac: (Full stacktrace at end of email) Exception in thread "main" java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:243) I wanted to reduce this to a minimal testcase, but after two hours when I thought I'd finally nailed it, I did an mvn clean somewhere and now I can't reproduce it :-) So what we have to work with is unfortunately my anecdotal observations: (Can't share the full mvn build..) * This is maven-compiler-plugin compiling via plexus-compiler via javax.tools.JavaCompiler * The AssertionError happens when calling diagnostic.getMessage(Locale) * Source file being compiled imports a class from a jar on the classpath which again imports from java.xml.bind * java.xml.bind is _not_ added with --add-modules-path * When I add --add-modules-path=java.xml.bind to the CompilationTask's options, the AssetionError is no longer thrown * When I remove a jar containing a javax.annotation.proccessing.Processor from the -classpath, the AssertionError was no longer thrown While my immediate problem is solved using --add-modules, I'm assuming this AssertionError is something which should/could be fixed? I'll try a bit more to create a minimal test case, but wanted to share my observations anyway, since compiler internal wizards might spot what's going on just from this. Sorry that this report is a bit messy, it was the best I could do this time. Let me know if there's more useful info I can provide. Cheers, Eirik. Full stacktrace: Exception in thread "main" java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:243) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:841) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821) at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1469) at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633) at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1273) at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1150) at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1076) at jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237) at jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52) at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1003) at jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136) at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:197) at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165) at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111) at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67) at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:183) at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165) at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111) at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67) at jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessage(JCDiagnostic.java:775) at jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$DiagnosticSourceUnwrapper.getMessage(ClientCodeWrapper.java:788) at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:131) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Mon Dec 12 09:40:33 2016 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 12 Dec 2016 10:40:33 +0100 Subject: [PATCH] 8148100: Convert lambda most specific positive tests to check runtime behavior In-Reply-To: References: <884c028b-f20e-53e2-5314-6ca2569556c6@oracle.com> Message-ID: Hi, Does this patch need to be improved? Thanks, Bernard 2016-09-21 16:24 GMT+02:00 bsrbnd : > Please find in attachment an all-in-one patch for the 9 tests, as > discussed previously. > > Bernard > > > 2016-09-19 16:01 GMT+02:00 bsrbnd : >> Thanks for your advices. >> >> I re-wrote, below, the patch in a more compliant way (I hope). >> I'll perhaps (probably) also go through the 8 others soon, if I have time... >> >> Bernard >> >> diff --git a/test/tools/javac/lambda/MostSpecific10.java >> b/test/tools/javac/lambda/MostSpecific10.java >> --- a/test/tools/javac/lambda/MostSpecific10.java >> +++ b/test/tools/javac/lambda/MostSpecific10.java >> @@ -25,9 +25,12 @@ >> * @test >> * @bug 8034223 >> * @summary Structural most-specific logic for lambdas, method refs, >> parens, and conditionals >> - * @compile MostSpecific10.java >> */ >> -class MostSpecific10 { >> +public class MostSpecific10 { >> + >> + public static void main(String[] args) { >> + new MostSpecific10().test(true); >> + } >> >> interface GetInt { >> int get(); >> @@ -38,7 +41,9 @@ >> } >> >> void m(GetInt getter) {} >> - void m(GetInteger getter) {} >> + void m(GetInteger getter) { >> + throw new RuntimeException("Less-specific method invocation: >> " + getter.getClass()); >> + } >> >> void test(boolean cond) { >> m(() -> 23); >> >> >> 2016-09-18 3:11 GMT+02:00 Jonathan Gibbons : >>> Bernard, >>> >>> Thanks for posting this patch. >>> >>> It's not wrong to say it explicitly, but the addition of the "@run main" >>> line is unnecessary, since that is the default behavior once you remove the >>> @compile. >>> >>> The replacement for void m(GetInteger getter) should be formatted in a more >>> standard manner. >>> >>> It's more common to put the main method at the head of a test, instead of at >>> the end. >>> >>> We can't check in "partial patches", so either you have to look at the 8 >>> other tests and fix them all together, or we have to accept this one change >>> as a "complete" fix for 8148100, and open a new, different issue for the 8 >>> other tests. (The OpenJDK rules only permit one changeset per issue per >>> repo,) >>> >>> -- Jon >>> >>> >>> >>> >>> On 9/17/16 10:16 AM, bsrbnd wrote: >>>> >>>> Hi, >>>> >>>> I just wrote a partial patch for issue 8148100. >>>> This is an updated version of >>>> test/tools/javac/lambda/MostSpecific10.java that verifies if the >>>> most-specific method is run with respect to JLS 15.12.2 (and also as >>>> explained in the issue description). >>>> I've not checked the 8 other tests yet... >>>> >>>> Regards, >>>> Bernard >>>> >>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>> b/test/tools/javac/lambda/MostSpecific10.java >>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>> @@ -26,8 +26,9 @@ >>>> * @bug 8034223 >>>> * @summary Structural most-specific logic for lambdas, method refs, >>>> parens, and conditionals >>>> * @compile MostSpecific10.java >>>> + * @run main MostSpecific10 >>>> */ >>>> -class MostSpecific10 { >>>> +public class MostSpecific10 { >>>> >>>> interface GetInt { >>>> int get(); >>>> @@ -38,7 +39,7 @@ >>>> } >>>> >>>> void m(GetInt getter) {} >>>> - void m(GetInteger getter) {} >>>> + void m(GetInteger getter) {throw new >>>> RuntimeException("Less-specific method invocation: " + >>>> getter.getClass());} >>>> >>>> void test(boolean cond) { >>>> m(() -> 23); >>>> @@ -50,5 +51,9 @@ >>>> m(cond ? (() -> 23) : ("abc"::length) ); >>>> m(( cond ? () -> 23 : cond ? ("abc"::length) : (() -> 23) )); >>>> } >>>> + >>>> + public static void main(String[] args) { >>>> + new MostSpecific10().test(true); >>>> + } >>>> >>>> } >>> >>> From jan.lahoda at oracle.com Mon Dec 12 13:35:10 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 12 Dec 2016 14:35:10 +0100 Subject: AssertionError in c.s.t.jc.comp.Modules.enter(..) In-Reply-To: References: Message-ID: <584EA78E.3030207@oracle.com> Hi Eirik, A reproducible test case would be ideal, but I have a few questions for now: does the build (without --add-modules java.xml.bind) produce any error/warnings? I assume the build does not crash with the AssertionError when doing a clean build, right? Any idea on what the diagnostics on which the compilation crashes could be? What version of the compiler plugin do you use? Thanks! Jan On 11.12.2016 20:12, Eirik Bj?rsn?s wrote: > > Hi, > > I'm getting the following AssertionError from javac: (Full stacktrace at > end of email) > > Exception in thread "main" java.lang.AssertionError > at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) > at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:243) > > > I wanted to reduce this to a minimal testcase, but after two hours > when I thought I'd finally nailed it, I did an mvn clean somewhere and > now I can't reproduce it :-) > > So what we have to work with is unfortunately my anecdotal observations: > (Can't share the full mvn build..) > > * This is maven-compiler-plugin compiling via plexus-compiler via > javax.tools.JavaCompiler > * The AssertionError happens when calling diagnostic.getMessage(Locale) > * Source file being compiled imports a class from a jar on the classpath > which again imports from java.xml.bind > * java.xml.bind is _not_ added with --add-modules-path > * When I add --add-modules-path=java.xml.bind to the CompilationTask's > options, the AssetionError is no longer thrown > * When I remove a jar containing a > javax.annotation.proccessing.Processor from the -classpath, the > AssertionError was no longer thrown > > While my immediate problem is solved using --add-modules, I'm assuming > this AssertionError is something which should/could be fixed? > > I'll try a bit more to create a minimal test case, but wanted to share > my observations anyway, since compiler internal wizards might spot > what's going on just from this. > > Sorry that this report is a bit messy, it was the best I could do this time. > > Let me know if there's more useful info I can provide. > > Cheers, > Eirik. > > > > Full stacktrace: > > Exception in thread "main" java.lang.AssertionError > at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) > at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:243) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:841) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821) > at > jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1469) > at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633) > at > jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1273) > at > jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1150) > at > jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1076) > at > jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237) > at > jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52) > at > jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1003) > at jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136) > at > jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:197) > at > jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165) > at > jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111) > at > jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67) > at > jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:183) > at > jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165) > at > jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111) > at > jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67) > at > jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessage(JCDiagnostic.java:775) > at > jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$DiagnosticSourceUnwrapper.getMessage(ClientCodeWrapper.java:788) > at > org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:131) > From cushon at google.com Tue Dec 13 03:29:27 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 12 Dec 2016 19:29:27 -0800 Subject: RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes Message-ID: Hello, As discussed in: http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010498.html javac does not currently check for invalid or out-of-range ConstantValue attributes. The proposed change is to emit an error for class files where a ConstantValue attribute disagrees with the field type, and to narrow any out-of-range values for bool, short, byte or char constant fields to within the expected range. Bug: https://bugs.openjdk.java.net/browse/JDK-8171132 Webrev: http://cr.openjdk.java.net/~cushon/8171132/webrev.00 Any feedback is welcome. Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Dec 13 04:18:17 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 12 Dec 2016 20:18:17 -0800 Subject: long classpaths and JDK-8162492 Message-ID: I noticed a performance regression with long classpaths and large numbers of sources. This is related to JDK-8162492, but the benchmarks in that bug are for long classpaths with a single source file, and my proposed fix doesn't address that. Under JDK 9 I'm seeing compilation time scale as the product of the classpath length and the number of calls to getFileObject or list. The example below takes 17s with JDK 8 and 8m40s with JDK 9. I think the issue is with the cache strategy in ArchiveContainer. ArchiveContainer calls Files.exists for each path and caches the result, but if it's queried for a large number of distinct paths it doesn't get cache hits, and ends up doing a lot of work. I'd like to propose bringing back the cache strategy that was used in ZipArchive: http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/1ff9d5118aae/src/share/classes/com/sun/tools/javac/file/ZipArchive.java#l73. ZipArchive scans all entries in the zip once, and puts the directory names in a cache. If getFileObject/list are called many times with paths that aren't in the archive it doesn't have to do any work, and the cache stays small. I have a couple of question about how to proceed: - does bringing back the ZipArchive-style cache sound reasonable, or are there other advantages to the new approach used in ArchiveContainer? - should I add this to JDK-8162492, or does it deserve a separate bug? Here's the repro - generate the test inputs (start in a fresh directory): $ javac -cp asm.jar Test.java && java -cp asm.jar:. Test compile: $ $JAVAC8 -fullversion javac full version "1.8.0_122-ea-b04" $ time $JAVAC8 @params.txt real 0m17.385s user 0m40.855s sys 0m1.305s $ $JAVAC9 -fullversion javac full version "9-ea+148" $ time $JAVAC9 @params.txt real 8m40.530s user 32m8.614s sys 0m57.024s === Test.java === import static java.nio.charset.StandardCharsets.UTF_8; import static org.objectweb.asm.Opcodes.ACC_PUBLIC; import static org.objectweb.asm.Opcodes.ACC_SUPER; import java.io.File; import java.nio.file.Files; import java.nio.file.Paths; import java.util.ArrayList; import java.util.List; import java.util.jar.JarEntry; import java.util.jar.JarOutputStream; import org.objectweb.asm.ClassWriter; class Test { static final int JARS = 1000; static final int CLASSES = 100; static final int SOURCES = 1000; public static void main(String[] args) throws Exception { List jars = new ArrayList<>(); for (int i = 0; i < JARS; i++) { String jarName = "lib" + i + ".jar"; jars.add(jarName); try (JarOutputStream jos = new JarOutputStream(Files.newOutputStream(Paths.get(jarName)))) { for (int j = 0; j < CLASSES; j++) { String name = String.format("b%d%d/B%d%d", i, j, i, j); jos.putNextEntry(new JarEntry(name + ".class")); ClassWriter cw = new ClassWriter(0); cw.visit(52, ACC_PUBLIC | ACC_SUPER, name, null, "java/lang/Object", null); jos.write(cw.toByteArray()); } } } List sources = new ArrayList<>(); for (int i = 0; i < SOURCES; i++) { StringBuilder sb = new StringBuilder(); sb.append(String.format("package a%d;\n", i)); sb.append(String.format("class A%d {\n", i)); for (int j = 0; j < CLASSES; j++) { String name = String.valueOf((i + j) % JARS) + j; sb.append(String.format("b%s.B%s x%d;\n", name, name, j)); } sb.append(" }\n"); String file = String.format("A%d.java", i, i); sources.add(file); Files.write(Paths.get(file), sb.toString().getBytes(UTF_8)); } List params = new ArrayList<>(); params.addAll(sources); params.add("-cp"); params.add(String.join(File.pathSeparator, jars)); Files.write(Paths.get("params.txt"), params, UTF_8); } } === -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at gmail.com Tue Dec 13 10:22:11 2016 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 13 Dec 2016 11:22:11 +0100 Subject: AssertionError in c.s.t.jc.comp.Modules.enter(..) In-Reply-To: <584EA78E.3030207@oracle.com> References: <584EA78E.3030207@oracle.com> Message-ID: Jan, I've been able to reproduce this in a J9 branch of Reststop (an open source). Here's a Github repo with a script to reproduce: https://github.com/eirbjo/javac-assertionerror-reproducer Observations: * The AssertionError happens _without_ --add-modules java.xml.bind. With --add-modules, there are no compilation errors * There are in total 6 Diagnostic instances, each ERRORs for missing java.xml.bind types in ConfDocMojo.java * The particular one causing the AssertionError is a "cant.resolve.location" for JAXBContext from the following line: private Map> findConfigs(JAXBContext context) throws MojoFailureException, MojoExecutionException, JAXBException, IOException { * Calling getMessage on the Diagnostic only fails the first time. Calling it a second time (from a debugger) does not cause an AssertionError. * When Assert.check in Modules.enter() fails, the variables are: rootModules: null, inInitModules: false, allowModules: true Why is rootModules null in this case? Cheers, Eirik. On Mon, Dec 12, 2016 at 2:35 PM, Jan Lahoda wrote: > Hi Eirik, > > A reproducible test case would be ideal, but I have a few questions for > now: does the build (without --add-modules java.xml.bind) produce any > error/warnings? I assume the build does not crash with the AssertionError > when doing a clean build, right? Any idea on what the diagnostics on which > the compilation crashes could be? What version of the compiler plugin do > you use? > > Thanks! > Jan > > > On 11.12.2016 20:12, Eirik Bj?rsn?s wrote: > >> >> Hi, >> >> I'm getting the following AssertionError from javac: (Full stacktrace at >> end of email) >> >> Exception in thread "main" java.lang.AssertionError >> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) >> at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) >> at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:243) >> >> >> I wanted to reduce this to a minimal testcase, but after two hours >> when I thought I'd finally nailed it, I did an mvn clean somewhere and >> now I can't reproduce it :-) >> >> So what we have to work with is unfortunately my anecdotal observations: >> (Can't share the full mvn build..) >> >> * This is maven-compiler-plugin compiling via plexus-compiler via >> javax.tools.JavaCompiler >> * The AssertionError happens when calling diagnostic.getMessage(Locale) >> * Source file being compiled imports a class from a jar on the classpath >> which again imports from java.xml.bind >> * java.xml.bind is _not_ added with --add-modules-path >> * When I add --add-modules-path=java.xml.bind to the CompilationTask's >> options, the AssetionError is no longer thrown >> * When I remove a jar containing a >> javax.annotation.proccessing.Processor from the -classpath, the >> AssertionError was no longer thrown >> >> While my immediate problem is solved using --add-modules, I'm assuming >> this AssertionError is something which should/could be fixed? >> >> I'll try a bit more to create a minimal test case, but wanted to share >> my observations anyway, since compiler internal wizards might spot >> what's going on just from this. >> >> Sorry that this report is a bit messy, it was the best I could do this >> time. >> >> Let me know if there's more useful info I can provide. >> >> Cheers, >> Eirik. >> >> >> >> Full stacktrace: >> >> Exception in thread "main" java.lang.AssertionError >> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) >> at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) >> at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:243) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourc >> eFile(JavaCompiler.java:841) >> at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourc >> eFile(JavaCompiler.java:821) >> at >> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE >> nvironment$ImplicitCompleter.complete(JavacProcessingEnviro >> nment.java:1469) >> at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633) >> at >> jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.com >> plete(Symbol.java:1273) >> at >> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complet >> e(Type.java:1150) >> at >> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getType >> Arguments(Type.java:1076) >> at >> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType >> (Printer.java:237) >> at >> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType >> (Printer.java:52) >> at >> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept( >> Type.java:1003) >> at jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136) >> at >> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticForm >> atter.formatArgument(AbstractDiagnosticFormatter.java:197) >> at >> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticForm >> atter.formatArguments(AbstractDiagnosticFormatter.java:165) >> at >> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatt >> er.formatMessage(BasicDiagnosticFormatter.java:111) >> at >> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatt >> er.formatMessage(BasicDiagnosticFormatter.java:67) >> at >> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticForm >> atter.formatArgument(AbstractDiagnosticFormatter.java:183) >> at >> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticForm >> atter.formatArguments(AbstractDiagnosticFormatter.java:165) >> at >> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatt >> er.formatMessage(BasicDiagnosticFormatter.java:111) >> at >> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatt >> er.formatMessage(BasicDiagnosticFormatter.java:67) >> at >> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessag >> e(JCDiagnostic.java:775) >> at >> jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$Diagn >> osticSourceUnwrapper.getMessage(ClientCodeWrapper.java:788) >> at >> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compil >> eInProcess(JavaxToolsCompiler.java:131) >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Dec 14 11:43:18 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 14 Dec 2016 12:43:18 +0100 Subject: long classpaths and JDK-8162492 In-Reply-To: References: Message-ID: Thanks for the report and reproducer. I took it for a spin and analyzed behavior for bit, and in additional to a massive amount of calls to Files.exist (which would be avoided by actually scanning eagerly), the current design also has a problem with rampant retained set growth (quadratic, it seems), which leads to GC thrashing (and would eventually have javac crash with an OOM on a long enough classpath). This is easily seen by running with -J-Xlog:gc [7.161s][info][gc] GC(31) Pause Young (G1 Evacuation Pause) 403M->132M(911M) 38.814ms [7.925s][info][gc] GC(32) Pause Young (G1 Evacuation Pause) 295M->137M(911M) 50.975ms ... [76.455s][info][gc] GC(80) Pause Young (G1 Evacuation Pause) 1026M->778M(6102M) 191.624ms [78.020s][info][gc] GC(81) Pause Young (G1 Evacuation Pause) 1057M->784M(6102M) 164.749ms real 11m11.944s user 98m15.140s sys 1m19.092s Not caching the failed lookup at all[1] leads to a much slower growth rate for the retained set and a quicker execution overall: [21.354s][info][gc] GC(39) Pause Young (G1 Evacuation Pause) 515M->88M(726M) 12.811ms [22.727s][info][gc] GC(40) Pause Young (G1 Evacuation Pause) 514M->88M(726M) 14.445ms ... [75.846s][info][gc] GC(79) Pause Young (G1 Evacuation Pause) 622M->108M(872M) 20.874ms [77.391s][info][gc] GC(80) Pause Young (G1 Evacuation Pause) 623M->109M(872M) 17.676ms real 7m3.745s user 8m34.560s sys 0m5.040s Not saying this[1] is anywhere near a good final solution, but helps to underscore that this might be more critical than a simple corner-case performance bug. Thanks! /Claes [1] diff -r 50135a630f35 src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java Tue Dec 13 12:25:58 2016 -0800 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java Wed Dec 14 12:39:52 2016 +0100 @@ -586,7 +586,7 @@ Path relativePath = path.resolveAgainst(fileSystem); if (!Files.exists(relativePath)) { - relativePath = null; + return null; } pathCache.put(path, relativePath); On 2016-12-13 05:18, Liam Miller-Cushon wrote: > I noticed a performance regression with long classpaths and large > numbers of sources. This is related to JDK-8162492, but the benchmarks > in that bug are for long classpaths with a single source file, and my > proposed fix doesn't address that. > > Under JDK 9 I'm seeing compilation time scale as the product of the > classpath length and the number of calls to getFileObject or list. The > example below takes 17s with JDK 8 and 8m40s with JDK 9. > > I think the issue is with the cache strategy in ArchiveContainer. > ArchiveContainer calls Files.exists for each path and caches the result, > but if it's queried for a large number of distinct paths it doesn't get > cache hits, and ends up doing a lot of work. > > I'd like to propose bringing back the cache strategy that was used in > ZipArchive: > http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/1ff9d5118aae/src/share/classes/com/sun/tools/javac/file/ZipArchive.java#l73. > ZipArchive scans all entries in the zip once, and puts the directory > names in a cache. If getFileObject/list are called many times with paths > that aren't in the archive it doesn't have to do any work, and the cache > stays small. > > I have a couple of question about how to proceed: > > - does bringing back the ZipArchive-style cache sound reasonable, or are > there other advantages to the new approach used in ArchiveContainer? > > - should I add this to JDK-8162492, or does it deserve a separate bug? > > > Here's the repro - > > generate the test inputs (start in a fresh directory): > > $ javac -cp asm.jar Test.java && java -cp asm.jar:. Test > > compile: > > $ $JAVAC8 -fullversion > javac full version "1.8.0_122-ea-b04" > $ time $JAVAC8 @params.txt > real0m17.385s > user0m40.855s > sys0m1.305s > > $ $JAVAC9 -fullversion > javac full version "9-ea+148" > $ time $JAVAC9 @params.txt > real8m40.530s > user32m8.614s > sys0m57.024s > > === Test.java === > import static java.nio.charset.StandardCharsets.UTF_8; > import static org.objectweb.asm.Opcodes.ACC_PUBLIC; > import static org.objectweb.asm.Opcodes.ACC_SUPER; > > import java.io.File; > import java.nio.file.Files; > import java.nio.file.Paths; > import java.util.ArrayList; > import java.util.List; > import java.util.jar.JarEntry; > import java.util.jar.JarOutputStream; > import org.objectweb.asm.ClassWriter; > > class Test { > > static final int JARS = 1000; > static final int CLASSES = 100; > static final int SOURCES = 1000; > > public static void main(String[] args) throws Exception { > List jars = new ArrayList<>(); > for (int i = 0; i < JARS; i++) { > String jarName = "lib" + i + ".jar"; > jars.add(jarName); > try (JarOutputStream jos = > new > JarOutputStream(Files.newOutputStream(Paths.get(jarName)))) { > for (int j = 0; j < CLASSES; j++) { > String name = String.format("b%d%d/B%d%d", i, j, i, j); > jos.putNextEntry(new JarEntry(name + ".class")); > ClassWriter cw = new ClassWriter(0); > cw.visit(52, ACC_PUBLIC | ACC_SUPER, name, null, > "java/lang/Object", null); > jos.write(cw.toByteArray()); > } > } > } > List sources = new ArrayList<>(); > for (int i = 0; i < SOURCES; i++) { > StringBuilder sb = new StringBuilder(); > sb.append(String.format("package a%d;\n", i)); > sb.append(String.format("class A%d {\n", i)); > for (int j = 0; j < CLASSES; j++) { > String name = String.valueOf((i + j) % JARS) + j; > sb.append(String.format("b%s.B%s x%d;\n", name, name, j)); > } > sb.append(" }\n"); > String file = String.format("A%d.java", i, i); > sources.add(file); > Files.write(Paths.get(file), sb.toString().getBytes(UTF_8)); > } > List params = new ArrayList<>(); > params.addAll(sources); > params.add("-cp"); > params.add(String.join(File.pathSeparator, jars)); > Files.write(Paths.get("params.txt"), params, UTF_8); > } > } > === > From vicente.romero at oracle.com Wed Dec 14 14:50:20 2016 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 14 Dec 2016 09:50:20 -0500 Subject: [PATCH] 8148100: Convert lambda most specific positive tests to check runtime behavior In-Reply-To: References: <884c028b-f20e-53e2-5314-6ca2569556c6@oracle.com> Message-ID: Hi Bernard, Very sorry for the delay with your patch, I will take care of it, Vicente On 12/12/2016 04:40 AM, B. Blaser wrote: > Hi, > Does this patch need to be improved? > > Thanks, > Bernard > > 2016-09-21 16:24 GMT+02:00 bsrbnd : >> Please find in attachment an all-in-one patch for the 9 tests, as >> discussed previously. >> >> Bernard >> >> >> 2016-09-19 16:01 GMT+02:00 bsrbnd : >>> Thanks for your advices. >>> >>> I re-wrote, below, the patch in a more compliant way (I hope). >>> I'll perhaps (probably) also go through the 8 others soon, if I have time... >>> >>> Bernard >>> >>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>> b/test/tools/javac/lambda/MostSpecific10.java >>> --- a/test/tools/javac/lambda/MostSpecific10.java >>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>> @@ -25,9 +25,12 @@ >>> * @test >>> * @bug 8034223 >>> * @summary Structural most-specific logic for lambdas, method refs, >>> parens, and conditionals >>> - * @compile MostSpecific10.java >>> */ >>> -class MostSpecific10 { >>> +public class MostSpecific10 { >>> + >>> + public static void main(String[] args) { >>> + new MostSpecific10().test(true); >>> + } >>> >>> interface GetInt { >>> int get(); >>> @@ -38,7 +41,9 @@ >>> } >>> >>> void m(GetInt getter) {} >>> - void m(GetInteger getter) {} >>> + void m(GetInteger getter) { >>> + throw new RuntimeException("Less-specific method invocation: >>> " + getter.getClass()); >>> + } >>> >>> void test(boolean cond) { >>> m(() -> 23); >>> >>> >>> 2016-09-18 3:11 GMT+02:00 Jonathan Gibbons : >>>> Bernard, >>>> >>>> Thanks for posting this patch. >>>> >>>> It's not wrong to say it explicitly, but the addition of the "@run main" >>>> line is unnecessary, since that is the default behavior once you remove the >>>> @compile. >>>> >>>> The replacement for void m(GetInteger getter) should be formatted in a more >>>> standard manner. >>>> >>>> It's more common to put the main method at the head of a test, instead of at >>>> the end. >>>> >>>> We can't check in "partial patches", so either you have to look at the 8 >>>> other tests and fix them all together, or we have to accept this one change >>>> as a "complete" fix for 8148100, and open a new, different issue for the 8 >>>> other tests. (The OpenJDK rules only permit one changeset per issue per >>>> repo,) >>>> >>>> -- Jon >>>> >>>> >>>> >>>> >>>> On 9/17/16 10:16 AM, bsrbnd wrote: >>>>> Hi, >>>>> >>>>> I just wrote a partial patch for issue 8148100. >>>>> This is an updated version of >>>>> test/tools/javac/lambda/MostSpecific10.java that verifies if the >>>>> most-specific method is run with respect to JLS 15.12.2 (and also as >>>>> explained in the issue description). >>>>> I've not checked the 8 other tests yet... >>>>> >>>>> Regards, >>>>> Bernard >>>>> >>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>>> b/test/tools/javac/lambda/MostSpecific10.java >>>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>>> @@ -26,8 +26,9 @@ >>>>> * @bug 8034223 >>>>> * @summary Structural most-specific logic for lambdas, method refs, >>>>> parens, and conditionals >>>>> * @compile MostSpecific10.java >>>>> + * @run main MostSpecific10 >>>>> */ >>>>> -class MostSpecific10 { >>>>> +public class MostSpecific10 { >>>>> >>>>> interface GetInt { >>>>> int get(); >>>>> @@ -38,7 +39,7 @@ >>>>> } >>>>> >>>>> void m(GetInt getter) {} >>>>> - void m(GetInteger getter) {} >>>>> + void m(GetInteger getter) {throw new >>>>> RuntimeException("Less-specific method invocation: " + >>>>> getter.getClass());} >>>>> >>>>> void test(boolean cond) { >>>>> m(() -> 23); >>>>> @@ -50,5 +51,9 @@ >>>>> m(cond ? (() -> 23) : ("abc"::length) ); >>>>> m(( cond ? () -> 23 : cond ? ("abc"::length) : (() -> 23) )); >>>>> } >>>>> + >>>>> + public static void main(String[] args) { >>>>> + new MostSpecific10().test(true); >>>>> + } >>>>> >>>>> } >>>> From maurizio.cimadamore at oracle.com Wed Dec 14 15:54:48 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 14 Dec 2016 15:54:48 +0000 Subject: RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes In-Reply-To: References: Message-ID: Overall the patch looks good, but I have a couple of comments: This line: if (var.type.tsym == syms.stringType.tsym) { should probably be replaced with: Assert.check(var.type.tsym == syms.stringType.tsym) As I'm not sure we even want to proceed if the variable type is other than String. On a related note, your convertType routine seems weak - it does all the required conversions - but without actively checking ranges and throwing errors if something bad is detected (e.g. a 'byte' field, whose constant value is 1000). Instead, I believe your code just truncates the part in excess, which, while acceptable (after all, the creator of such a bad classfile gets what he/she deserves) - could lead to some painful debugging; so an eager check/error would be preferrable, I think. Note that we already have code like this: case BYTE: if (Byte.MIN_VALUE <= value && value <= Byte.MAX_VALUE) return true; break; case CHAR: if (Character.MIN_VALUE <= value && value <= Character.MAX_VALUE) return true; break; case SHORT: if (Short.MIN_VALUE <= value && value <= Short.MAX_VALUE) return true; break; case INT: return true; In Types.isAssignable. I suggest we refactor that code into a standalone routine - either in Types or even in TypeTag - something like boolean checkRange(int value) And then we use that from both Types.isAssignable and also your new convertType routine. In you go down this path, I think the test should be expanded to cover this case too. What do you think? Maurizio On 13/12/16 03:29, Liam Miller-Cushon wrote: > Hello, > > As discussed in: > http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010498.html > > javac does not currently check for invalid or out-of-range > ConstantValue attributes. > > The proposed change is to emit an error for class files where a > ConstantValue attribute disagrees with the field type, and to narrow > any out-of-range values for bool, short, byte or char constant fields > to within the expected range. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171132 > Webrev: http://cr.openjdk.java.net/~cushon/8171132/webrev.00 > > > Any feedback is welcome. > > Thanks, > Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Dec 14 18:10:54 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 14 Dec 2016 10:10:54 -0800 Subject: RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes In-Reply-To: References: Message-ID: Thanks for the review, The update change is at: http://cr.openjdk.java.net/~cushon/8171132/webrev.01 > should probably be replaced with: > > Assert.check(var.type.tsym == syms.stringType.tsym) > > Done. > On a related note, your convertType routine seems weak - it does all the > required conversions - but without actively checking ranges and throwing > errors if something bad is detected (e.g. a 'byte' field, whose constant > value is 1000). Instead, I believe your code just truncates the part in > excess, which, while acceptable (after all, the creator of such a bad > classfile gets what he/she deserves) - could lead to some painful > debugging; so an eager check/error would be preferrable, I think. > I may have misunderstood Alex's message here: http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010500.html > javac must not reject Lib.class on this basis. However, javac should handle an out-of-band value in the CONSTANT_Integer c.p. entry as a quality-of-implementation detail. I agree that truncating could be surprising and hard to debug. So if an error is permitted by the spec I'm happy to make the suggested change, and the details you suggested sound good to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed Dec 14 20:31:02 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 14 Dec 2016 12:31:02 -0800 Subject: RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes In-Reply-To: References: Message-ID: <5851AC06.7020706@oracle.com> On 12/14/2016 10:10 AM, Liam Miller-Cushon wrote: > On a related note, your convertType routine seems weak - it does all > the required conversions - but without actively checking ranges and > throwing errors if something bad is detected (e.g. a 'byte' field, > whose constant value is 1000). Instead, I believe your code just > truncates the part in excess, which, while acceptable (after all, > the creator of such a bad classfile gets what he/she deserves) - > could lead to some painful debugging; so an eager check/error would > be preferrable, I think. > > I may have misunderstood Alex's message here: > http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010500.html > > > javac must not reject Lib.class on this basis. However, javac should > handle an out-of-band value in the CONSTANT_Integer c.p. entry as a > quality-of-implementation detail. > > I agree that truncating could be surprising and hard to debug. So if an > error is permitted by the spec I'm happy to make the suggested change, > and the details you suggested sound good to me. I'm not sure which spec you're asking about ... the JLS, for example, doesn't mention reading class files so it can't be that. I mentioned "quality-of-implementation detail" to highlight that javac can react to the ConstantValue attribute for Lib.B (or Test.TWO I guess) how ever it wishes. javac could convert the value on Monday, zero it on Tuesday, and throw error every other day. Alex From Alan.Bateman at oracle.com Wed Dec 14 21:46:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Dec 2016 21:46:40 +0000 Subject: 8170987: Module system implementation refresh (12/2016) Message-ID: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> Folks on jigsaw-dev will be aware that we are on yet another mission to bring the changes accumulated in the jake forest to jdk9/dev. The plan this time is to bring the changes to jdk9/dev to make jdk-9+150. The changes in this update are mostly for JSR 376 issues #VersionedDependences and #ModuleNameCharacters and so involve updates to the binary form of the module declaration. There is also some small changes left over from #IndirectQualifiedReflectiveAccess that we didn't include in the last refresh. This update has the implementation of Incubator Modules (JEP 11 [1]), everything except the javac support. This was initially planned to push to jdk9/dev but was re-routed to jake to avoid needing re-work when merged with the changes in jake. There is a bit of refactoring in the implementation in this update. We expect to do more on than, plus lots of clean-up, once all the feature work is out of way. The webrevs with the changes for this update are here: http://cr.openjdk.java.net/~alanb/8170987/1 They are currently based on jdk-9+148 and will be re-based for jdk9/dev later this week. One review note this time is to ignore the changes in ModuleBootstrap for DEBUG_ADD_OPENS, that is the only change in this webrev that is not proposed to move to jdk9/dev. -Alan [1] http://openjdk.java.net/jeps/11 From lois.foltan at oracle.com Wed Dec 14 21:58:13 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 14 Dec 2016 16:58:13 -0500 Subject: 8170987: Module system implementation refresh (12/2016) In-Reply-To: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> References: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> Message-ID: <5851C075.9000207@oracle.com> On 12/14/2016 4:46 PM, Alan Bateman wrote: > Folks on jigsaw-dev will be aware that we are on yet another mission > to bring the changes accumulated in the jake forest to jdk9/dev. The > plan this time is to bring the changes to jdk9/dev to make jdk-9+150. > > The changes in this update are mostly for JSR 376 issues > #VersionedDependences and #ModuleNameCharacters and so involve updates > to the binary form of the module declaration. There is also some small > changes left over from #IndirectQualifiedReflectiveAccess that we > didn't include in the last refresh. > > This update has the implementation of Incubator Modules (JEP 11 [1]), > everything except the javac support. This was initially planned to > push to jdk9/dev but was re-routed to jake to avoid needing re-work > when merged with the changes in jake. > > There is a bit of refactoring in the implementation in this update. We > expect to do more on than, plus lots of clean-up, once all the feature > work is out of way. > > The webrevs with the changes for this update are here: > > http://cr.openjdk.java.net/~alanb/8170987/1 I have reviewed the hotspot changes, looks good. Lois > > They are currently based on jdk-9+148 and will be re-based for > jdk9/dev later this week. > > One review note this time is to ignore the changes in ModuleBootstrap > for DEBUG_ADD_OPENS, that is the only change in this webrev that is > not proposed to move to jdk9/dev. > > -Alan > > [1] http://openjdk.java.net/jeps/11 > From mandy.chung at oracle.com Thu Dec 15 01:17:19 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 14 Dec 2016 17:17:19 -0800 Subject: 8170987: Module system implementation refresh (12/2016) In-Reply-To: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> References: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> Message-ID: <20ADC9D9-67F0-4C42-8FAE-CE83BE5200E8@oracle.com> > > The webrevs with the changes for this update are here: > > http://cr.openjdk.java.net/~alanb/8170987/1 I have pushed the change to rename jdk.crypto.pkcs11 and jdk.pack200 and dropped java.compact$N. So module-info.java changes will not be needed when you sync with jdk9/dev. I reviewed all changes except javac/javadoc changes. Looks good in general. src/java.base/share/classes/jdk/internal/module/Checks.java 115 /** 116 * Returns {@code true} if the given name is a legal binary name. 117 */ 118 public static boolean isJavaIdentifier(String name) { Not sure if it?s intended to have the javadoc for isJavaIdentifier method be the same as isBinaryName. When we use ?-module-version for user modules, the runtime will load regex. The system modules jlink plugin uses the cached version if JDK modules to be compiled with ?0module-version in the future. This might be something we should look at in the future for performance. src/java.base/share/classes/jdk/internal/module/ModuleResolution.java 64 throw new RuntimeException("cannot add deprecated to " + value); This comment applies to ModuleResoluton::with* methods. This should probably be an InternalError? 108 return String.valueOf(value); Nit: since you override toString method, might be helpful to print an informative description. src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java 1102 if (value.equals("deprecated")) 1103 return (new ModuleResolution(0)).withDeprecated(); 1104 else if (value.equals("deprecated-for-removal")) 1105 return (new ModuleResolution(0)).withDeprecatedForRemoval(); 1106 else if (value.equals("incubating")) 1107 return (new ModuleResolution(0)).withIncubating(); Why not passing the flag to ModuleResolution constructor? Similar statement is also in sun/tools/jar/GNUStyleOptions.java. I was wondering if jmod describe and jar ?-print-module-descriptor should print all optional attributes. While the module resolution is of limited use, it would be handy to print all optional attributes, if present rather than having to run javap. It?s okay to follow up as a separate JBS issue if we want to do that. test/jdk/modules/incubator/ImageModules.java @modules jdk.jlink jdk.jartool are missing. I have fixed it. Mandy From cushon at google.com Thu Dec 15 01:16:21 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 14 Dec 2016 17:16:21 -0800 Subject: RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes In-Reply-To: <5851AC06.7020706@oracle.com> References: <5851AC06.7020706@oracle.com> Message-ID: On Wed, Dec 14, 2016 at 12:31 PM, Alex Buckley wrote: > I'm not sure which spec you're asking about ... the JLS, for example, > doesn't mention reading class files so it can't be that. I mentioned > "quality-of-implementation detail" to highlight that javac can react to the > ConstantValue attribute for Lib.B (or Test.TWO I guess) how ever it wishes. > javac could convert the value on Monday, zero it on Tuesday, and throw > error every other day. > Thanks! I was asking about the JVMS, which I understand doesn't require a class file to be rejected for this reason. I now realize it doesn't disallow that. I updated the change to report an error on out-of-range values: http://cr.openjdk.java.net/~cushon/8171132/webrev.02/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu Dec 15 04:13:41 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 14 Dec 2016 20:13:41 -0800 Subject: long classpaths and JDK-8162492 In-Reply-To: References: Message-ID: Thanks for investigating! I went ahead and filed https://bugs.openjdk.java.net/browse/JDK-8171294 with the repro. And here's a prototype of eager scanning: http://cr.openjdk.java.net/~cushon/8171294/webrev.00/. On Wed, Dec 14, 2016 at 3:43 AM, Claes Redestad wrote: > Thanks for the report and reproducer. > > I took it for a spin and analyzed behavior for bit, and in additional > to a massive amount of calls to Files.exist (which would be avoided > by actually scanning eagerly), the current design also has a problem > with rampant retained set growth (quadratic, it seems), which leads to > GC thrashing (and would eventually have javac crash with an OOM on > a long enough classpath). > > This is easily seen by running with -J-Xlog:gc > > [7.161s][info][gc] GC(31) Pause Young (G1 Evacuation Pause) > 403M->132M(911M) 38.814ms > [7.925s][info][gc] GC(32) Pause Young (G1 Evacuation Pause) > 295M->137M(911M) 50.975ms > ... > [76.455s][info][gc] GC(80) Pause Young (G1 Evacuation Pause) > 1026M->778M(6102M) 191.624ms > [78.020s][info][gc] GC(81) Pause Young (G1 Evacuation Pause) > 1057M->784M(6102M) 164.749ms > > real 11m11.944s > user 98m15.140s > sys 1m19.092s > > Not caching the failed lookup at all[1] leads to a much slower growth > rate for the retained set and a quicker execution overall: > > [21.354s][info][gc] GC(39) Pause Young (G1 Evacuation Pause) > 515M->88M(726M) 12.811ms > [22.727s][info][gc] GC(40) Pause Young (G1 Evacuation Pause) > 514M->88M(726M) 14.445ms > ... > [75.846s][info][gc] GC(79) Pause Young (G1 Evacuation Pause) > 622M->108M(872M) 20.874ms > [77.391s][info][gc] GC(80) Pause Young (G1 Evacuation Pause) > 623M->109M(872M) 17.676ms > > real 7m3.745s > user 8m34.560s > sys 0m5.040s > > Not saying this[1] is anywhere near a good final solution, but helps to > underscore that this might be more critical than a simple corner-case > performance bug. > > Thanks! > > /Claes > > [1] > diff -r 50135a630f35 src/jdk.compiler/share/classes > /com/sun/tools/javac/file/JavacFileManager.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java > Tue Dec 13 12:25:58 2016 -0800 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java > Wed Dec 14 12:39:52 2016 +0100 > @@ -586,7 +586,7 @@ > Path relativePath = path.resolveAgainst(fileSystem); > > if (!Files.exists(relativePath)) { > - relativePath = null; > + return null; > } > > pathCache.put(path, relativePath); > > > > On 2016-12-13 05:18, Liam Miller-Cushon wrote: > >> I noticed a performance regression with long classpaths and large >> numbers of sources. This is related to JDK-8162492, but the benchmarks >> in that bug are for long classpaths with a single source file, and my >> proposed fix doesn't address that. >> >> Under JDK 9 I'm seeing compilation time scale as the product of the >> classpath length and the number of calls to getFileObject or list. The >> example below takes 17s with JDK 8 and 8m40s with JDK 9. >> >> I think the issue is with the cache strategy in ArchiveContainer. >> ArchiveContainer calls Files.exists for each path and caches the result, >> but if it's queried for a large number of distinct paths it doesn't get >> cache hits, and ends up doing a lot of work. >> >> I'd like to propose bringing back the cache strategy that was used in >> ZipArchive: >> http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/1ff9d511 >> 8aae/src/share/classes/com/sun/tools/javac/file/ZipArchive.java#l73. >> ZipArchive scans all entries in the zip once, and puts the directory >> names in a cache. If getFileObject/list are called many times with paths >> that aren't in the archive it doesn't have to do any work, and the cache >> stays small. >> >> I have a couple of question about how to proceed: >> >> - does bringing back the ZipArchive-style cache sound reasonable, or are >> there other advantages to the new approach used in ArchiveContainer? >> >> - should I add this to JDK-8162492, or does it deserve a separate bug? >> >> >> Here's the repro - >> >> generate the test inputs (start in a fresh directory): >> >> $ javac -cp asm.jar Test.java && java -cp asm.jar:. Test >> >> compile: >> >> $ $JAVAC8 -fullversion >> javac full version "1.8.0_122-ea-b04" >> $ time $JAVAC8 @params.txt >> real0m17.385s >> user0m40.855s >> sys0m1.305s >> >> $ $JAVAC9 -fullversion >> javac full version "9-ea+148" >> $ time $JAVAC9 @params.txt >> real8m40.530s >> user32m8.614s >> sys0m57.024s >> >> === Test.java === >> import static java.nio.charset.StandardCharsets.UTF_8; >> import static org.objectweb.asm.Opcodes.ACC_PUBLIC; >> import static org.objectweb.asm.Opcodes.ACC_SUPER; >> >> import java.io.File; >> import java.nio.file.Files; >> import java.nio.file.Paths; >> import java.util.ArrayList; >> import java.util.List; >> import java.util.jar.JarEntry; >> import java.util.jar.JarOutputStream; >> import org.objectweb.asm.ClassWriter; >> >> class Test { >> >> static final int JARS = 1000; >> static final int CLASSES = 100; >> static final int SOURCES = 1000; >> >> public static void main(String[] args) throws Exception { >> List jars = new ArrayList<>(); >> for (int i = 0; i < JARS; i++) { >> String jarName = "lib" + i + ".jar"; >> jars.add(jarName); >> try (JarOutputStream jos = >> new >> JarOutputStream(Files.newOutputStream(Paths.get(jarName)))) { >> for (int j = 0; j < CLASSES; j++) { >> String name = String.format("b%d%d/B%d%d", i, j, i, >> j); >> jos.putNextEntry(new JarEntry(name + ".class")); >> ClassWriter cw = new ClassWriter(0); >> cw.visit(52, ACC_PUBLIC | ACC_SUPER, name, null, >> "java/lang/Object", null); >> jos.write(cw.toByteArray()); >> } >> } >> } >> List sources = new ArrayList<>(); >> for (int i = 0; i < SOURCES; i++) { >> StringBuilder sb = new StringBuilder(); >> sb.append(String.format("package a%d;\n", i)); >> sb.append(String.format("class A%d {\n", i)); >> for (int j = 0; j < CLASSES; j++) { >> String name = String.valueOf((i + j) % JARS) + j; >> sb.append(String.format("b%s.B%s x%d;\n", name, name, >> j)); >> } >> sb.append(" }\n"); >> String file = String.format("A%d.java", i, i); >> sources.add(file); >> Files.write(Paths.get(file), sb.toString().getBytes(UTF_8)); >> } >> List params = new ArrayList<>(); >> params.addAll(sources); >> params.add("-cp"); >> params.add(String.join(File.pathSeparator, jars)); >> Files.write(Paths.get("params.txt"), params, UTF_8); >> } >> } >> === >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Dec 15 09:17:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Dec 2016 09:17:42 +0000 Subject: 8170987: Module system implementation refresh (12/2016) In-Reply-To: <20ADC9D9-67F0-4C42-8FAE-CE83BE5200E8@oracle.com> References: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> <20ADC9D9-67F0-4C42-8FAE-CE83BE5200E8@oracle.com> Message-ID: <77c9fc64-d1e8-189f-dd7c-cb6a5cd9543f@oracle.com> On 15/12/2016 01:17, Mandy Chung wrote: > I have pushed the change to rename jdk.crypto.pkcs11 and jdk.pack200 > and dropped java.compact$N. So module-info.java changes will not be > needed when you sync with jdk9/dev. Thank you. I'll do a merge today to see that everything works together. > : > > Not sure if it?s intended to have the javadoc for isJavaIdentifier > method be the same as isBinaryName. We can drop it but it was left there to avoid needing to change the usages that will be changing once we sort out residual issues in the Builder API, specifically the uses/provides methods that don't yet do the right validation (the `provides` methods shouldn't allow simple names for example, it also needs to ensure that the builder can't create a ModuleDescriptor that claim to have a provider that is not in the module. So I think this will all clean itself up in time. > > When we use ?-module-version for user modules, the runtime will load > regex. The system modules jlink plugin uses the cached version if > JDK modules to be compiled with ?0module-version in the future. > This might be something we should look at in the future for performance. I'm sure Claes will be interested in that although I don't think we have any need to compile the JDK modules with --module-version, except maybe for testing exploded modules. > > src/java.base/share/classes/jdk/internal/module/ModuleResolution.java > > 64 throw new RuntimeException("cannot add deprecated to " + value); > > This comment applies to ModuleResoluton::with* methods. This should > probably be an InternalError? IllegalArgumentException will probably work here. -Alan From maurizio.cimadamore at oracle.com Thu Dec 15 13:23:42 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 15 Dec 2016 13:23:42 +0000 Subject: 8170987: Module system implementation refresh (12/2016) In-Reply-To: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> References: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> Message-ID: <8f35eb97-7893-2388-ea0e-38429eab8376@oracle.com> Langtools changes look good - I like the changes in ClassReader/Writer. Maurizio On 14/12/16 21:46, Alan Bateman wrote: > Folks on jigsaw-dev will be aware that we are on yet another mission > to bring the changes accumulated in the jake forest to jdk9/dev. The > plan this time is to bring the changes to jdk9/dev to make jdk-9+150. > > The changes in this update are mostly for JSR 376 issues > #VersionedDependences and #ModuleNameCharacters and so involve updates > to the binary form of the module declaration. There is also some small > changes left over from #IndirectQualifiedReflectiveAccess that we > didn't include in the last refresh. > > This update has the implementation of Incubator Modules (JEP 11 [1]), > everything except the javac support. This was initially planned to > push to jdk9/dev but was re-routed to jake to avoid needing re-work > when merged with the changes in jake. > > There is a bit of refactoring in the implementation in this update. We > expect to do more on than, plus lots of clean-up, once all the feature > work is out of way. > > The webrevs with the changes for this update are here: > > http://cr.openjdk.java.net/~alanb/8170987/1 > > They are currently based on jdk-9+148 and will be re-based for > jdk9/dev later this week. > > One review note this time is to ignore the changes in ModuleBootstrap > for DEBUG_ADD_OPENS, that is the only change in this webrev that is > not proposed to move to jdk9/dev. > > -Alan > > [1] http://openjdk.java.net/jeps/11 > From maurizio.cimadamore at oracle.com Thu Dec 15 13:29:31 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 15 Dec 2016 13:29:31 +0000 Subject: RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes In-Reply-To: References: <5851AC06.7020706@oracle.com> Message-ID: <80352327-89c9-330a-cd31-bb5182152360@oracle.com> Looks good - the only minor issue is that the new resource keys should probably be excluded in the examples-not-yet.txt file (otherwise diags test will fail). We typically try and provide an example of all diagnostics generated by javac. IN case of errors that are hard to reproduce (and classfile errors related to bad classfiles definitively fall in this category), we typically just omit the diagnostic key from the test (albeit it will be nice one day to have an example for _all_ diagnostics). Maurizio On 15/12/16 01:16, Liam Miller-Cushon wrote: > On Wed, Dec 14, 2016 at 12:31 PM, Alex Buckley > > wrote: > > I'm not sure which spec you're asking about ... the JLS, for > example, doesn't mention reading class files so it can't be that. > I mentioned "quality-of-implementation detail" to highlight that > javac can react to the ConstantValue attribute for Lib.B (or > Test.TWO I guess) how ever it wishes. javac could convert the > value on Monday, zero it on Tuesday, and throw error every other day. > > > Thanks! I was asking about the JVMS, which I understand doesn't > require a class file to be rejected for this reason. I now realize it > doesn't disallow that. > > I updated the change to report an error on out-of-range values: > http://cr.openjdk.java.net/~cushon/8171132/webrev.02/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Dec 15 14:58:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Dec 2016 14:58:03 +0000 Subject: 8170987: Module system implementation refresh (12/2016) In-Reply-To: <77c9fc64-d1e8-189f-dd7c-cb6a5cd9543f@oracle.com> References: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> <20ADC9D9-67F0-4C42-8FAE-CE83BE5200E8@oracle.com> <77c9fc64-d1e8-189f-dd7c-cb6a5cd9543f@oracle.com> Message-ID: <9C8D820F-AB97-48B7-90D7-70ED87DDB0BB@oracle.com> > On 15 Dec 2016, at 09:17, Alan Bateman wrote: >> ... >> When we use ?-module-version for user modules, the runtime will load >> regex. The system modules jlink plugin uses the cached version if >> JDK modules to be compiled with ?0module-version in the future. >> This might be something we should look at in the future for performance. > I'm sure Claes will be interested in that although I don't think we have any need to compile the JDK modules with --module-version, except maybe for testing exploded modules. Don?t we want the Optional returned by Requires::compiledVersion to be non-empty, for system modules? -Chris. From cushon at google.com Thu Dec 15 18:11:12 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 15 Dec 2016 10:11:12 -0800 Subject: RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes In-Reply-To: <80352327-89c9-330a-cd31-bb5182152360@oracle.com> References: <5851AC06.7020706@oracle.com> <80352327-89c9-330a-cd31-bb5182152360@oracle.com> Message-ID: Done: http://cr.openjdk.java.net/~cushon/8171132/webrev.03/ On Thu, Dec 15, 2016 at 5:29 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Looks good - the only minor issue is that the new resource keys should > probably be excluded in the examples-not-yet.txt file (otherwise diags test > will fail). We typically try and provide an example of all diagnostics > generated by javac. IN case of errors that are hard to reproduce (and > classfile errors related to bad classfiles definitively fall in this > category), we typically just omit the diagnostic key from the test (albeit > it will be nice one day to have an example for _all_ diagnostics). > > Maurizio > > On 15/12/16 01:16, Liam Miller-Cushon wrote: > > On Wed, Dec 14, 2016 at 12:31 PM, Alex Buckley > wrote: > >> I'm not sure which spec you're asking about ... the JLS, for example, >> doesn't mention reading class files so it can't be that. I mentioned >> "quality-of-implementation detail" to highlight that javac can react to the >> ConstantValue attribute for Lib.B (or Test.TWO I guess) how ever it wishes. >> javac could convert the value on Monday, zero it on Tuesday, and throw >> error every other day. >> > > Thanks! I was asking about the JVMS, which I understand doesn't require a > class file to be rejected for this reason. I now realize it doesn't > disallow that. > > I updated the change to report an error on out-of-range values: > http://cr.openjdk.java.net/~cushon/8171132/webrev.02/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Dec 15 19:02:54 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 15 Dec 2016 19:02:54 +0000 Subject: RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes In-Reply-To: References: <5851AC06.7020706@oracle.com> <80352327-89c9-330a-cd31-bb5182152360@oracle.com> Message-ID: <0ef41448-abe4-9ff6-9e1c-02c7e79f40a7@oracle.com> Thanks - I will push this in the next few days Maurizio On 15/12/16 18:11, Liam Miller-Cushon wrote: > Done: http://cr.openjdk.java.net/~cushon/8171132/webrev.03/ > > > On Thu, Dec 15, 2016 at 5:29 AM, Maurizio Cimadamore > > wrote: > > Looks good - the only minor issue is that the new resource keys > should probably be excluded in the examples-not-yet.txt file > (otherwise diags test will fail). We typically try and provide an > example of all diagnostics generated by javac. IN case of errors > that are hard to reproduce (and classfile errors related to bad > classfiles definitively fall in this category), we typically just > omit the diagnostic key from the test (albeit it will be nice one > day to have an example for _all_ diagnostics). > > Maurizio > > > On 15/12/16 01:16, Liam Miller-Cushon wrote: >> On Wed, Dec 14, 2016 at 12:31 PM, Alex Buckley >> > wrote: >> >> I'm not sure which spec you're asking about ... the JLS, for >> example, doesn't mention reading class files so it can't be >> that. I mentioned "quality-of-implementation detail" to >> highlight that javac can react to the ConstantValue attribute >> for Lib.B (or Test.TWO I guess) how ever it wishes. javac >> could convert the value on Monday, zero it on Tuesday, and >> throw error every other day. >> >> >> Thanks! I was asking about the JVMS, which I understand doesn't >> require a class file to be rejected for this reason. I now >> realize it doesn't disallow that. >> >> I updated the change to report an error on out-of-range values: >> http://cr.openjdk.java.net/~cushon/8171132/webrev.02/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.x.nazarov at oracle.com Fri Dec 16 12:58:01 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Fri, 16 Dec 2016 15:58:01 +0300 Subject: 8170987: Module system implementation refresh (12/2016) In-Reply-To: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> References: <0381e9e2-b26c-7c8b-16cc-d2baba0d0536@oracle.com> Message-ID: <0B2FEFE8-898D-4BE7-9FAC-ED52B37DFB86@oracle.com> Langtools changes look good. ?Andrey > On 15 Dec 2016, at 00:46, Alan Bateman wrote: > > Folks on jigsaw-dev will be aware that we are on yet another mission to bring the changes accumulated in the jake forest to jdk9/dev. The plan this time is to bring the changes to jdk9/dev to make jdk-9+150. > > The changes in this update are mostly for JSR 376 issues #VersionedDependences and #ModuleNameCharacters and so involve updates to the binary form of the module declaration. There is also some small changes left over from #IndirectQualifiedReflectiveAccess that we didn't include in the last refresh. > > This update has the implementation of Incubator Modules (JEP 11 [1]), everything except the javac support. This was initially planned to push to jdk9/dev but was re-routed to jake to avoid needing re-work when merged with the changes in jake. > > There is a bit of refactoring in the implementation in this update. We expect to do more on than, plus lots of clean-up, once all the feature work is out of way. > > The webrevs with the changes for this update are here: > > http://cr.openjdk.java.net/~alanb/8170987/1 > > They are currently based on jdk-9+148 and will be re-based for jdk9/dev later this week. > > One review note this time is to ignore the changes in ModuleBootstrap for DEBUG_ADD_OPENS, that is the only change in this webrev that is not proposed to move to jdk9/dev. > > -Alan > > [1] http://openjdk.java.net/jeps/11 > From bsrbnd at gmail.com Mon Dec 19 16:54:00 2016 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 19 Dec 2016 17:54:00 +0100 Subject: JDK-8171370: Convert anonymous inner classes into lambdas/method references Message-ID: Hi, Thanks for this improvement! I've thought of suggesting something like that when working on issue 8147527... Changes in "Lower" look fine, Bernard From cushon at google.com Mon Dec 19 23:07:43 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 19 Dec 2016 15:07:43 -0800 Subject: unchecked casts and intersection types Message-ID: I was surprised by the unchecked warning in the following code. Is this behaviour correct? It stems from Types.isCastable using the same logic for union and intersection types, and in both cases requiring that each element type be castable to the target. For intersection types, isn't it sufficient for any element type to be castable? class Test { interface A {} interface B extends A {} interface C {} & C> B f(T t) { B result; A a = t; result = (B) a; // ok result = (B) t; // unchecked // required: B // found: T // where T is a type-variable: // T extends A,C declared in method f(T) return result; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Dec 20 00:33:07 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 19 Dec 2016 16:33:07 -0800 Subject: RFR: 8171412: tools/javac/modules/AddLimitMods.java failed with "error: module not found" Message-ID: <58587C43.4060907@oracle.com> Relatively simple fix for module initialization. javac was not correctly allowing for a qualified export to a non-existent module. It handles the case where the reference was in a source file, but not in a compiled module. The fix is to check for the existence of modules when expanding the command-line option tokens ALL-SYSTEM and ALL-MODULE-PATH, so that non-existent modules are ignored. JBS: https://bugs.openjdk.java.net/browse/JDK-8171412 Webrev: http://cr.openjdk.java.net/~jjg/8171412/webrev.00/ -- Jon From maurizio.cimadamore at oracle.com Tue Dec 20 10:26:06 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 20 Dec 2016 10:26:06 +0000 Subject: unchecked casts and intersection types In-Reply-To: References: Message-ID: <19a36133-f2cd-bfe9-a87b-ecf1242cdce4@oracle.com> On 19/12/16 23:07, Liam Miller-Cushon wrote: > I was surprised by the unchecked warning in the following code. Is > this behaviour correct? > > It stems from Types.isCastable using the same logic for union and > intersection types, and in both cases requiring that each element type > be castable to the target. For intersection types, isn't it sufficient > for any element type to be castable? It's surprising, yes, but I think it's sound; consider this case: class A { } class B { } class C extends B implements I { } interface I { } B b = ... A a = (I & A)b; Now, you want to cast B to something that is a subtype of both I and A. Of course you can cast from B to I (there could exist a type, such as C, that extends B and implements I). But that doesn't mean that the cast is ok - there's no way a B can be casted to an A - so, whatever type is going to be a subtype of both A and I, that type is not going to extend B, so javac is correct in statically rejecting the cast, I believe. The union is a bit of the same - albeit for different reason; if you have (I | A) you can have either a I or an A, so, to go to B you should make sure that there's a path from either of them to the type B. So, in both cases if one of the components is not castable to the target type of the cast, you have a problem, I think. In your example, however, I see that there's indeed a problem - I don't think the warning javac is correct, but not because of how javac performs the cast - but more because javac fails to see that if you have an intersection like: A & C Then it's never possible for a member of the intersection to implement the interface A with a parameterization other than String, or a compile-time error would occur, as per 8.1.5: "A class may not at the same time be a subtype of two interface types which are different parameterizations of the same generic interface (?9.1.2 ), or a subtype of a parameterization of a generic interface and a raw type naming that same generic interface, or a compile-time error occurs." So, the situation javac is complaining about can never occur in practice because of restrictions in the inheritance graph. Detecting this condition would not be too dissimilar to what cast rules already do for 'final' (see 5.5). I note that that, while the spec is as strict as javac in banning cast where the source type is an intersection type: "If S is an intersection type A_1 |&| ... |&| A_n , then it is a compile-time error if there exists an A_i (1 ? /i/ ? /n/) such that A_i cannot be cast to T by this algorithm. That is, the success of the cast is determined by the most restrictive component of the intersection type. " There doesn't seem an equivalent rule in 5.5.2 about unchecked warnings where S is an intersection, which I think it's an omission (going from List & A to List should defo give a warning?) Maurizio > > class Test { > interface A {} > interface B extends A {} > interface C {} > > & C> B f(T t) { > B result; > > A a = t; > result = (B) a; // ok > > result = (B) t; // unchecked > // required: B > // found: T > // where T is a type-variable: > // T extends A,C declared in method f(T) > > return result; > } > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Dec 20 11:19:45 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 20 Dec 2016 11:19:45 +0000 Subject: RFR: 8171412: tools/javac/modules/AddLimitMods.java failed with "error: module not found" In-Reply-To: <58587C43.4060907@oracle.com> References: <58587C43.4060907@oracle.com> Message-ID: Looks good Maurizio On 20/12/16 00:33, Jonathan Gibbons wrote: > Relatively simple fix for module initialization. > > javac was not correctly allowing for a qualified export to a > non-existent module. > It handles the case where the reference was in a source file, but not > in a compiled module. > > The fix is to check for the existence of modules when expanding the > command-line > option tokens ALL-SYSTEM and ALL-MODULE-PATH, so that non-existent > modules are > ignored. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8171412 > Webrev: http://cr.openjdk.java.net/~jjg/8171412/webrev.00/ > > -- Jon From cushon at google.com Wed Dec 21 20:34:56 2016 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 21 Dec 2016 12:34:56 -0800 Subject: unchecked casts and intersection types In-Reply-To: <19a36133-f2cd-bfe9-a87b-ecf1242cdce4@oracle.com> References: <19a36133-f2cd-bfe9-a87b-ecf1242cdce4@oracle.com> Message-ID: Thanks for the explanation! Now, you want to cast B to something that is a subtype of both I and A. Of > course you can cast from B to I (there could exist a type, such as C, that > extends B and implements I). But that doesn't mean that the cast is ok - > there's no way a B can be casted to an A - so, whatever type is going to be > a subtype of both A and I, that type is not going to extend B, so javac is > correct in statically rejecting the cast, I believe. > > The union is a bit of the same - albeit for different reason; if you have > (I | A) you can have either a I or an A, so, to go to B you should make > sure that there's a path from either of them to the type B. > The case where the target is an intersection or the source is a union seems clear enough, and I was forgetting about symmetry. Otherwise a cast where the source is an intersection and the target is any element of the intersection would be sound, I think? (Similarly if it was possible for the target to be a union.) > In your example, however, I see that there's indeed a problem - > I filed https://bugs.openjdk.java.net/browse/JDK-8171867 to keep track of this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Dec 21 22:30:00 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Dec 2016 22:30:00 +0000 Subject: unchecked casts and intersection types In-Reply-To: References: <19a36133-f2cd-bfe9-a87b-ecf1242cdce4@oracle.com> Message-ID: <1537b69e-ac94-42ab-f1ff-9c0afc36c871@oracle.com> On 21/12/16 20:34, Liam Miller-Cushon wrote: > Otherwise a cast where the source is an intersection and the target is > any element of the intersection would be sound, I think Yeah - that's a normal 'upcast'/widening. So it's always sound. Thanks for filing the issue for the enhancement. Maurizio From ogierke at pivotal.io Fri Dec 23 11:22:59 2016 From: ogierke at pivotal.io (Oliver Gierke) Date: Fri, 23 Dec 2016 12:22:59 +0100 Subject: Issues with generic type detection of SAM types implemented using lambdas Message-ID: <4E1C251C-163A-4093-855F-CEDC043B8524@pivotal.io> Hi all, Lambda based implementations of SAM types currently don't support inspecting the type for generic type parameters. This can cause unexpected surprise as some high-level API taking a SAM type as parameter is usually an indicator to users, that they can be used with Lambdas. If the object passed in is then inspected for generic types somewhere down the call stack this causes issues. Handing in a dedicated implementation of the SAM type is a workaround bit I think that's highly confusing and can be a source of errors hard to understand and debug. I've added an example below. Cheers, Ollie public class LambdaTypeDetectionSample { public static void main(String[] args) { Function lambdaFunction = i -> i.toString(); Function oldschoolFunction = new Function() { public String apply(Integer t) { return t.toString(); } }; printTypeArguments(oldschoolFunction); // Yields: // java.util.function.Function is a class sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl // class java.lang.Integer // class java.lang.String printTypeArguments(lambdaFunction); // Yields: // interface java.util.function.Function is a class java.lang.Class } private static void printTypeArguments(Function function) { Type type = function.getClass().getGenericInterfaces()[0]; System.out.println(type + " is a " + type.getClass()); if (type instanceof ParameterizedType) { ParameterizedType functionInterface = (ParameterizedType) type; Arrays.stream(functionInterface.getActualTypeArguments()).forEach(System.out::println); } } } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: