From forax at univ-mlv.fr Tue May 1 19:16:57 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 1 May 2018 21:16:57 +0200 (CEST) Subject: jdk11 javac doesn't support --release Message-ID: <447515184.541869.1525202217641.JavaMail.zimbra@u-pem.fr> Hi all, Hi Jan, javac doesn't support --release 11 [1] which preclude me to fully test some projects with the jdk 11 or any amber branches. /usr/jdk/jdk-11/bin/javac --release 11 error: release version 11 not supported Usage: javac use --help for a list of possible options Is there a plan to fix that soon ? R?mi [1] https://bugs.openjdk.java.net/browse/JDK-8193784 From jonathan.gibbons at oracle.com Tue May 1 19:49:12 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 1 May 2018 12:49:12 -0700 Subject: jdk11 javac doesn't support --release In-Reply-To: <447515184.541869.1525202217641.JavaMail.zimbra@u-pem.fr> References: <447515184.541869.1525202217641.JavaMail.zimbra@u-pem.fr> Message-ID: <03690d67-c5eb-8dc4-9b46-d351bbba68cc@oracle.com> R?mi, This caught me out last week as well, and yes, it is being fixed; we should see a fix by the end of the week. We have Plan A, B and C, for a hot fix, not-so-hot fix, and long term fix ;-) -- Jon On 5/1/18 12:16 PM, Remi Forax wrote: > Hi all, Hi Jan, > javac doesn't support --release 11 [1] which preclude me to fully test some projects with the jdk 11 or any amber branches. > > /usr/jdk/jdk-11/bin/javac --release 11 > error: release version 11 not supported > Usage: javac > use --help for a list of possible options > > Is there a plan to fix that soon ? > > R?mi > > [1] https://bugs.openjdk.java.net/browse/JDK-8193784 From jonathan.gibbons at oracle.com Tue May 1 19:51:33 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 01 May 2018 12:51:33 -0700 Subject: jdk11 javac doesn't support --release In-Reply-To: <03690d67-c5eb-8dc4-9b46-d351bbba68cc@oracle.com> References: <447515184.541869.1525202217641.JavaMail.zimbra@u-pem.fr> <03690d67-c5eb-8dc4-9b46-d351bbba68cc@oracle.com> Message-ID: <5AE8C545.6070606@oracle.com> Remi, If you want a quick patch to unblock your work, here it is: $ hg diff make diff -r ae58e24ce81a make/gendata/Gendata-jdk.compiler.gmk --- a/make/gendata/Gendata-jdk.compiler.gmk Mon Apr 30 09:49:08 2018 -0700 +++ b/make/gendata/Gendata-jdk.compiler.gmk Tue May 01 12:49:46 2018 -0700 @@ -83,6 +83,14 @@ $(CT_MODULESOURCEPATH) \ $(CT_MODULES) \ >$(@D)/A/system-modules + $(MKDIR) $(@D)/B + $(JAVA_SMALL) $(INTERIM_LANGTOOLS_ARGS) \ + $(COMPILECREATESYMBOLS_ADD_EXPORTS) \ + -classpath $(BUILDTOOLS_OUTPUTDIR)/create_symbols \ + build.tools.symbolgenerator.TransitiveDependencies \ + $(CT_MODULESOURCEPATH) \ + $(CT_MODULES) \ + >$(@D)/B/system-modules $(TOUCH) $@ # Can't generate ct.sym directly into modules libs as the SetupJarArchive macro On 05/01/2018 12:49 PM, Jonathan Gibbons wrote: > R?mi, > > This caught me out last week as well, and yes, it is being fixed; we > should see a fix by the end of the week. > > We have Plan A, B and C, for a hot fix, not-so-hot fix, and long term > fix ;-) > > -- Jon > > > On 5/1/18 12:16 PM, Remi Forax wrote: >> Hi all, Hi Jan, >> javac doesn't support --release 11 [1] which preclude me to fully >> test some projects with the jdk 11 or any amber branches. >> >> /usr/jdk/jdk-11/bin/javac --release 11 >> error: release version 11 not supported >> Usage: javac >> use --help for a list of possible options >> >> Is there a plan to fix that soon ? >> >> R?mi >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8193784 > From jonathan.gibbons at oracle.com Tue May 1 20:15:19 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 1 May 2018 13:15:19 -0700 Subject: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 In-Reply-To: <4f63e470-be02-0def-e93b-eea8f9f9fe79@oracle.com> References: <4f63e470-be02-0def-e93b-eea8f9f9fe79@oracle.com> Message-ID: OK, for the non-white content :-) but a minor nit regarding whitespace.? Many of the affected comments are inconsistent with the use of

after a blank line in the comment. Is this intentional? See this file, as an example: http://cr.openjdk.java.net/~darcy/8202334.0/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java.sdiff.html and this extract: 34 * A visitor of types based on their {@linkplain TypeKind kind} with 35 * default behavior appropriate for source versions {@link 36 * SourceVersion#RELEASE_9 RELEASE_9} through {@link 37 * SourceVersion#RELEASE_11 RELEASE_11}. 38 * 39 * For {@linkplain 40 * TypeMirror types} Xyz that may have more than one 41 * kind, the visitXyz methods in this class delegate 42 * to the visitXyzAsKind method corresponding to the 43 * first argument's kind. The visitXyzAsKind methods 44 * call {@link #defaultAction defaultAction}, passing their arguments 45 * to {@code defaultAction}'s corresponding parameters. 46 * 47 *

Methods in this class may be overridden subject to their 48 * general contract. Note that annotating methods in concrete 49 * subclasses with {@link java.lang.Override @Override} will help 50 * ensure that methods are overridden as intended. Note that lines 38 and 46 are blank, but 39 does not use

but 47 does. -- Jon On 4/26/18 10:50 AM, joe darcy wrote: > Hello, > > Please review the webrev and CSR for 8202334: "Update > javax.lang.model.util visitors for 11": > > ??? http://cr.openjdk.java.net/~darcy/8202334.0/ > ??? https://bugs.openjdk.java.net/browse/JDK-8202335 > > From the CSR: > >> The `javax.lang.model` API was added in Java SE 6. In each of Java SE >> 7, 8, and 9, new sets of utility visitors were added for each >> release, for example starting with `AbstractElementVisitor6`, types >> `AbstractElementVisitor7`, `AbstractElementVisitor8`, >> `AbstractElementVisitor8` were added in SE 7 and 8, respectively. >> Similar patterns were followed for `ElementKindVisitor6`, and the >> rest of the utility visitors. >> >> In Java SE 10, there were no language changes requiring new >> operational behavior from the root visitors. Therefore, rather than >> introducing yet another slate of visitor classes, the 9-era visitors >> were updated to indicate they are appropriate for 10 as well >> (CCC-8193194). >> >> In the absence of language changes in 11 which would require new >> operational behavior from the visitors, the 9-era visitors should be >> updated to indicate they are appropriate for releases 9 through 11. >> >> Solution >> -------- >> Update the specification and `SupportedSourceVersion` annotations on >> the 9-era visitor classes to indicate they are appropriate for >> release 11. > > Thanks, > > -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue May 1 20:31:01 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 01 May 2018 13:31:01 -0700 Subject: JDK 11 RFR of 8202334: Update javax.lang.model.util visitors for 11 In-Reply-To: References: <4f63e470-be02-0def-e93b-eea8f9f9fe79@oracle.com> Message-ID: <5AE8CE85.50800@oracle.com> Hi Jon, On 5/1/2018 1:15 PM, Jonathan Gibbons wrote: > > OK, for the non-white content :-) but a minor nit regarding > whitespace. Many of the affected comments are inconsistent with the > use of

after a blank line in the comment. Is this intentional? > It is intentional. I often prefer to have each sentence appear with whitespace around it in the javadoc sources to make future edits have less "by catch" of spurious updates to surrounding text. Thanks, -Joe > See this file, as an example: > > http://cr.openjdk.java.net/~darcy/8202334.0/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java.sdiff.html > > and this extract: > > 34 * A visitor of types based on their {@linkplain TypeKind kind} with > 35 * default behavior appropriate for source versions {@link > 36 * SourceVersion#RELEASE_9 RELEASE_9} through {@link > 37 * SourceVersion#RELEASE_11 RELEASE_11}. > 38 * > 39 * For {@linkplain > 40 * TypeMirror types} Xyz that may have more than one > 41 * kind, the visitXyz methods in this class delegate > 42 * to the visitXyzAsKind method corresponding to the > 43 * first argument's kind. The visitXyzAsKind methods > 44 * call {@link #defaultAction defaultAction}, passing their arguments > 45 * to {@code defaultAction}'s corresponding parameters. > 46 * > 47 *

Methods in this class may be overridden subject to their > 48 * general contract. Note that annotating methods in concrete > 49 * subclasses with {@link java.lang.Override @Override} will help > 50 * ensure that methods are overridden as intended. > Note that lines 38 and 46 are blank, but 39 does not use

but 47 does. > > -- Jon > > > > On 4/26/18 10:50 AM, joe darcy wrote: >> Hello, >> >> Please review the webrev and CSR for 8202334: "Update >> javax.lang.model.util visitors for 11": >> >> http://cr.openjdk.java.net/~darcy/8202334.0/ >> https://bugs.openjdk.java.net/browse/JDK-8202335 >> >> From the CSR: >> >>> The `javax.lang.model` API was added in Java SE 6. In each of Java >>> SE 7, 8, and 9, new sets of utility visitors were added for each >>> release, for example starting with `AbstractElementVisitor6`, types >>> `AbstractElementVisitor7`, `AbstractElementVisitor8`, >>> `AbstractElementVisitor8` were added in SE 7 and 8, respectively. >>> Similar patterns were followed for `ElementKindVisitor6`, and the >>> rest of the utility visitors. >>> >>> In Java SE 10, there were no language changes requiring new >>> operational behavior from the root visitors. Therefore, rather than >>> introducing yet another slate of visitor classes, the 9-era visitors >>> were updated to indicate they are appropriate for 10 as well >>> (CCC-8193194). >>> >>> In the absence of language changes in 11 which would require new >>> operational behavior from the visitors, the 9-era visitors should be >>> updated to indicate they are appropriate for releases 9 through 11. >>> >>> Solution >>> -------- >>> Update the specification and `SupportedSourceVersion` annotations on >>> the 9-era visitor classes to indicate they are appropriate for >>> release 11. >> >> Thanks, >> >> -Joe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue May 1 22:05:50 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 2 May 2018 00:05:50 +0200 (CEST) Subject: jdk11 javac doesn't support --release In-Reply-To: <5AE8C545.6070606@oracle.com> References: <447515184.541869.1525202217641.JavaMail.zimbra@u-pem.fr> <03690d67-c5eb-8dc4-9b46-d351bbba68cc@oracle.com> <5AE8C545.6070606@oracle.com> Message-ID: <692685306.573975.1525212350600.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "jonathan gibbons" > ?: "Remi Forax" , "compiler-dev" > Envoy?: Mardi 1 Mai 2018 21:51:33 > Objet: Re: jdk11 javac doesn't support --release > Remi, Hi Jonathan, > > If you want a quick patch to unblock your work, here it is: > > $ hg diff make > diff -r ae58e24ce81a make/gendata/Gendata-jdk.compiler.gmk > --- a/make/gendata/Gendata-jdk.compiler.gmk Mon Apr 30 09:49:08 2018 > -0700 > +++ b/make/gendata/Gendata-jdk.compiler.gmk Tue May 01 12:49:46 2018 > -0700 > @@ -83,6 +83,14 @@ > $(CT_MODULESOURCEPATH) \ > $(CT_MODULES) \ > >$(@D)/A/system-modules > + $(MKDIR) $(@D)/B > + $(JAVA_SMALL) $(INTERIM_LANGTOOLS_ARGS) \ > + $(COMPILECREATESYMBOLS_ADD_EXPORTS) \ > + -classpath $(BUILDTOOLS_OUTPUTDIR)/create_symbols \ > + build.tools.symbolgenerator.TransitiveDependencies \ > + $(CT_MODULESOURCEPATH) \ > + $(CT_MODULES) \ > + >$(@D)/B/system-modules > $(TOUCH) $@ > > # Can't generate ct.sym directly into modules libs as the > SetupJarArchive macro > many thanks, i will test that tomorrow (nice plan B :) ). R?mi > > On 05/01/2018 12:49 PM, Jonathan Gibbons wrote: >> R?mi, >> >> This caught me out last week as well, and yes, it is being fixed; we >> should see a fix by the end of the week. >> >> We have Plan A, B and C, for a hot fix, not-so-hot fix, and long term >> fix ;-) >> >> -- Jon >> >> >> On 5/1/18 12:16 PM, Remi Forax wrote: >>> Hi all, Hi Jan, >>> javac doesn't support --release 11 [1] which preclude me to fully >>> test some projects with the jdk 11 or any amber branches. >>> >>> /usr/jdk/jdk-11/bin/javac --release 11 >>> error: release version 11 not supported >>> Usage: javac >>> use --help for a list of possible options >>> >>> Is there a plan to fix that soon ? >>> >>> R?mi >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8193784 From maurizio.cimadamore at oracle.com Wed May 2 11:19:02 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 2 May 2018 12:19:02 +0100 Subject: RFR 8202372: Diagnostic with incorrect line info generated when compiling lambda expression Message-ID: Hi, I put together a webrev based on the fix that B. Blaser put together few days ago. I've enhanced the test as I realized that the erroneous condition could present in multiple situations (the patch seems to fix all of them). The underlying issue is that when we create a fake block for the lambda expression (which is needed for speculatively check its contents), we forget setting its position - meaning that all diags reported against the rewritten block will now appear off sync. One solution would be to tweak the code to never use speculative trees to report diagnostic - but that would be very invasive; a cheaper fix (the one attempted here) is to add the required positional info to the rewritten tree so that it matches the original position. http://cr.openjdk.java.net/~mcimadamore/8202372/ Cheers Maurizio From bsrbnd at gmail.com Wed May 2 12:00:15 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 2 May 2018 14:00:15 +0200 Subject: RFR 8202372: Diagnostic with incorrect line info generated when compiling lambda expression In-Reply-To: References: Message-ID: Looks good! Cheers, Bernard On 2 May 2018 at 13:19, Maurizio Cimadamore wrote: > Hi, > I put together a webrev based on the fix that B. Blaser put together few > days ago. I've enhanced the test as I realized that the erroneous condition > could present in multiple situations (the patch seems to fix all of them). > > The underlying issue is that when we create a fake block for the lambda > expression (which is needed for speculatively check its contents), we forget > setting its position - meaning that all diags reported against the rewritten > block will now appear off sync. > > One solution would be to tweak the code to never use speculative trees to > report diagnostic - but that would be very invasive; a cheaper fix (the one > attempted here) is to add the required positional info to the rewritten tree > so that it matches the original position. > > http://cr.openjdk.java.net/~mcimadamore/8202372/ > > Cheers > Maurizio > From jan.lahoda at oracle.com Wed May 2 12:15:11 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 2 May 2018 14:15:11 +0200 Subject: RFR 8202372: Diagnostic with incorrect line info generated when compiling lambda expression In-Reply-To: References: Message-ID: <5AE9ABCF.2030504@oracle.com> In: test/langtools/tools/javac/lambda/8202372/T8202372.java There is a typo: nodynamioccopyright => nodynamiccopyright (there appears to be a handful of more occurrences of the typo in a handful of other files: test/langtools/tools/javac/lvti/T8200199.java test/langtools/tools/javac/lvti/badTypeReference/BadTypeReference.java test/langtools/tools/javac/preview/classReaderTest/Client.java ) Otherwise looks good to me. Jan On 2.5.2018 14:00, B. Blaser wrote: > Looks good! > > Cheers, > Bernard > > On 2 May 2018 at 13:19, Maurizio Cimadamore > wrote: >> Hi, >> I put together a webrev based on the fix that B. Blaser put together few >> days ago. I've enhanced the test as I realized that the erroneous condition >> could present in multiple situations (the patch seems to fix all of them). >> >> The underlying issue is that when we create a fake block for the lambda >> expression (which is needed for speculatively check its contents), we forget >> setting its position - meaning that all diags reported against the rewritten >> block will now appear off sync. >> >> One solution would be to tweak the code to never use speculative trees to >> report diagnostic - but that would be very invasive; a cheaper fix (the one >> attempted here) is to add the required positional info to the rewritten tree >> so that it matches the original position. >> >> http://cr.openjdk.java.net/~mcimadamore/8202372/ >> >> Cheers >> Maurizio >> From vicente.romero at oracle.com Wed May 2 13:16:13 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 2 May 2018 09:16:13 -0400 Subject: RFR 8202372: Diagnostic with incorrect line info generated when compiling lambda expression In-Reply-To: References: Message-ID: looks good, Vicente On 05/02/2018 07:19 AM, Maurizio Cimadamore wrote: > Hi, > I put together a webrev based on the fix that B. Blaser put together > few days ago. I've enhanced the test as I realized that the erroneous > condition could present in multiple situations (the patch seems to fix > all of them). > > The underlying issue is that when we create a fake block for the > lambda expression (which is needed for speculatively check its > contents), we forget setting its position - meaning that all diags > reported against the rewritten block will now appear off sync. > > One solution would be to tweak the code to never use speculative trees > to report diagnostic - but that would be very invasive; a cheaper fix > (the one attempted here) is to add the required positional info to the > rewritten tree so that it matches the original position. > > http://cr.openjdk.java.net/~mcimadamore/8202372/ > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Wed May 2 13:56:12 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 2 May 2018 14:56:12 +0100 Subject: RFR 8202372: Diagnostic with incorrect line info generated when compiling lambda expression In-Reply-To: <5AE9ABCF.2030504@oracle.com> References: <5AE9ABCF.2030504@oracle.com> Message-ID: Good catch - turns out there's a bug in my jtreg IntelliJ plugin that is causing this :-) If it's ok, I will fix the bogus occurrences as part of this commit (with no followup review). Let me know if that's ok. Maurizio On 02/05/18 13:15, Jan Lahoda wrote: > In: > test/langtools/tools/javac/lambda/8202372/T8202372.java > > There is a typo: > > nodynamioccopyright > => > nodynamiccopyright > > (there appears to be a handful of more occurrences of the typo in a > handful of other files: > test/langtools/tools/javac/lvti/T8200199.java > test/langtools/tools/javac/lvti/badTypeReference/BadTypeReference.java > test/langtools/tools/javac/preview/classReaderTest/Client.java > ) > > Otherwise looks good to me. > > Jan > > On 2.5.2018 14:00, B. Blaser wrote: >> Looks good! >> >> Cheers, >> Bernard >> >> On 2 May 2018 at 13:19, Maurizio Cimadamore >> wrote: >>> Hi, >>> I put together a webrev based on the fix that B. Blaser put together >>> few >>> days ago. I've enhanced the test as I realized that the erroneous >>> condition >>> could present in multiple situations (the patch seems to fix all of >>> them). >>> >>> The underlying issue is that when we create a fake block for the lambda >>> expression (which is needed for speculatively check its contents), >>> we forget >>> setting its position - meaning that all diags reported against the >>> rewritten >>> block will now appear off sync. >>> >>> One solution would be to tweak the code to never use speculative >>> trees to >>> report diagnostic - but that would be very invasive; a cheaper fix >>> (the one >>> attempted here) is to add the required positional info to the >>> rewritten tree >>> so that it matches the original position. >>> >>> http://cr.openjdk.java.net/~mcimadamore/8202372/ >>> >>> Cheers >>> Maurizio >>> From jan.lahoda at oracle.com Wed May 2 13:59:41 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 2 May 2018 15:59:41 +0200 Subject: RFR 8202372: Diagnostic with incorrect line info generated when compiling lambda expression In-Reply-To: References: <5AE9ABCF.2030504@oracle.com> Message-ID: <5AE9C44D.2040804@oracle.com> On 2.5.2018 15:56, Maurizio Cimadamore wrote: > Good catch - turns out there's a bug in my jtreg IntelliJ plugin that is > causing this :-) > > If it's ok, I will fix the bogus occurrences as part of this commit > (with no followup review). > > Let me know if that's ok. Sure, fine with me. Jan > > Maurizio > > > On 02/05/18 13:15, Jan Lahoda wrote: >> In: >> test/langtools/tools/javac/lambda/8202372/T8202372.java >> >> There is a typo: >> >> nodynamioccopyright >> => >> nodynamiccopyright >> >> (there appears to be a handful of more occurrences of the typo in a >> handful of other files: >> test/langtools/tools/javac/lvti/T8200199.java >> test/langtools/tools/javac/lvti/badTypeReference/BadTypeReference.java >> test/langtools/tools/javac/preview/classReaderTest/Client.java >> ) >> >> Otherwise looks good to me. >> >> Jan >> >> On 2.5.2018 14:00, B. Blaser wrote: >>> Looks good! >>> >>> Cheers, >>> Bernard >>> >>> On 2 May 2018 at 13:19, Maurizio Cimadamore >>> wrote: >>>> Hi, >>>> I put together a webrev based on the fix that B. Blaser put together >>>> few >>>> days ago. I've enhanced the test as I realized that the erroneous >>>> condition >>>> could present in multiple situations (the patch seems to fix all of >>>> them). >>>> >>>> The underlying issue is that when we create a fake block for the lambda >>>> expression (which is needed for speculatively check its contents), >>>> we forget >>>> setting its position - meaning that all diags reported against the >>>> rewritten >>>> block will now appear off sync. >>>> >>>> One solution would be to tweak the code to never use speculative >>>> trees to >>>> report diagnostic - but that would be very invasive; a cheaper fix >>>> (the one >>>> attempted here) is to add the required positional info to the >>>> rewritten tree >>>> so that it matches the original position. >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8202372/ >>>> >>>> Cheers >>>> Maurizio >>>> > From jan.lahoda at oracle.com Thu May 3 18:07:43 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 3 May 2018 20:07:43 +0200 Subject: RFR : JDK-8202387: javac --release 11 not supported Message-ID: <5AEB4FEF.9080306@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8202387 This patch adds historical data for JDK 10 and adds support for --release 11. To simplify adding new platforms, the CreateSymbols tool is updated to support incrementally adding platform support. So now it is possible to run command like: /bin/java build.tools.symbolgenerator.CreateSymbols build-description-incremental symbols include.list to add historical data for JDK 10. In the future it might even be possible to use the source launcher so that one would not need to compile the tool before use. The webrevs are split into two: -updating the CreateSymbols tool, and adding a test that verifies that "--release " works (as suggested): http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ -actually adding the data for JDK 10, and adding --release 11: http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ How does this look? Thanks, Jan From jonathan.gibbons at oracle.com Fri May 4 01:27:26 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 03 May 2018 18:27:26 -0700 Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEB4FEF.9080306@oracle.com> References: <5AEB4FEF.9080306@oracle.com> Message-ID: <5AEBB6FE.5090400@oracle.com> OK. It would be even better, perhaps in a subsequent update, if make/gendata/Gendata-jdk.compiler.gmk did not have to be updated for each release ... i.e. by changing A to B, and soon to C etc. The version letter can surely be inferred by the system. -- Jon On 05/03/2018 11:07 AM, Jan Lahoda wrote: > Hi, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8202387 > > This patch adds historical data for JDK 10 and adds support for > --release 11. > > To simplify adding new platforms, the CreateSymbols tool is updated to > support incrementally adding platform support. So now it is possible > to run command like: > /bin/java > build.tools.symbolgenerator.CreateSymbols > build-description-incremental symbols include.list > > to add historical data for JDK 10. In the future it might even be > possible to use the source launcher so that one would not need to > compile the tool before use. > > The webrevs are split into two: > -updating the CreateSymbols tool, and adding a test that verifies that > "--release " works (as suggested): > http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ > -actually adding the data for JDK 10, and adding --release 11: > http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ > > How does this look? > > Thanks, > Jan From jan.lahoda at oracle.com Fri May 4 13:48:55 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 4 May 2018 15:48:55 +0200 Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEBB6FE.5090400@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> Message-ID: <5AEC64C7.9020206@oracle.com> [+build-dev] On 4.5.2018 03:27, Jonathan Gibbons wrote: > OK. > > It would be even better, perhaps in a subsequent update, if > make/gendata/Gendata-jdk.compiler.gmk > did not have to be updated for each release ... i.e. by changing A to B, > and soon to C etc. The version > letter can surely be inferred by the system. True. Updated webrevs: http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ (code changes, including update to Makefiles to automatically infer the current JDK version) http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ (historical data for JDK 10, similar patches will be needed for each new JDK version) How does this look? Thanks, Jan > > -- Jon > > > > On 05/03/2018 11:07 AM, Jan Lahoda wrote: >> Hi, >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8202387 >> >> This patch adds historical data for JDK 10 and adds support for >> --release 11. >> >> To simplify adding new platforms, the CreateSymbols tool is updated to >> support incrementally adding platform support. So now it is possible >> to run command like: >> /bin/java >> build.tools.symbolgenerator.CreateSymbols >> build-description-incremental symbols include.list >> >> to add historical data for JDK 10. In the future it might even be >> possible to use the source launcher so that one would not need to >> compile the tool before use. >> >> The webrevs are split into two: >> -updating the CreateSymbols tool, and adding a test that verifies that >> "--release " works (as suggested): >> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >> -actually adding the data for JDK 10, and adding --release 11: >> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >> >> How does this look? >> >> Thanks, >> Jan > From erik.joelsson at oracle.com Fri May 4 15:36:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 May 2018 08:36:50 -0700 Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEC64C7.9020206@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> Message-ID: <62cbe2a0-dc93-5f7f-8888-b8708d064a0d@oracle.com> Build change looks good. /Erik On 2018-05-04 06:48, Jan Lahoda wrote: > [+build-dev] > > On 4.5.2018 03:27, Jonathan Gibbons wrote: >> OK. >> >> It would be even better, perhaps in a subsequent update, if >> make/gendata/Gendata-jdk.compiler.gmk >> did not have to be updated for each release ... i.e. by changing A to B, >> and soon to C etc. The version >> letter can surely be inferred by the system. > > True. Updated webrevs: > http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ > (code changes, including update to Makefiles to automatically infer > the current JDK version) > > http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ > (historical data for JDK 10, similar patches will be needed for each > new JDK version) > > How does this look? > > Thanks, > ??? Jan > >> >> -- Jon >> >> >> >> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>> Hi, >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>> >>> This patch adds historical data for JDK 10 and adds support for >>> --release 11. >>> >>> To simplify adding new platforms, the CreateSymbols tool is updated to >>> support incrementally adding platform support. So now it is possible >>> to run command like: >>> /bin/java >>> build.tools.symbolgenerator.CreateSymbols >>> build-description-incremental symbols include.list >>> >>> to add historical data for JDK 10. In the future it might even be >>> possible to use the source launcher so that one would not need to >>> compile the tool before use. >>> >>> The webrevs are split into two: >>> -updating the CreateSymbols tool, and adding a test that verifies that >>> "--release " works (as suggested): >>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>> -actually adding the data for JDK 10, and adding --release 11: >>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >> From forax at univ-mlv.fr Fri May 4 16:09:35 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 4 May 2018 18:09:35 +0200 (CEST) Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEC64C7.9020206@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> Message-ID: <551463107.1794248.1525450175516.JavaMail.zimbra@u-pem.fr> Hi Jan, there is several occurences of Arrays.asList() that can be replaced by List.of() to make them really immutable. in CreateSymbols.java in dumpCurrentClasses, while ((read = in.read()) != (-1)) { baos.write(read); } should be replaced by in.transferTo(baos); in TransitiveDependencies.java, - todo should be an ArrayDeque instead of a LinkedList, array based data structure are usually faster - newBufferedWriter can takes only one argument in PreviewOptionTest.java, - versionsToTest.stream().forEach can be replaced by versionsToTest.forEach regards, R?mi ----- Mail original ----- > De: "jan lahoda" > ?: "jonathan gibbons" , "compiler-dev" , > build-dev at openjdk.java.net > Envoy?: Vendredi 4 Mai 2018 15:48:55 > Objet: Re: RFR : JDK-8202387: javac --release 11 not supported > [+build-dev] > > On 4.5.2018 03:27, Jonathan Gibbons wrote: >> OK. >> >> It would be even better, perhaps in a subsequent update, if >> make/gendata/Gendata-jdk.compiler.gmk >> did not have to be updated for each release ... i.e. by changing A to B, >> and soon to C etc. The version >> letter can surely be inferred by the system. > > True. Updated webrevs: > http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ > (code changes, including update to Makefiles to automatically infer the > current JDK version) > > http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ > (historical data for JDK 10, similar patches will be needed for each new > JDK version) > > How does this look? > > Thanks, > Jan > >> >> -- Jon >> >> >> >> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>> Hi, >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>> >>> This patch adds historical data for JDK 10 and adds support for >>> --release 11. >>> >>> To simplify adding new platforms, the CreateSymbols tool is updated to >>> support incrementally adding platform support. So now it is possible >>> to run command like: >>> /bin/java >>> build.tools.symbolgenerator.CreateSymbols >>> build-description-incremental symbols include.list >>> >>> to add historical data for JDK 10. In the future it might even be >>> possible to use the source launcher so that one would not need to >>> compile the tool before use. >>> >>> The webrevs are split into two: >>> -updating the CreateSymbols tool, and adding a test that verifies that >>> "--release " works (as suggested): >>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>> -actually adding the data for JDK 10, and adding --release 11: >>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>> >>> How does this look? >>> >>> Thanks, >>> Jan From jonathan.gibbons at oracle.com Fri May 4 20:45:11 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 May 2018 13:45:11 -0700 Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEC64C7.9020206@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> Message-ID: <5AECC657.3050304@oracle.com> I like the Makefile improvement. +1 -- Jon On 05/04/2018 06:48 AM, Jan Lahoda wrote: > [+build-dev] > > On 4.5.2018 03:27, Jonathan Gibbons wrote: >> OK. >> >> It would be even better, perhaps in a subsequent update, if >> make/gendata/Gendata-jdk.compiler.gmk >> did not have to be updated for each release ... i.e. by changing A to B, >> and soon to C etc. The version >> letter can surely be inferred by the system. > > True. Updated webrevs: > http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ > (code changes, including update to Makefiles to automatically infer > the current JDK version) > > http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ > (historical data for JDK 10, similar patches will be needed for each > new JDK version) > > How does this look? > > Thanks, > Jan > >> >> -- Jon >> >> >> >> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>> Hi, >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>> >>> This patch adds historical data for JDK 10 and adds support for >>> --release 11. >>> >>> To simplify adding new platforms, the CreateSymbols tool is updated to >>> support incrementally adding platform support. So now it is possible >>> to run command like: >>> /bin/java >>> build.tools.symbolgenerator.CreateSymbols >>> build-description-incremental symbols include.list >>> >>> to add historical data for JDK 10. In the future it might even be >>> possible to use the source launcher so that one would not need to >>> compile the tool before use. >>> >>> The webrevs are split into two: >>> -updating the CreateSymbols tool, and adding a test that verifies that >>> "--release " works (as suggested): >>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>> -actually adding the data for JDK 10, and adding --release 11: >>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>> >>> How does this look? >>> >>> Thanks, >>> Jan >> From jonathan.gibbons at oracle.com Fri May 4 21:59:53 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 May 2018 14:59:53 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <5AECD7D9.4080400@oracle.com> Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases. The webrev includes a delta-webrev for those that just want to see what has changed since last time. Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html Original webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html Delta webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html Note that the work is temporarily blocked by JDK-8202387: javac --release 11 not supported. A fix for that is underway and in review: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html This work has been tested using a workaround for this issue, and will be tested again when the real fix is in place. -- Jon On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Sun May 6 18:39:24 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Sun, 6 May 2018 20:39:24 +0200 Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <551463107.1794248.1525450175516.JavaMail.zimbra@u-pem.fr> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> <551463107.1794248.1525450175516.JavaMail.zimbra@u-pem.fr> Message-ID: <5AEF4BDC.8060609@oracle.com> Hi R?mi, Thanks for the comments; updated webrev: http://cr.openjdk.java.net/~jlahoda/8202387/code.02/ Jan On 4.5.2018 18:09, Remi Forax wrote: > Hi Jan, > there is several occurences of Arrays.asList() that can be replaced by List.of() to make them really immutable. > > in CreateSymbols.java > in dumpCurrentClasses, > while ((read = in.read()) != (-1)) { > baos.write(read); > } > should be replaced by > in.transferTo(baos); > > in TransitiveDependencies.java, > - todo should be an ArrayDeque instead of a LinkedList, array based data structure are usually faster > - newBufferedWriter can takes only one argument > > in PreviewOptionTest.java, > - versionsToTest.stream().forEach can be replaced by versionsToTest.forEach > > regards, > R?mi > > ----- Mail original ----- >> De: "jan lahoda" >> ?: "jonathan gibbons" , "compiler-dev" , >> build-dev at openjdk.java.net >> Envoy?: Vendredi 4 Mai 2018 15:48:55 >> Objet: Re: RFR : JDK-8202387: javac --release 11 not supported > >> [+build-dev] >> >> On 4.5.2018 03:27, Jonathan Gibbons wrote: >>> OK. >>> >>> It would be even better, perhaps in a subsequent update, if >>> make/gendata/Gendata-jdk.compiler.gmk >>> did not have to be updated for each release ... i.e. by changing A to B, >>> and soon to C etc. The version >>> letter can surely be inferred by the system. >> >> True. Updated webrevs: >> http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ >> (code changes, including update to Makefiles to automatically infer the >> current JDK version) >> >> http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ >> (historical data for JDK 10, similar patches will be needed for each new >> JDK version) >> >> How does this look? >> >> Thanks, >> Jan >> >>> >>> -- Jon >>> >>> >>> >>> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>>> >>>> This patch adds historical data for JDK 10 and adds support for >>>> --release 11. >>>> >>>> To simplify adding new platforms, the CreateSymbols tool is updated to >>>> support incrementally adding platform support. So now it is possible >>>> to run command like: >>>> /bin/java >>>> build.tools.symbolgenerator.CreateSymbols >>>> build-description-incremental symbols include.list >>>> >>>> to add historical data for JDK 10. In the future it might even be >>>> possible to use the source launcher so that one would not need to >>>> compile the tool before use. >>>> >>>> The webrevs are split into two: >>>> -updating the CreateSymbols tool, and adding a test that verifies that >>>> "--release " works (as suggested): >>>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>>> -actually adding the data for JDK 10, and adding --release 11: >>>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> Jan From forax at univ-mlv.fr Sun May 6 18:53:27 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 6 May 2018 20:53:27 +0200 (CEST) Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEF4BDC.8060609@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> <551463107.1794248.1525450175516.JavaMail.zimbra@u-pem.fr> <5AEF4BDC.8060609@oracle.com> Message-ID: <1679984286.2142883.1525632807277.JavaMail.zimbra@u-pem.fr> Looks good. R?mi ----- Mail original ----- > De: "jan lahoda" > ?: "Remi Forax" > Cc: "jonathan gibbons" , "compiler-dev" , "build-dev" > > Envoy?: Dimanche 6 Mai 2018 20:39:24 > Objet: Re: RFR : JDK-8202387: javac --release 11 not supported > Hi R?mi, > > Thanks for the comments; updated webrev: > http://cr.openjdk.java.net/~jlahoda/8202387/code.02/ > > Jan > > On 4.5.2018 18:09, Remi Forax wrote: >> Hi Jan, >> there is several occurences of Arrays.asList() that can be replaced by List.of() >> to make them really immutable. >> >> in CreateSymbols.java >> in dumpCurrentClasses, >> while ((read = in.read()) != (-1)) { >> baos.write(read); >> } >> should be replaced by >> in.transferTo(baos); >> >> in TransitiveDependencies.java, >> - todo should be an ArrayDeque instead of a LinkedList, array based data >> structure are usually faster >> - newBufferedWriter can takes only one argument >> >> in PreviewOptionTest.java, >> - versionsToTest.stream().forEach can be replaced by versionsToTest.forEach >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "jan lahoda" >>> ?: "jonathan gibbons" , "compiler-dev" >>> , >>> build-dev at openjdk.java.net >>> Envoy?: Vendredi 4 Mai 2018 15:48:55 >>> Objet: Re: RFR : JDK-8202387: javac --release 11 not supported >> >>> [+build-dev] >>> >>> On 4.5.2018 03:27, Jonathan Gibbons wrote: >>>> OK. >>>> >>>> It would be even better, perhaps in a subsequent update, if >>>> make/gendata/Gendata-jdk.compiler.gmk >>>> did not have to be updated for each release ... i.e. by changing A to B, >>>> and soon to C etc. The version >>>> letter can surely be inferred by the system. >>> >>> True. Updated webrevs: >>> http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ >>> (code changes, including update to Makefiles to automatically infer the >>> current JDK version) >>> >>> http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ >>> (historical data for JDK 10, similar patches will be needed for each new >>> JDK version) >>> >>> How does this look? >>> >>> Thanks, >>> Jan >>> >>>> >>>> -- Jon >>>> >>>> >>>> >>>> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>>>> >>>>> This patch adds historical data for JDK 10 and adds support for >>>>> --release 11. >>>>> >>>>> To simplify adding new platforms, the CreateSymbols tool is updated to >>>>> support incrementally adding platform support. So now it is possible >>>>> to run command like: >>>>> /bin/java >>>>> build.tools.symbolgenerator.CreateSymbols >>>>> build-description-incremental symbols include.list >>>>> >>>>> to add historical data for JDK 10. In the future it might even be >>>>> possible to use the source launcher so that one would not need to >>>>> compile the tool before use. >>>>> >>>>> The webrevs are split into two: >>>>> -updating the CreateSymbols tool, and adding a test that verifies that >>>>> "--release " works (as suggested): >>>>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>>>> -actually adding the data for JDK 10, and adding --release 11: >>>>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>>>> >>>>> How does this look? >>>>> >>>>> Thanks, > >>>> Jan From jan.lahoda at oracle.com Wed May 9 12:32:36 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 9 May 2018 14:32:36 +0200 Subject: RFR: JDK-8202843: langtools ant build fails Message-ID: <5AF2EA64.8080605@oracle.com> Hi, The langtools ant build (used for javac development) fails with: -- [exec] /usr/local/home/lahvac/src/jdk/jdk10/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java:3011: error: cannot find symbol [exec] var url = new URL(filename); [exec] ^ [exec] symbol: class var [exec] location: class JShellTool ... --- This is because the build still uses -source 9 -target 9, while the code already uses type inference. We could update the setting to -source 10 -target 10, but I am not sure we need it - can we just use the default? This is not an official build, so some small differences from the official build are acceptable I think. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8202843/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8202843 Thanks, Jan From jan.lahoda at oracle.com Wed May 9 13:44:02 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 9 May 2018 15:44:02 +0200 Subject: RFR : JDK-8202832: cycle detection depends on ordering of requires directives Message-ID: <5AF2FB22.2040106@oracle.com> Hi, Detection of cyclic dependency among modules is broken, as the tested module is marked as acyclic after checking its first dependency. The intent of marking the module acyclic was to prevent duplicated errors, but it might be more consistent to report error on all sources that are included in the cycle, so this is what the proposed patch is doing. Webrev: http://cr.openjdk.java.net/~jlahoda/8202832/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8202832 Thanks, Jan From maurizio.cimadamore at oracle.com Wed May 9 13:58:44 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 9 May 2018 14:58:44 +0100 Subject: RFR: JDK-8202843: langtools ant build fails In-Reply-To: <5AF2EA64.8080605@oracle.com> References: <5AF2EA64.8080605@oracle.com> Message-ID: Looks good Maurizio On 09/05/18 13:32, Jan Lahoda wrote: > Hi, > > The langtools ant build (used for javac development) fails with: > -- > ???? [exec] > /usr/local/home/lahvac/src/jdk/jdk10/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java:3011: > error: cannot find symbol > ???? [exec] var url = new URL(filename); > ???? [exec] ^ > ???? [exec] symbol: class var > ???? [exec] location: class JShellTool > ... > --- > > This is because the build still uses -source 9 -target 9, while the > code already uses type inference. We could update the setting to > -source 10 -target 10, but I am not sure we need it - can we just use > the default? This is not an official build, so some small differences > from the official build are acceptable I think. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8202843/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8202843 > > Thanks, > ??? Jan From mandy.chung at oracle.com Thu May 10 04:04:13 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 9 May 2018 21:04:13 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5AECD7D9.4080400@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <5AECD7D9.4080400@oracle.com> Message-ID: On 5/4/18 2:59 PM, Jonathan Gibbons wrote: > Here's an update to the previously proposed patch for JEP 330: Launch > Single-File Source-Code Programs. > It includes all review feedback so far. The changes are mostly minor, > but with the addition of more test cases. > > The webrev includes a delta-webrev for those that just want to see > what has changed since last time. > > Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html > > ??? Original webrev: > http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html > ??? Delta webrev: > http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html > I looked through the change and it looks fine to me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu May 10 12:49:11 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 10 May 2018 08:49:11 -0400 Subject: RFR : JDK-8202832: cycle detection depends on ordering of requires directives In-Reply-To: <5AF2FB22.2040106@oracle.com> References: <5AF2FB22.2040106@oracle.com> Message-ID: <964c791e-83e0-d545-d323-6e4a4f308a5d@oracle.com> looks good, Vicente On 05/09/2018 09:44 AM, Jan Lahoda wrote: > Hi, > > Detection of cyclic dependency among modules is broken, as the tested > module is marked as acyclic after checking its first dependency. > > The intent of marking the module acyclic was to prevent duplicated > errors, but it might be more consistent to report error on all sources > that are included in the cycle, so this is what the proposed patch is > doing. > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8202832/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8202832 > > Thanks, > ??? Jan From maurizio.cimadamore at oracle.com Fri May 11 10:31:04 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 May 2018 11:31:04 +0100 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5AECD7D9.4080400@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <5AECD7D9.4080400@oracle.com> Message-ID: Thumbs up - thanks for taking the comments into account. Great job! Maurizio On 04/05/18 22:59, Jonathan Gibbons wrote: > Here's an update to the previously proposed patch for JEP 330: Launch > Single-File Source-Code Programs. > It includes all review feedback so far. The changes are mostly minor, > but with the addition of more test cases. > > The webrev includes a delta-webrev for those that just want to see > what has changed since last time. > > Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html > > ??? Original webrev: > http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html > ??? Delta webrev: > http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html > > Note that the work is temporarily blocked by JDK-8202387: javac > --release 11 not supported. > A fix for that is underway and in review: > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html > This work has been tested using a workaround for this issue, and will > be tested again when the real fix is in place. > > -- Jon > > On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> ? * The part to handle the new command-line options is in the native >> ??? Java launcher code. >> ? * The part to invoke the compiler and subsequently execute the code >> ??? found in the source file is in a new class in the jdk.compiler >> module. >> ? * There are some minor Makefile changes, to add support for a new >> ??? resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >> >> -- Jon > From jan.lahoda at oracle.com Fri May 11 13:17:32 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 11 May 2018 15:17:32 +0200 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: References: <5ACFBE5C.1080508@oracle.com> <5AECD7D9.4080400@oracle.com> Message-ID: On 11.5.2018 12:31, Maurizio Cimadamore wrote: > Thumbs up - thanks for taking the comments into account. > > Great job! +1 Jan > > Maurizio > > > On 04/05/18 22:59, Jonathan Gibbons wrote: >> Here's an update to the previously proposed patch for JEP 330: Launch >> Single-File Source-Code Programs. >> It includes all review feedback so far. The changes are mostly minor, >> but with the addition of more test cases. >> >> The webrev includes a delta-webrev for those that just want to see >> what has changed since last time. >> >> Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html >> >> ??? Original webrev: >> http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html >> ??? Delta webrev: >> http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html >> >> Note that the work is temporarily blocked by JDK-8202387: javac >> --release 11 not supported. >> A fix for that is underway and in review: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html >> This work has been tested using a workaround for this issue, and will >> be tested again when the real fix is in place. >> >> -- Jon >> >> On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: >>> Please review an initial implementation for the feature described in >>> JEP 330: Launch Single-File Source-Code Programs. >>> >>> The work is described in the JEP and CSR, and falls into various parts: >>> >>> ? * The part to handle the new command-line options is in the native >>> ??? Java launcher code. >>> ? * The part to invoke the compiler and subsequently execute the code >>> ??? found in the source file is in a new class in the jdk.compiler >>> module. >>> ? * There are some minor Makefile changes, to add support for a new >>> ??? resource file. >>> >>> There are no changes to javac itself. >>> >>> JEP: http://openjdk.java.net/jeps/330 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >>> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >>> >>> -- Jon >> > From amaembo at gmail.com Mon May 14 09:00:47 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 14 May 2018 16:00:47 +0700 Subject: Confusing compilation error message on incorrect module-info.java Message-ID: Hello! Consider the following module-info.java file: class X {} module test {} When compiling it with javac 10 I see: module-info.java:2: error: 'module' or 'open' expected module test {} ^ 1 error I find it confusing when javac says that 'module' is expected and points to the 'module' word. Probably the error message should be refined. With best regards, Tagir Valeev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue May 15 00:52:05 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 May 2018 10:52:05 +1000 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control Message-ID: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> This review is being spread across four groups: langtools, core-libs, hotspot and serviceability. This is the specific review thread for langtools - webrev: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ See below for full details - including annotated full webrev guiding the review. The intent is to have JEP-181 targeted and integrated by the end of this month. Thanks, David ----- The nestmates project (JEP-181) introduces new classfile attributes to identify classes and interfaces in the same nest, so that the VM can perform access control based on those attributes and so allow direct private access between nestmates without requiring javac to generate synthetic accessor methods. These access control changes also extend to core reflection and the MethodHandle.Lookup contexts. Direct private calls between nestmates requires a more general calling context than is permitted by invokespecial, and so the JVMS is updated to allow, and javac updated to use, invokevirtual and invokeinterface for private class and interface method calls respectively. These changed semantics also extend to MethodHandle findXXX operations. At this time we are only concerned with static nest definitions, which map to a top-level class/interface as the nest-host and all its nested types as nest-members. Please see the JEP for further details. JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 All of the specification changes have been previously been worked out by the Valhalla Project Expert Group, and the implementation reviewed by the various contributors and discussed on the valhalla-dev mailing list. Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, Vladimir Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan Master webrev of all changes: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ Annotated master webrev index: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html Performance: this is expected to be performance neutral in a general sense. Benchmarking and performance runs are about to start. Testing Discussion: ------------------ The testing for nestmates can be broken into four main groups: - New tests specifically related to nestmates and currently in the runtime/Nestmates directory - New tests to complement existing tests by adding in testcases not previously expressible. - For example java/lang/invoke/SpecialInterfaceCall.java tests use of invokespecial for private interface methods and performing receiver typechecks, so we add java/lang/invoke/PrivateInterfaceCall.java to do similar tests for invokeinterface. - New JVM TI tests to verify the spec changes related to nest attributes. - Existing tests significantly affected by the nestmates changes, primarily: - runtime/SelectionResolution In most cases the nestmate changes makes certain invocations that were illegal, legal (e.g. not requiring invokespecial to invoke private interface methods; allowing access to private members via reflection/Methodhandles that were previously not allowed). - Existing tests incidentally affected by the nestmate changes This includes tests of things utilising class redefinition/retransformation to alter nested types but which unintentionally alter nest relationships (which is not permitted). There are still a number of tests problem-listed with issues filed against them to have them adapted to work with nestmates. Some of these are intended to be addressed in the short-term, while some (such as the runtime/SelectionResolution test changes) may not eventuate. - https://bugs.openjdk.java.net/browse/JDK-8203033 - https://bugs.openjdk.java.net/browse/JDK-8199450 - https://bugs.openjdk.java.net/browse/JDK-8196855 - https://bugs.openjdk.java.net/browse/JDK-8194857 - https://bugs.openjdk.java.net/browse/JDK-8187655 There is also further test work still to be completed (the JNI and JDI invocation tests): - https://bugs.openjdk.java.net/browse/JDK-8191117 which will continue in parallel with the main RFR. Pre-integration Testing: - General: - Mach5: hs/jdk tier1,2 - Mach5: hs-nightly (tiers 1 -3) - Targetted - nashorn (for asm changes) - hotspot: runtime/* serviceability/* compiler/* vmTestbase/* - jdk: java/lang/invoke/* java/lang/reflect/* java/lang/instrument/* java/lang/Class/* java/lang/management/* - langtools: tools/javac tools/javap From maurizio.cimadamore at oracle.com Tue May 15 07:59:43 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 May 2018 08:59:43 +0100 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> Message-ID: <02ceac9b-36ed-05cd-8753-fc7c4113697e@oracle.com> Hi David, the webrev looks good. You did an excellent job in staying on top of all these different areas - kudos! The only thing I can't decide is whether we will need an escape hatch flag for when you compile using -target 11 and, for some weird reason you need to disable nestmates (e.g. you want javac to emit accessors). But with all the testing you did, I'm confident that what we have is good - we can always add such a flag at a later stage - it's so trivial. Cheers Maurizio On 15/05/18 01:52, David Holmes wrote: > This review is being spread across four groups: langtools, core-libs, > hotspot and serviceability. This is the specific review thread for > langtools - webrev: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ > > See below for full details - including annotated full webrev guiding > the review. > > The intent is to have JEP-181 targeted and integrated by the end of > this month. > > Thanks, > David > ----- > > The nestmates project (JEP-181) introduces new classfile attributes to > identify classes and interfaces in the same nest, so that the VM can > perform access control based on those attributes and so allow direct > private access between nestmates without requiring javac to generate > synthetic accessor methods. These access control changes also extend > to core reflection and the MethodHandle.Lookup contexts. > > Direct private calls between nestmates requires a more general calling > context than is permitted by invokespecial, and so the JVMS is updated > to allow, and javac updated to use, invokevirtual and invokeinterface > for private class and interface method calls respectively. These > changed semantics also extend to MethodHandle findXXX operations. > > At this time we are only concerned with static nest definitions, which > map to a top-level class/interface as the nest-host and all its nested > types as nest-members. > > Please see the JEP for further details. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 > Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 > CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 > > All of the specification changes have been previously been worked out > by the Valhalla Project Expert Group, and the implementation reviewed > by the various contributors and discussed on the valhalla-dev mailing > list. > > Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, > Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, Vladimir > Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan > > Master webrev of all changes: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ > > Annotated master webrev index: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html > > Performance: this is expected to be performance neutral in a general > sense. Benchmarking and performance runs are about to start. > > Testing Discussion: > ------------------ > > The testing for nestmates can be broken into four main groups: > > -? New tests specifically related to nestmates and currently in the > runtime/Nestmates directory > > - New tests to complement existing tests by adding in testcases not > previously expressible. > ? -? For example java/lang/invoke/SpecialInterfaceCall.java tests use > of invokespecial for private interface methods and performing receiver > typechecks, so we add java/lang/invoke/PrivateInterfaceCall.java to do > similar tests for invokeinterface. > > -? New JVM TI tests to verify the spec changes related to nest > attributes. > > -? Existing tests significantly affected by the nestmates changes, > primarily: > ?? -? runtime/SelectionResolution > > ?? In most cases the nestmate changes makes certain invocations that > were illegal, legal (e.g. not requiring invokespecial to invoke > private interface methods; allowing access to private members via > reflection/Methodhandles that were previously not allowed). > > - Existing tests incidentally affected by the nestmate changes > > ? This includes tests of things utilising class > redefinition/retransformation to alter nested types but which > unintentionally alter nest relationships (which is not permitted). > > There are still a number of tests problem-listed with issues filed > against them to have them adapted to work with nestmates. Some of > these are intended to be addressed in the short-term, while some (such > as the runtime/SelectionResolution test changes) may not eventuate. > > - https://bugs.openjdk.java.net/browse/JDK-8203033 > - https://bugs.openjdk.java.net/browse/JDK-8199450 > - https://bugs.openjdk.java.net/browse/JDK-8196855 > - https://bugs.openjdk.java.net/browse/JDK-8194857 > - https://bugs.openjdk.java.net/browse/JDK-8187655 > > There is also further test work still to be completed (the JNI and JDI > invocation tests): > - https://bugs.openjdk.java.net/browse/JDK-8191117 > which will continue in parallel with the main RFR. > > Pre-integration Testing: > ?- General: > ??? - Mach5: hs/jdk tier1,2 > ??? - Mach5: hs-nightly (tiers 1 -3) > ?- Targetted > ?? - nashorn (for asm changes) > ?? - hotspot: runtime/* > ????????????? serviceability/* > ????????????? compiler/* > ????????????? vmTestbase/* > ?? - jdk: java/lang/invoke/* > ????????? java/lang/reflect/* > ????????? java/lang/instrument/* > ????????? java/lang/Class/* > ????????? java/lang/management/* > ? - langtools: tools/javac > ?????????????? tools/javap > From forax at univ-mlv.fr Tue May 15 08:13:41 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 15 May 2018 10:13:41 +0200 (CEST) Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: <02ceac9b-36ed-05cd-8753-fc7c4113697e@oracle.com> References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> <02ceac9b-36ed-05cd-8753-fc7c4113697e@oracle.com> Message-ID: <963299393.538375.1526372021300.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "David Holmes" , "compiler-dev" > Envoy?: Mardi 15 Mai 2018 09:59:43 > Objet: Re: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control > Hi David, > the webrev looks good. > > You did an excellent job in staying on top of all these different areas > - kudos! yes ! > > The only thing I can't decide is whether we will need an escape hatch > flag for when you compile using -target 11 and, for some weird reason > you need to disable nestmates (e.g. you want javac to emit accessors). > But with all the testing you did, I'm confident that what we have is > good - we can always add such a flag at a later stage - it's so trivial. I agree with this strategy. Given that we are aligning the VM class semantics to the Java the language semantics, i do not think people will still want accessors, perhaps in a nightmare, 'i still want accessors otherwise the stacktraces are too easy to read', in 5 when ldc class was intoduced, nobody ask to keep the class accessor code. > > Cheers > Maurizio regards, R?mi > > > On 15/05/18 01:52, David Holmes wrote: >> This review is being spread across four groups: langtools, core-libs, >> hotspot and serviceability. This is the specific review thread for >> langtools - webrev: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ >> >> See below for full details - including annotated full webrev guiding >> the review. >> >> The intent is to have JEP-181 targeted and integrated by the end of >> this month. >> >> Thanks, >> David >> ----- >> >> The nestmates project (JEP-181) introduces new classfile attributes to >> identify classes and interfaces in the same nest, so that the VM can >> perform access control based on those attributes and so allow direct >> private access between nestmates without requiring javac to generate >> synthetic accessor methods. These access control changes also extend >> to core reflection and the MethodHandle.Lookup contexts. >> >> Direct private calls between nestmates requires a more general calling >> context than is permitted by invokespecial, and so the JVMS is updated >> to allow, and javac updated to use, invokevirtual and invokeinterface >> for private class and interface method calls respectively. These >> changed semantics also extend to MethodHandle findXXX operations. >> >> At this time we are only concerned with static nest definitions, which >> map to a top-level class/interface as the nest-host and all its nested >> types as nest-members. >> >> Please see the JEP for further details. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 >> >> All of the specification changes have been previously been worked out >> by the Valhalla Project Expert Group, and the implementation reviewed >> by the various contributors and discussed on the valhalla-dev mailing >> list. >> >> Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, >> Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, Vladimir >> Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan >> >> Master webrev of all changes: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ >> >> Annotated master webrev index: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html >> >> Performance: this is expected to be performance neutral in a general >> sense. Benchmarking and performance runs are about to start. >> >> Testing Discussion: >> ------------------ >> >> The testing for nestmates can be broken into four main groups: >> >> -? New tests specifically related to nestmates and currently in the >> runtime/Nestmates directory >> >> - New tests to complement existing tests by adding in testcases not >> previously expressible. >> ? -? For example java/lang/invoke/SpecialInterfaceCall.java tests use >> of invokespecial for private interface methods and performing receiver >> typechecks, so we add java/lang/invoke/PrivateInterfaceCall.java to do >> similar tests for invokeinterface. >> >> -? New JVM TI tests to verify the spec changes related to nest >> attributes. >> >> -? Existing tests significantly affected by the nestmates changes, >> primarily: >> ?? -? runtime/SelectionResolution >> >> ?? In most cases the nestmate changes makes certain invocations that >> were illegal, legal (e.g. not requiring invokespecial to invoke >> private interface methods; allowing access to private members via >> reflection/Methodhandles that were previously not allowed). >> >> - Existing tests incidentally affected by the nestmate changes >> >> ? This includes tests of things utilising class >> redefinition/retransformation to alter nested types but which >> unintentionally alter nest relationships (which is not permitted). >> >> There are still a number of tests problem-listed with issues filed >> against them to have them adapted to work with nestmates. Some of >> these are intended to be addressed in the short-term, while some (such >> as the runtime/SelectionResolution test changes) may not eventuate. >> >> - https://bugs.openjdk.java.net/browse/JDK-8203033 >> - https://bugs.openjdk.java.net/browse/JDK-8199450 >> - https://bugs.openjdk.java.net/browse/JDK-8196855 >> - https://bugs.openjdk.java.net/browse/JDK-8194857 >> - https://bugs.openjdk.java.net/browse/JDK-8187655 >> >> There is also further test work still to be completed (the JNI and JDI >> invocation tests): >> - https://bugs.openjdk.java.net/browse/JDK-8191117 >> which will continue in parallel with the main RFR. >> >> Pre-integration Testing: >> ?- General: >> ??? - Mach5: hs/jdk tier1,2 >> ??? - Mach5: hs-nightly (tiers 1 -3) >> ?- Targetted >> ?? - nashorn (for asm changes) >> ?? - hotspot: runtime/* >> ????????????? serviceability/* >> ????????????? compiler/* >> ????????????? vmTestbase/* >> ?? - jdk: java/lang/invoke/* >> ????????? java/lang/reflect/* >> ????????? java/lang/instrument/* >> ????????? java/lang/Class/* >> ????????? java/lang/management/* >> ? - langtools: tools/javac >> ?????????????? tools/javap From david.holmes at oracle.com Tue May 15 08:33:11 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 May 2018 18:33:11 +1000 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: <02ceac9b-36ed-05cd-8753-fc7c4113697e@oracle.com> References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> <02ceac9b-36ed-05cd-8753-fc7c4113697e@oracle.com> Message-ID: <8e95ed8b-f926-c2a6-2252-d9f27693a2cb@oracle.com> Thanks Maurizio! David On 15/05/2018 5:59 PM, Maurizio Cimadamore wrote: > Hi David, > the webrev looks good. > > You did an excellent job in staying on top of all these different areas > - kudos! > > The only thing I can't decide is whether we will need an escape hatch > flag for when you compile using -target 11 and, for some weird reason > you need to disable nestmates (e.g. you want javac to emit accessors). > But with all the testing you did, I'm confident that what we have is > good - we can always add such a flag at a later stage - it's so trivial. > > Cheers > Maurizio > > > On 15/05/18 01:52, David Holmes wrote: >> This review is being spread across four groups: langtools, core-libs, >> hotspot and serviceability. This is the specific review thread for >> langtools - webrev: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ >> >> See below for full details - including annotated full webrev guiding >> the review. >> >> The intent is to have JEP-181 targeted and integrated by the end of >> this month. >> >> Thanks, >> David >> ----- >> >> The nestmates project (JEP-181) introduces new classfile attributes to >> identify classes and interfaces in the same nest, so that the VM can >> perform access control based on those attributes and so allow direct >> private access between nestmates without requiring javac to generate >> synthetic accessor methods. These access control changes also extend >> to core reflection and the MethodHandle.Lookup contexts. >> >> Direct private calls between nestmates requires a more general calling >> context than is permitted by invokespecial, and so the JVMS is updated >> to allow, and javac updated to use, invokevirtual and invokeinterface >> for private class and interface method calls respectively. These >> changed semantics also extend to MethodHandle findXXX operations. >> >> At this time we are only concerned with static nest definitions, which >> map to a top-level class/interface as the nest-host and all its nested >> types as nest-members. >> >> Please see the JEP for further details. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 >> >> All of the specification changes have been previously been worked out >> by the Valhalla Project Expert Group, and the implementation reviewed >> by the various contributors and discussed on the valhalla-dev mailing >> list. >> >> Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, >> Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, Vladimir >> Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan >> >> Master webrev of all changes: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ >> >> Annotated master webrev index: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html >> >> Performance: this is expected to be performance neutral in a general >> sense. Benchmarking and performance runs are about to start. >> >> Testing Discussion: >> ------------------ >> >> The testing for nestmates can be broken into four main groups: >> >> -? New tests specifically related to nestmates and currently in the >> runtime/Nestmates directory >> >> - New tests to complement existing tests by adding in testcases not >> previously expressible. >> ? -? For example java/lang/invoke/SpecialInterfaceCall.java tests use >> of invokespecial for private interface methods and performing receiver >> typechecks, so we add java/lang/invoke/PrivateInterfaceCall.java to do >> similar tests for invokeinterface. >> >> -? New JVM TI tests to verify the spec changes related to nest >> attributes. >> >> -? Existing tests significantly affected by the nestmates changes, >> primarily: >> ?? -? runtime/SelectionResolution >> >> ?? In most cases the nestmate changes makes certain invocations that >> were illegal, legal (e.g. not requiring invokespecial to invoke >> private interface methods; allowing access to private members via >> reflection/Methodhandles that were previously not allowed). >> >> - Existing tests incidentally affected by the nestmate changes >> >> ? This includes tests of things utilising class >> redefinition/retransformation to alter nested types but which >> unintentionally alter nest relationships (which is not permitted). >> >> There are still a number of tests problem-listed with issues filed >> against them to have them adapted to work with nestmates. Some of >> these are intended to be addressed in the short-term, while some (such >> as the runtime/SelectionResolution test changes) may not eventuate. >> >> - https://bugs.openjdk.java.net/browse/JDK-8203033 >> - https://bugs.openjdk.java.net/browse/JDK-8199450 >> - https://bugs.openjdk.java.net/browse/JDK-8196855 >> - https://bugs.openjdk.java.net/browse/JDK-8194857 >> - https://bugs.openjdk.java.net/browse/JDK-8187655 >> >> There is also further test work still to be completed (the JNI and JDI >> invocation tests): >> - https://bugs.openjdk.java.net/browse/JDK-8191117 >> which will continue in parallel with the main RFR. >> >> Pre-integration Testing: >> ?- General: >> ??? - Mach5: hs/jdk tier1,2 >> ??? - Mach5: hs-nightly (tiers 1 -3) >> ?- Targetted >> ?? - nashorn (for asm changes) >> ?? - hotspot: runtime/* >> ????????????? serviceability/* >> ????????????? compiler/* >> ????????????? vmTestbase/* >> ?? - jdk: java/lang/invoke/* >> ????????? java/lang/reflect/* >> ????????? java/lang/instrument/* >> ????????? java/lang/Class/* >> ????????? java/lang/management/* >> ? - langtools: tools/javac >> ?????????????? tools/javap >> > From david.holmes at oracle.com Tue May 15 08:33:46 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 May 2018 18:33:46 +1000 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: <963299393.538375.1526372021300.JavaMail.zimbra@u-pem.fr> References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> <02ceac9b-36ed-05cd-8753-fc7c4113697e@oracle.com> <963299393.538375.1526372021300.JavaMail.zimbra@u-pem.fr> Message-ID: <22cfa968-908a-dadd-0be4-80ec006cf170@oracle.com> Thanks Remi! David On 15/05/2018 6:13 PM, Remi Forax wrote: > ----- Mail original ----- >> De: "Maurizio Cimadamore" >> ?: "David Holmes" , "compiler-dev" >> Envoy?: Mardi 15 Mai 2018 09:59:43 >> Objet: Re: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control > >> Hi David, >> the webrev looks good. >> >> You did an excellent job in staying on top of all these different areas >> - kudos! > > yes ! > >> >> The only thing I can't decide is whether we will need an escape hatch >> flag for when you compile using -target 11 and, for some weird reason >> you need to disable nestmates (e.g. you want javac to emit accessors). >> But with all the testing you did, I'm confident that what we have is >> good - we can always add such a flag at a later stage - it's so trivial. > > I agree with this strategy. Given that we are aligning the VM class semantics to the Java the language semantics, i do not think people will still want accessors, perhaps in a nightmare, 'i still want accessors otherwise the stacktraces are too easy to read', in 5 when ldc class was intoduced, nobody ask to keep the class accessor code. > >> >> Cheers >> Maurizio > > regards, > R?mi > >> >> >> On 15/05/18 01:52, David Holmes wrote: >>> This review is being spread across four groups: langtools, core-libs, >>> hotspot and serviceability. This is the specific review thread for >>> langtools - webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ >>> >>> See below for full details - including annotated full webrev guiding >>> the review. >>> >>> The intent is to have JEP-181 targeted and integrated by the end of >>> this month. >>> >>> Thanks, >>> David >>> ----- >>> >>> The nestmates project (JEP-181) introduces new classfile attributes to >>> identify classes and interfaces in the same nest, so that the VM can >>> perform access control based on those attributes and so allow direct >>> private access between nestmates without requiring javac to generate >>> synthetic accessor methods. These access control changes also extend >>> to core reflection and the MethodHandle.Lookup contexts. >>> >>> Direct private calls between nestmates requires a more general calling >>> context than is permitted by invokespecial, and so the JVMS is updated >>> to allow, and javac updated to use, invokevirtual and invokeinterface >>> for private class and interface method calls respectively. These >>> changed semantics also extend to MethodHandle findXXX operations. >>> >>> At this time we are only concerned with static nest definitions, which >>> map to a top-level class/interface as the nest-host and all its nested >>> types as nest-members. >>> >>> Please see the JEP for further details. >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 >>> >>> All of the specification changes have been previously been worked out >>> by the Valhalla Project Expert Group, and the implementation reviewed >>> by the various contributors and discussed on the valhalla-dev mailing >>> list. >>> >>> Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, >>> Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, Vladimir >>> Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan >>> >>> Master webrev of all changes: >>> >>> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ >>> >>> Annotated master webrev index: >>> >>> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html >>> >>> Performance: this is expected to be performance neutral in a general >>> sense. Benchmarking and performance runs are about to start. >>> >>> Testing Discussion: >>> ------------------ >>> >>> The testing for nestmates can be broken into four main groups: >>> >>> -? New tests specifically related to nestmates and currently in the >>> runtime/Nestmates directory >>> >>> - New tests to complement existing tests by adding in testcases not >>> previously expressible. >>> ? -? For example java/lang/invoke/SpecialInterfaceCall.java tests use >>> of invokespecial for private interface methods and performing receiver >>> typechecks, so we add java/lang/invoke/PrivateInterfaceCall.java to do >>> similar tests for invokeinterface. >>> >>> -? New JVM TI tests to verify the spec changes related to nest >>> attributes. >>> >>> -? Existing tests significantly affected by the nestmates changes, >>> primarily: >>> ?? -? runtime/SelectionResolution >>> >>> ?? In most cases the nestmate changes makes certain invocations that >>> were illegal, legal (e.g. not requiring invokespecial to invoke >>> private interface methods; allowing access to private members via >>> reflection/Methodhandles that were previously not allowed). >>> >>> - Existing tests incidentally affected by the nestmate changes >>> >>> ? This includes tests of things utilising class >>> redefinition/retransformation to alter nested types but which >>> unintentionally alter nest relationships (which is not permitted). >>> >>> There are still a number of tests problem-listed with issues filed >>> against them to have them adapted to work with nestmates. Some of >>> these are intended to be addressed in the short-term, while some (such >>> as the runtime/SelectionResolution test changes) may not eventuate. >>> >>> - https://bugs.openjdk.java.net/browse/JDK-8203033 >>> - https://bugs.openjdk.java.net/browse/JDK-8199450 >>> - https://bugs.openjdk.java.net/browse/JDK-8196855 >>> - https://bugs.openjdk.java.net/browse/JDK-8194857 >>> - https://bugs.openjdk.java.net/browse/JDK-8187655 >>> >>> There is also further test work still to be completed (the JNI and JDI >>> invocation tests): >>> - https://bugs.openjdk.java.net/browse/JDK-8191117 >>> which will continue in parallel with the main RFR. >>> >>> Pre-integration Testing: >>> ?- General: >>> ??? - Mach5: hs/jdk tier1,2 >>> ??? - Mach5: hs-nightly (tiers 1 -3) >>> ?- Targetted >>> ?? - nashorn (for asm changes) >>> ?? - hotspot: runtime/* >>> ????????????? serviceability/* >>> ????????????? compiler/* >>> ????????????? vmTestbase/* >>> ?? - jdk: java/lang/invoke/* >>> ????????? java/lang/reflect/* >>> ????????? java/lang/instrument/* >>> ????????? java/lang/Class/* >>> ????????? java/lang/management/* >>> ? - langtools: tools/javac >>> ?????????????? tools/javap From maurizio.cimadamore at oracle.com Tue May 15 08:35:31 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 May 2018 09:35:31 +0100 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: <963299393.538375.1526372021300.JavaMail.zimbra@u-pem.fr> References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> <02ceac9b-36ed-05cd-8753-fc7c4113697e@oracle.com> <963299393.538375.1526372021300.JavaMail.zimbra@u-pem.fr> Message-ID: <360a1355-5d01-5cb8-8ba3-7a9f5b4e7953@oracle.com> On 15/05/18 09:13, Remi Forax wrote: > I agree with this strategy. Given that we are aligning the VM class semantics to the Java the language semantics, i do not think people will still want accessors, perhaps in a nightmare, 'i still want accessors otherwise the stacktraces are too easy to read', in 5 when ldc class was intoduced, nobody ask to keep the class accessor code. To be clear, I wasn't thinking of a flag to be used by the general public, but one used by the build system - in the past we had issues e.g. with indified string concat causing bootstrap issues in the JDK build, so we had to resort to such 'escape hatches' to disable generation of certain code shape (esp. while compiling java.base). But I doubt we will find such surprises at this late stage, given the amount of effort David put into testing all this. Maurizio From jan.lahoda at oracle.com Tue May 15 14:04:57 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 15 May 2018 16:04:57 +0200 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> Message-ID: <5AFAE909.7090706@oracle.com> The javac/jshell changes look OK to me. Jan On 15.5.2018 02:52, David Holmes wrote: > This review is being spread across four groups: langtools, core-libs, > hotspot and serviceability. This is the specific review thread for > langtools - webrev: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ > > See below for full details - including annotated full webrev guiding the > review. > > The intent is to have JEP-181 targeted and integrated by the end of this > month. > > Thanks, > David > ----- > > The nestmates project (JEP-181) introduces new classfile attributes to > identify classes and interfaces in the same nest, so that the VM can > perform access control based on those attributes and so allow direct > private access between nestmates without requiring javac to generate > synthetic accessor methods. These access control changes also extend to > core reflection and the MethodHandle.Lookup contexts. > > Direct private calls between nestmates requires a more general calling > context than is permitted by invokespecial, and so the JVMS is updated > to allow, and javac updated to use, invokevirtual and invokeinterface > for private class and interface method calls respectively. These changed > semantics also extend to MethodHandle findXXX operations. > > At this time we are only concerned with static nest definitions, which > map to a top-level class/interface as the nest-host and all its nested > types as nest-members. > > Please see the JEP for further details. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 > Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 > CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 > > All of the specification changes have been previously been worked out by > the Valhalla Project Expert Group, and the implementation reviewed by > the various contributors and discussed on the valhalla-dev mailing list. > > Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, > Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, Vladimir > Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan > > Master webrev of all changes: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ > > Annotated master webrev index: > > http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html > > Performance: this is expected to be performance neutral in a general > sense. Benchmarking and performance runs are about to start. > > Testing Discussion: > ------------------ > > The testing for nestmates can be broken into four main groups: > > - New tests specifically related to nestmates and currently in the > runtime/Nestmates directory > > - New tests to complement existing tests by adding in testcases not > previously expressible. > - For example java/lang/invoke/SpecialInterfaceCall.java tests use > of invokespecial for private interface methods and performing receiver > typechecks, so we add java/lang/invoke/PrivateInterfaceCall.java to do > similar tests for invokeinterface. > > - New JVM TI tests to verify the spec changes related to nest attributes. > > - Existing tests significantly affected by the nestmates changes, > primarily: > - runtime/SelectionResolution > > In most cases the nestmate changes makes certain invocations that > were illegal, legal (e.g. not requiring invokespecial to invoke private > interface methods; allowing access to private members via > reflection/Methodhandles that were previously not allowed). > > - Existing tests incidentally affected by the nestmate changes > > This includes tests of things utilising class > redefinition/retransformation to alter nested types but which > unintentionally alter nest relationships (which is not permitted). > > There are still a number of tests problem-listed with issues filed > against them to have them adapted to work with nestmates. Some of these > are intended to be addressed in the short-term, while some (such as the > runtime/SelectionResolution test changes) may not eventuate. > > - https://bugs.openjdk.java.net/browse/JDK-8203033 > - https://bugs.openjdk.java.net/browse/JDK-8199450 > - https://bugs.openjdk.java.net/browse/JDK-8196855 > - https://bugs.openjdk.java.net/browse/JDK-8194857 > - https://bugs.openjdk.java.net/browse/JDK-8187655 > > There is also further test work still to be completed (the JNI and JDI > invocation tests): > - https://bugs.openjdk.java.net/browse/JDK-8191117 > which will continue in parallel with the main RFR. > > Pre-integration Testing: > - General: > - Mach5: hs/jdk tier1,2 > - Mach5: hs-nightly (tiers 1 -3) > - Targetted > - nashorn (for asm changes) > - hotspot: runtime/* > serviceability/* > compiler/* > vmTestbase/* > - jdk: java/lang/invoke/* > java/lang/reflect/* > java/lang/instrument/* > java/lang/Class/* > java/lang/management/* > - langtools: tools/javac > tools/javap > From david.holmes at oracle.com Tue May 15 21:48:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 May 2018 07:48:07 +1000 Subject: [langtools] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control In-Reply-To: <5AFAE909.7090706@oracle.com> References: <1d62a49f-63d3-e667-9d18-920ba855ee1d@oracle.com> <5AFAE909.7090706@oracle.com> Message-ID: <91066cf2-9c4c-b098-57a2-a0db93fa6fe5@oracle.com> Thanks Jan! David On 16/05/2018 12:04 AM, Jan Lahoda wrote: > The javac/jshell changes look OK to me. > > Jan > > On 15.5.2018 02:52, David Holmes wrote: >> This review is being spread across four groups: langtools, core-libs, >> hotspot and serviceability. This is the specific review thread for >> langtools - webrev: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.langtools.v1/ >> >> See below for full details - including annotated full webrev guiding the >> review. >> >> The intent is to have JEP-181 targeted and integrated by the end of this >> month. >> >> Thanks, >> David >> ----- >> >> The nestmates project (JEP-181) introduces new classfile attributes to >> identify classes and interfaces in the same nest, so that the VM can >> perform access control based on those attributes and so allow direct >> private access between nestmates without requiring javac to generate >> synthetic accessor methods. These access control changes also extend to >> core reflection and the MethodHandle.Lookup contexts. >> >> Direct private calls between nestmates requires a more general calling >> context than is permitted by invokespecial, and so the JVMS is updated >> to allow, and javac updated to use, invokevirtual and invokeinterface >> for private class and interface method calls respectively. These changed >> semantics also extend to MethodHandle findXXX operations. >> >> At this time we are only concerned with static nest definitions, which >> map to a top-level class/interface as the nest-host and all its nested >> types as nest-members. >> >> Please see the JEP for further details. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 >> >> All of the specification changes have been previously been worked out by >> the Valhalla Project Expert Group, and the implementation reviewed by >> the various contributors and discussed on the valhalla-dev mailing list. >> >> Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, >> Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, Vladimir >> Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan >> >> Master webrev of all changes: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ >> >> Annotated master webrev index: >> >> http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html >> >> Performance: this is expected to be performance neutral in a general >> sense. Benchmarking and performance runs are about to start. >> >> Testing Discussion: >> ------------------ >> >> The testing for nestmates can be broken into four main groups: >> >> -? New tests specifically related to nestmates and currently in the >> runtime/Nestmates directory >> >> - New tests to complement existing tests by adding in testcases not >> previously expressible. >> ?? -? For example java/lang/invoke/SpecialInterfaceCall.java tests use >> of invokespecial for private interface methods and performing receiver >> typechecks, so we add java/lang/invoke/PrivateInterfaceCall.java to do >> similar tests for invokeinterface. >> >> -? New JVM TI tests to verify the spec changes related to nest >> attributes. >> >> -? Existing tests significantly affected by the nestmates changes, >> primarily: >> ??? -? runtime/SelectionResolution >> >> ??? In most cases the nestmate changes makes certain invocations that >> were illegal, legal (e.g. not requiring invokespecial to invoke private >> interface methods; allowing access to private members via >> reflection/Methodhandles that were previously not allowed). >> >> - Existing tests incidentally affected by the nestmate changes >> >> ?? This includes tests of things utilising class >> redefinition/retransformation to alter nested types but which >> unintentionally alter nest relationships (which is not permitted). >> >> There are still a number of tests problem-listed with issues filed >> against them to have them adapted to work with nestmates. Some of these >> are intended to be addressed in the short-term, while some (such as the >> runtime/SelectionResolution test changes) may not eventuate. >> >> - https://bugs.openjdk.java.net/browse/JDK-8203033 >> - https://bugs.openjdk.java.net/browse/JDK-8199450 >> - https://bugs.openjdk.java.net/browse/JDK-8196855 >> - https://bugs.openjdk.java.net/browse/JDK-8194857 >> - https://bugs.openjdk.java.net/browse/JDK-8187655 >> >> There is also further test work still to be completed (the JNI and JDI >> invocation tests): >> - https://bugs.openjdk.java.net/browse/JDK-8191117 >> which will continue in parallel with the main RFR. >> >> Pre-integration Testing: >> ? - General: >> ???? - Mach5: hs/jdk tier1,2 >> ???? - Mach5: hs-nightly (tiers 1 -3) >> ? - Targetted >> ??? - nashorn (for asm changes) >> ??? - hotspot: runtime/* >> ?????????????? serviceability/* >> ?????????????? compiler/* >> ?????????????? vmTestbase/* >> ??? - jdk: java/lang/invoke/* >> ?????????? java/lang/reflect/* >> ?????????? java/lang/instrument/* >> ?????????? java/lang/Class/* >> ?????????? java/lang/management/* >> ?? - langtools: tools/javac >> ??????????????? tools/javap >> From bsrbnd at gmail.com Thu May 17 12:39:09 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 17 May 2018 14:39:09 +0200 Subject: Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory Message-ID: Hi, Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory. Next is a quick fix for this. Any feedback is welcome. Cheers, Bernard diff -r 8e4fcfb4cfe4 test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java --- a/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java Thu May 17 10:32:26 2018 +0200 +++ b/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java Thu May 17 14:17:52 2018 +0200 @@ -25,10 +25,14 @@ * @test * @bug 8202387 * @summary Verify that javac can handle --release + * @library /tools/lib * @modules jdk.compiler/com.sun.tools.javac.code */ import java.io.IOException; +import java.nio.file.Files; +import java.nio.file.Path; +import java.nio.file.Paths; import java.util.Arrays; import java.util.List; import javax.tools.JavaCompiler; @@ -38,18 +42,29 @@ import com.sun.tools.javac.code.Source; +import toolbox.ToolBox; + public class ReleaseOptionCurrent { public static void main(String... args) throws IOException { new ReleaseOptionCurrent().run(); } + private final ToolBox tb = new ToolBox(); + void run() throws IOException { String lineSep = System.getProperty("line.separator"); + Path classes = Paths.get("classes"); + + if (Files.exists(classes)) { + tb.cleanDirectory(classes); + } else { + Files.createDirectories(classes); + } JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); try (StandardJavaFileManager fm = compiler.getStandardFileManager(null, null, null)) { Iterable input = fm.getJavaFileObjects(System.getProperty("test.src") + "/ReleaseOption.java"); - List options = Arrays.asList("--release", Source.DEFAULT.name); + List options = Arrays.asList("-d", classes.toString(), "--release", Source.DEFAULT.name); boolean result = compiler.getTask(null, fm, null, options, null, input).call(); if (!result) { From david.holmes at oracle.com Thu May 17 13:08:25 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 May 2018 23:08:25 +1000 Subject: Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory In-Reply-To: References: Message-ID: Hi Bernard, Can't you just use System.getProperty("test.classes") to get the output directory? Cheers, David On 17/05/2018 10:39 PM, B. Blaser wrote: > Hi, > > Test ReleaseOptionCurrent.java writes ReleaseOption.class in the > source directory. > Next is a quick fix for this. > Any feedback is welcome. > > Cheers, > Bernard > > > diff -r 8e4fcfb4cfe4 > test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > --- a/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > Thu May 17 10:32:26 2018 +0200 > +++ b/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > Thu May 17 14:17:52 2018 +0200 > @@ -25,10 +25,14 @@ > * @test > * @bug 8202387 > * @summary Verify that javac can handle --release > + * @library /tools/lib > * @modules jdk.compiler/com.sun.tools.javac.code > */ > > import java.io.IOException; > +import java.nio.file.Files; > +import java.nio.file.Path; > +import java.nio.file.Paths; > import java.util.Arrays; > import java.util.List; > import javax.tools.JavaCompiler; > @@ -38,18 +42,29 @@ > > import com.sun.tools.javac.code.Source; > > +import toolbox.ToolBox; > + > public class ReleaseOptionCurrent { > public static void main(String... args) throws IOException { > new ReleaseOptionCurrent().run(); > } > > + private final ToolBox tb = new ToolBox(); > + > void run() throws IOException { > String lineSep = System.getProperty("line.separator"); > + Path classes = Paths.get("classes"); > + > + if (Files.exists(classes)) { > + tb.cleanDirectory(classes); > + } else { > + Files.createDirectories(classes); > + } > JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); > try (StandardJavaFileManager fm = > compiler.getStandardFileManager(null, null, null)) { > Iterable input = > > fm.getJavaFileObjects(System.getProperty("test.src") + > "/ReleaseOption.java"); > - List options = Arrays.asList("--release", > Source.DEFAULT.name); > + List options = Arrays.asList("-d", > classes.toString(), "--release", Source.DEFAULT.name); > > boolean result = compiler.getTask(null, fm, null, > options, null, input).call(); > if (!result) { > From jonathan.gibbons at oracle.com Thu May 17 14:27:50 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 17 May 2018 07:27:50 -0700 Subject: Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory In-Reply-To: References: Message-ID: <95506eb1-cd87-d153-a465-85e6a6e90c82@oracle.com> Bernard, Since you are using classes in the current directory, you do not need to clean the directory (jtreg runs tests in an empty directory) nor do you need to create the directory (javac now does that). -- Jon On 5/17/18 5:39 AM, B. Blaser wrote: > Hi, > > Test ReleaseOptionCurrent.java writes ReleaseOption.class in the > source directory. > Next is a quick fix for this. > Any feedback is welcome. > > Cheers, > Bernard > > > diff -r 8e4fcfb4cfe4 > test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > --- a/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > Thu May 17 10:32:26 2018 +0200 > +++ b/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > Thu May 17 14:17:52 2018 +0200 > @@ -25,10 +25,14 @@ > * @test > * @bug 8202387 > * @summary Verify that javac can handle --release > + * @library /tools/lib > * @modules jdk.compiler/com.sun.tools.javac.code > */ > > import java.io.IOException; > +import java.nio.file.Files; > +import java.nio.file.Path; > +import java.nio.file.Paths; > import java.util.Arrays; > import java.util.List; > import javax.tools.JavaCompiler; > @@ -38,18 +42,29 @@ > > import com.sun.tools.javac.code.Source; > > +import toolbox.ToolBox; > + > public class ReleaseOptionCurrent { > public static void main(String... args) throws IOException { > new ReleaseOptionCurrent().run(); > } > > + private final ToolBox tb = new ToolBox(); > + > void run() throws IOException { > String lineSep = System.getProperty("line.separator"); > + Path classes = Paths.get("classes"); > + > + if (Files.exists(classes)) { > + tb.cleanDirectory(classes); > + } else { > + Files.createDirectories(classes); > + } > JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); > try (StandardJavaFileManager fm = > compiler.getStandardFileManager(null, null, null)) { > Iterable input = > > fm.getJavaFileObjects(System.getProperty("test.src") + > "/ReleaseOption.java"); > - List options = Arrays.asList("--release", > Source.DEFAULT.name); > + List options = Arrays.asList("-d", > classes.toString(), "--release", Source.DEFAULT.name); > > boolean result = compiler.getTask(null, fm, null, > options, null, input).call(); > if (!result) { From jonathan.gibbons at oracle.com Thu May 17 14:29:12 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 17 May 2018 07:29:12 -0700 Subject: Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory In-Reply-To: References: Message-ID: <6fe342e5-2621-04bb-f942-9b25e675ab7e@oracle.com> David, test.classes is for the test classes compiled by jtreg, It should not be used for arbitrary classes that may be compiled while the test is being run. -- Jon On 5/17/18 6:08 AM, David Holmes wrote: > Hi Bernard, > > Can't you just use System.getProperty("test.classes") to get the > output directory? > > Cheers, > David > > On 17/05/2018 10:39 PM, B. Blaser wrote: >> Hi, >> >> Test ReleaseOptionCurrent.java writes ReleaseOption.class in the >> source directory. >> Next is a quick fix for this. >> Any feedback is welcome. >> >> Cheers, >> Bernard >> >> >> diff -r 8e4fcfb4cfe4 >> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java >> --- >> a/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java >> ??? Thu May 17 10:32:26 2018 +0200 >> +++ >> b/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java >> ??? Thu May 17 14:17:52 2018 +0200 >> @@ -25,10 +25,14 @@ >> ?? * @test >> ?? * @bug 8202387 >> ?? * @summary Verify that javac can handle --release >> + * @library /tools/lib >> ?? * @modules jdk.compiler/com.sun.tools.javac.code >> ?? */ >> >> ? import java.io.IOException; >> +import java.nio.file.Files; >> +import java.nio.file.Path; >> +import java.nio.file.Paths; >> ? import java.util.Arrays; >> ? import java.util.List; >> ? import javax.tools.JavaCompiler; >> @@ -38,18 +42,29 @@ >> >> ? import com.sun.tools.javac.code.Source; >> >> +import toolbox.ToolBox; >> + >> ? public class ReleaseOptionCurrent { >> ????? public static void main(String... args) throws IOException { >> ????????? new ReleaseOptionCurrent().run(); >> ????? } >> >> +??? private final ToolBox tb = new ToolBox(); >> + >> ????? void run() throws IOException { >> ????????? String lineSep = System.getProperty("line.separator"); >> +??????? Path classes = Paths.get("classes"); >> + >> +??????? if (Files.exists(classes)) { >> +??????????? tb.cleanDirectory(classes); >> +??????? } else { >> +??????????? Files.createDirectories(classes); >> +??????? } >> ????????? JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); >> ????????? try (StandardJavaFileManager fm = >> compiler.getStandardFileManager(null, null, null)) { >> ????????????? Iterable input = >> >> fm.getJavaFileObjects(System.getProperty("test.src") + >> "/ReleaseOption.java"); >> -??????????? List options = Arrays.asList("--release", >> Source.DEFAULT.name); >> +??????????? List options = Arrays.asList("-d", >> classes.toString(), "--release", Source.DEFAULT.name); >> >> ????????????? boolean result = compiler.getTask(null, fm, null, >> options, null, input).call(); >> ????????????? if (!result) { >> From bsrbnd at gmail.com Thu May 17 16:28:07 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 17 May 2018 18:28:07 +0200 Subject: Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory In-Reply-To: <95506eb1-cd87-d153-a465-85e6a6e90c82@oracle.com> References: <95506eb1-cd87-d153-a465-85e6a6e90c82@oracle.com> Message-ID: Hi Jon & David, Thanks for your feedback. On 17 May 2018 at 16:27, Jonathan Gibbons wrote: > Bernard, > > Since you are using classes in the current directory, you do not need to > clean the directory (jtreg runs tests in an empty directory) nor do you need > to create the directory (javac now does that). > > -- Jon The fix is intended to put 'ReleaseOption.class' in the scratch folder, the sub-directory 'classes' being probably unnecessary. If I understand well Jon's explanation, simply '-d .' should make it (as next), is that right? Thanks, Bernard diff -r 8e4fcfb4cfe4 test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java --- a/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java Thu May 17 10:32:26 2018 +0200 +++ b/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java Thu May 17 18:03:14 2018 +0200 @@ -49,7 +49,7 @@ try (StandardJavaFileManager fm = compiler.getStandardFileManager(null, null, null)) { Iterable input = fm.getJavaFileObjects(System.getProperty("test.src") + "/ReleaseOption.java"); - List options = Arrays.asList("--release", Source.DEFAULT.name); + List options = Arrays.asList("-d", ".", "--release", Source.DEFAULT.name); boolean result = compiler.getTask(null, fm, null, options, null, input).call(); if (!result) { From jonathan.gibbons at oracle.com Thu May 17 17:01:02 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 17 May 2018 10:01:02 -0700 Subject: Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory In-Reply-To: References: <95506eb1-cd87-d153-a465-85e6a6e90c82@oracle.com> Message-ID: <5a6e9b1f-ec54-044b-fc2f-ba584300b30b@oracle.com> Bernard, `-d .`? would be reasonable in this case, since there will be no other files in the directory. -- Jon On 5/17/18 9:28 AM, B. Blaser wrote: > Hi Jon & David, > > Thanks for your feedback. > > On 17 May 2018 at 16:27, Jonathan Gibbons wrote: >> Bernard, >> >> Since you are using classes in the current directory, you do not need to >> clean the directory (jtreg runs tests in an empty directory) nor do you need >> to create the directory (javac now does that). >> >> -- Jon > The fix is intended to put 'ReleaseOption.class' in the scratch > folder, the sub-directory 'classes' being probably unnecessary. > If I understand well Jon's explanation, simply '-d .' should make it > (as next), is that right? > > Thanks, > Bernard > > > diff -r 8e4fcfb4cfe4 > test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > --- a/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > Thu May 17 10:32:26 2018 +0200 > +++ b/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > Thu May 17 18:03:14 2018 +0200 > @@ -49,7 +49,7 @@ > try (StandardJavaFileManager fm = > compiler.getStandardFileManager(null, null, null)) { > Iterable input = > > fm.getJavaFileObjects(System.getProperty("test.src") + > "/ReleaseOption.java"); > - List options = Arrays.asList("--release", > Source.DEFAULT.name); > + List options = Arrays.asList("-d", ".", > "--release", Source.DEFAULT.name); > > boolean result = compiler.getTask(null, fm, null, > options, null, input).call(); > if (!result) { From jan.lahoda at oracle.com Thu May 17 17:17:49 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 17 May 2018 19:17:49 +0200 Subject: Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory In-Reply-To: References: <95506eb1-cd87-d153-a465-85e6a6e90c82@oracle.com> Message-ID: <5AFDB93D.7020307@oracle.com> Hi Bernard, Looks good to me. Thanks for working on this. If everyone agrees, I'll work on pushing this. Jan On 17.5.2018 18:28, B. Blaser wrote: > Hi Jon & David, > > Thanks for your feedback. > > On 17 May 2018 at 16:27, Jonathan Gibbons wrote: >> Bernard, >> >> Since you are using classes in the current directory, you do not need to >> clean the directory (jtreg runs tests in an empty directory) nor do you need >> to create the directory (javac now does that). >> >> -- Jon > > The fix is intended to put 'ReleaseOption.class' in the scratch > folder, the sub-directory 'classes' being probably unnecessary. > If I understand well Jon's explanation, simply '-d .' should make it > (as next), is that right? > > Thanks, > Bernard > > > diff -r 8e4fcfb4cfe4 > test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > --- a/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > Thu May 17 10:32:26 2018 +0200 > +++ b/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java > Thu May 17 18:03:14 2018 +0200 > @@ -49,7 +49,7 @@ > try (StandardJavaFileManager fm = > compiler.getStandardFileManager(null, null, null)) { > Iterable input = > > fm.getJavaFileObjects(System.getProperty("test.src") + > "/ReleaseOption.java"); > - List options = Arrays.asList("--release", > Source.DEFAULT.name); > + List options = Arrays.asList("-d", ".", > "--release", Source.DEFAULT.name); > > boolean result = compiler.getTask(null, fm, null, > options, null, input).call(); > if (!result) { > From jonathan.gibbons at oracle.com Thu May 17 17:27:54 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 17 May 2018 10:27:54 -0700 Subject: Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory In-Reply-To: <5AFDB93D.7020307@oracle.com> References: <95506eb1-cd87-d153-a465-85e6a6e90c82@oracle.com> <5AFDB93D.7020307@oracle.com> Message-ID: Jan, Bernard's inline patch is OK by me -- Jon On 5/17/18 10:17 AM, Jan Lahoda wrote: > Hi Bernard, > > Looks good to me. Thanks for working on this. If everyone agrees, I'll > work on pushing this. > > Jan > > On 17.5.2018 18:28, B. Blaser wrote: >> Hi Jon & David, >> >> Thanks for your feedback. >> >> On 17 May 2018 at 16:27, Jonathan Gibbons >> wrote: >>> Bernard, >>> >>> Since you are using classes in the current directory, you do not >>> need to >>> clean the directory (jtreg runs tests in an empty directory) nor do >>> you need >>> to create the directory (javac now does that). >>> >>> -- Jon >> >> The fix is intended to put 'ReleaseOption.class' in the scratch >> folder, the sub-directory 'classes' being probably unnecessary. >> If I understand well Jon's explanation, simply '-d .' should make it >> (as next), is that right? >> >> Thanks, >> Bernard >> >> >> diff -r 8e4fcfb4cfe4 >> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java >> --- >> a/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java >> ??? Thu May 17 10:32:26 2018 +0200 >> +++ >> b/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java >> ??? Thu May 17 18:03:14 2018 +0200 >> @@ -49,7 +49,7 @@ >> ????????? try (StandardJavaFileManager fm = >> compiler.getStandardFileManager(null, null, null)) { >> ????????????? Iterable input = >> >> fm.getJavaFileObjects(System.getProperty("test.src") + >> "/ReleaseOption.java"); >> -??????????? List options = Arrays.asList("--release", >> Source.DEFAULT.name); >> +??????????? List options = Arrays.asList("-d", ".", >> "--release", Source.DEFAULT.name); >> >> ????????????? boolean result = compiler.getTask(null, fm, null, >> options, null, input).call(); >> ????????????? if (!result) { >> From jan.lahoda at oracle.com Fri May 18 10:52:22 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 May 2018 12:52:22 +0200 Subject: Test ReleaseOptionCurrent.java writes ReleaseOption.class in the source directory In-Reply-To: References: <95506eb1-cd87-d153-a465-85e6a6e90c82@oracle.com> <5AFDB93D.7020307@oracle.com> Message-ID: <5AFEB066.7060201@oracle.com> Done: http://hg.openjdk.java.net/jdk/jdk/rev/5593cab7fb96 Thanks, Jan On 17.5.2018 19:27, Jonathan Gibbons wrote: > Jan, > > Bernard's inline patch is OK by me > > -- Jon > > > On 5/17/18 10:17 AM, Jan Lahoda wrote: >> Hi Bernard, >> >> Looks good to me. Thanks for working on this. If everyone agrees, I'll >> work on pushing this. >> >> Jan >> >> On 17.5.2018 18:28, B. Blaser wrote: >>> Hi Jon & David, >>> >>> Thanks for your feedback. >>> >>> On 17 May 2018 at 16:27, Jonathan Gibbons >>> wrote: >>>> Bernard, >>>> >>>> Since you are using classes in the current directory, you do not >>>> need to >>>> clean the directory (jtreg runs tests in an empty directory) nor do >>>> you need >>>> to create the directory (javac now does that). >>>> >>>> -- Jon >>> >>> The fix is intended to put 'ReleaseOption.class' in the scratch >>> folder, the sub-directory 'classes' being probably unnecessary. >>> If I understand well Jon's explanation, simply '-d .' should make it >>> (as next), is that right? >>> >>> Thanks, >>> Bernard >>> >>> >>> diff -r 8e4fcfb4cfe4 >>> test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java >>> --- >>> a/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java >>> Thu May 17 10:32:26 2018 +0200 >>> +++ >>> b/test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java >>> Thu May 17 18:03:14 2018 +0200 >>> @@ -49,7 +49,7 @@ >>> try (StandardJavaFileManager fm = >>> compiler.getStandardFileManager(null, null, null)) { >>> Iterable input = >>> >>> fm.getJavaFileObjects(System.getProperty("test.src") + >>> "/ReleaseOption.java"); >>> - List options = Arrays.asList("--release", >>> Source.DEFAULT.name); >>> + List options = Arrays.asList("-d", ".", >>> "--release", Source.DEFAULT.name); >>> >>> boolean result = compiler.getTask(null, fm, null, >>> options, null, input).call(); >>> if (!result) { >>> > From jan.lahoda at oracle.com Fri May 18 11:02:25 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 May 2018 13:02:25 +0200 Subject: RFR: JDK-8198315: Incomplete classpath causes NPE in TransTypes Message-ID: <5AFEB2C1.4010909@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8198315 The issue here is that while reporting an error, a missing symbol is completed, which then throws CompletionFailure. This CF is caught and there's an attempt to report it as an error as well, but as it has the same coordinates as the original report, it is skipped as a duplicate. So, in the end, neither of these errors gets reported, and the compilation continues to backend and javac crashes later. There are multiple directions for a solution possible, I think: a) catch and handle the CFs while reporting the error. I tried to implement that, but catching the CompletionFailures inside RichDiagnosticFormatter didn't seem like a nice solution. b) make sure the CF throw while reporting the error is reported (by e.g. recording the coordinates after error reporting. But in this case, this would lead to a worse error messages, so it would be better to avoid this option. c) prevent completing the symbol while reporting the error. This is what the proposed patch is trying to do. Webrev: http://cr.openjdk.java.net/~jlahoda/8198315/webrev.00/ What do you think? Thanks, Jan From maurizio.cimadamore at oracle.com Fri May 18 12:16:45 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 May 2018 13:16:45 +0100 Subject: RFR: JDK-8198315: Incomplete classpath causes NPE in TransTypes In-Reply-To: <5AFEB2C1.4010909@oracle.com> References: <5AFEB2C1.4010909@oracle.com> Message-ID: <08497c84-f9b5-3f5d-8913-1fb3ce9a3703@oracle.com> Looks good. As we discussed offline yesterday I don't think this is 100% clear from completion (sometimes directSupertypes on intersections might complete too), but it's better than what we had before. Thanks Maurizio On 18/05/18 12:02, Jan Lahoda wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8198315 > > The issue here is that while reporting an error, a missing symbol is > completed, which then throws CompletionFailure. This CF is caught and > there's an attempt to report it as an error as well, but as it has the > same coordinates as the original report, it is skipped as a duplicate. > So, in the end, neither of these errors gets reported, and the > compilation continues to backend and javac crashes later. > > There are multiple directions for a solution possible, I think: > a) catch and handle the CFs while reporting the error. I tried to > implement that, but catching the CompletionFailures inside > RichDiagnosticFormatter didn't seem like a nice solution. > b) make sure the CF throw while reporting the error is reported (by > e.g. recording the coordinates after error reporting. But in this > case, this would lead to a worse error messages, so it would be better > to avoid this option. > c) prevent completing the symbol while reporting the error. This is > what the proposed patch is trying to do. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8198315/webrev.00/ > > What do you think? > > Thanks, > ??? Jan From maurizio.cimadamore at oracle.com Fri May 18 18:12:48 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 May 2018 19:12:48 +0100 Subject: RFR 8203436: javac should fail early when emitting illegal signature attributes Message-ID: Hi, this patch makes javac a bit stricter when it comes to generating bytecode that has illegal signature attributes (which can happen in case of non-denotable types). Instead of allowing compilation and then fail at verify time, this patch issues an error message. I've refactored another generation-related diagnostic to share the same 'header' - an example of the diagnostics involved is included in the webrev. http://cr.openjdk.java.net/~mcimadamore/8203436/ Cheers Maurizio From vicente.romero at oracle.com Fri May 18 18:28:18 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 18 May 2018 14:28:18 -0400 Subject: RFR 8203436: javac should fail early when emitting illegal signature attributes In-Reply-To: References: Message-ID: <3a032144-53f9-9507-b677-3572a604c9d3@oracle.com> looks good! Vicente On 05/18/2018 02:12 PM, Maurizio Cimadamore wrote: > Hi, > this patch makes javac a bit stricter when it comes to generating > bytecode that has illegal signature attributes (which can happen in > case of non-denotable types). Instead of allowing compilation and then > fail at verify time, this patch issues an error message. > > I've refactored another generation-related diagnostic to share the > same 'header' - an example of the diagnostics involved is included in > the webrev. > > http://cr.openjdk.java.net/~mcimadamore/8203436/ > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Fri May 18 20:46:09 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 May 2018 21:46:09 +0100 Subject: RFR 8203436: javac should fail early when emitting illegal signature attributes In-Reply-To: <3a032144-53f9-9507-b677-3572a604c9d3@oracle.com> References: <3a032144-53f9-9507-b677-3572a604c9d3@oracle.com> Message-ID: <165511fc-adb9-a4ef-f768-152fa3fb04dc@oracle.com> Thanks, I discovered another interesting test: interface A { } interface B { } class Outer { ?? class Inner { } ?? Outer m() { return null; } ?? void test(Outer outer) { ????? m().new Inner() { }; ?? } } This time it attempts to create a signature attribute with an intersection. This used to crash javac in 5-10, but with this patch a regular error message is emitted: error: error while generating class ? (illegal signature attribute for type INT#1) ? where INT#1 is an intersection type: ??? INT#1 extends Object,A,B 1 error I'll add this test to the patch. Maurizio On 18/05/18 19:28, Vicente Romero wrote: > looks good! > Vicente > > On 05/18/2018 02:12 PM, Maurizio Cimadamore wrote: >> Hi, >> this patch makes javac a bit stricter when it comes to generating >> bytecode that has illegal signature attributes (which can happen in >> case of non-denotable types). Instead of allowing compilation and >> then fail at verify time, this patch issues an error message. >> >> I've refactored another generation-related diagnostic to share the >> same 'header' - an example of the diagnostics involved is included in >> the webrev. >> >> http://cr.openjdk.java.net/~mcimadamore/8203436/ >> >> Cheers >> Maurizio >> > From vicente.romero at oracle.com Fri May 18 20:49:11 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 18 May 2018 16:49:11 -0400 Subject: RFR 8203436: javac should fail early when emitting illegal signature attributes In-Reply-To: <165511fc-adb9-a4ef-f768-152fa3fb04dc@oracle.com> References: <3a032144-53f9-9507-b677-3572a604c9d3@oracle.com> <165511fc-adb9-a4ef-f768-152fa3fb04dc@oracle.com> Message-ID: <6e5f0b9b-6ace-3831-da5e-6899ae217dce@oracle.com> On 05/18/2018 04:46 PM, Maurizio Cimadamore wrote: > Thanks, > > I discovered another interesting test: > > interface A { } > interface B { } > > class Outer { > ?? class Inner { } > > ?? Outer m() { return null; } > > ?? void test(Outer outer) { > ????? m().new Inner() { }; > ?? } > } yep very interesting > > > This time it attempts to create a signature attribute with an > intersection. This used to crash javac in 5-10, but with this patch a > regular error message is emitted: > > error: error while generating class > ? (illegal signature attribute for type INT#1) > ? where INT#1 is an intersection type: > ??? INT#1 extends Object,A,B > 1 error > > > I'll add this test to the patch. sounds good > > Maurizio Vicente > > > On 18/05/18 19:28, Vicente Romero wrote: >> looks good! >> Vicente >> >> On 05/18/2018 02:12 PM, Maurizio Cimadamore wrote: >>> Hi, >>> this patch makes javac a bit stricter when it comes to generating >>> bytecode that has illegal signature attributes (which can happen in >>> case of non-denotable types). Instead of allowing compilation and >>> then fail at verify time, this patch issues an error message. >>> >>> I've refactored another generation-related diagnostic to share the >>> same 'header' - an example of the diagnostics involved is included >>> in the webrev. >>> >>> http://cr.openjdk.java.net/~mcimadamore/8203436/ >>> >>> Cheers >>> Maurizio >>> >> > From forax at univ-mlv.fr Sat May 19 12:30:21 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 19 May 2018 14:30:21 +0200 (CEST) Subject: Compiling module descriptors is not reproducible? In-Reply-To: <9cd38a61-66bd-c9bb-421a-4a88b8513106@oracle.com> References: <20180519101809.0246af1d@almond.int.arc7.info> <9cd38a61-66bd-c9bb-421a-4a88b8513106@oracle.com> Message-ID: <621473782.2302763.1526733021338.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "org openjdk" , "jigsaw-dev" > Envoy?: Samedi 19 Mai 2018 13:26:55 > Objet: Re: Compiling module descriptors is not reproducible? > On 19/05/2018 10:18, Mark Raynsford wrote: >> Hello! >> >> I've been interested for a while in making all of my software builds >> reproducible [0]. I don't think there's ever been any kind of >> written guarantee that the output of javac will be completely >> deterministic, but to date it seems like it actually has been. However, >> I was a bit disappointed today to find that the output of one of the >> builds at AdoptOpenJDK [1] seems to be inserting compiler version >> information into compiled module descriptors. It doesn't seem to be >> doing this for any other class files. > The requires table in the Module attribute can be used by compilers to > record version information about dependences. javac does record the > version information, I don't know if there is a way to disable that. It seems there is no way: http://hg.openjdk.java.net/jdk/jdk/file/5ec7380f671d/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java#l986 > In any case, I assume your question will be partly answered by looking at > the output of `java --list-modules` on the different builds. If you > download OpenJDK builds from jdk.java.net/10 then you should see that > the standard and JDK-specific modules all report their version string as > "10" or "10.0.1" as they have been built with configure options that > make it so. At a guess, your mail may have included the output from an > exploded (as opposed to images) build. > > -Alan R?mi From behrangsa at gmail.com Sat May 19 13:27:53 2018 From: behrangsa at gmail.com (Behrang) Date: Sat, 19 May 2018 23:27:53 +1000 Subject: Compiling module descriptors is not reproducible? In-Reply-To: <621473782.2302763.1526733021338.JavaMail.zimbra@u-pem.fr> References: <20180519101809.0246af1d@almond.int.arc7.info> <9cd38a61-66bd-c9bb-421a-4a88b8513106@oracle.com> <621473782.2302763.1526733021338.JavaMail.zimbra@u-pem.fr> Message-ID: Best regards, Behrang Saeedzadeh On 19 May 2018 at 22:30, Remi Forax wrote: > ----- Mail original ----- > > De: "Alan Bateman" > > ?: "org openjdk" , "jigsaw-dev" < > jigsaw-dev at openjdk.java.net> > > Envoy?: Samedi 19 Mai 2018 13:26:55 > > Objet: Re: Compiling module descriptors is not reproducible? > > > On 19/05/2018 10:18, Mark Raynsford wrote: > >> Hello! > >> > >> I've been interested for a while in making all of my software builds > >> reproducible [0]. I don't think there's ever been any kind of > >> written guarantee that the output of javac will be completely > >> deterministic, but to date it seems like it actually has been. However, > >> I was a bit disappointed today to find that the output of one of the > >> builds at AdoptOpenJDK [1] seems to be inserting compiler version > >> information into compiled module descriptors. It doesn't seem to be > >> doing this for any other class files. > > The requires table in the Module attribute can be used by compilers to > > record version information about dependences. javac does record the > > version information, I don't know if there is a way to disable that. > > It seems there is no way: > http://hg.openjdk.java.net/jdk/jdk/file/5ec7380f671d/src/ > jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java#l986 > > > In any case, I assume your question will be partly answered by looking at > > the output of `java --list-modules` on the different builds. If you > > download OpenJDK builds from jdk.java.net/10 then you should see that > > the standard and JDK-specific modules all report their version string as > > "10" or "10.0.1" as they have been built with configure options that > > make it so. At a guess, your mail may have included the output from an > > exploded (as opposed to images) build. > > > > -Alan > > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon May 21 11:24:04 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 21 May 2018 13:24:04 +0200 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 In-Reply-To: <5A998145.1050105@oracle.com> References: <5A998145.1050105@oracle.com> Message-ID: <5B02AC54.4030302@oracle.com> Hi, A webrev updated to the current situation, and with a comment explaining the need for the HashMap is here (as suggested offline): http://cr.openjdk.java.net/~jlahoda/8193717/webrev.01/ Any feedback is welcome. Thanks, Jan On 2.3.2018 17:52, Jan Lahoda wrote: > Hi, > > Having a source with a lot of imports can lead to a long compilation > time, as the imports are lazily searched on each query to the Scope. But > at least for named imports, the name is known, and can be used for quick > filtering. (Sadly, for on-demand imports/package imports, this is much > more difficult, and this patch does not improve them.) > > The principle of the patch is to have a map from name to scopes that may > contain the given name in Scope.NamedImportScope. > > Also, the "current-file top-level scope" > (JCCompilationUnit.toplevelScope) is no longer appended to the named > import scope, but rather the relevant lookup is enhanced to query it as > well if needed. This seems cleaner that trying to append the scope to > the fast name lookup. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193717 > Webrev: http://cr.openjdk.java.net/~jlahoda/8193717/webrev.00/ > > Liam, could you please check if this helps with your real-world case? > > How does this look? > > Thanks, > Jan From maurizio.cimadamore at oracle.com Mon May 21 11:44:34 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 21 May 2018 12:44:34 +0100 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 In-Reply-To: <5B02AC54.4030302@oracle.com> References: <5A998145.1050105@oracle.com> <5B02AC54.4030302@oracle.com> Message-ID: Few comments: * the use of an array as a value in the map seems to cause too much GC overhead - e.g. the array has to be re-allocated from scratch each time a new subscope is added for a given name; wouldn?t a List be better? I assume that element count will be low, so the linked list overhead might be negligible (and better than allocating a bigger-than-needed array, as for an ArrayList). * this code looks dubious: |Scope[] scopes = name2Scopes.getOrDefault(name, new Scope[0]); + if (scopes == null) + return Collections.emptyList(); | When can ?scopes? ever be null? If there?s no entry for given name, the use of getOrDefault guarantees that a zero-element array is returned; so the only option would be if ?null? is explicitly stored as a map value; but looking at the code, the stores are done here: |Scope[] existing = name2Scopes.get(name); + if (existing != null) + existing = Arrays.copyOf(existing, existing.length + 1); + else + existing = new Scope[1]; + existing[existing.length - 1] = newScope; + name2Scopes.put(name, existing); | So, again, this should guarantee that the value associated with a ?put? is always non-null? Maurizio On 21/05/18 12:24, Jan Lahoda wrote: > Hi, > > A webrev updated to the current situation, and with a comment > explaining the need for the HashMap is here (as suggested offline): > http://cr.openjdk.java.net/~jlahoda/8193717/webrev.01/ > > Any feedback is welcome. > > Thanks, > ??? Jan > > On 2.3.2018 17:52, Jan Lahoda wrote: >> Hi, >> >> Having a source with a lot of imports can lead to a long compilation >> time, as the imports are lazily searched on each query to the Scope. But >> at least for named imports, the name is known, and can be used for quick >> filtering. (Sadly, for on-demand imports/package imports, this is much >> more difficult, and this patch does not improve them.) >> >> The principle of the patch is to have a map from name to scopes that may >> contain the given name in Scope.NamedImportScope. >> >> Also, the "current-file top-level scope" >> (JCCompilationUnit.toplevelScope) is no longer appended to the named >> import scope, but rather the relevant lookup is enhanced to query it as >> well if needed. This seems cleaner that trying to append the scope to >> the fast name lookup. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193717 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8193717/webrev.00/ >> >> Liam, could you please check if this helps with your real-world case? >> >> How does this look? >> >> Thanks, >> ????? Jan ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon May 21 13:15:57 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 21 May 2018 15:15:57 +0200 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 In-Reply-To: References: <5A998145.1050105@oracle.com> <5B02AC54.4030302@oracle.com> Message-ID: <5B02C68D.4070703@oracle.com> Hi Maurizio, Thanks for the comments! On 21.5.2018 13:44, Maurizio Cimadamore wrote: > Few comments: > > * > > the use of an array as a value in the map seems to cause too much GC > overhead - e.g. the array has to be re-allocated from scratch each > time a new subscope is added for a given name; wouldn?t a List be > better? I assume that element count will be low, so the linked list > overhead might be negligible (and better than allocating a > bigger-than-needed array, as for an ArrayList). The idea here was that (presumably) most of these arrays will have just one element (so no resizing needed), and it is easier to keep the order in which the Scopes were added using arrays than with com.sun.tools.javac.util.List. But can be changed to a linked list if needed. > > * > > this code looks dubious: > > |Scope[] scopes = name2Scopes.getOrDefault(name, new Scope[0]); + if > (scopes == null) + return Collections.emptyList(); | Oops, right, that is unnecessary. I'll change the getOrDefault to get (so that if there's no mapping, it method will end up quickly and not create the compound iterator), if that's OK. Jan > > When can ?scopes? ever be null? If there?s no entry for given name, the > use of getOrDefault guarantees that a zero-element array is returned; so > the only option would be if ?null? is explicitly stored as a map value; > but looking at the code, the stores are done here: > > |Scope[] existing = name2Scopes.get(name); + if (existing != null) + > existing = Arrays.copyOf(existing, existing.length + 1); + else + > existing = new Scope[1]; + existing[existing.length - 1] = newScope; + > name2Scopes.put(name, existing); | > > So, again, this should guarantee that the value associated with a ?put? > is always non-null? > > Maurizio > > On 21/05/18 12:24, Jan Lahoda wrote: > >> Hi, >> >> A webrev updated to the current situation, and with a comment >> explaining the need for the HashMap is here (as suggested offline): >> http://cr.openjdk.java.net/~jlahoda/8193717/webrev.01/ >> >> Any feedback is welcome. >> >> Thanks, >> Jan >> >> On 2.3.2018 17:52, Jan Lahoda wrote: >>> Hi, >>> >>> Having a source with a lot of imports can lead to a long compilation >>> time, as the imports are lazily searched on each query to the Scope. But >>> at least for named imports, the name is known, and can be used for quick >>> filtering. (Sadly, for on-demand imports/package imports, this is much >>> more difficult, and this patch does not improve them.) >>> >>> The principle of the patch is to have a map from name to scopes that may >>> contain the given name in Scope.NamedImportScope. >>> >>> Also, the "current-file top-level scope" >>> (JCCompilationUnit.toplevelScope) is no longer appended to the named >>> import scope, but rather the relevant lookup is enhanced to query it as >>> well if needed. This seems cleaner that trying to append the scope to >>> the fast name lookup. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193717 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8193717/webrev.00/ >>> >>> Liam, could you please check if this helps with your real-world case? >>> >>> How does this look? >>> >>> Thanks, >>> Jan > > ? From maurizio.cimadamore at oracle.com Mon May 21 13:31:40 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 21 May 2018 14:31:40 +0100 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 In-Reply-To: <5B02C68D.4070703@oracle.com> References: <5A998145.1050105@oracle.com> <5B02AC54.4030302@oracle.com> <5B02C68D.4070703@oracle.com> Message-ID: On 21/05/18 14:15, Jan Lahoda wrote: > Hi Maurizio, > > Thanks for the comments! > > On 21.5.2018 13:44, Maurizio Cimadamore wrote: >> Few comments: >> >> ? * >> >> ??? the use of an array as a value in the map seems to cause too much GC >> ??? overhead - e.g. the array has to be re-allocated from scratch each >> ??? time a new subscope is added for a given name; wouldn?t a List be >> ??? better? I assume that element count will be low, so the linked list >> ??? overhead might be negligible (and better than allocating a >> ??? bigger-than-needed array, as for an ArrayList). > > The idea here was that (presumably) most of these arrays will have > just one element (so no resizing needed), and it is easier to keep the > order in which the Scopes were added using arrays than with > com.sun.tools.javac.util.List. But can be changed to a linked list if > needed. I trust your call here - I just wanted to point out that this code might regress badly if the assumption it relies upon is violated. Maurizio > >> >> ? * >> >> ??? this code looks dubious: >> >> |Scope[] scopes = name2Scopes.getOrDefault(name, new Scope[0]); + if >> (scopes == null) + return Collections.emptyList(); | > > Oops, right, that is unnecessary. I'll change the getOrDefault to get > (so that if there's no mapping, it method will end up quickly and not > create the compound iterator), if that's OK. > > Jan > >> >> When can ?scopes? ever be null? If there?s no entry for given name, the >> use of getOrDefault guarantees that a zero-element array is returned; so >> the only option would be if ?null? is explicitly stored as a map value; >> but looking at the code, the stores are done here: >> >> |Scope[] existing = name2Scopes.get(name); + if (existing != null) + >> existing = Arrays.copyOf(existing, existing.length + 1); + else + >> existing = new Scope[1]; + existing[existing.length - 1] = newScope; + >> name2Scopes.put(name, existing); | >> >> So, again, this should guarantee that the value associated with a ?put? >> is always non-null? >> >> Maurizio >> >> On 21/05/18 12:24, Jan Lahoda wrote: >> >>> Hi, >>> >>> A webrev updated to the current situation, and with a comment >>> explaining the need for the HashMap is here (as suggested offline): >>> http://cr.openjdk.java.net/~jlahoda/8193717/webrev.01/ >>> >>> Any feedback is welcome. >>> >>> Thanks, >>> ??? Jan >>> >>> On 2.3.2018 17:52, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Having a source with a lot of imports can lead to a long compilation >>>> time, as the imports are lazily searched on each query to the >>>> Scope. But >>>> at least for named imports, the name is known, and can be used for >>>> quick >>>> filtering. (Sadly, for on-demand imports/package imports, this is much >>>> more difficult, and this patch does not improve them.) >>>> >>>> The principle of the patch is to have a map from name to scopes >>>> that may >>>> contain the given name in Scope.NamedImportScope. >>>> >>>> Also, the "current-file top-level scope" >>>> (JCCompilationUnit.toplevelScope) is no longer appended to the named >>>> import scope, but rather the relevant lookup is enhanced to query >>>> it as >>>> well if needed. This seems cleaner that trying to append the scope to >>>> the fast name lookup. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193717 >>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8193717/webrev.00/ >>>> >>>> Liam, could you please check if this helps with your real-world case? >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> ????? Jan >> >> ? From maurizio.cimadamore at oracle.com Mon May 21 13:33:12 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 21 May 2018 14:33:12 +0100 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 In-Reply-To: <5B02C68D.4070703@oracle.com> References: <5A998145.1050105@oracle.com> <5B02AC54.4030302@oracle.com> <5B02C68D.4070703@oracle.com> Message-ID: <7caae558-b65f-f346-3acb-153e111601de@oracle.com> On 21/05/18 14:15, Jan Lahoda wrote: > Oops, right, that is unnecessary. I'll change the getOrDefault to get > (so that if there's no mapping, it method will end up quickly and not > create the compound iterator), if that's OK. Looks fine to me. Maurizio From daniel.smith at oracle.com Mon May 21 15:21:36 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 21 May 2018 09:21:36 -0600 Subject: General Registration -- 2018 JVM Language Summit Message-ID: <0D0B87FE-F018-4457-A361-9FB02A945A26@oracle.com> GENERAL REGISTRATION -- JVM LANGUAGE SUMMIT, JULY 2018 General registration for the 2018 JVM Language Summit is now open. The event will be held at Oracle's Santa Clara campus on July 30-31, 2018. Speaker registration remains open through May 25. If you have an interesting topic to speak about, please submit an abstract! Many JVM Language Summit speakers and attendees are also deeply involved in the OpenJDK Community, where they do much of their technical work in their roles as OpenJDK Committers. This year, as an experiment, we're going to host the first OpenJDK Committers' Workshop right after the JVM Language Summit. To fit everything into the week, and allow time for travel, there will be two (rather than the usual three) days of the JVM Language Summit followed immediately by two days of the OpenJDK Committers' Workshop, at the same location. In short, OpenJDK Committers in attendance can look forward to four days of intense, inspiring collaboration around the JVM this year. Overview The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. The summit will be immediately followed by the OpenJDK Committers' Workshop, August 1-2. This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. The schedule consists of a single track of traditional presentations interspersed with less-formal multitrack "workshop" discussion groups and, possibly, impromptu "lightning talks." Workshops are open discussions with only a small amount of prepared material. We ask each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2018 at jvmlangsummit.com _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From maurizio.cimadamore at oracle.com Mon May 21 17:30:01 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 21 May 2018 18:30:01 +0100 Subject: RFR 8203488: Remove error generation from TransTypes Message-ID: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Hi, as written in the bug report, TransTypes generates two kind of user-facing errors: 1) bridge clash 2) arity mismatch due to sig poly invocation with -target 6 We can simply get rid of (1) as we now have Attr checking that override/hide do not clash. We can also get rid of (2), by reworking the fix that introduced it (JDK-8013179 ). The issue there was that, when compiling code that contained a call to MethodHandle.invoke, with target -6, the compiler was left in a limbo between polysig methods (which have sharp signatures) and the underlying Java vararg signature (which is not sharp at all). Since the target method was a 'varargs' but the call itself was not a varargs call, javac complained about an arity mismatch. The solution to this problem is to either use polysig type-checking or regular type-checking depending on whether the support is enabled in the backend. If a polysig call is treated as a true polysig call, we emit a symbol with a sharp descriptor, set the resolution phase to BASIC (no varargs, no boxing) and we just treat it as a regular call from there on. This simplified a number of places (e.g. Attr.checkId and LambdaToMethod) where we needed to special case polysig methods. If backend support for polysig method is disabled (-target 6), then we treat a polysig method as a varargs method; meaning that we leave resolution phase as VARARGS, and then javac will do regular vararg conversion (e.g. box arguments into an array and pass that to the method). This of course doesn't make much sense for polysig methods such as MethodHandle.invoke, but the user gets what he's asking for by compiling code that has polysig call using a target that doesn't know what polysig methods even are. Of course, same code would fail to compile if using --release 6 (as MethodHandle API was not there in 6). Webrev: http://cr.openjdk.java.net/~mcimadamore/8203488/ Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon May 21 17:33:02 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 21 May 2018 18:33:02 +0100 Subject: RFR 8203436: javac should fail early when emitting illegal signature attributes In-Reply-To: References: Message-ID: <4a5668c7-c138-e4ac-3cf8-03c86f24ed8f@oracle.com> I've prepared a new revision which contains a new test (this time for intersection types leaking in sig attributes); I also moved the code that checks for synthetic name clash from Check to Lower, closer to the only point where it is used, to achieve better encapsulation. Webrev: http://cr.openjdk.java.net/~mcimadamore/8203436-v2/ Maurizio On 18/05/18 19:12, Maurizio Cimadamore wrote: > Hi, > this patch makes javac a bit stricter when it comes to generating > bytecode that has illegal signature attributes (which can happen in > case of non-denotable types). Instead of allowing compilation and then > fail at verify time, this patch issues an error message. > > I've refactored another generation-related diagnostic to share the > same 'header' - an example of the diagnostics involved is included in > the webrev. > > http://cr.openjdk.java.net/~mcimadamore/8203436/ > > Cheers > Maurizio > From forax at univ-mlv.fr Mon May 21 17:51:37 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 21 May 2018 19:51:37 +0200 (CEST) Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: <1380657564.86643.1526925097982.JavaMail.zimbra@u-pem.fr> > De: "Maurizio Cimadamore" > ?: "compiler-dev" > Envoy?: Lundi 21 Mai 2018 19:30:01 > Objet: RFR 8203488: Remove error generation from TransTypes > Hi, > as written in the bug report, TransTypes generates two kind of user-facing > errors: > 1) bridge clash > 2) arity mismatch due to sig poly invocation with -target 6 > We can simply get rid of (1) as we now have Attr checking that override/hide do > not clash. We can also get rid of (2), by reworking the fix that introduced it > (JDK- [ https://bugs.openjdk.java.net/browse/JDK-8013179 | 8013179 ] ). The > issue there was that, when compiling code that contained a call to > MethodHandle.invoke, with target -6, the compiler was left in a limbo between > polysig methods (which have sharp signatures) and the underlying Java vararg > signature (which is not sharp at all). Since the target method was a 'varargs' > but the call itself was not a varargs call, javac complained about an arity > mismatch. > The solution to this problem is to either use polysig type-checking or regular > type-checking depending on whether the support is enabled in the backend. If a > polysig call is treated as a true polysig call, we emit a symbol with a sharp > descriptor, set the resolution phase to BASIC (no varargs, no boxing) and we > just treat it as a regular call from there on. This simplified a number of > places (e.g. Attr.checkId and LambdaToMethod) where we needed to special case > polysig methods. > If backend support for polysig method is disabled (-target 6), then we treat a > polysig method as a varargs method; meaning that we leave resolution phase as > VARARGS, and then javac will do regular vararg conversion (e.g. box arguments > into an array and pass that to the method). This of course doesn't make much > sense for polysig methods such as MethodHandle.invoke, but the user gets what > he's asking for by compiling code that has polysig call using a target that > doesn't know what polysig methods even are. With my JSR 292 hat, Polymorphic signature calls should have not been allowed in 6 (-source 6), calling it as a varargs is never was you want, this feature should only be enabled for 7+ I'm not a big fan of generating a code that will not work at runtime, i think it's better to explain to the user that he/she should use --release 7. So instead of trying to revert to a basic call, i think it's better to just emit an error early in Attr. > Of course, same code would fail to compile if using --release 6 (as MethodHandle > API was not there in 6). BTW, the VarHandle API also add more calls tagged with @PolymorphicSignature and the semantics of a polymorphic siganture calls was sightly changed, i wonder how the compiler behave when you calls one of these methods with -source 7 or 8 ? > Webrev: > [ http://cr.openjdk.java.net/~mcimadamore/8203488/ | > http://cr.openjdk.java.net/~mcimadamore/8203488/ ] > Maurizio R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon May 21 18:06:07 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 21 May 2018 14:06:07 -0400 Subject: RFR 8203436: javac should fail early when emitting illegal signature attributes In-Reply-To: <4a5668c7-c138-e4ac-3cf8-03c86f24ed8f@oracle.com> References: <4a5668c7-c138-e4ac-3cf8-03c86f24ed8f@oracle.com> Message-ID: <130bb96a-4a96-371a-412f-89b5c3995355@oracle.com> looks good, Vicente On 05/21/2018 01:33 PM, Maurizio Cimadamore wrote: > I've prepared a new revision which contains a new test (this time for > intersection types leaking in sig attributes); I also moved the code > that checks for synthetic name clash from Check to Lower, closer to > the only point where it is used, to achieve better encapsulation. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8203436-v2/ > > Maurizio > > > On 18/05/18 19:12, Maurizio Cimadamore wrote: >> Hi, >> this patch makes javac a bit stricter when it comes to generating >> bytecode that has illegal signature attributes (which can happen in >> case of non-denotable types). Instead of allowing compilation and >> then fail at verify time, this patch issues an error message. >> >> I've refactored another generation-related diagnostic to share the >> same 'header' - an example of the diagnostics involved is included in >> the webrev. >> >> http://cr.openjdk.java.net/~mcimadamore/8203436/ >> >> Cheers >> Maurizio >> > From vicente.romero at oracle.com Mon May 21 19:36:39 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 21 May 2018 15:36:39 -0400 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: very nice clean-up! looks good, Vicente On 05/21/2018 01:30 PM, Maurizio Cimadamore wrote: > > Hi, > as written in the bug report, TransTypes generates two kind of > user-facing errors: > > 1) bridge clash > > 2) arity mismatch due to sig poly invocation with -target 6 > > We can simply get rid of (1) as we now have Attr checking that > override/hide do not clash. We can also get rid of (2), by reworking > the fix that introduced it (JDK-8013179 > ). The issue there > was that, when compiling code that contained a call to > MethodHandle.invoke, with target -6, the compiler was left in a limbo > between polysig methods (which have sharp signatures) and the > underlying Java vararg signature (which is not sharp at all). Since > the target method was a 'varargs' but the call itself was not a > varargs call, javac complained about an arity mismatch. > > The solution to this problem is to either use polysig type-checking or > regular type-checking depending on whether the support is enabled in > the backend. If a polysig call is treated as a true polysig call, we > emit a symbol with a sharp descriptor, set the resolution phase to > BASIC (no varargs, no boxing) and we just treat it as a regular call > from there on. This simplified a number of places (e.g. Attr.checkId > and LambdaToMethod) where we needed to special case polysig methods. > > If backend support for polysig method is disabled (-target 6), then we > treat a polysig method as a varargs method; meaning that we leave > resolution phase as VARARGS, and then javac will do regular vararg > conversion (e.g. box arguments into an array and pass that to the > method). This of course doesn't make much sense for polysig methods > such as MethodHandle.invoke, but the user gets what he's asking for by > compiling code that has polysig call using a target that doesn't know > what polysig methods even are. > > Of course, same code would fail to compile if using --release 6 (as > MethodHandle API was not there in 6). > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8203488/ > > Maurizio > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon May 21 20:09:11 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 21 May 2018 21:09:11 +0100 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <1380657564.86643.1526925097982.JavaMail.zimbra@u-pem.fr> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> <1380657564.86643.1526925097982.JavaMail.zimbra@u-pem.fr> Message-ID: <5986eeb3-bd06-51c8-cf00-530a4d0178a0@oracle.com> On 21/05/18 18:51, Remi Forax wrote: > > > ------------------------------------------------------------------------ > > *De: *"Maurizio Cimadamore" > *?: *"compiler-dev" > *Envoy?: *Lundi 21 Mai 2018 19:30:01 > *Objet: *RFR 8203488: Remove error generation from TransTypes > > Hi, > as written in the bug report, TransTypes generates two kind of > user-facing errors: > > 1) bridge clash > > 2) arity mismatch due to sig poly invocation with -target 6 > > We can simply get rid of (1) as we now have Attr checking that > override/hide do not clash. We can also get rid of (2), by > reworking the fix that introduced it (JDK-8013179 > ). The issue > there was that, when compiling code that contained a call to > MethodHandle.invoke, with target -6, the compiler was left in a > limbo between polysig methods (which have sharp signatures) and > the underlying Java vararg signature (which is not sharp at all). > Since the target method was a 'varargs' but the call itself was > not a varargs call, javac complained about an arity mismatch. > > The solution to this problem is to either use polysig > type-checking or regular type-checking depending on whether the > support is enabled in the backend. If a polysig call is treated as > a true polysig call, we emit a symbol with a sharp descriptor, set > the resolution phase to BASIC (no varargs, no boxing) and we just > treat it as a regular call from there on. This simplified a number > of places (e.g. Attr.checkId and LambdaToMethod) where we needed > to special case polysig methods. > > If backend support for polysig method is disabled (-target 6), > then we treat a polysig method as a varargs method; meaning that > we leave resolution phase as VARARGS, and then javac will do > regular vararg conversion (e.g. box arguments into an array and > pass that to the method). This of course doesn't make much sense > for polysig methods such as MethodHandle.invoke, but the user gets > what he's asking for by compiling code that has polysig call using > a target that doesn't know what polysig methods even are. > > > With my JSR 292 hat, Polymorphic signature calls should have not been > allowed in 6 (-source 6), calling it as a varargs is never was you > want, this feature should only be enabled for 7+ > I'm not a big fan of generating a code that will not work at runtime, > i think it's better to explain to the user that he/she should use > --release 7. > So instead of trying to revert to a basic call, i think it's better to > just emit an error early in Attr. That's an option too, either error or warning. > > Of course, same code would fail to compile if using --release 6 > (as MethodHandle API was not there in 6). > > > BTW, the VarHandle API also add more calls tagged with > @PolymorphicSignature and the semantics of a polymorphic siganture > calls was sightly changed, i wonder how the compiler behave when you > calls one of these methods with -source 7 or 8 ? Good point; seems like whatever we do for MH in -target 6, we should do for VH in target < 9. Maurizio > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8203488/ > > Maurizio > > > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon May 21 20:17:24 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 21 May 2018 21:17:24 +0100 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <5986eeb3-bd06-51c8-cf00-530a4d0178a0@oracle.com> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> <1380657564.86643.1526925097982.JavaMail.zimbra@u-pem.fr> <5986eeb3-bd06-51c8-cf00-530a4d0178a0@oracle.com> Message-ID: <22e7523f-758b-0102-f6d4-e178a7307da5@oracle.com> On 21/05/18 21:09, Maurizio Cimadamore wrote: > That's an option too, either error or warning. One possibility here would be to force users to use --release when using either MethodHandle or VarHandle. E.g. you can either specify no -source/-target combo or, if you need to cross-compile, you do so with --release. That way you will be prevented from using API points which are unsupported at a given source/target level. But maybe that's too harsh. Also, thinking more on VarHandle, I believe what we have in VarHandle is different: the behavior that we pushed as part of JDK 9 was a generalization of the former behavior; so if you compile VarHandles with target 8, I don't think anything bad actually happens - if you use a JDK 9/10/11 compiler, the compiler will type-check the polysig correctly. Then, in terms of code generation, nothing has changed. In other words, javac has no flag to enable varhandles, specifically. But it does have a flag to enable polysig. So we do have a problem when compiling polysig with no polysig target selected, but we don't have a problem when compiling VH with an older target selected. Maurizio From forax at univ-mlv.fr Mon May 21 21:35:06 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 21 May 2018 23:35:06 +0200 (CEST) Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <5986eeb3-bd06-51c8-cf00-530a4d0178a0@oracle.com> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> <1380657564.86643.1526925097982.JavaMail.zimbra@u-pem.fr> <5986eeb3-bd06-51c8-cf00-530a4d0178a0@oracle.com> Message-ID: <1605922170.104597.1526938506484.JavaMail.zimbra@u-pem.fr> > De: "Maurizio Cimadamore" > ?: "Remi Forax" > Cc: "compiler-dev" , "John Rose" > > Envoy?: Lundi 21 Mai 2018 22:09:11 > Objet: Re: RFR 8203488: Remove error generation from TransTypes > On 21/05/18 18:51, Remi Forax wrote: >>> De: "Maurizio Cimadamore" [ mailto:maurizio.cimadamore at oracle.com | >>> ] >>> ?: "compiler-dev" [ mailto:compiler-dev at openjdk.java.net | >>> ] >>> Envoy?: Lundi 21 Mai 2018 19:30:01 >>> Objet: RFR 8203488: Remove error generation from TransTypes >>> Hi, >>> as written in the bug report, TransTypes generates two kind of user-facing >>> errors: >>> 1) bridge clash >>> 2) arity mismatch due to sig poly invocation with -target 6 >>> We can simply get rid of (1) as we now have Attr checking that override/hide do >>> not clash. We can also get rid of (2), by reworking the fix that introduced it >>> (JDK- [ https://bugs.openjdk.java.net/browse/JDK-8013179 | 8013179 ] ). The >>> issue there was that, when compiling code that contained a call to >>> MethodHandle.invoke, with target -6, the compiler was left in a limbo between >>> polysig methods (which have sharp signatures) and the underlying Java vararg >>> signature (which is not sharp at all). Since the target method was a 'varargs' >>> but the call itself was not a varargs call, javac complained about an arity >>> mismatch. >>> The solution to this problem is to either use polysig type-checking or regular >>> type-checking depending on whether the support is enabled in the backend. If a >>> polysig call is treated as a true polysig call, we emit a symbol with a sharp >>> descriptor, set the resolution phase to BASIC (no varargs, no boxing) and we >>> just treat it as a regular call from there on. This simplified a number of >>> places (e.g. Attr.checkId and LambdaToMethod) where we needed to special case >>> polysig methods. >>> If backend support for polysig method is disabled (-target 6), then we treat a >>> polysig method as a varargs method; meaning that we leave resolution phase as >>> VARARGS, and then javac will do regular vararg conversion (e.g. box arguments >>> into an array and pass that to the method). This of course doesn't make much >>> sense for polysig methods such as MethodHandle.invoke, but the user gets what >>> he's asking for by compiling code that has polysig call using a target that >>> doesn't know what polysig methods even are. >> With my JSR 292 hat, Polymorphic signature calls should have not been allowed in >> 6 (-source 6), calling it as a varargs is never was you want, this feature >> should only be enabled for 7+ >> I'm not a big fan of generating a code that will not work at runtime, i think >> it's better to explain to the user that he/she should use --release 7. >> So instead of trying to revert to a basic call, i think it's better to just emit >> an error early in Attr. > That's an option too, either error or warning. I think an error is better here, like when you try to use a feature with a JDK least recent that the one that introduce the feature. R?mi >>> Of course, same code would fail to compile if using --release 6 (as MethodHandle >>> API was not there in 6). >> BTW, the VarHandle API also add more calls tagged with @PolymorphicSignature and >> the semantics of a polymorphic siganture calls was sightly changed, i wonder >> how the compiler behave when you calls one of these methods with -source 7 or 8 >> ? > Good point; seems like whatever we do for MH in -target 6, we should do for VH > in target < 9. > Maurizio >>> Webrev: >>> [ http://cr.openjdk.java.net/%7Emcimadamore/8203488/ | >>> http://cr.openjdk.java.net/~mcimadamore/8203488/ ] >>> Maurizio >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon May 21 21:48:27 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 21 May 2018 23:48:27 +0200 (CEST) Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <22e7523f-758b-0102-f6d4-e178a7307da5@oracle.com> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> <1380657564.86643.1526925097982.JavaMail.zimbra@u-pem.fr> <5986eeb3-bd06-51c8-cf00-530a4d0178a0@oracle.com> <22e7523f-758b-0102-f6d4-e178a7307da5@oracle.com> Message-ID: <1259545715.105446.1526939307345.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "Remi Forax" > Cc: "compiler-dev" > Envoy?: Lundi 21 Mai 2018 22:17:24 > Objet: Re: RFR 8203488: Remove error generation from TransTypes > On 21/05/18 21:09, Maurizio Cimadamore wrote: >> That's an option too, either error or warning. > One possibility here would be to force users to use --release when using > either MethodHandle or VarHandle. E.g. you can either specify no > -source/-target combo or, if you need to cross-compile, you do so with > --release. That way you will be prevented from using API points which > are unsupported at a given source/target level. But maybe that's too harsh. forcing --release, or deprecating -source/-target if you prefer is something that we should do independently of a particular feature, it will make Java safer. > > Also, thinking more on VarHandle, I believe what we have in VarHandle is > different: the behavior that we pushed as part of JDK 9 was a > generalization of the former behavior; so if you compile VarHandles with > target 8, I don't think anything bad actually happens - if you use a JDK > 9/10/11 compiler, the compiler will type-check the polysig correctly. > Then, in terms of code generation, nothing has changed. In other words, > javac has no flag to enable varhandles, specifically. But it does have a > flag to enable polysig. So we do have a problem when compiling polysig > with no polysig target selected, but we don't have a problem when > compiling VH with an older target selected. The semantics of a polysig change between 7 and 9, in 9 you can return a boolean by example, but given that the semantics of 9 is a super-set of the semantics of 7. So if you use the compiler of a jdk7 or jdk8 with the VarHandle API you will have a surprise but it's just another reason to deprecate -source/-target. > > Maurizio R?mi From cushon at google.com Mon May 21 21:48:17 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 21 May 2018 14:48:17 -0700 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: Hi Maurizio, Does removing handling of clashes from TransTypes make 'hypothetical' bridges unnecessary? The comments in TransTypes say hypothetical bridges are used to detect clashes, but if we're not doing that anymore perhaps that code can be removed too? That would make JDK-8133247 obsolete. On Mon, May 21, 2018 at 10:30 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi, > as written in the bug report, TransTypes generates two kind of user-facing > errors: > > 1) bridge clash > > 2) arity mismatch due to sig poly invocation with -target 6 > > We can simply get rid of (1) as we now have Attr checking that > override/hide do not clash. We can also get rid of (2), by reworking the > fix that introduced it (JDK-8013179 > ). The issue there was > that, when compiling code that contained a call to MethodHandle.invoke, > with target -6, the compiler was left in a limbo between polysig methods > (which have sharp signatures) and the underlying Java vararg signature > (which is not sharp at all). Since the target method was a 'varargs' but > the call itself was not a varargs call, javac complained about an arity > mismatch. > > The solution to this problem is to either use polysig type-checking or > regular type-checking depending on whether the support is enabled in the > backend. If a polysig call is treated as a true polysig call, we emit a > symbol with a sharp descriptor, set the resolution phase to BASIC (no > varargs, no boxing) and we just treat it as a regular call from there on. > This simplified a number of places (e.g. Attr.checkId and LambdaToMethod) > where we needed to special case polysig methods. > > If backend support for polysig method is disabled (-target 6), then we > treat a polysig method as a varargs method; meaning that we leave > resolution phase as VARARGS, and then javac will do regular vararg > conversion (e.g. box arguments into an array and pass that to the method). > This of course doesn't make much sense for polysig methods such as > MethodHandle.invoke, but the user gets what he's asking for by compiling > code that has polysig call using a target that doesn't know what polysig > methods even are. > > Of course, same code would fail to compile if using --release 6 (as > MethodHandle API was not there in 6). > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8203488/ > > Maurizio > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon May 21 22:14:42 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 21 May 2018 15:14:42 -0700 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <22e7523f-758b-0102-f6d4-e178a7307da5@oracle.com> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> <1380657564.86643.1526925097982.JavaMail.zimbra@u-pem.fr> <5986eeb3-bd06-51c8-cf00-530a4d0178a0@oracle.com> <22e7523f-758b-0102-f6d4-e178a7307da5@oracle.com> Message-ID: <5B0344D2.3050802@oracle.com> On 05/21/2018 01:17 PM, Maurizio Cimadamore wrote: > > > On 21/05/18 21:09, Maurizio Cimadamore wrote: >> That's an option too, either error or warning. > One possibility here would be to force users to use --release when > using either MethodHandle or VarHandle. E.g. you can either specify no > -source/-target combo or, if you need to cross-compile, you do so with > --release. That way you will be prevented from using API points which > are unsupported at a given source/target level. But maybe that's too > harsh. You should not *force* --release, because that has a restricted view of the available API. You should at least allow people to give the full triple of -source/-target/-bootclasspath. > > Also, thinking more on VarHandle, I believe what we have in VarHandle > is different: the behavior that we pushed as part of JDK 9 was a > generalization of the former behavior; so if you compile VarHandles > with target 8, I don't think anything bad actually happens - if you > use a JDK 9/10/11 compiler, the compiler will type-check the polysig > correctly. Then, in terms of code generation, nothing has changed. In > other words, javac has no flag to enable varhandles, specifically. But > it does have a flag to enable polysig. So we do have a problem when > compiling polysig with no polysig target selected, but we don't have a > problem when compiling VH with an older target selected. > > Maurizio From iris.clark at oracle.com Mon May 21 22:54:57 2018 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 21 May 2018 15:54:57 -0700 (PDT) Subject: RFR (S): 8203500: Fix broken links to Specification in "specs" directory Message-ID: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> Hi. Please review this small change to fix a few broken links to Specification in the "specs" directory from the JavaDoc API. The incorrect references either not include "{@docRoot}" or include the non-existent "{@docRootParent}". They should all begin with "{@docRoot}/../specs/". Bug: 8203500 Fix broken links to Specification in "spec" directory https://bugs.openjdk.java.net/browse/JDK-8203500 webrev: http://cr.openjdk.java.net/~iris/8203500/webrev/ Thanks, Iris -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Mon May 21 22:58:10 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 21 May 2018 18:58:10 -0400 Subject: RFR (S): 8203500: Fix broken links to Specification in "specs" directory In-Reply-To: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> References: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> Message-ID: <2BFC00B4-79B7-4272-A662-DC0F24E7542B@oracle.com> The change looks fine. Iris > On May 21, 2018, at 6:54 PM, Iris Clark wrote: > > Hi. > > > > Please review this small change to fix a few broken links to > > Specification in the "specs" directory from the JavaDoc API. > > The incorrect references either not include "{@docRoot}" or > > include the non-existent "{@docRootParent}". They should all > > begin with "{@docRoot}/../specs/". > > > > Bug: > > > > 8203500 Fix broken links to Specification in "spec" directory > > https://bugs.openjdk.java.net/browse/JDK-8203500 > > > > webrev: > > > > http://cr.openjdk.java.net/~iris/8203500/webrev/ > > > > Thanks, > > Iris > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From iris.clark at oracle.com Mon May 21 22:59:12 2018 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 21 May 2018 15:59:12 -0700 (PDT) Subject: RFR (S): 8203500: Fix broken links to Specification in "specs" directory In-Reply-To: <2BFC00B4-79B7-4272-A662-DC0F24E7542B@oracle.com> References: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> <2BFC00B4-79B7-4272-A662-DC0F24E7542B@oracle.com> Message-ID: <7ac21eb6-33e1-446f-afa4-3eb7fd7f7dab@default> Hi, Lance. Thanks for the speedy review! iris From: Lance Andersen Sent: Monday, May 21, 2018 3:58 PM To: Iris Clark Cc: compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR (S): 8203500: Fix broken links to Specification in "specs" directory The change looks fine. Iris On May 21, 2018, at 6:54 PM, Iris Clark wrote: Hi. Please review this small change to fix a few broken links to Specification in the "specs" directory from the JavaDoc API. The incorrect references either not include "{@docRoot}" or include the non-existent "{@docRootParent}". They should all begin with "HYPERLINK "mailto:%7b at docRoot%7d/../specs/"{@docRoot}/../specs/". Bug: 8203500 Fix broken links to Specification in "spec" directory https://bugs.openjdk.java.net/browse/JDK-8203500 webrev: http://cr.openjdk.java.net/~iris/8203500/webrev/ Thanks, Iris http://oracle.com/us/design/oracle-email-sig-198324.gif HYPERLINK "http://oracle.com/us/design/oracle-email-sig-198324.gif" Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 HYPERLINK "mailto:Lance.Andersen at oracle.com"Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 658 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Mon May 21 23:00:10 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 21 May 2018 16:00:10 -0700 Subject: RFR (S): 8203500: Fix broken links to Specification in "specs" directory In-Reply-To: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> References: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> Message-ID: Looks good to me. -- Jon On 5/21/18 3:54 PM, Iris Clark wrote: > > Hi. > > Please review this small change to fix a few broken links to > > Specification in the ?specs? directory from the JavaDoc API. > > The incorrect references either not include "{@docRoot}" or > > include the non-existent "{@docRootParent}". ?They should all > > begin with ?{@docRoot}/../specs/?. > > Bug: > > ?? ?8203500 Fix broken links to Specification in ?spec? directory > > https://bugs.openjdk.java.net/browse/JDK-8203500 > > webrev: > > http://cr.openjdk.java.net/~iris/8203500/webrev/ > > > Thanks, > > Iris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon May 21 23:14:47 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 21 May 2018 16:14:47 -0700 Subject: RFR (S): 8203500: Fix broken links to Specification in "specs" directory In-Reply-To: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> References: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> Message-ID: <7f59b86d-d8f4-530e-2311-8f5fc706facc@oracle.com> The fix looks fine. Mandy On 5/21/18 3:54 PM, Iris Clark wrote: > > Hi. > > Please review this small change to fix a few broken links to > > Specification in the ?specs? directory from the JavaDoc API. > > The incorrect references either not include "{@docRoot}" or > > include the non-existent "{@docRootParent}". ?They should all > > begin with ?{@docRoot}/../specs/?. > > Bug: > > ?? ?8203500 Fix broken links to Specification in ?spec? directory > > https://bugs.openjdk.java.net/browse/JDK-8203500 > > webrev: > > http://cr.openjdk.java.net/~iris/8203500/webrev/ > > > Thanks, > > Iris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Mon May 21 23:14:35 2018 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 21 May 2018 16:14:35 -0700 (PDT) Subject: RFR (S): 8203500: Fix broken links to Specification in "specs" directory In-Reply-To: References: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> Message-ID: <9b6b5e9a-c9ff-4676-8842-99ea75f50006@default> Hi, Jon. Thanks for the speedy review! iris From: Jonathan Gibbons Sent: Monday, May 21, 2018 4:00 PM To: compiler-dev at openjdk.java.net Subject: Re: RFR (S): 8203500: Fix broken links to Specification in "specs" directory Looks good to me. -- Jon On 5/21/18 3:54 PM, Iris Clark wrote: Hi. Please review this small change to fix a few broken links to Specification in the "specs" directory from the JavaDoc API. The incorrect references either not include "{@docRoot}" or include the non-existent "{@docRootParent}". They should all begin with "HYPERLINK "mailto:%7b at docRoot%7d/../specs/"{@docRoot}/../specs/". Bug: 8203500 Fix broken links to Specification in "spec" directory https://bugs.openjdk.java.net/browse/JDK-8203500 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Eiris/8203500/webrev/"http://cr.openjdk.java.net/~iris/8203500/webrev/ Thanks, Iris -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Mon May 21 23:20:52 2018 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 21 May 2018 16:20:52 -0700 (PDT) Subject: RFR (S): 8203500: Fix broken links to Specification in "specs" directory In-Reply-To: <7f59b86d-d8f4-530e-2311-8f5fc706facc@oracle.com> References: <3f2d8de7-3f1f-4132-a452-2da5f18326e0@default> <7f59b86d-d8f4-530e-2311-8f5fc706facc@oracle.com> Message-ID: <011f88b2-8807-4f83-b3d6-7e55687911b5@default> Hi, Mandy. Thanks for the super-fast review! iris From: mandy chung Sent: Monday, May 21, 2018 4:15 PM To: Iris Clark Cc: compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR (S): 8203500: Fix broken links to Specification in "specs" directory The fix looks fine. Mandy On 5/21/18 3:54 PM, Iris Clark wrote: Hi. Please review this small change to fix a few broken links to Specification in the "specs" directory from the JavaDoc API. The incorrect references either not include "{@docRoot}" or include the non-existent "{@docRootParent}". They should all begin with "HYPERLINK "mailto:%7b at docRoot%7d/../specs/"{@docRoot}/../specs/". Bug: 8203500 Fix broken links to Specification in "spec" directory https://bugs.openjdk.java.net/browse/JDK-8203500 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Eiris/8203500/webrev/"http://cr.openjdk.java.net/~iris/8203500/webrev/ Thanks, Iris -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 22 10:01:11 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 22 May 2018 11:01:11 +0100 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: On 21/05/18 22:48, Liam Miller-Cushon wrote: > Hi Maurizio, > > Does removing handling of clashes from TransTypes make 'hypothetical' > bridges unnecessary? It is possible, I need to spend some more time looking into this patch from a compatibility perspective - e.g. make sure that under no circumstance the code I have removed would be triggered by some user code. This is tricky to verify, since TransTypes doesn't exactly assert the override clash rules defined in the JLS, so there might be more things caught in that net (I'm thinking esp. about separate compilation). Thanks Maurizio > > The comments in TransTypes say hypothetical bridges are used to detect > clashes, but if we're not doing that anymore perhaps that code can be > removed too? That would make JDK-8133247 obsolete. > > On Mon, May 21, 2018 at 10:30 AM Maurizio Cimadamore > > wrote: > > Hi, > as written in the bug report, TransTypes generates two kind of > user-facing errors: > > 1) bridge clash > > 2) arity mismatch due to sig poly invocation with -target 6 > > We can simply get rid of (1) as we now have Attr checking that > override/hide do not clash. We can also get rid of (2), by > reworking the fix that introduced it (JDK-8013179 > ). The issue > there was that, when compiling code that contained a call to > MethodHandle.invoke, with target -6, the compiler was left in a > limbo between polysig methods (which have sharp signatures) and > the underlying Java vararg signature (which is not sharp at all). > Since the target method was a 'varargs' but the call itself was > not a varargs call, javac complained about an arity mismatch. > > The solution to this problem is to either use polysig > type-checking or regular type-checking depending on whether the > support is enabled in the backend. If a polysig call is treated as > a true polysig call, we emit a symbol with a sharp descriptor, set > the resolution phase to BASIC (no varargs, no boxing) and we just > treat it as a regular call from there on. This simplified a number > of places (e.g. Attr.checkId and LambdaToMethod) where we needed > to special case polysig methods. > > If backend support for polysig method is disabled (-target 6), > then we treat a polysig method as a varargs method; meaning that > we leave resolution phase as VARARGS, and then javac will do > regular vararg conversion (e.g. box arguments into an array and > pass that to the method). This of course doesn't make much sense > for polysig methods such as MethodHandle.invoke, but the user gets > what he's asking for by compiling code that has polysig call using > a target that doesn't know what polysig methods even are. > > Of course, same code would fail to compile if using --release 6 > (as MethodHandle API was not there in 6). > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8203488/ > > > Maurizio > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivas.dama at oracle.com Tue May 22 17:32:08 2018 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Tue, 22 May 2018 10:32:08 -0700 (PDT) Subject: RFR: 8202178(type.getKind() for var is None instead of Error) Message-ID: <3769f96d-f24c-4b35-a945-0db264365448@default> Hi, Please review http://cr.openjdk.java.net/~sdama/8202178/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8202178 Regards, Srinivas From maurizio.cimadamore at oracle.com Tue May 22 18:18:46 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 22 May 2018 19:18:46 +0100 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: Submitted new revision; changes: * removed more code from TransTypes (HYPOTHETICAL and other stuff) * added a new error when polysig metods are called with wrong -target (note, this will go away in 12, as the 6 target will be dropped, so I don't think we need to spend too many cycles on this) Webrev: http://cr.openjdk.java.net/~mcimadamore/8203488-v2/ Cheers Maurizio On 21/05/18 18:30, Maurizio Cimadamore wrote: > > Hi, > as written in the bug report, TransTypes generates two kind of > user-facing errors: > > 1) bridge clash > > 2) arity mismatch due to sig poly invocation with -target 6 > > We can simply get rid of (1) as we now have Attr checking that > override/hide do not clash. We can also get rid of (2), by reworking > the fix that introduced it (JDK-8013179 > ). The issue there > was that, when compiling code that contained a call to > MethodHandle.invoke, with target -6, the compiler was left in a limbo > between polysig methods (which have sharp signatures) and the > underlying Java vararg signature (which is not sharp at all). Since > the target method was a 'varargs' but the call itself was not a > varargs call, javac complained about an arity mismatch. > > The solution to this problem is to either use polysig type-checking or > regular type-checking depending on whether the support is enabled in > the backend. If a polysig call is treated as a true polysig call, we > emit a symbol with a sharp descriptor, set the resolution phase to > BASIC (no varargs, no boxing) and we just treat it as a regular call > from there on. This simplified a number of places (e.g. Attr.checkId > and LambdaToMethod) where we needed to special case polysig methods. > > If backend support for polysig method is disabled (-target 6), then we > treat a polysig method as a varargs method; meaning that we leave > resolution phase as VARARGS, and then javac will do regular vararg > conversion (e.g. box arguments into an array and pass that to the > method). This of course doesn't make much sense for polysig methods > such as MethodHandle.invoke, but the user gets what he's asking for by > compiling code that has polysig call using a target that doesn't know > what polysig methods even are. > > Of course, same code would fail to compile if using --release 6 (as > MethodHandle API was not there in 6). > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8203488/ > > Maurizio > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue May 22 18:45:52 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 22 May 2018 11:45:52 -0700 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: On Tue, May 22, 2018 at 11:19 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > * removed more code from TransTypes (HYPOTHETICAL and other stuff) > The TransTypes changes look good to me, for what that's worth. What do you think about adding the test case from JDK-8133247 now that it should be fixed? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 22 20:33:11 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 22 May 2018 21:33:11 +0100 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: <780e7a82-934c-151c-392f-ad8f9583c32f@oracle.com> On 22/05/18 19:45, Liam Miller-Cushon wrote: > On Tue, May 22, 2018 at 11:19 AM Maurizio Cimadamore > > wrote: > > * removed more code from TransTypes (HYPOTHETICAL and other stuff) > > The TransTypes changes look good to me, for what that's worth. > > What do you think about adding the test case from?JDK-8133247 now that > it should be fixed? Good idea Thanks Maurizio > > Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 22 20:47:06 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 22 May 2018 21:47:06 +0100 Subject: RFR: 8202178(type.getKind() for var is None instead of Error) In-Reply-To: <3769f96d-f24c-4b35-a945-0db264365448@default> References: <3769f96d-f24c-4b35-a945-0db264365448@default> Message-ID: Hi, the changes in MemberEnter look good (as they replicate more or less what happens in Attr.visitVarDef). That said, I'm not sure about the changes in Check - the routine you modified is only called when a variable has an initializer, which is not the case at least in the test you attached. Also, since you are there, I suggest to enhance the test to try: * 'var' field with regular initializer * 'var' field with constant (e.g. string "Hello") initializer * 'var' field with no initializer (as now) Each of the above case goes through a slightly different code path. Maurizio On 22/05/18 18:32, Srinivas Dama wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8202178/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8202178 > > Regards, > Srinivas From vicente.romero at oracle.com Tue May 22 21:15:55 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 22 May 2018 17:15:55 -0400 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: can the HYPOTHETICAL flag be removed now? On 05/22/2018 02:18 PM, Maurizio Cimadamore wrote: > > Submitted new revision; changes: > > * removed more code from TransTypes (HYPOTHETICAL and other stuff) > > * added a new error when polysig metods are called with wrong -target > (note, this will go away in 12, as the 6 target will be dropped, so I > don't think we need to spend too many cycles on this) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8203488-v2/ > > Cheers > > Maurizio > > > On 21/05/18 18:30, Maurizio Cimadamore wrote: >> >> Hi, >> as written in the bug report, TransTypes generates two kind of >> user-facing errors: >> >> 1) bridge clash >> >> 2) arity mismatch due to sig poly invocation with -target 6 >> >> We can simply get rid of (1) as we now have Attr checking that >> override/hide do not clash. We can also get rid of (2), by reworking >> the fix that introduced it (JDK-8013179 >> ). The issue there >> was that, when compiling code that contained a call to >> MethodHandle.invoke, with target -6, the compiler was left in a limbo >> between polysig methods (which have sharp signatures) and the >> underlying Java vararg signature (which is not sharp at all). Since >> the target method was a 'varargs' but the call itself was not a >> varargs call, javac complained about an arity mismatch. >> >> The solution to this problem is to either use polysig type-checking >> or regular type-checking depending on whether the support is enabled >> in the backend. If a polysig call is treated as a true polysig call, >> we emit a symbol with a sharp descriptor, set the resolution phase to >> BASIC (no varargs, no boxing) and we just treat it as a regular call >> from there on. This simplified a number of places (e.g. Attr.checkId >> and LambdaToMethod) where we needed to special case polysig methods. >> >> If backend support for polysig method is disabled (-target 6), then >> we treat a polysig method as a varargs method; meaning that we leave >> resolution phase as VARARGS, and then javac will do regular vararg >> conversion (e.g. box arguments into an array and pass that to the >> method). This of course doesn't make much sense for polysig methods >> such as MethodHandle.invoke, but the user gets what he's asking for >> by compiling code that has polysig call using a target that doesn't >> know what polysig methods even are. >> >> Of course, same code would fail to compile if using --release 6 (as >> MethodHandle API was not there in 6). >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8203488/ >> >> Maurizio >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 22 22:42:39 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 22 May 2018 23:42:39 +0100 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: On 22/05/18 22:15, Vicente Romero wrote: > can the HYPOTHETICAL flag be removed now? Not really - IIRC, it is also used by poly sig method symbols that are synthetically generated using the callsite type info. I will double check though. Maurizio > > On 05/22/2018 02:18 PM, Maurizio Cimadamore wrote: >> >> Submitted new revision; changes: >> >> * removed more code from TransTypes (HYPOTHETICAL and other stuff) >> >> * added a new error when polysig metods are called with wrong -target >> (note, this will go away in 12, as the 6 target will be dropped, so I >> don't think we need to spend too many cycles on this) >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8203488-v2/ >> >> Cheers >> >> Maurizio >> >> >> On 21/05/18 18:30, Maurizio Cimadamore wrote: >>> >>> Hi, >>> as written in the bug report, TransTypes generates two kind of >>> user-facing errors: >>> >>> 1) bridge clash >>> >>> 2) arity mismatch due to sig poly invocation with -target 6 >>> >>> We can simply get rid of (1) as we now have Attr checking that >>> override/hide do not clash. We can also get rid of (2), by reworking >>> the fix that introduced it (JDK-8013179 >>> ). The issue there >>> was that, when compiling code that contained a call to >>> MethodHandle.invoke, with target -6, the compiler was left in a >>> limbo between polysig methods (which have sharp signatures) and the >>> underlying Java vararg signature (which is not sharp at all). Since >>> the target method was a 'varargs' but the call itself was not a >>> varargs call, javac complained about an arity mismatch. >>> >>> The solution to this problem is to either use polysig type-checking >>> or regular type-checking depending on whether the support is enabled >>> in the backend. If a polysig call is treated as a true polysig call, >>> we emit a symbol with a sharp descriptor, set the resolution phase >>> to BASIC (no varargs, no boxing) and we just treat it as a regular >>> call from there on. This simplified a number of places (e.g. >>> Attr.checkId and LambdaToMethod) where we needed to special case >>> polysig methods. >>> >>> If backend support for polysig method is disabled (-target 6), then >>> we treat a polysig method as a varargs method; meaning that we leave >>> resolution phase as VARARGS, and then javac will do regular vararg >>> conversion (e.g. box arguments into an array and pass that to the >>> method). This of course doesn't make much sense for polysig methods >>> such as MethodHandle.invoke, but the user gets what he's asking for >>> by compiling code that has polysig call using a target that doesn't >>> know what polysig methods even are. >>> >>> Of course, same code would fail to compile if using --release 6 (as >>> MethodHandle API was not there in 6). >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8203488/ >>> >>> Maurizio >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed May 23 08:52:14 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 23 May 2018 10:52:14 +0200 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 In-Reply-To: <7caae558-b65f-f346-3acb-153e111601de@oracle.com> References: <5A998145.1050105@oracle.com> <5B02AC54.4030302@oracle.com> <5B02C68D.4070703@oracle.com> <7caae558-b65f-f346-3acb-153e111601de@oracle.com> Message-ID: <5B052BBE.6060508@oracle.com> On 21.5.2018 15:33, Maurizio Cimadamore wrote: > > > On 21/05/18 14:15, Jan Lahoda wrote: >> Oops, right, that is unnecessary. I'll change the getOrDefault to get >> (so that if there's no mapping, it method will end up quickly and not >> create the compound iterator), if that's OK. > Looks fine to me. Thanks! Updated webrev: http://cr.openjdk.java.net/~jlahoda/8193717/webrev.02/ Jan > > Maurizio > From maurizio.cimadamore at oracle.com Wed May 23 08:54:51 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 23 May 2018 09:54:51 +0100 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 In-Reply-To: <5B052BBE.6060508@oracle.com> References: <5A998145.1050105@oracle.com> <5B02AC54.4030302@oracle.com> <5B02C68D.4070703@oracle.com> <7caae558-b65f-f346-3acb-153e111601de@oracle.com> <5B052BBE.6060508@oracle.com> Message-ID: <9f86dff8-b260-af31-719c-2799d6b38812@oracle.com> Looks good Maurizio On 23/05/18 09:52, Jan Lahoda wrote: > On 21.5.2018 15:33, Maurizio Cimadamore wrote: >> >> >> On 21/05/18 14:15, Jan Lahoda wrote: >>> Oops, right, that is unnecessary. I'll change the getOrDefault to get >>> (so that if there's no mapping, it method will end up quickly and not >>> create the compound iterator), if that's OK. >> Looks fine to me. > > Thanks! Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8193717/webrev.02/ > > Jan > >> >> Maurizio >> From maurizio.cimadamore at oracle.com Wed May 23 11:29:36 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 23 May 2018 12:29:36 +0100 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> Message-ID: <3a6c0848-b988-cf12-54f8-66d275a44fe8@oracle.com> Here's another revision which adds the test for 8203488 http://cr.openjdk.java.net/~mcimadamore/8203488-v3/ The HYPOTHETICAL flag is not unused, but I think we could be able to drop it with a followup patch. But let's separate the efforts. Maurizio On 22/05/18 23:42, Maurizio Cimadamore wrote: > > > > On 22/05/18 22:15, Vicente Romero wrote: >> can the HYPOTHETICAL flag be removed now? > Not really - IIRC, it is also used by poly sig method symbols that are > synthetically generated using the callsite type info. > I will double check though. > > Maurizio >> >> On 05/22/2018 02:18 PM, Maurizio Cimadamore wrote: >>> >>> Submitted new revision; changes: >>> >>> * removed more code from TransTypes (HYPOTHETICAL and other stuff) >>> >>> * added a new error when polysig metods are called with wrong >>> -target (note, this will go away in 12, as the 6 target will be >>> dropped, so I don't think we need to spend too many cycles on this) >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8203488-v2/ >>> >>> Cheers >>> >>> Maurizio >>> >>> >>> On 21/05/18 18:30, Maurizio Cimadamore wrote: >>>> >>>> Hi, >>>> as written in the bug report, TransTypes generates two kind of >>>> user-facing errors: >>>> >>>> 1) bridge clash >>>> >>>> 2) arity mismatch due to sig poly invocation with -target 6 >>>> >>>> We can simply get rid of (1) as we now have Attr checking that >>>> override/hide do not clash. We can also get rid of (2), by >>>> reworking the fix that introduced it (JDK-8013179 >>>> ). The issue >>>> there was that, when compiling code that contained a call to >>>> MethodHandle.invoke, with target -6, the compiler was left in a >>>> limbo between polysig methods (which have sharp signatures) and the >>>> underlying Java vararg signature (which is not sharp at all). Since >>>> the target method was a 'varargs' but the call itself was not a >>>> varargs call, javac complained about an arity mismatch. >>>> >>>> The solution to this problem is to either use polysig type-checking >>>> or regular type-checking depending on whether the support is >>>> enabled in the backend. If a polysig call is treated as a true >>>> polysig call, we emit a symbol with a sharp descriptor, set the >>>> resolution phase to BASIC (no varargs, no boxing) and we just treat >>>> it as a regular call from there on. This simplified a number of >>>> places (e.g. Attr.checkId and LambdaToMethod) where we needed to >>>> special case polysig methods. >>>> >>>> If backend support for polysig method is disabled (-target 6), then >>>> we treat a polysig method as a varargs method; meaning that we >>>> leave resolution phase as VARARGS, and then javac will do regular >>>> vararg conversion (e.g. box arguments into an array and pass that >>>> to the method). This of course doesn't make much sense for polysig >>>> methods such as MethodHandle.invoke, but the user gets what he's >>>> asking for by compiling code that has polysig call using a target >>>> that doesn't know what polysig methods even are. >>>> >>>> Of course, same code would fail to compile if using --release 6 (as >>>> MethodHandle API was not there in 6). >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8203488/ >>>> >>>> Maurizio >>>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed May 23 12:19:31 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 23 May 2018 08:19:31 -0400 Subject: RFR 8203488: Remove error generation from TransTypes In-Reply-To: <3a6c0848-b988-cf12-54f8-66d275a44fe8@oracle.com> References: <664e2d8a-43c1-cb4f-5d6a-edd982d0adc5@oracle.com> <3a6c0848-b988-cf12-54f8-66d275a44fe8@oracle.com> Message-ID: <544ccedd-d95b-f91a-9ab7-6f574c116ab6@oracle.com> looks good to me, Vicente On 05/23/2018 07:29 AM, Maurizio Cimadamore wrote: > > Here's another revision which adds the test for 8203488 > > http://cr.openjdk.java.net/~mcimadamore/8203488-v3/ > > The HYPOTHETICAL flag is not unused, but I think we could be able to > drop it with a followup patch. But let's separate the efforts. > > Maurizio > > > On 22/05/18 23:42, Maurizio Cimadamore wrote: >> >> >> >> On 22/05/18 22:15, Vicente Romero wrote: >>> can the HYPOTHETICAL flag be removed now? >> Not really - IIRC, it is also used by poly sig method symbols that >> are synthetically generated using the callsite type info. >> I will double check though. >> >> Maurizio >>> >>> On 05/22/2018 02:18 PM, Maurizio Cimadamore wrote: >>>> >>>> Submitted new revision; changes: >>>> >>>> * removed more code from TransTypes (HYPOTHETICAL and other stuff) >>>> >>>> * added a new error when polysig metods are called with wrong >>>> -target (note, this will go away in 12, as the 6 target will be >>>> dropped, so I don't think we need to spend too many cycles on this) >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8203488-v2/ >>>> >>>> Cheers >>>> >>>> Maurizio >>>> >>>> >>>> On 21/05/18 18:30, Maurizio Cimadamore wrote: >>>>> >>>>> Hi, >>>>> as written in the bug report, TransTypes generates two kind of >>>>> user-facing errors: >>>>> >>>>> 1) bridge clash >>>>> >>>>> 2) arity mismatch due to sig poly invocation with -target 6 >>>>> >>>>> We can simply get rid of (1) as we now have Attr checking that >>>>> override/hide do not clash. We can also get rid of (2), by >>>>> reworking the fix that introduced it (JDK-8013179 >>>>> ). The issue >>>>> there was that, when compiling code that contained a call to >>>>> MethodHandle.invoke, with target -6, the compiler was left in a >>>>> limbo between polysig methods (which have sharp signatures) and >>>>> the underlying Java vararg signature (which is not sharp at all). >>>>> Since the target method was a 'varargs' but the call itself was >>>>> not a varargs call, javac complained about an arity mismatch. >>>>> >>>>> The solution to this problem is to either use polysig >>>>> type-checking or regular type-checking depending on whether the >>>>> support is enabled in the backend. If a polysig call is treated as >>>>> a true polysig call, we emit a symbol with a sharp descriptor, set >>>>> the resolution phase to BASIC (no varargs, no boxing) and we just >>>>> treat it as a regular call from there on. This simplified a number >>>>> of places (e.g. Attr.checkId and LambdaToMethod) where we needed >>>>> to special case polysig methods. >>>>> >>>>> If backend support for polysig method is disabled (-target 6), >>>>> then we treat a polysig method as a varargs method; meaning that >>>>> we leave resolution phase as VARARGS, and then javac will do >>>>> regular vararg conversion (e.g. box arguments into an array and >>>>> pass that to the method). This of course doesn't make much sense >>>>> for polysig methods such as MethodHandle.invoke, but the user gets >>>>> what he's asking for by compiling code that has polysig call using >>>>> a target that doesn't know what polysig methods even are. >>>>> >>>>> Of course, same code would fail to compile if using --release 6 >>>>> (as MethodHandle API was not there in 6). >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/8203488/ >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivas.dama at oracle.com Thu May 24 19:57:18 2018 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Thu, 24 May 2018 12:57:18 -0700 (PDT) Subject: RFR: 8202178(type.getKind() for var is None instead of Error) Message-ID: <1098b3eb-ad1b-4344-834b-3daf6483f938@default> Hi Maurizio, Thank you for the comments. Here is the latest webrev: http://cr.openjdk.java.net/~sdama/8202178/webrev.01/ I have verified with different 'var' initializations as you suggested for instance variables in accordance with bug. It seems changes in Check are not required for the case of instance variables having 'NONE' types as this will be addressed in MemeberEnter only. So I have removed Check changes and modified test. If it turns out to handle any other case other than instance variables,I will file a separate bug and add new test case. Please review. Regards, Srinivas ----- Original Message ----- From: maurizio.cimadamore at oracle.com To: srinivas.dama at oracle.com, compiler-dev at openjdk.java.net Sent: Wednesday, 23 May, 2018 2:17:09 AM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: RFR: 8202178(type.getKind() for var is None instead of Error) Hi, the changes in MemberEnter look good (as they replicate more or less what happens in Attr.visitVarDef). That said, I'm not sure about the changes in Check - the routine you modified is only called when a variable has an initializer, which is not the case at least in the test you attached. Also, since you are there, I suggest to enhance the test to try: * 'var' field with regular initializer * 'var' field with constant (e.g. string "Hello") initializer * 'var' field with no initializer (as now) Each of the above case goes through a slightly different code path. Maurizio On 22/05/18 18:32, Srinivas Dama wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8202178/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8202178 > > Regards, > Srinivas From maurizio.cimadamore at oracle.com Thu May 24 20:40:37 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 24 May 2018 21:40:37 +0100 Subject: RFR: 8202178(type.getKind() for var is None instead of Error) In-Reply-To: <1098b3eb-ad1b-4344-834b-3daf6483f938@default> References: <1098b3eb-ad1b-4344-834b-3daf6483f938@default> Message-ID: <4a7888ca-f675-1bad-9098-f85612c9c599@oracle.com> Hi On 24/05/18 20:57, Srinivas Dama wrote: > I have verified with different 'var' initializations as you suggested for instance > variables in accordance with bug. Would it be possible to tweak your test to generate the combinations you tried? Thanks Maurizio From maurizio.cimadamore at oracle.com Fri May 25 20:15:02 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 25 May 2018 21:15:02 +0100 Subject: RFR: 8202178(type.getKind() for var is None instead of Error) In-Reply-To: <4a7888ca-f675-1bad-9098-f85612c9c599@oracle.com> References: <1098b3eb-ad1b-4344-834b-3daf6483f938@default> <4a7888ca-f675-1bad-9098-f85612c9c599@oracle.com> Message-ID: <60d2fc9b-5130-6026-8cb6-13df9d5c82ef@oracle.com> As discussed privately, let's wrap this up as is for now; and let's file a followup test improvement for later. Cheers Maurizio On 24/05/18 21:40, Maurizio Cimadamore wrote: > Hi > > > On 24/05/18 20:57, Srinivas Dama wrote: >> I have verified with different 'var' initializations as you suggested >> for instance >> variables in accordance with bug. > Would it be possible to tweak your test to generate the combinations > you tried? > > Thanks > Maurizio From vicente.romero at oracle.com Mon May 28 20:09:10 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 28 May 2018 16:09:10 -0400 Subject: RFR: 8203892: Target interface added as marker interface in calls to altMetafactory Message-ID: <3db78de6-8d14-b9a3-0749-2bb8fc891b3f@oracle.com> Please review the fix for [1], which is a regression provoked by [2]. The fix can be find at [3]. The regression could be reproduced with this test case: import java.util.*; import java.util.function.*; import java.io.*; class Test { ??? public static Comparator comparingInt(ToIntFunction keyExtractor) { ??????? Objects.requireNonNull(keyExtractor); ??????? return (Comparator & Serializable) ??????????? (c1, c2) -> Integer.compare(keyExtractor.applyAsInt(c1), keyExtractor.applyAsInt(c2)); ??? } } in this case javac generates a BSM to the alternative metafactory, but after the change for [2] the target type was included as one of the marker interfaces. This patch fixes that issue. TIA, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8203892 [2] https://bugs.openjdk.java.net/browse/JDK-8148354 [3] http://cr.openjdk.java.net/~vromero/8203892/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 29 09:12:01 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 29 May 2018 10:12:01 +0100 Subject: RFR: 8203892: Target interface added as marker interface in calls to altMetafactory In-Reply-To: <3db78de6-8d14-b9a3-0749-2bb8fc891b3f@oracle.com> References: <3db78de6-8d14-b9a3-0749-2bb8fc891b3f@oracle.com> Message-ID: Looks good Maurizio On 28/05/18 21:09, Vicente Romero wrote: > Please review the fix for [1], which is a regression provoked by [2]. > The fix can be find at [3]. The regression could be reproduced with > this test case: > > import java.util.*; > import java.util.function.*; > import java.io.*; > > class Test { > ??? public static Comparator comparingInt(ToIntFunction T> keyExtractor) { > ??????? Objects.requireNonNull(keyExtractor); > ??????? return (Comparator & Serializable) > ??????????? (c1, c2) -> Integer.compare(keyExtractor.applyAsInt(c1), > keyExtractor.applyAsInt(c2)); > ??? } > } > > in this case javac generates a BSM to the alternative metafactory, but > after the change for [2] the target type was included as one of the > marker interfaces. This patch fixes that issue. > > TIA, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8203892 > [2] https://bugs.openjdk.java.net/browse/JDK-8148354 > [3] http://cr.openjdk.java.net/~vromero/8203892/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Tue May 29 15:16:46 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 29 May 2018 17:16:46 +0200 Subject: RFR: JDK-8203926: Problem list test/langtools/tools/javac/importscope/T8193717.java Message-ID: <5B0D6EDE.4050704@oracle.com> Hi, The test/langtools/tools/javac/importscope/T8193717.java test created a test source code with a lot of imports (500.000), and it runs out of memory on some machines/systems. It is not clear if this can be resolved quickly while the test would still verify the original patch is working, so I'd like to problem list the test: http://cr.openjdk.java.net/~jlahoda/8203926/webrev.00/ Any objections? Thanks, Jan From maurizio.cimadamore at oracle.com Tue May 29 16:06:41 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 29 May 2018 17:06:41 +0100 Subject: RFR: JDK-8203926: Problem list test/langtools/tools/javac/importscope/T8193717.java In-Reply-To: <5B0D6EDE.4050704@oracle.com> References: <5B0D6EDE.4050704@oracle.com> Message-ID: <2047eab0-6ee9-6e01-e4ea-0995acf565cb@oracle.com> Looks good Thanks Maurizio On 29/05/18 16:16, Jan Lahoda wrote: > Hi, > > The test/langtools/tools/javac/importscope/T8193717.java test created > a test source code with a lot of imports (500.000), and it runs out of > memory on some machines/systems. It is not clear if this can be > resolved quickly while the test would still verify the original patch > is working, so I'd like to problem list the test: > http://cr.openjdk.java.net/~jlahoda/8203926/webrev.00/ > > Any objections? > > Thanks, > ??? Jan From bsrbnd at gmail.com Wed May 30 13:53:22 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 30 May 2018 15:53:22 +0200 Subject: RFR (XS): OutOfMemoryError when running jdk/internal/shellsupport/doc/JavadocHelperTest.java Message-ID: Hi, When running tier1 like this: $ make run-test-tier1 I get only one failing test due to an OutOfMemoryError because it exceeds the default 512Mb limit [1]. One way to solve this problem is to disable the memory limit when running the tests with JTREG="MAX_MEM=0", but I guess this would be more convenient to increase the memory limit of this sole test with '-Xmx1G', as below. Any comment is welcome. Cheers, Bernard [1] http://hg.openjdk.java.net/jdk/jdk/file/02934b0d661b/doc/testing.md#l206 diff --git a/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java b/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java --- a/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java +++ b/test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java @@ -30,7 +30,7 @@ * jdk.compiler/com.sun.tools.javac.main * jdk.compiler/jdk.internal.shellsupport.doc * @build toolbox.ToolBox toolbox.JarTask toolbox.JavacTask - * @run testng/timeout=900/othervm JavadocHelperTest + * @run testng/timeout=900/othervm -Xmx1G JavadocHelperTest */ import java.io.IOException; From jonathan.gibbons at oracle.com Wed May 30 19:00:20 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 30 May 2018 12:00:20 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <5B0EF4C4.9050501@oracle.com> Please review a minor update to the proposed implementation of JEP 330. The primary change is to disallow the use of the "shebang" feature in Java source files (i.e. files whose name ends in ".java") as recently proposed on this list [1]. There is some additional minor cleanup to the launcher -help text. In the webrev, the overall changes can be seen in the main webrev index. The recent changes can be see in the delta-webrev named "v3" in the main webrev index page. JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/ -- Jon [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed May 30 20:31:57 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 30 May 2018 13:31:57 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5B0EF4C4.9050501@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <5B0EF4C4.9050501@oracle.com> Message-ID: I reviewed the delta-webrev (v3). Looks good. Thanks for fixing missing newlines in launcher.properties Mandy On 5/30/18 12:00 PM, Jonathan Gibbons wrote: > Please review a minor update to the proposed implementation of JEP 330. > > The primary change is to disallow the use of the "shebang" feature in > Java source files > (i.e. files whose name ends in ".java") as recently proposed on this > list [1]. > > There is some additional minor cleanup to the launcher -help text. > > In the webrev, the overall changes can be seen in the main webrev index. > The recent changes can be see in the delta-webrev named "v3" in the main > webrev index page. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/ > > -- Jon > > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html > > On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> ? * The part to handle the new command-line options is in the native >> ??? Java launcher code. >> ? * The part to invoke the compiler and subsequently execute the code >> ??? found in the source file is in a new class in the jdk.compiler >> module. >> ? * There are some minor Makefile changes, to add support for a new >> ??? resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >> >> -- Jon > From cay.horstmann at gmail.com Thu May 31 05:09:43 2018 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Wed, 30 May 2018 22:09:43 -0700 Subject: JEP 330 Message-ID: I noticed that JEP 330 is proposed for Java 11. I am all for having support for "shebang" in shell scripts, but as an educator, I object to the characterization that the JEP will contribute to easing the Java learning curve--which is spelled out in the motivation of the JEP. In its current form, it will not. And there are better ways to modify javac that would be helpful. If the "single file" rule were removed, and students would never have to use javac, sure. But having yet another trivia fact ("You can omit javac with a single source file") is not helpful. I put some thoughts into http://horstmann.com/unblog/2018-05-30/index.html Cheers, Cay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pietro.Paolini at alfasystems.com Thu May 31 09:05:20 2018 From: Pietro.Paolini at alfasystems.com (Pietro Paolini) Date: Thu, 31 May 2018 09:05:20 +0000 Subject: Warn when certain constructor is used Message-ID: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> Hi all, I am not sure the question is appropriate for compiler-dev but I would like to give it a try anyway. I would like to detect when a certain class's constructor is used and log its usage along with filename and line number somewhere, such as a log file or standard output, I can't use an IDE to do that as I am working on a fairly large codebase and I need to automate the process, moreover it seems like an interesting problem to solve. https://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html I was hoping that could help me but I haven't spot anything as yet, even though I must admit that my knowledge on the matter is limited. Thanks, Pietro Pietro Paolini Consultant Alfa ________________________________ e: pietro.paolini at alfasystems.com | w: alfasystems.com t: +44 (0) 20 7920-2643 | Moor Place, 1 Fore Street Avenue, London, EC2Y 9DT, GB ________________________________ The contents of this communication are not intended to be binding or constitute any form of offer or acceptance or give rise to any legal obligations on behalf of the sender or Alfa. The views or opinions expressed represent those of the author and not necessarily those of Alfa. This email and any attachments are strictly confidential and are intended solely for use by the individual or entity to whom it is addressed. If you are not the addressee (or responsible for delivery of the message to the addressee) you may not copy, forward, disclose or use any part of the message or its attachments. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a result of the use of this medium to transmit information by or to Alfa or its affiliates. Alfa Financial Software Ltd Reg. in England No: 0248 2325 From maurizio.cimadamore at oracle.com Thu May 31 10:31:52 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 31 May 2018 11:31:52 +0100 Subject: Warn when certain constructor is used In-Reply-To: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> Message-ID: <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> Hi Pietro, I believe the compiler tree API is what you want (I'm giving you JDK 7 API links, since your link seems to be referring to JDK 7, but these API points are available in later releases as well, of course): https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/index.html More specifically, if you are writing an annotation processor, the compiler tree API allows you to retrieve a Tree objects for a given Element: https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html After which, you can define a visitor which detects the constructor calls you are interested in. For the visitor look here: https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/util/TreeScanner.html there's a scan method for every tree node, I think you want to override visitNewClass: https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/util/TreeScanner.html#visitNewClass(com.sun.source.tree.NewClassTree,%20P) As for generating diagnostics, you can do that by using the Messager interface which is part of the annotation processing API: https://docs.oracle.com/javase/7/docs/api/javax/annotation/processing/Messager.html you obtain one of these from the ProcessingEnvironment object you get at the start of anno processing - see https://docs.oracle.com/javase/7/docs/api/javax/annotation/processing/Processor.html#init(javax.annotation.processing.ProcessingEnvironment) I think these pointers should be enough to get started, feel free to reach out if you get stuck. Maurizio On 31/05/18 10:05, Pietro Paolini wrote: > Hi all, > > I am not sure the question is appropriate for compiler-dev but I would like to give it a try anyway. > > I would like to detect when a certain class's constructor is used and log its usage along with filename and line number somewhere, such as a log file or standard output, I can't use an IDE to do that as I am working on a fairly large codebase and I need to automate the process, moreover it seems like an interesting problem to solve. > > https://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html > > I was hoping that could help me but I haven't spot anything as yet, even though I must admit that my knowledge on the matter is limited. > > Thanks, > Pietro > > > Pietro Paolini > Consultant > > Alfa > ________________________________ > e: pietro.paolini at alfasystems.com | w: alfasystems.com > t: +44 (0) 20 7920-2643 | Moor Place, 1 Fore Street Avenue, London, EC2Y 9DT, GB > ________________________________ > > The contents of this communication are not intended to be binding or constitute any form of offer or acceptance or give rise to any legal obligations on behalf of the sender or Alfa. The views or opinions expressed represent those of the author and not necessarily those of Alfa. This email and any attachments are strictly confidential and are intended solely for use by the individual or entity to whom it is addressed. If you are not the addressee (or responsible for delivery of the message to the addressee) you may not copy, forward, disclose or use any part of the message or its attachments. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a result of the use of this medium to transmit information by or to Alfa or its affiliates. > > Alfa Financial Software Ltd > Reg. in England No: 0248 2325 From Pietro.Paolini at alfasystems.com Thu May 31 11:21:56 2018 From: Pietro.Paolini at alfasystems.com (Pietro Paolini) Date: Thu, 31 May 2018 11:21:56 +0000 Subject: Warn when certain constructor is used In-Reply-To: <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> Message-ID: <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> Hi Maurizio, I got stuck but I feel I am not that far from it, I have taken bits and pieces from here http://scg.unibe.ch/archive/projects/Erni08b.pdf - that is somewhat different from What I want to do, namely it wants to re-write part of the AST while I just want to scan it to print some diagnostic info. I realize my usages of the term AST may be improper, is that the *actual* AST the parser generated ? @SupportedAnnotationTypes("*") class LocalDateUtilDate extends TreeScanner { @Override public Object visitNewClass(NewClassTree newClassTree, Object o) { processingEnvironment.getMessager().printMessage(Diagnostic.Kind.WARNING, "You should not be using ..."); return super.visitNewClass(newClassTree, o); } } @Override public boolean process(Set annotations, RoundEnvironment roundEnv) { if (!roundEnv.processingOver()) { Set elements = roundEnv.getRootElements(); for (Element element : elements) { if (element.getKind() == ElementKind.CLASS) { JCTree tree = (JCTree) trees.getTree(element); tree.accept(new LocalDateUtilDate()); } System.out.println(element); } } return false; } JCTree tree = (JCTree) trees.getTree(element); tree.accept(new LocalDateUtilDate()); This bit does not compile as I am probably using the API badly, what do I need to do to get my scanner "scanning" :-) ? Thanks, P. > -----Original Message----- > From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > Sent: 31 May 2018 11:32 > To: Pietro Paolini; compiler-dev at openjdk.java.net > Subject: Re: Warn when certain constructor is used > > Hi Pietro, > I believe the compiler tree API is what you want (I'm giving you JDK 7 > API links, since your link seems to be referring to JDK 7, but these API > points are available in later releases as well, of course): > > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/index.html > > More specifically, if you are writing an annotation processor, the > compiler tree API allows you to retrieve a Tree objects for a given Element: > > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > il/Trees.html > > After which, you can define a visitor which detects the constructor > calls you are interested in. For the visitor look here: > > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > il/TreeScanner.html > > there's a scan method for every tree node, I think you want to override > visitNewClass: > > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > il/TreeScanner.html#visitNewClass(com.sun.source.tree.NewClassTree,%20P) > > As for generating diagnostics, you can do that by using the Messager > interface which is part of the annotation processing API: > > https://docs.oracle.com/javase/7/docs/api/javax/annotation/processing/Mes > sager.html > > you obtain one of these from the ProcessingEnvironment object you get at > the start of anno processing - see > > https://docs.oracle.com/javase/7/docs/api/javax/annotation/processing/Proc > essor.html#init(javax.annotation.processing.ProcessingEnvironment) > > > I think these pointers should be enough to get started, feel free to > reach out if you get stuck. > > Maurizio > > > On 31/05/18 10:05, Pietro Paolini wrote: > > Hi all, > > > > I am not sure the question is appropriate for compiler-dev but I would like > to give it a try anyway. > > > > I would like to detect when a certain class's constructor is used and log its > usage along with filename and line number somewhere, such as a log file or > standard output, I can't use an IDE to do that as I am working on a fairly large > codebase and I need to automate the process, moreover it seems like an > interesting problem to solve. > > > > https://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html > > > > I was hoping that could help me but I haven't spot anything as yet, even > though I must admit that my knowledge on the matter is limited. > > > > Thanks, > > Pietro > > > > > > Pietro Paolini > > Consultant > > > > Alfa > > ________________________________ > > e: pietro.paolini at alfasystems.com | w: > alfasystems.com > > t: +44 (0) 20 7920-2643 | Moor Place, 1 Fore Street Avenue, London, EC2Y > 9DT, GB > > ________________________________ > > > > The contents of this communication are not intended to be binding or > constitute any form of offer or acceptance or give rise to any legal obligations > on behalf of the sender or Alfa. The views or opinions expressed represent > those of the author and not necessarily those of Alfa. This email and any > attachments are strictly confidential and are intended solely for use by the > individual or entity to whom it is addressed. If you are not the addressee (or > responsible for delivery of the message to the addressee) you may not copy, > forward, disclose or use any part of the message or its attachments. At > present the integrity of email across the internet cannot be guaranteed and > messages sent via this medium are potentially at risk. All liability is excluded > to the extent permitted by law for any claims arising as a result of the use of > this medium to transmit information by or to Alfa or its affiliates. > > > > Alfa Financial Software Ltd > > Reg. in England No: 0248 2325 From maurizio.cimadamore at oracle.com Thu May 31 11:45:27 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 31 May 2018 12:45:27 +0100 Subject: Warn when certain constructor is used In-Reply-To: <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> Message-ID: <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> On 31/05/18 12:21, Pietro Paolini wrote: > JCTree tree = (JCTree) trees.getTree(element); > tree.accept(new LocalDateUtilDate()); There re two visitor methods in JCTree, one internal (used by javac), one external (used by the API). I don't think you need to cast down to JCTree (yet, at least). Just keep it as a com.sun.source.tree.Tree, and you will see that the only 'accept' method there takes two arguments: a visitor (which you have) and a visitor parameter; since you don't seem to need a visitor parameter, you can just pass 'null' as second parameter. Maurizio From forax at univ-mlv.fr Thu May 31 12:18:47 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 31 May 2018 14:18:47 +0200 (CEST) Subject: Warn when certain constructor is used In-Reply-To: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> Message-ID: <2029690261.1796343.1527769127501.JavaMail.zimbra@u-pem.fr> Hi Pietro, detecting usages of certain API entrypoints is usually done on the bytecode instead of on the source code in the Java world, it's usually easier because the bytecode is more stable than the source code and it has also the advantage to work not only with Java the language but also in Scala, Groovy, Kotlin, etc. You can use ASM [1] for that, here is an example [2] from stackoverflow. cheers, R?mi [1] http://asm.ow2.io/ [2] https://stackoverflow.com/questions/930289/how-can-i-find-all-the-methods-that-call-a-given-method-in-java#931410 ----- Mail original ----- > De: "Pietro Paolini" > ?: "compiler-dev" > Envoy?: Jeudi 31 Mai 2018 11:05:20 > Objet: Warn when certain constructor is used > Hi all, > > I am not sure the question is appropriate for compiler-dev but I would like to > give it a try anyway. > > I would like to detect when a certain class's constructor is used and log its > usage along with filename and line number somewhere, such as a log file or > standard output, I can't use an IDE to do that as I am working on a fairly > large codebase and I need to automate the process, moreover it seems like an > interesting problem to solve. > > https://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html > > I was hoping that could help me but I haven't spot anything as yet, even though > I must admit that my knowledge on the matter is limited. > > Thanks, > Pietro > > > Pietro Paolini > Consultant > > Alfa > ________________________________ > e: pietro.paolini at alfasystems.com | w: > alfasystems.com > t: +44 (0) 20 7920-2643 | Moor Place, 1 Fore Street Avenue, London, EC2Y 9DT, GB > ________________________________ > > The contents of this communication are not intended to be binding or constitute > any form of offer or acceptance or give rise to any legal obligations on behalf > of the sender or Alfa. The views or opinions expressed represent those of the > author and not necessarily those of Alfa. This email and any attachments are > strictly confidential and are intended solely for use by the individual or > entity to whom it is addressed. If you are not the addressee (or responsible > for delivery of the message to the addressee) you may not copy, forward, > disclose or use any part of the message or its attachments. At present the > integrity of email across the internet cannot be guaranteed and messages sent > via this medium are potentially at risk. All liability is excluded to the > extent permitted by law for any claims arising as a result of the use of this > medium to transmit information by or to Alfa or its affiliates. > > Alfa Financial Software Ltd > Reg. in England No: 0248 2325 From Pietro.Paolini at alfasystems.com Thu May 31 12:19:49 2018 From: Pietro.Paolini at alfasystems.com (Pietro Paolini) Date: Thu, 31 May 2018 12:19:49 +0000 Subject: Warn when certain constructor is used In-Reply-To: <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> Message-ID: <5D285FC05679A441ACF34A90905BFA922F9BAA81@GBEDBP01.chp.co.uk> Hi Maurizio, Thanks a lot. I would have an additional, and hopefully last, question. I am getting the NewClassTree which seems to provide me access to the - forgive me the coarse wording of it - the "token", namely the textual representation of it, while I am mainly interested in the type. I am getting around it by comparing strings but I wonder if there is any way to get to the type of the expression : := new identifier ( arguments ) What I have in my mind is to detect all instances in which the identifier has *type* A and the argument's list is composed by a single *type* , let say B. That allows me to print something: "Hey, constructor new A(B) has been detected" Thanks a lot for your help so far, really. Thanks, P. > -----Original Message----- > From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > Sent: 31 May 2018 12:45 > To: Pietro Paolini > Cc: compiler-dev at openjdk.java.net > Subject: Re: Warn when certain constructor is used > > > > On 31/05/18 12:21, Pietro Paolini wrote: > > JCTree tree = (JCTree) trees.getTree(element); > > tree.accept(new LocalDateUtilDate()); > There re two visitor methods in JCTree, one internal (used by javac), > one external (used by the API). I don't think you need to cast down to > JCTree (yet, at least). Just keep it as a com.sun.source.tree.Tree, and > you will see that the only 'accept' method there takes two arguments: a > visitor (which you have) and a visitor parameter; since you don't seem > to need a visitor parameter, you can just pass 'null' as second parameter. > > Maurizio From volker.simonis at gmail.com Thu May 31 13:15:35 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 31 May 2018 15:15:35 +0200 Subject: JEP 330 In-Reply-To: References: Message-ID: Hi Cay, just nit-picking: JEP 330 proposes to "Launch Single-File Source-Code Programs" for OpenJDK 11 and NOT FOR Java 11. That's an important difference - especially if you teach Java - and I think it would be great if every student would understand that difference. This JEP doesn't intend to change the Java Language Specification (as it was suggested in the discussions). That's the reason, why "shebang" files will NOT BE VALID Java source files. The whole feature is an implementation detail of the OpenJDK launcher. It's not even required that other launchers implement this as well. So this feature is obviously more appropriate for teaching "OpenJDK" rather than "Java" :) Regards, Volker On Thu, May 31, 2018 at 7:09 AM, Cay Horstmann wrote: > I noticed that JEP 330 is proposed for Java 11. I am all for having support > for "shebang" in shell scripts, but as an educator, I object to the > characterization that the JEP will contribute to easing the Java learning > curve--which is spelled out in the motivation of the JEP. In its current > form, it will not. And there are better ways to modify javac that would be > helpful. > > If the "single file" rule were removed, and students would never have to use > javac, sure. But having yet another trivia fact ("You can omit javac with a > single source file") is not helpful. I put some thoughts into > http://horstmann.com/unblog/2018-05-30/index.html > > Cheers, > > Cay From forax at univ-mlv.fr Thu May 31 13:42:15 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 31 May 2018 15:42:15 +0200 (CEST) Subject: JEP 330 In-Reply-To: References: Message-ID: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> Hi Cay, > De: "cay horstmann" > ?: "compiler-dev" > Envoy?: Jeudi 31 Mai 2018 07:09:43 > Objet: JEP 330 > I noticed that JEP 330 is proposed for Java 11. I am all for having support for > "shebang" in shell scripts, but as an educator, I object to the > characterization that the JEP will contribute to easing the Java learning > curve--which is spelled out in the motivation of the JEP. In its current form, > it will not. And there are better ways to modify javac that would be helpful. Technically, the JEP doesn't modify javac, just the launcher of the VM but I agree with you that it will not really help teaching. The JEP also said that it simplify the writing of small utility scripts and i think it is its major selling point. There are a lot of scripts (bootstrap, build, deployment, continuous testing scripts, etc) that should be written in Java instead of being written in shell because Java is cross platform. My secret hope is to be able to write gradle scripts in Java. > If the "single file" rule were removed, and students would never have to use > javac, sure. But having yet another trivia fact ("You can omit javac with a > single source file") is not helpful. I put some thoughts into [ > http://horstmann.com/unblog/2018-05-30/index.html | > http://horstmann.com/unblog/2018-05-30/index.html ] > Cheers, > Cay regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu May 31 14:44:36 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 31 May 2018 15:44:36 +0100 Subject: Warn when certain constructor is used In-Reply-To: <5D285FC05679A441ACF34A90905BFA922F9BAA81@GBEDBP01.chp.co.uk> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BAA81@GBEDBP01.chp.co.uk> Message-ID: <2f4445d8-2e5e-7c83-f873-2a9756863a23@oracle.com> Try to call https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html#getElement(com.sun.source.util.TreePath) This should trigger attribution of the tree and give you the 'symbol' associated with the constructor. From there you can access the symbol signature using https://docs.oracle.com/javase/7/docs/api/javax/lang/model/element/Element.html#asType() And downcasting to this: https://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/ExecutableType.html If this works, good, otherwise the solution would be more cumbersome - and it will involve setting up a task listener. But try this first. Maurizio On 31/05/18 13:19, Pietro Paolini wrote: > Hi Maurizio, > > Thanks a lot. I would have an additional, and hopefully last, question. > > I am getting the NewClassTree which seems to provide me access to the - forgive me the coarse wording of it - the "token", namely the textual representation > of it, while I am mainly interested in the type. > > I am getting around it by comparing strings but I wonder if there is any way to get to the type of the expression : > > := new identifier ( arguments ) > > What I have in my mind is to detect all instances in which the identifier has *type* A and the argument's list is composed by a single *type* , let say B. That allows me to > print something: > > "Hey, constructor new A(B) has been detected" > > Thanks a lot for your help so far, really. > > Thanks, > P. > > > > > >> -----Original Message----- >> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] >> Sent: 31 May 2018 12:45 >> To: Pietro Paolini >> Cc: compiler-dev at openjdk.java.net >> Subject: Re: Warn when certain constructor is used >> >> >> >> On 31/05/18 12:21, Pietro Paolini wrote: >>> JCTree tree = (JCTree) trees.getTree(element); >>> tree.accept(new LocalDateUtilDate()); >> There re two visitor methods in JCTree, one internal (used by javac), >> one external (used by the API). I don't think you need to cast down to >> JCTree (yet, at least). Just keep it as a com.sun.source.tree.Tree, and >> you will see that the only 'accept' method there takes two arguments: a >> visitor (which you have) and a visitor parameter; since you don't seem >> to need a visitor parameter, you can just pass 'null' as second parameter. >> >> Maurizio From cay.horstmann at sjsu.edu Thu May 31 16:30:56 2018 From: cay.horstmann at sjsu.edu (Cay Horstmann) Date: Thu, 31 May 2018 09:30:56 -0700 Subject: JEP 330 In-Reply-To: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> Message-ID: <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> Hi R?mi, > The JEP also said that it simplify the writing of small utility scripts > and? i think it is its major selling point.> There are a lot of scripts (bootstrap, build, deployment, continuous > testing scripts, etc) that should be written in Java instead of being > written in shell because Java is cross platform. I actually have a bunch of scripts that I wrote in Java (and then call from a shell script or alias). But the "single file" thing isn't as useful as it appears at first. Most of my scripts depend on some JAR (JavaMail, Commons CSV, ...). With a Python script, you use pip to manage those dependencies, and in the script you just import them. In Java, the best I can do is rely on Maven/Ivy. Suppose I have a Java script that uses JavaMail and I want to give it to a colleague. Let's assume that the colleague knows how to fetch the dependencies into the Ivy cache. What would the shebang line look like? A classpath into ~/.ivy2??? I don't know how to do that cross platform. Now THAT would be a great problem to solve in the launcher. Cheers, Cay -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From eaftan at google.com Thu May 31 16:59:03 2018 From: eaftan at google.com (Eddie Aftandilian) Date: Thu, 31 May 2018 09:59:03 -0700 Subject: Warn when certain constructor is used In-Reply-To: <2f4445d8-2e5e-7c83-f873-2a9756863a23@oracle.com> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BAA81@GBEDBP01.chp.co.uk> <2f4445d8-2e5e-7c83-f873-2a9756863a23@oracle.com> Message-ID: Forgive the self promotion, but you could use Error Prone ( github.com/google/error-prone). Just write a BugChecker that implements NewClassTreeMatcher, match on the constructor you want, and emit a warning when it matches. Here's an example similar to what you want to do: https://github.com/google/error-prone/blob/d6574253e5cff136662c4fd2ace6ba1c5ae831fa/core/src/main/java/com/google/errorprone/bugpatterns/StringBuilderInitWithChar.java On Thu, May 31, 2018 at 7:45 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Try to call > > > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html#getElement(com.sun.source.util.TreePath) > > This should trigger attribution of the tree and give you the 'symbol' > associated with the constructor. From there you can access the symbol > signature using > > > https://docs.oracle.com/javase/7/docs/api/javax/lang/model/element/Element.html#asType() > > And downcasting to this: > > > https://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/ExecutableType.html > > If this works, good, otherwise the solution would be more cumbersome - > and it will involve setting up a task listener. But try this first. > > Maurizio > > > On 31/05/18 13:19, Pietro Paolini wrote: > > Hi Maurizio, > > > > Thanks a lot. I would have an additional, and hopefully last, question. > > > > I am getting the NewClassTree which seems to provide me access to the - > forgive me the coarse wording of it - the "token", namely the textual > representation > > of it, while I am mainly interested in the type. > > > > I am getting around it by comparing strings but I wonder if there is any > way to get to the type of the expression : > > > > := new identifier ( arguments ) > > > > What I have in my mind is to detect all instances in which the > identifier has *type* A and the argument's list is composed by a single > *type* , let say B. That allows me to > > print something: > > > > "Hey, constructor new A(B) has been detected" > > > > Thanks a lot for your help so far, really. > > > > Thanks, > > P. > > > > > > > > > > > >> -----Original Message----- > >> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > >> Sent: 31 May 2018 12:45 > >> To: Pietro Paolini > >> Cc: compiler-dev at openjdk.java.net > >> Subject: Re: Warn when certain constructor is used > >> > >> > >> > >> On 31/05/18 12:21, Pietro Paolini wrote: > >>> JCTree tree = (JCTree) trees.getTree(element); > >>> tree.accept(new LocalDateUtilDate()); > >> There re two visitor methods in JCTree, one internal (used by javac), > >> one external (used by the API). I don't think you need to cast down to > >> JCTree (yet, at least). Just keep it as a com.sun.source.tree.Tree, and > >> you will see that the only 'accept' method there takes two arguments: a > >> visitor (which you have) and a visitor parameter; since you don't seem > >> to need a visitor parameter, you can just pass 'null' as second > parameter. > >> > >> Maurizio > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 31 18:54:27 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 31 May 2018 11:54:27 -0700 Subject: JEP 330 In-Reply-To: References: Message-ID: <5B1044E3.6020704@oracle.com> On 05/30/2018 10:09 PM, Cay Horstmann wrote: > I noticed that JEP 330 is proposed for Java 11. I am all for having > support for "shebang" in shell scripts, but as an educator, I object > to the characterization that the JEP will contribute to easing the > Java learning curve--which is spelled out in the motivation of the > JEP. In its current form, it will not. And there are better ways to > modify javac that would be helpful. > > If the "single file" rule were removed, and students would never have > to use javac, sure. But having yet another trivia fact ("You can omit > javac with a single source file") is not helpful. I put some thoughts > into http://horstmann.com/unblog/2018-05-30/index.html > > Cheers, > > Cay Cay, The intent of the feature, as relates to easing the Java learning curve, is to assist in the first few "baby steps" that some folk might take when starting to learn Java. The intent is that for folk starting out from scratch, learning to use one command (java) is simpler than learning to use two (java and javac). Once they are familiar with using java to run simple small programs, then they can progress to using javac and java for programs using many files. Then, the next possible step on the ladder is to learn the jar command to make an executable. If you are teaching folk at a level where they are already more familiar with command-line tools, then yes, you may want to skip the ability to use the Java launcher to execute single-file source code programs. -- Jon From forax at univ-mlv.fr Thu May 31 20:36:48 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 31 May 2018 22:36:48 +0200 (CEST) Subject: JEP 330 In-Reply-To: <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> Message-ID: <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Cay Horstmann" > ?: "compiler-dev" > Envoy?: Jeudi 31 Mai 2018 18:30:56 > Objet: Re: JEP 330 > Hi R?mi, > >> The JEP also said that it simplify the writing of small utility scripts > and >> ? i think it is its major selling point.> There are a lot of > scripts (bootstrap, build, deployment, continuous > testing scripts, > etc) that should be written in Java instead of being > written in shell > because Java is cross platform. > I actually have a bunch of scripts that I wrote in Java (and then call > from a shell script or alias). But the "single file" thing isn't as > useful as it appears at first. Most of my scripts depend on some JAR > (JavaMail, Commons CSV, ...). > > With a Python script, you use pip to manage those dependencies, and in > the script you just import them. In Java, the best I can do is rely on > Maven/Ivy. or just put the jar near the shebang file :) > > Suppose I have a Java script that uses JavaMail and I want to give it to > a colleague. Let's assume that the colleague knows how to fetch the > dependencies into the Ivy cache. What would the shebang line look like? > A classpath into ~/.ivy2??? I don't know how to do that cross platform. > > Now THAT would be a great problem to solve in the launcher. You create a ModuleLayer (or an URLClassLoader if you are not using modules), and load the jars you want. > > Cheers, > > Cay R?mi From john.r.rose at oracle.com Thu May 31 20:55:14 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 31 May 2018 13:55:14 -0700 Subject: JEP 330 In-Reply-To: <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> References: <764402974.1851785.1527774135320.JavaMail.zimbra@u-pem.fr> <93ddabac-fced-0781-857c-b0be602a8b13@gmail.com> <2041815405.1975607.1527799008320.JavaMail.zimbra@u-pem.fr> Message-ID: <6F620960-15F7-48F8-BB1A-4DDE64DCFB13@oracle.com> On May 31, 2018, at 1:36 PM, Remi Forax wrote: > > or just put the jar near the shebang file :) That raises an interesting question: How does the shebang script refer to a side file in the same directory? In /bin/sh we would say something like "${0%/*}/side.jar". I suppose there is a JVM property which exposes that command line argument already; if not there should be. Then an API like java.nio.file.Path can help find the side file. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From cay.horstmann at sjsu.edu Thu May 31 21:19:58 2018 From: cay.horstmann at sjsu.edu (Cay Horstmann) Date: Thu, 31 May 2018 14:19:58 -0700 Subject: JEP 330 In-Reply-To: <5B1044E3.6020704@oracle.com> References: <5B1044E3.6020704@oracle.com> Message-ID: Hi Jon, as it happens, teaching Java to beginners is something that I do a lot. In twenty years, I have never met any beginner who was seriously struggling with javac vs. java. There are many other issues that confuse beginners, starting with public, static, void, main, and args. As I point out in my blog, that confusion could be remedied by a better launcher that is willing to instantiate a class. That would be a large win for beginners. Also, beginners often start with an IDE that hides javac and java from them for a while. When they get to the point where they use the command line tools, they have probably already encountered multiple classes. If the motivation of the JEP is to provide shebang support, sure. But from a teaching perspective, I don't see how it is a win. Cheers, Cay Le 31/05/2018 ? 11:54, Jonathan Gibbons a ?crit?: > > Cay, > > The intent of the feature, as relates to easing the Java learning curve, > is to assist in the first few "baby steps" that some folk might take > when starting to learn Java. > > The intent is that for folk starting out from scratch, learning to use > one command (java) is simpler than learning to use two (java and > javac).? Once they are familiar with using java to run simple small > programs, then they can progress to using javac and java for programs > using many files.? Then, the next possible step on the ladder is to > learn the jar command to make an executable. > > If you are teaching folk at a level where they are already more familiar > with command-line tools, then yes, you may want to skip the ability to > use the Java launcher to execute single-file source code programs. > > -- Jon -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From Pietro.Paolini at alfasystems.com Thu May 31 21:25:41 2018 From: Pietro.Paolini at alfasystems.com (Pietro Paolini) Date: Thu, 31 May 2018 21:25:41 +0000 Subject: Warn when certain constructor is used In-Reply-To: <2f4445d8-2e5e-7c83-f873-2a9756863a23@oracle.com> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BAA81@GBEDBP01.chp.co.uk> <2f4445d8-2e5e-7c83-f873-2a9756863a23@oracle.com> Message-ID: <5D285FC05679A441ACF34A90905BFA922F9BBC65@GBEDBP01.chp.co.uk> > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > il/Trees.html#getElement(com.sun.source.util.TreePath) On what kind of object ? if (!roundEnv.processingOver()) { Set elements = roundEnv.getRootElements(); for (Element element : elements) { if (element.getKind() == ElementKind.CLASS) { JCTree tree = (JCTree) trees.getTree(element).accept(new LocalDateUtilDate(), null); } System.out.println(element); } } I haven't met any "TreePath" as yet. > -----Original Message----- > From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > Sent: 31 May 2018 15:45 > To: Pietro Paolini > Cc: compiler-dev at openjdk.java.net > Subject: Re: Warn when certain constructor is used > > Try to call > > https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut > il/Trees.html#getElement(com.sun.source.util.TreePath) > > This should trigger attribution of the tree and give you the 'symbol' > associated with the constructor. From there you can access the symbol > signature using > > https://docs.oracle.com/javase/7/docs/api/javax/lang/model/element/Eleme > nt.html#asType() > > And downcasting to this: > > https://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/Executable > Type.html > > If this works, good, otherwise the solution would be more cumbersome - > and it will involve setting up a task listener. But try this first. > > Maurizio > > > On 31/05/18 13:19, Pietro Paolini wrote: > > Hi Maurizio, > > > > Thanks a lot. I would have an additional, and hopefully last, question. > > > > I am getting the NewClassTree which seems to provide me access to the - > forgive me the coarse wording of it - the "token", namely the textual > representation > > of it, while I am mainly interested in the type. > > > > I am getting around it by comparing strings but I wonder if there is any way > to get to the type of the expression : > > > > := new identifier ( arguments ) > > > > What I have in my mind is to detect all instances in which the identifier has > *type* A and the argument's list is composed by a single *type* , let say B. > That allows me to > > print something: > > > > "Hey, constructor new A(B) has been detected" > > > > Thanks a lot for your help so far, really. > > > > Thanks, > > P. > > > > > > > > > > > >> -----Original Message----- > >> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] > >> Sent: 31 May 2018 12:45 > >> To: Pietro Paolini > >> Cc: compiler-dev at openjdk.java.net > >> Subject: Re: Warn when certain constructor is used > >> > >> > >> > >> On 31/05/18 12:21, Pietro Paolini wrote: > >>> JCTree tree = (JCTree) trees.getTree(element); > >>> tree.accept(new LocalDateUtilDate()); > >> There re two visitor methods in JCTree, one internal (used by javac), > >> one external (used by the API). I don't think you need to cast down to > >> JCTree (yet, at least). Just keep it as a com.sun.source.tree.Tree, and > >> you will see that the only 'accept' method there takes two arguments: a > >> visitor (which you have) and a visitor parameter; since you don't seem > >> to need a visitor parameter, you can just pass 'null' as second parameter. > >> > >> Maurizio From jonathan.gibbons at oracle.com Thu May 31 21:37:53 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 31 May 2018 14:37:53 -0700 Subject: JEP 330 In-Reply-To: References: <5B1044E3.6020704@oracle.com> Message-ID: <5B106B31.1080107@oracle.com> Cay, Simplifying "public static void main" is something that has been discussed, and would be a change to JLS and javac. Nothing in this JEP precludes that further work, which is another of the reasons why this JEP is careful to avoid changing JLS and javac. If and when JLS changes to permit a simpler main program, then I would expect this launcher work to be able to trivially leverage such changes. -- Jon On 05/31/2018 02:19 PM, Cay Horstmann wrote: > Hi Jon, > > as it happens, teaching Java to beginners is something that I do a > lot. In twenty years, I have never met any beginner who was seriously > struggling with javac vs. java. There are many other issues that > confuse beginners, starting with public, static, void, main, and args. > As I point out in my blog, that confusion could be remedied by a > better launcher that is willing to instantiate a class. That would be > a large win for beginners. > > Also, beginners often start with an IDE that hides javac and java from > them for a while. When they get to the point where they use the > command line tools, they have probably already encountered multiple > classes. > > If the motivation of the JEP is to provide shebang support, sure. But > from a teaching perspective, I don't see how it is a win. > > Cheers, > > Cay > > Le 31/05/2018 ? 11:54, Jonathan Gibbons a ?crit : > >> >> Cay, >> >> The intent of the feature, as relates to easing the Java learning >> curve, is to assist in the first few "baby steps" that some folk >> might take when starting to learn Java. >> >> The intent is that for folk starting out from scratch, learning to >> use one command (java) is simpler than learning to use two (java and >> javac). Once they are familiar with using java to run simple small >> programs, then they can progress to using javac and java for programs >> using many files. Then, the next possible step on the ladder is to >> learn the jar command to make an executable. >> >> If you are teaching folk at a level where they are already more >> familiar with command-line tools, then yes, you may want to skip the >> ability to use the Java launcher to execute single-file source code >> programs. >> >> -- Jon > > From maurizio.cimadamore at oracle.com Thu May 31 23:02:07 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Jun 2018 00:02:07 +0100 Subject: Warn when certain constructor is used In-Reply-To: <5D285FC05679A441ACF34A90905BFA922F9BBC65@GBEDBP01.chp.co.uk> References: <5D285FC05679A441ACF34A90905BFA922F9B7875@GBEDBP01.chp.co.uk> <64cc8e09-7ccc-0e15-fa0c-c9fb915ee730@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9B99F7@GBEDBP01.chp.co.uk> <1aba7da3-6ddf-7e50-46d8-7a6fb47d76d3@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BAA81@GBEDBP01.chp.co.uk> <2f4445d8-2e5e-7c83-f873-2a9756863a23@oracle.com> <5D285FC05679A441ACF34A90905BFA922F9BBC65@GBEDBP01.chp.co.uk> Message-ID: <29992f5c-0251-3866-2b1c-8c7ee40bf46d@oracle.com> You can get a treepath from an element here: https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html#getPath(javax.lang.model.element.Element) And from the TreePath you obtain there, you can get a compilation unit: https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/util/TreePath.html#getCompilationUnit() Once you have this ingredient, you can finally obtain a path for any tree you'd like: https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html#getPath(com.sun.source.tree.CompilationUnitTree,%20com.sun.source.tree.Tree) So, I suggest you (1) obtain the TreePath form one of your root elements (2) extract the compilation unit from one of these path and stash it somewhere (3) when you reach the node you want (visitNewClass), you (4) obtain the TreePath for the node (by passing compilation unit and tree), and then (5) you call getElement on that path. Maurizio On 31/05/18 22:25, Pietro Paolini wrote: >> https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut >> il/Trees.html#getElement(com.sun.source.util.TreePath) > On what kind of object ? > > if (!roundEnv.processingOver()) { > Set elements = roundEnv.getRootElements(); > for (Element element : elements) { > if (element.getKind() == ElementKind.CLASS) { > JCTree tree = (JCTree) trees.getTree(element).accept(new LocalDateUtilDate(), null); > } > > System.out.println(element); > } > } > > I haven't met any "TreePath" as yet. > >> -----Original Message----- >> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] >> Sent: 31 May 2018 15:45 >> To: Pietro Paolini >> Cc: compiler-dev at openjdk.java.net >> Subject: Re: Warn when certain constructor is used >> >> Try to call >> >> https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/ut >> il/Trees.html#getElement(com.sun.source.util.TreePath) >> >> This should trigger attribution of the tree and give you the 'symbol' >> associated with the constructor. From there you can access the symbol >> signature using >> >> https://docs.oracle.com/javase/7/docs/api/javax/lang/model/element/Eleme >> nt.html#asType() >> >> And downcasting to this: >> >> https://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/Executable >> Type.html >> >> If this works, good, otherwise the solution would be more cumbersome - >> and it will involve setting up a task listener. But try this first. >> >> Maurizio >> >> >> On 31/05/18 13:19, Pietro Paolini wrote: >>> Hi Maurizio, >>> >>> Thanks a lot. I would have an additional, and hopefully last, question. >>> >>> I am getting the NewClassTree which seems to provide me access to the - >> forgive me the coarse wording of it - the "token", namely the textual >> representation >>> of it, while I am mainly interested in the type. >>> >>> I am getting around it by comparing strings but I wonder if there is any way >> to get to the type of the expression : >>> := new identifier ( arguments ) >>> >>> What I have in my mind is to detect all instances in which the identifier has >> *type* A and the argument's list is composed by a single *type* , let say B. >> That allows me to >>> print something: >>> >>> "Hey, constructor new A(B) has been detected" >>> >>> Thanks a lot for your help so far, really. >>> >>> Thanks, >>> P. >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] >>>> Sent: 31 May 2018 12:45 >>>> To: Pietro Paolini >>>> Cc: compiler-dev at openjdk.java.net >>>> Subject: Re: Warn when certain constructor is used >>>> >>>> >>>> >>>> On 31/05/18 12:21, Pietro Paolini wrote: >>>>> JCTree tree = (JCTree) trees.getTree(element); >>>>> tree.accept(new LocalDateUtilDate()); >>>> There re two visitor methods in JCTree, one internal (used by javac), >>>> one external (used by the API). I don't think you need to cast down to >>>> JCTree (yet, at least). Just keep it as a com.sun.source.tree.Tree, and >>>> you will see that the only 'accept' method there takes two arguments: a >>>> visitor (which you have) and a visitor parameter; since you don't seem >>>> to need a visitor parameter, you can just pass 'null' as second parameter. >>>> >>>> Maurizio