From maurizio.cimadamore at oracle.com Fri Sep 9 20:54:52 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 9 Sep 2016 21:54:52 +0100 Subject: test Message-ID: please ignore Maurizio From jan.lahoda at oracle.com Tue Sep 13 14:28:36 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 13 Sep 2016 16:28:36 +0200 Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible In-Reply-To: <576406A3.10008@oracle.com> References: <575EDB5C.5060601@oracle.com> <575FF892.90608@oracle.com> <576406A3.10008@oracle.com> Message-ID: <57D80D14.3070206@oracle.com> Hello, I've updated the patch to the current situation. The top-level repository patch is here: http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/ Langtools repository patch is here: http://cr.openjdk.java.net/~jlahoda/8153362/langtools.04-phase2/ Does this look OK? Thanks, Jan On 17.6.2016 16:18, Jan Lahoda wrote: > Hi, > > I've updated the patches, reflecting the feedback so far. > > The langtools change is now split into two parts, one is only adding the > new lint key (but no checks are actually performed): > http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase1/ > > And the second part is adding the checks: > http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase2/ > > We could push the first part first, and the second one together with > other changes later, so that the repositories don't have to be updated > in a lockstep. > > In addition to the langtools changes, only the top-level repository > needs to be changed now, to disable the checks in some modules: > http://cr.openjdk.java.net/~jlahoda/8153362/top-level.01/ > > Any feedback is welcome! > > Thanks, > Jan > > On 14.6.2016 14:29, Jan Lahoda wrote: >> Hi Alan, >> >> On 14.6.2016 12:57, Alan Bateman wrote: >>> On 13/06/2016 17:12, Jan Lahoda wrote: >>> >>>> Hello, >>>> >>>> There is: >>>> https://bugs.openjdk.java.net/browse/JDK-8153362 >>>> >>>> which is about a new warning that should be produced by javac when >>>> exported API refers to types not exported/accessible to the API >>>> clients. >>>> >>>> I've put my current javac change here: >>>> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/ >>> Did you have a short list of names for the lint option before deciding >>> on "unexportedinapi"? If time has already been put into this and this is >> >> I had a few (e.g. "publishingunexported"), but none of them particularly >> nice. >> >>> the best of a bad bunch then ignore my mail. I bring it up because it >>> feels more like a "potentiallynotaccessible" or "notaccessible" or >>> "leaksnotaccessible". For the cases where we have ended up with >> >> I like "leaksnotaccessible". Unless there would be better ideas or >> objections, I'd go with that. Thanks for the ideas! >> >>> protected fields in public classes but the field type is package-private >>> then the field is never accessible. For the JSObject.getWindow case then >>> consumers will need to require java.desktop to use this method. >>> >>> Related is the description: >>> >>> javac.opt.Xlint.desc.unexportedinapi=\ >>> Warn about use of types not visible to clients in exported API >>> >>> Shouldn't get say something about the type potentially not accessible >>> rather than visible? >> >> Yes, it should. I'll fix that. Thanks for catching that. >> >> Jan >> >>> >>> -Alan >>> >>> PS: You asked about the JVMCI classes in the hotspot repo. While this >>> might look strange then it is intentional. The "framework" uses the >>> reflective APIs to export the otherwise internal packages to the JVMCI >>> implementation when it is located and loaded. From daniel.smith at oracle.com Thu Sep 15 17:34:48 2016 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 15 Sep 2016 11:34:48 -0600 Subject: RFR: JDK-8138822 Source version error missing version number Message-ID: This is a trivial fix for an error message that is missing a parameter. Just need a quick review. https://bugs.openjdk.java.net/browse/JDK-8138822 Patch is below. ?Dan --------------------- # HG changeset patch # Parent 6e028413ea0835895813b3c84d78cc46e815cf07 diff -r 6e028413ea08 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java Wed Sep 14 20:00:20 2016 +0530 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java Wed Sep 14 16:45:20 2016 -0600 @@ -92,6 +92,7 @@ private final Attribute theUnfinishedDefaultValue; private final boolean allowRepeatedAnnos; + private final String sourceName; protected Annotate(Context context) { context.put(annotateKey, this); @@ -114,6 +115,7 @@ Source source = Source.instance(context); allowRepeatedAnnos = source.allowRepeatedAnnotations(); + sourceName = source.name; } /** Semaphore to delay annotation processing */ @@ -322,7 +324,7 @@ if (annotated.containsKey(a.type.tsym)) { if (!allowRepeatedAnnos) { - log.error(DiagnosticFlag.SOURCE_LEVEL, a.pos(), "repeatable.annotations.not.supported.in.source"); + log.error(DiagnosticFlag.SOURCE_LEVEL, a.pos(), "repeatable.annotations.not.supported.in.source", sourceName); } ListBuffer l = annotated.get(a.type.tsym); l = l.append(c); diff -r 6e028413ea08 test/tools/javac/annotations/repeatingAnnotations/WrongVersion.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/tools/javac/annotations/repeatingAnnotations/WrongVersion.java Wed Sep 14 16:45:20 2016 -0600 @@ -0,0 +1,22 @@ +/* + * @test /nodynamiccopyright/ + * @bug 8138822 + * @summary test that only Java 8+ allows repeating annotations + * @compile WrongVersion.java + * @compile/fail/ref=WrongVersion6.out -XDrawDiagnostics -Xlint:-options -source 6 WrongVersion.java + * @compile/fail/ref=WrongVersion7.out -XDrawDiagnostics -Xlint:-options -source 7 WrongVersion.java + */ +import java.lang.annotation.Repeatable; + + at Ann(1) @Ann(2) +class C { +} + + at Repeatable(AnnContainer.class) + at interface Ann { + int value(); +} + + at interface AnnContainer { + Ann[] value(); +} diff -r 6e028413ea08 test/tools/javac/annotations/repeatingAnnotations/WrongVersion6.out --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/tools/javac/annotations/repeatingAnnotations/WrongVersion6.out Wed Sep 14 16:45:20 2016 -0600 @@ -0,0 +1,2 @@ +WrongVersion.java:11:9: compiler.err.repeatable.annotations.not.supported.in.source: 1.6 +1 error diff -r 6e028413ea08 test/tools/javac/annotations/repeatingAnnotations/WrongVersion7.out --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/tools/javac/annotations/repeatingAnnotations/WrongVersion7.out Wed Sep 14 16:45:20 2016 -0600 @@ -0,0 +1,2 @@ +WrongVersion.java:11:9: compiler.err.repeatable.annotations.not.supported.in.source: 1.7 +1 error From jonathan.gibbons at oracle.com Fri Sep 16 15:44:17 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 16 Sep 2016 08:44:17 -0700 Subject: RFR: JDK-8138822 Source version error missing version number In-Reply-To: References: Message-ID: Approved, but fix would be even better if you used the typesafe Error methods to access the diagnostic. -- Jon On 9/15/16 10:34 AM, Dan Smith wrote: > This is a trivial fix for an error message that is missing a parameter. Just need a quick review. > > https://bugs.openjdk.java.net/browse/JDK-8138822 > > Patch is below. > > ?Dan > > --------------------- > > # HG changeset patch > # Parent 6e028413ea0835895813b3c84d78cc46e815cf07 > > diff -r 6e028413ea08 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java Wed Sep 14 20:00:20 2016 +0530 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java Wed Sep 14 16:45:20 2016 -0600 > @@ -92,6 +92,7 @@ > > private final Attribute theUnfinishedDefaultValue; > private final boolean allowRepeatedAnnos; > + private final String sourceName; > > protected Annotate(Context context) { > context.put(annotateKey, this); > @@ -114,6 +115,7 @@ > > Source source = Source.instance(context); > allowRepeatedAnnos = source.allowRepeatedAnnotations(); > + sourceName = source.name; > } > > /** Semaphore to delay annotation processing */ > @@ -322,7 +324,7 @@ > > if (annotated.containsKey(a.type.tsym)) { > if (!allowRepeatedAnnos) { > - log.error(DiagnosticFlag.SOURCE_LEVEL, a.pos(), "repeatable.annotations.not.supported.in.source"); > + log.error(DiagnosticFlag.SOURCE_LEVEL, a.pos(), "repeatable.annotations.not.supported.in.source", sourceName); > } > ListBuffer l = annotated.get(a.type.tsym); > l = l.append(c); > diff -r 6e028413ea08 test/tools/javac/annotations/repeatingAnnotations/WrongVersion.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/annotations/repeatingAnnotations/WrongVersion.java Wed Sep 14 16:45:20 2016 -0600 > @@ -0,0 +1,22 @@ > +/* > + * @test /nodynamiccopyright/ > + * @bug 8138822 > + * @summary test that only Java 8+ allows repeating annotations > + * @compile WrongVersion.java > + * @compile/fail/ref=WrongVersion6.out -XDrawDiagnostics -Xlint:-options -source 6 WrongVersion.java > + * @compile/fail/ref=WrongVersion7.out -XDrawDiagnostics -Xlint:-options -source 7 WrongVersion.java > + */ > +import java.lang.annotation.Repeatable; > + > + at Ann(1) @Ann(2) > +class C { > +} > + > + at Repeatable(AnnContainer.class) > + at interface Ann { > + int value(); > +} > + > + at interface AnnContainer { > + Ann[] value(); > +} > diff -r 6e028413ea08 test/tools/javac/annotations/repeatingAnnotations/WrongVersion6.out > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/annotations/repeatingAnnotations/WrongVersion6.out Wed Sep 14 16:45:20 2016 -0600 > @@ -0,0 +1,2 @@ > +WrongVersion.java:11:9: compiler.err.repeatable.annotations.not.supported.in.source: 1.6 > +1 error > diff -r 6e028413ea08 test/tools/javac/annotations/repeatingAnnotations/WrongVersion7.out > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/annotations/repeatingAnnotations/WrongVersion7.out Wed Sep 14 16:45:20 2016 -0600 > @@ -0,0 +1,2 @@ > +WrongVersion.java:11:9: compiler.err.repeatable.annotations.not.supported.in.source: 1.7 > +1 error > From bsrbnd at gmail.com Sat Sep 17 17:16:44 2016 From: bsrbnd at gmail.com (bsrbnd) Date: Sat, 17 Sep 2016 19:16:44 +0200 Subject: [PATCH] 8148100: Convert lambda most specific positive tests to check runtime behavior Message-ID: 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 jonathan.gibbons at oracle.com Sun Sep 18 01:11:14 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 17 Sep 2016 18:11:14 -0700 Subject: [PATCH] 8148100: Convert lambda most specific positive tests to check runtime behavior In-Reply-To: References: Message-ID: <884c028b-f20e-53e2-5314-6ca2569556c6@oracle.com> 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 uschindler at apache.org Mon Sep 19 13:05:22 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 19 Sep 2016 15:05:22 +0200 Subject: JavaC "-release" option no longer working? Message-ID: <003c01d21276$7dcaa880$795ff980$@apache.org> Hi, The Lucene team is already using the new "-release" option instead of "-source"/"-target" where applicable (JDK 9+), to allow real cross-compiling. Unfortunately, it is no longer working when we upgraded from build 134 to build 136 last night on our Jenkins server: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17849/console compile-core: [mkdir] Created dir: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java [javac] Compiling 773 source files to /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java [javac] javac: invalid flag: -release [javac] Usage: javac [javac] use --help for a list of possible options Is this an intended change - what's wrong? I did not see any log entries? I reverted back to build 134 for now. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From forax at univ-mlv.fr Mon Sep 19 13:24:09 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Sep 2016 15:24:09 +0200 (CEST) Subject: JavaC "-release" option no longer working? In-Reply-To: <003c01d21276$7dcaa880$795ff980$@apache.org> References: <003c01d21276$7dcaa880$795ff980$@apache.org> Message-ID: <2107949497.332389.1474291449074.JavaMail.zimbra@u-pem.fr> Hi Uwe, Most options of javac now use the GNU style, so it's --release instead of -release. cheers, R?mi ----- Mail original ----- > De: "Uwe Schindler" > ?: "rory odonnell" , "Dalibor Topic" , "Balchandra Vaidya" > , "Muneer Kolarkunnu" > Cc: compiler-dev at openjdk.java.net > Envoy?: Lundi 19 Septembre 2016 15:05:22 > Objet: JavaC "-release" option no longer working? > Hi, > > The Lucene team is already using the new "-release" option instead of > "-source"/"-target" where applicable (JDK 9+), to allow real cross-compiling. > Unfortunately, it is no longer working when we upgraded from build 134 to build > 136 last night on our Jenkins server: > > http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17849/console > > compile-core: > [mkdir] Created dir: > /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java > [javac] Compiling 773 source files to > /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java > [javac] javac: invalid flag: -release > [javac] Usage: javac > [javac] use --help for a list of possible options > > Is this an intended change - what's wrong? I did not see any log entries? > > I reverted back to build 134 for now. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ From andrey.x.nazarov at oracle.com Mon Sep 19 13:27:03 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Mon, 19 Sep 2016 16:27:03 +0300 Subject: JavaC "-release" option no longer working? In-Reply-To: <003c01d21276$7dcaa880$795ff980$@apache.org> References: <003c01d21276$7dcaa880$795ff980$@apache.org> Message-ID: <99be2667-ad8d-77e0-4205-c3d28c442427@oracle.com> Hi, Javac now uses GNU style options. Try --release. see javac --help --Andrey On 19.09.2016 16:05, Uwe Schindler wrote: > Hi, > > The Lucene team is already using the new "-release" option instead of "-source"/"-target" where applicable (JDK 9+), to allow real cross-compiling. Unfortunately, it is no longer working when we upgraded from build 134 to build 136 last night on our Jenkins server: > > http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17849/console > > compile-core: > [mkdir] Created dir: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java > [javac] Compiling 773 source files to /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java > [javac] javac: invalid flag: -release > [javac] Usage: javac > [javac] use --help for a list of possible options > > Is this an intended change - what's wrong? I did not see any log entries? > > I reverted back to build 134 for now. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > From uschindler at apache.org Mon Sep 19 13:31:47 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 19 Sep 2016 15:31:47 +0200 Subject: JavaC "-release" option no longer working? In-Reply-To: <2107949497.332389.1474291449074.JavaMail.zimbra@u-pem.fr> References: <003c01d21276$7dcaa880$795ff980$@apache.org> <2107949497.332389.1474291449074.JavaMail.zimbra@u-pem.fr> Message-ID: <003f01d2127a$2da23180$88e69480$@apache.org> Hi, What is the JDK bugtracker issue about this? I am asking because I did not see any changelog entry about this, otherwise I would have figured it out. I don't have build 136 on my local machine yet, so I just posted what Jenkins was complaining about! Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Remi Forax [mailto:forax at univ-mlv.fr] > Sent: Monday, September 19, 2016 3:24 PM > To: Uwe Schindler > Cc: rory odonnell ; Dalibor Topic > ; Balchandra Vaidya > ; Muneer Kolarkunnu > ; compiler-dev at openjdk.java.net > Subject: Re: JavaC "-release" option no longer working? > > Hi Uwe, > Most options of javac now use the GNU style, > so it's --release instead of -release. > > cheers, > R?mi > > ----- Mail original ----- > > De: "Uwe Schindler" > > ?: "rory odonnell" , "Dalibor Topic" > , "Balchandra Vaidya" > > , "Muneer Kolarkunnu" > > > Cc: compiler-dev at openjdk.java.net > > Envoy?: Lundi 19 Septembre 2016 15:05:22 > > Objet: JavaC "-release" option no longer working? > > > Hi, > > > > The Lucene team is already using the new "-release" option instead of > > "-source"/"-target" where applicable (JDK 9+), to allow real cross- > compiling. > > Unfortunately, it is no longer working when we upgraded from build 134 to > build > > 136 last night on our Jenkins server: > > > > http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17849/console > > > > compile-core: > > [mkdir] Created dir: > > /home/jenkins/workspace/Lucene-Solr-master- > Linux/lucene/build/core/classes/java > > [javac] Compiling 773 source files to > > /home/jenkins/workspace/Lucene-Solr-master- > Linux/lucene/build/core/classes/java > > [javac] javac: invalid flag: -release > > [javac] Usage: javac > > [javac] use --help for a list of possible options > > > > Is this an intended change - what's wrong? I did not see any log entries? > > > > I reverted back to build 134 for now. > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > ASF Member, Apache Lucene PMC / Committer > > Bremen, Germany > > http://lucene.apache.org/ From bsrbnd at gmail.com Mon Sep 19 14:01:04 2016 From: bsrbnd at gmail.com (bsrbnd) Date: Mon, 19 Sep 2016 16:01:04 +0200 Subject: [PATCH] 8148100: Convert lambda most specific positive tests to check runtime behavior In-Reply-To: <884c028b-f20e-53e2-5314-6ca2569556c6@oracle.com> References: <884c028b-f20e-53e2-5314-6ca2569556c6@oracle.com> Message-ID: 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 jonathan.gibbons at oracle.com Mon Sep 19 16:22:21 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 19 Sep 2016 09:22:21 -0700 Subject: JavaC "-release" option no longer working? In-Reply-To: <2107949497.332389.1474291449074.JavaMail.zimbra@u-pem.fr> References: <003c01d21276$7dcaa880$795ff980$@apache.org> <2107949497.332389.1474291449074.JavaMail.zimbra@u-pem.fr> Message-ID: R?mi, A more accurate statement would be that most *new* options of javac use the GNU style. With the exception of -classpath and -sourcepath, we have not changed any options that existed prior to JDK 9, and for those two options, we added new-style aliases, without removing the old forms. -- Jon On 9/19/16 6:24 AM, Remi Forax wrote: > Hi Uwe, > Most options of javac now use the GNU style, > so it's --release instead of -release. > > cheers, > R?mi > > ----- Mail original ----- >> De: "Uwe Schindler" >> ?: "rory odonnell" , "Dalibor Topic" , "Balchandra Vaidya" >> , "Muneer Kolarkunnu" >> Cc: compiler-dev at openjdk.java.net >> Envoy?: Lundi 19 Septembre 2016 15:05:22 >> Objet: JavaC "-release" option no longer working? >> Hi, >> >> The Lucene team is already using the new "-release" option instead of >> "-source"/"-target" where applicable (JDK 9+), to allow real cross-compiling. >> Unfortunately, it is no longer working when we upgraded from build 134 to build >> 136 last night on our Jenkins server: >> >> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17849/console >> >> compile-core: >> [mkdir] Created dir: >> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java >> [javac] Compiling 773 source files to >> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java >> [javac] javac: invalid flag: -release >> [javac] Usage: javac >> [javac] use --help for a list of possible options >> >> Is this an intended change - what's wrong? I did not see any log entries? >> >> I reverted back to build 134 for now. >> >> Uwe >> >> ----- >> Uwe Schindler >> uschindler at apache.org >> ASF Member, Apache Lucene PMC / Committer >> Bremen, Germany >> http://lucene.apache.org/ From mandy.chung at oracle.com Mon Sep 19 16:33:16 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Sep 2016 09:33:16 -0700 Subject: JavaC "-release" option no longer working? In-Reply-To: <003f01d2127a$2da23180$88e69480$@apache.org> References: <003c01d21276$7dcaa880$795ff980$@apache.org> <2107949497.332389.1474291449074.JavaMail.zimbra@u-pem.fr> <003f01d2127a$2da23180$88e69480$@apache.org> Message-ID: The -release option was removed in jdk-9+135 [1]: https://bugs.openjdk.java.net/browse/JDK-8160851 Mandy [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466 > On Sep 19, 2016, at 6:31 AM, Uwe Schindler wrote: > > Hi, > > What is the JDK bugtracker issue about this? I am asking because I did not see any changelog entry about this, otherwise I would have figured it out. I don't have build 136 on my local machine yet, so I just posted what Jenkins was complaining about! > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ >> -----Original Message----- >> From: Remi Forax [mailto:forax at univ-mlv.fr] >> Sent: Monday, September 19, 2016 3:24 PM >> To: Uwe Schindler >> Cc: rory odonnell ; Dalibor Topic >> ; Balchandra Vaidya >> ; Muneer Kolarkunnu >> ; compiler-dev at openjdk.java.net >> Subject: Re: JavaC "-release" option no longer working? >> >> Hi Uwe, >> Most options of javac now use the GNU style, >> so it's --release instead of -release. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Uwe Schindler" >>> ?: "rory odonnell" , "Dalibor Topic" >> , "Balchandra Vaidya" >>> , "Muneer Kolarkunnu" >> >>> Cc: compiler-dev at openjdk.java.net >>> Envoy?: Lundi 19 Septembre 2016 15:05:22 >>> Objet: JavaC "-release" option no longer working? >> >>> Hi, >>> >>> The Lucene team is already using the new "-release" option instead of >>> "-source"/"-target" where applicable (JDK 9+), to allow real cross- >> compiling. >>> Unfortunately, it is no longer working when we upgraded from build 134 to >> build >>> 136 last night on our Jenkins server: >>> >>> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17849/console >>> >>> compile-core: >>> [mkdir] Created dir: >>> /home/jenkins/workspace/Lucene-Solr-master- >> Linux/lucene/build/core/classes/java >>> [javac] Compiling 773 source files to >>> /home/jenkins/workspace/Lucene-Solr-master- >> Linux/lucene/build/core/classes/java >>> [javac] javac: invalid flag: -release >>> [javac] Usage: javac >>> [javac] use --help for a list of possible options >>> >>> Is this an intended change - what's wrong? I did not see any log entries? >>> >>> I reverted back to build 134 for now. >>> >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> uschindler at apache.org >>> ASF Member, Apache Lucene PMC / Committer >>> Bremen, Germany >>> http://lucene.apache.org/ > From forax at univ-mlv.fr Mon Sep 19 17:12:37 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Sep 2016 19:12:37 +0200 (CEST) Subject: JavaC "-release" option no longer working? In-Reply-To: References: <003c01d21276$7dcaa880$795ff980$@apache.org> <2107949497.332389.1474291449074.JavaMail.zimbra@u-pem.fr> Message-ID: <652416209.488974.1474305157244.JavaMail.zimbra@u-pem.fr> yes, true. Thanks, Jon. R?mi ----- Mail original ----- > De: "Jonathan Gibbons" > ?: compiler-dev at openjdk.java.net > Envoy?: Lundi 19 Septembre 2016 18:22:21 > Objet: Re: JavaC "-release" option no longer working? > R?mi, > > A more accurate statement would be that most *new* options of javac use the GNU > style. > > With the exception of -classpath and -sourcepath, we have not changed any > options that existed prior to JDK 9, and for those two options, we added > new-style aliases, without removing the old forms. > > -- Jon > > > On 9/19/16 6:24 AM, Remi Forax wrote: >> Hi Uwe, >> Most options of javac now use the GNU style, >> so it's --release instead of -release. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Uwe Schindler" >>> ?: "rory odonnell" , "Dalibor Topic" >>> , "Balchandra Vaidya" >>> , "Muneer Kolarkunnu" >>> >>> Cc: compiler-dev at openjdk.java.net >>> Envoy?: Lundi 19 Septembre 2016 15:05:22 >>> Objet: JavaC "-release" option no longer working? >>> Hi, >>> >>> The Lucene team is already using the new "-release" option instead of >>> "-source"/"-target" where applicable (JDK 9+), to allow real cross-compiling. >>> Unfortunately, it is no longer working when we upgraded from build 134 to build >>> 136 last night on our Jenkins server: >>> >>> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17849/console >>> >>> compile-core: >>> [mkdir] Created dir: >>> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java >>> [javac] Compiling 773 source files to >>> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/classes/java >>> [javac] javac: invalid flag: -release >>> [javac] Usage: javac >>> [javac] use --help for a list of possible options >>> >>> Is this an intended change - what's wrong? I did not see any log entries? >>> >>> I reverted back to build 134 for now. >>> >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> uschindler at apache.org >>> ASF Member, Apache Lucene PMC / Committer >>> Bremen, Germany > >> http://lucene.apache.org/ From blackdrag at gmx.org Mon Sep 19 19:49:17 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 19 Sep 2016 21:49:17 +0200 Subject: JavaC "-release" option no longer working? In-Reply-To: References: <003c01d21276$7dcaa880$795ff980$@apache.org> <2107949497.332389.1474291449074.JavaMail.zimbra@u-pem.fr> Message-ID: <57E0413D.4@gmx.org> On 19.09.2016 18:22, Jonathan Gibbons wrote: > R?mi, > > A more accurate statement would be that most *new* options of javac use > the GNU style. > > With the exception of -classpath and -sourcepath, we have not changed > any options that existed prior to JDK 9, and for those two options, we > added new-style aliases, without removing the old forms. what abut -verison? bye Jochen From uschindler at apache.org Mon Sep 19 22:15:29 2016 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 20 Sep 2016 00:15:29 +0200 Subject: JavaC "-release" option no longer working? In-Reply-To: References: <003c01d21276$7dcaa880$795ff980$@apache.org> <2107949497.332389.1474291449074.JavaMail.zimbra@u-pem.fr> <003f01d2127a$2da23180$88e69480$@apache.org> Message-ID: <001c01d212c3$5762c860$06285920$@apache.org> Thanks Mandy, I fixed our builds: https://github.com/apache/lucene-solr/commit/3712bf58196cd0bd56fad213547dee12029e7cbf Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Mandy Chung [mailto:mandy.chung at oracle.com] > Sent: Monday, September 19, 2016 6:33 PM > To: Uwe Schindler > Cc: Remi Forax ; rory odonnell > ; compiler-dev at openjdk.java.net; Muneer > Kolarkunnu > Subject: Re: JavaC "-release" option no longer working? > > The -release option was removed in jdk-9+135 [1]: > https://bugs.openjdk.java.net/browse/JDK-8160851 > > Mandy > [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/047d4d42b466 > > > > On Sep 19, 2016, at 6:31 AM, Uwe Schindler > wrote: > > > > Hi, > > > > What is the JDK bugtracker issue about this? I am asking because I did not > see any changelog entry about this, otherwise I would have figured it out. I > don't have build 136 on my local machine yet, so I just posted what Jenkins > was complaining about! > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > ASF Member, Apache Lucene PMC / Committer > > Bremen, Germany > > http://lucene.apache.org/ > >> -----Original Message----- > >> From: Remi Forax [mailto:forax at univ-mlv.fr] > >> Sent: Monday, September 19, 2016 3:24 PM > >> To: Uwe Schindler > >> Cc: rory odonnell ; Dalibor Topic > >> ; Balchandra Vaidya > >> ; Muneer Kolarkunnu > >> ; compiler-dev at openjdk.java.net > >> Subject: Re: JavaC "-release" option no longer working? > >> > >> Hi Uwe, > >> Most options of javac now use the GNU style, > >> so it's --release instead of -release. > >> > >> cheers, > >> R?mi > >> > >> ----- Mail original ----- > >>> De: "Uwe Schindler" > >>> ?: "rory odonnell" , "Dalibor Topic" > >> , "Balchandra Vaidya" > >>> , "Muneer Kolarkunnu" > >> > >>> Cc: compiler-dev at openjdk.java.net > >>> Envoy?: Lundi 19 Septembre 2016 15:05:22 > >>> Objet: JavaC "-release" option no longer working? > >> > >>> Hi, > >>> > >>> The Lucene team is already using the new "-release" option instead of > >>> "-source"/"-target" where applicable (JDK 9+), to allow real cross- > >> compiling. > >>> Unfortunately, it is no longer working when we upgraded from build 134 > to > >> build > >>> 136 last night on our Jenkins server: > >>> > >>> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17849/console > >>> > >>> compile-core: > >>> [mkdir] Created dir: > >>> /home/jenkins/workspace/Lucene-Solr-master- > >> Linux/lucene/build/core/classes/java > >>> [javac] Compiling 773 source files to > >>> /home/jenkins/workspace/Lucene-Solr-master- > >> Linux/lucene/build/core/classes/java > >>> [javac] javac: invalid flag: -release > >>> [javac] Usage: javac > >>> [javac] use --help for a list of possible options > >>> > >>> Is this an intended change - what's wrong? I did not see any log entries? > >>> > >>> I reverted back to build 134 for now. > >>> > >>> Uwe > >>> > >>> ----- > >>> Uwe Schindler > >>> uschindler at apache.org > >>> ASF Member, Apache Lucene PMC / Committer > >>> Bremen, Germany > >>> http://lucene.apache.org/ > > From bsrbnd at gmail.com Wed Sep 21 14:24:32 2016 From: bsrbnd at gmail.com (bsrbnd) Date: Wed, 21 Sep 2016 16:24:32 +0200 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: 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); >>> + } >>> >>> } >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_8148100.diff Type: text/x-patch Size: 7910 bytes Desc: not available URL: From jan.lahoda at oracle.com Tue Sep 27 12:42:08 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 27 Sep 2016 14:42:08 +0200 Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible In-Reply-To: <57D80D14.3070206@oracle.com> References: <575EDB5C.5060601@oracle.com> <575FF892.90608@oracle.com> <576406A3.10008@oracle.com> <57D80D14.3070206@oracle.com> Message-ID: <57EA6920.6070601@oracle.com> Hi, Any feedback on the top-level repository changes? http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/ Thanks! Jan On 13.9.2016 16:28, Jan Lahoda wrote: > Hello, > > I've updated the patch to the current situation. The top-level > repository patch is here: > http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/ > > Langtools repository patch is here: > http://cr.openjdk.java.net/~jlahoda/8153362/langtools.04-phase2/ > > Does this look OK? > > Thanks, > Jan > > On 17.6.2016 16:18, Jan Lahoda wrote: >> Hi, >> >> I've updated the patches, reflecting the feedback so far. >> >> The langtools change is now split into two parts, one is only adding the >> new lint key (but no checks are actually performed): >> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase1/ >> >> And the second part is adding the checks: >> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase2/ >> >> We could push the first part first, and the second one together with >> other changes later, so that the repositories don't have to be updated >> in a lockstep. >> >> In addition to the langtools changes, only the top-level repository >> needs to be changed now, to disable the checks in some modules: >> http://cr.openjdk.java.net/~jlahoda/8153362/top-level.01/ >> >> Any feedback is welcome! >> >> Thanks, >> Jan >> >> On 14.6.2016 14:29, Jan Lahoda wrote: >>> Hi Alan, >>> >>> On 14.6.2016 12:57, Alan Bateman wrote: >>>> On 13/06/2016 17:12, Jan Lahoda wrote: >>>> >>>>> Hello, >>>>> >>>>> There is: >>>>> https://bugs.openjdk.java.net/browse/JDK-8153362 >>>>> >>>>> which is about a new warning that should be produced by javac when >>>>> exported API refers to types not exported/accessible to the API >>>>> clients. >>>>> >>>>> I've put my current javac change here: >>>>> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/ >>>> Did you have a short list of names for the lint option before deciding >>>> on "unexportedinapi"? If time has already been put into this and >>>> this is >>> >>> I had a few (e.g. "publishingunexported"), but none of them particularly >>> nice. >>> >>>> the best of a bad bunch then ignore my mail. I bring it up because it >>>> feels more like a "potentiallynotaccessible" or "notaccessible" or >>>> "leaksnotaccessible". For the cases where we have ended up with >>> >>> I like "leaksnotaccessible". Unless there would be better ideas or >>> objections, I'd go with that. Thanks for the ideas! >>> >>>> protected fields in public classes but the field type is >>>> package-private >>>> then the field is never accessible. For the JSObject.getWindow case >>>> then >>>> consumers will need to require java.desktop to use this method. >>>> >>>> Related is the description: >>>> >>>> javac.opt.Xlint.desc.unexportedinapi=\ >>>> Warn about use of types not visible to clients in exported API >>>> >>>> Shouldn't get say something about the type potentially not accessible >>>> rather than visible? >>> >>> Yes, it should. I'll fix that. Thanks for catching that. >>> >>> Jan >>> >>>> >>>> -Alan >>>> >>>> PS: You asked about the JVMCI classes in the hotspot repo. While this >>>> might look strange then it is intentional. The "framework" uses the >>>> reflective APIs to export the otherwise internal packages to the JVMCI >>>> implementation when it is located and loaded. From Alan.Bateman at oracle.com Tue Sep 27 12:49:52 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Sep 2016 13:49:52 +0100 Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible In-Reply-To: <57EA6920.6070601@oracle.com> References: <575EDB5C.5060601@oracle.com> <575FF892.90608@oracle.com> <576406A3.10008@oracle.com> <57D80D14.3070206@oracle.com> <57EA6920.6070601@oracle.com> Message-ID: <1a7fec0e-70b2-dec7-74cf-a21676daf0d8@oracle.com> On 27/09/2016 13:42, Jan Lahoda wrote: > Hi, > > Any feedback on the top-level repository changes? > http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/ This looks okay to me. Some of these should be looked at and I wonder if you have created any bugs. In passing I see recipes for jdk.dev_XXXX that should be removed as they aren't used. Not your issue so we can create another issue to tracking removing them (assuming you don't want to touch this). -Alan From jan.lahoda at oracle.com Tue Sep 27 13:57:20 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 27 Sep 2016 15:57:20 +0200 Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible In-Reply-To: <1a7fec0e-70b2-dec7-74cf-a21676daf0d8@oracle.com> References: <575EDB5C.5060601@oracle.com> <575FF892.90608@oracle.com> <576406A3.10008@oracle.com> <57D80D14.3070206@oracle.com> <57EA6920.6070601@oracle.com> <1a7fec0e-70b2-dec7-74cf-a21676daf0d8@oracle.com> Message-ID: <57EA7AC0.8020003@oracle.com> On 27.9.2016 14:49, Alan Bateman wrote: > On 27/09/2016 13:42, Jan Lahoda wrote: > >> Hi, >> >> Any feedback on the top-level repository changes? >> http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/ > This looks okay to me. Some of these should be looked at and I wonder if > you have created any bugs. My plan is to file one bug per module before push. > > In passing I see recipes for jdk.dev_XXXX that should be removed as they > aren't used. Not your issue so we can create another issue to tracking > removing them (assuming you don't want to touch this). I could do that if needed, but I am not sure I understand all the context of these recipes. Thanks for the comments. Jan > > -Alan From andreas.lundblad at oracle.com Thu Sep 29 18:18:50 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Thu, 29 Sep 2016 20:18:50 +0200 Subject: Initial RFR for JDK-8134413: Devise alternate scheme for initializing javac context classes Message-ID: <20160929181849.GA26100@e6430> This is a request for an initial informal review of the work on JDK-8134413. A formal RFR with a proper webrev will be sent out at a later stage. A brief background for those of you who haven't followed my work so far... A summary of todays situation: - The Context is a simple Map. - Initialization is done lazily through static instance(Context c) or preRegister(Context c) methods. - This approach relies on leaking uninitialized 'this' references at the top of every component constructor. - It's practically impossible to figure out in which order components are initialized by looking at the code. - Introducing new dependencies or tweaking the initialization order requires use of aspirin. Maurizio outlines a solution to this in the bug report [1]. I encourage you read it. A summary follows: - The proposal suggests we initialize all components up front in the Context constructor. - There are "hard dependencies" and "soft dependencies" among components. - If, for instance, the *initialization* of Enter requires TreeMaker to be initialized, we call it a hard dependency. (It imposes an initialization order constraint.) - If the *use* of Enter requires TreeMaker to be initialized, we call it a soft dependency. - The graph of hard dependencies has no cycles so the suggested approach works well. - The override-specific-components-mechanism (currently solved with preRegister) is instead solved by subclassing Context, and overriding the behavior for creating a specific component. The current status of the work: - The proposed solution has been implemented. - A postInit hook mechanism has been introduced to pick up soft dependencies after initialization is complete (i.e. to resolve cycles). - There are currently about 20 javac test failures and 4 javadoc failures. Some of them are due to the same issue though. Help here is most welcome. - There's some work left to do for jshell. There are a few inline comments on the format "// [context-init] ..." with some question marks. Feel free to grep for those and help me out. The work lives in the sandbox repo on the branch JDK-8134413-branch Comments and feedback most welcome. I'm leaving Oracle October 9 so the sooner the better. After this date I will happily continue in discussions but it may be hard to find time to do much development. best regards, Andreas [1] https://bugs.openjdk.java.net/browse/JDK-8134413 From eaftan at google.com Fri Sep 30 21:31:11 2016 From: eaftan at google.com (Eddie Aftandilian) Date: Fri, 30 Sep 2016 14:31:11 -0700 Subject: Clarification about accessibility of private members Message-ID: JLS 6.6.1 says, "Otherwise, the member or constructor is declared private, and access is permitted if and only if it occurs within the body of the top level class (?7.6) that encloses the declaration of the member or constructor." Under that definition, I believe the following code should be legal: class Holder { class Super { private String s1; } class Sub extends Super { private String doIt() { return s1; } } } Holder is the top level class that encloses the declaration of s1, and the "return s1" statement occurs inside Holder's body. However, javac 1.8.0 issues an error on this code: Holder.java:7: error: s1 has private access in Holder.Super return s1; ^ 1 error What am I missing? Thanks, Eddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.batkovich at jetbrains.com Wed Sep 7 14:44:06 2016 From: dmitry.batkovich at jetbrains.com (Dmitry Batkovich) Date: Wed, 07 Sep 2016 14:44:06 -0000 Subject: question about JDK-7153958 "add constant pool reference to class containing inlined constants" Message-ID: Hi. 1. There seems to be a problem while javac writes inlined constant references to .class-file Initial enhancement was implemented in https://bugs.openjdk.java.net/browse/JDK-7153958. To understand my problem consider a little example: ---Const1.java: public class Const1 { public static final String CONST = ""; } ---Const2.java: public class Const2 { public static final String CONST = ""; } ---Main.java: public class Main { public static void main(String[] args) { if (Const1.CONST == "q" && Const2.CONST == "w") { SomeClass.doSome(); } } } Here I have a constant condition "Const1.CONST == "q" && Const2.CONST == "w"" that will be inlined by javac. Since it was inlined I expect to see Const1 and Const2 in constant pool of Main.class. But I see only Const1. Seems there is a bug around of Lower#addPrunedInfo() method usages and test case CPoolRefClassContainingInlinedCts is poor because it tests only simplest cases. 2. https://bugs.openjdk.java.net/browse/JDK-7153958 was introduced to help analyze dependencies(!). Consider example above: here then-statement (SomeClass.doSome()) is inlined since if-statement condition is always false and reference to SomeClass is not presented in constant pool of Main.class. But it's required to analyze dependencies of Main class. So, do you have any plans to fix/enhance these problems? I think that JDK-7153958 is useless and confusing at this moment with current implementation but can be very useful for tools developers. Dmitry Batkovich -------------- next part -------------- An HTML attachment was scrubbed... URL: