From jan.lahoda at oracle.com Mon Jun 1 08:07:00 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 1 Jun 2020 10:07:00 +0200 Subject: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3 In-Reply-To: <3f816bd3-bc9d-8f94-db98-94fd0423948d@oracle.com> References: <87877fd1-5413-7518-a2e6-d6d2132f6356@oracle.com> <3f816bd3-bc9d-8f94-db98-94fd0423948d@oracle.com> Message-ID: <85933330-a0e2-74cf-876c-42b64eb28482@oracle.com> Further testing revealed some issues with the patch, especially: -use of un-encoded version when deleting the old data for the version (so the data deletion failed for versions > 9) -need to delete old module data as well -when searching for existing methods and fields, we need to continue the search to find the best existing candidate (the code still had a for loop break, so only the first match was found). I apologize for missing those in the first review. Delta webrev: http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-01-create-symbols/ Full updated webrev: http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-create-symbols/ Does this look OK? Thanks! Jan On 28. 05. 20 16:47, Jonathan Gibbons wrote: > Looks good to me. > > -- Jon > > On 5/18/20 9:36 AM, Jan Lahoda wrote: >> I apologize, I used a wrong patch for the "data" webrev. The "class >> name java/util/jar/Attributes$Name" entry in java.base-7.sym.txt is >> first adding field descriptions, and then removing the old ones: >> --- >>> class name java/util/jar/Attributes$Name >>> field name EXTENSION_INSTALLATION descriptor >>> Ljava/util/jar/Attributes$Name; flags 19 >>> field name IMPLEMENTATION_VENDOR_ID descriptor >>> Ljava/util/jar/Attributes$Name; flags 19 >>> field name IMPLEMENTATION_URL descriptor >>> Ljava/util/jar/Attributes$Name; flags 19 >>> -field name EXTENSION_INSTALLATION descriptor >>> Ljava/util/jar/Attributes$Name; >>> -field name IMPLEMENTATION_VENDOR_ID descriptor >>> Ljava/util/jar/Attributes$Name; >>> -field name IMPLEMENTATION_URL descriptor >>> Ljava/util/jar/Attributes$Name;--- >> >> The correct order (and the order generated by the tool in the >> webrev.00-create-symbols/ webrev) is to first remove the field >> descriptions and then add the new ones: >> --- >>> class name java/util/jar/Attributes$Name >>> -field name EXTENSION_INSTALLATION descriptor >>> Ljava/util/jar/Attributes$Name; >>> -field name IMPLEMENTATION_VENDOR_ID descriptor >>> Ljava/util/jar/Attributes$Name; >>> -field name IMPLEMENTATION_URL descriptor >>> Ljava/util/jar/Attributes$Name; >>> field name EXTENSION_INSTALLATION descriptor >>> Ljava/util/jar/Attributes$Name; flags 19 >>> field name IMPLEMENTATION_VENDOR_ID descriptor >>> Ljava/util/jar/Attributes$Name; flags 19 >>> field name IMPLEMENTATION_URL descriptor >>> Ljava/util/jar/Attributes$Name; flags 19 >> --- >> >> An updated webrev is the correct data is here: >> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-data/ >> >> The only change is the above difference in order of entries in >> Attributes$Name. >> >> Sorry for trouble. >> >> Jan >> >> On 18. 05. 20 16:55, Jan Lahoda wrote: >>> Hi, >>> >>> Some new APIs have been introduced in JSR 337 MR3 (JDK 8). We should >>> update the historical data for JDK 8 with these new APIs. >>> >>> As this was the first time we need to update data for a release that >>> other release data use as a baseline, it was necessary to improve the >>> CreateSymbols tool a little: >>> -adding ability to ignore synchronized and native flags for methods >>> (as these don't affect the API) >>> -when analyzing a new entry (method/field/class), and multiple >>> existing entries compatible with the new one exist, the existing >>> entry that matches the baseline is chosen (this helps to eliminate >>> unnecessary entries, esp. when the synchronized or native flag changes) >>> -when replacing/updating a release data, the original approach was to >>> remove the data for the release, and read them from classfiles, and >>> build the record again from scratch. This does not work well for >>> baseline data, so the new approach is: >>> --keep all the existing data >>> --the new data are load into a new auxiliary slot, called "$" >>> --the old data for the given release are deleted >>> --the auxiliary release is renamed from "$" to the correct release name >>> >>> Together these changes allow to minimize the updates to JDK 8 data, >>> to mostly only changes in the MR3, with some extra changes like >>> new/removed overrides (where the superclass has the method that >>> is/was overridden). >>> >>> The proposed changes to CreateSymbols are: >>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-create-symbols/ >>> >>> The proposed updates to the historical data are: >>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-data/ >>> >>> Note the changes only apply for JDK 8 historical data, so JDK 8 data >>> are updated, and JDK 7 and 9 data undo the changes. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244763 >>> >>> The intent is to backport to JDK 11u. >>> >>> How does this look? >>> >>> Thanks! >>> >>> Jan From TOSHIONA at jp.ibm.com Mon Jun 1 09:05:29 2020 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Mon, 1 Jun 2020 18:05:29 +0900 Subject: RFR: JDK-8233829: javac cannot find non-ASCII module name under non-UTF8 environment In-Reply-To: References: <6eb52787-0ebd-1487-52c2-67cbfa04a6a4@oracle.com> Message-ID: Hi Jon, Could you look at this fix, if possible? Any comments or suggestions are welcome. Webrev.02: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/ Issue: https://bugs.openjdk.java.net/browse/JDK-8233829 Best regards, Toshio Nakamura > From: "Toshio 5 Nakamura" > To: Jonathan Gibbons > Cc: compiler-dev at openjdk.java.net > Date: 2020/05/15 00:23 > Subject: [EXTERNAL] Re: RFR: JDK-8233829: javac cannot find non- > ASCII module name under non-UTF8 environment > Sent by: "compiler-dev" > > Hi Jon, > > Thank you for comments. > > Could you check webrev.02 which contains a testcase? > Actually, this is not a direct test of the original problem since > non-English Windows is required. > But, I realized the patch fixed Unicode Surrogate Pair case, as well. > It's caused by difference between Standard UTF-8 and Modified UTF-8, > and it can be checked on English environment. > > I confirmed the test failed without the patch and passed with the patch. > Tier1 tests also pass on Linux and Windows. > > Webrev.02: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.02/ > > Best regards, > > Toshio Nakamura > > Jonathan Gibbons wrote on 2020/05/14 11:50:03: > > > From: Jonathan Gibbons > > To: Toshio 5 Nakamura , compiler-dev at openjdk.java.net > > Date: 2020/05/14 11:50 > > Subject: [EXTERNAL] Re: RFR: JDK-8233829: javac cannot find non- > > ASCII module name under non-UTF8 environment > > > > Hi, > > Normally, bug fixes like this this should be accompanied by a > > corresponding regression test. While it may be a bit tricky to write > > a test for this situation, it seems like it would be worth having > > the test if possible. > > -- Jon > > On 5/13/20 7:11 PM, Toshio 5 Nakamura wrote: > > Hi, > > > > Can anyone please review this fix? > > Revised the patch simpler. In my understanding, the encoding is > > modified UTF-8 instead of standard UTF-8 in this case. So, the fix > > uses Convert utility class. > > > > Webrev.01: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.01/ > > > > Best regards, > > Toshio Nakamura > > > > > From: Toshio 5 Nakamura/Japan/IBM > > > To: compiler-dev at openjdk.java.net > > > Date: 2020/04/16 21:39 > > > Subject: RFR: JDK-8233829: Non-ASCII module name cannot be handled > > > under non-UTF8 environment > > > > > > Hi all, > > > > > > Could you review this fix? Also, I'd like to ask a sponsor of the fix, since > > > I'm not a committer. > > > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8233829 > > > Webrev: http://cr.openjdk.java.net/~tnakamura/8233829/webrev.00/ > > > > > > If module name is in non-ASCII and environment is in non-UTF8, > > > javac's "--add-modules" option cannot find the module. > > > > > > com.sun.tools.javac.jvm.ModuleNameReader.utf8Mapper uses > > > String(byte[], int, int). > > > In problematic case, the String was generated by default encoding > > > which wasn't UTF8. > > > For example, Japanese Windows uses MS932 (Shift_JIS) encoding. > > > The byte[] in utf8Mapper method is always decoded by UTF-8. > > > > > > Tier1 tests on Linux and Windows passed. > > > > > > Best Regards, > > > Toshio Nakamura -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Jun 2 01:23:25 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 1 Jun 2020 18:23:25 -0700 Subject: JDK 15 RFR of JDK-8246290: Refine specification of javax.lang.model.element.Modifier::toString Message-ID: <1a82ef82-af79-720c-be43-d9981b87db2e@oracle.com> Hello, Please review the patch below with a small spec clarification of Modifier::toString; CSR at ??? JDK-8246291: Refine specification of javax.lang.model.element.Modifier::toString ??? https://bugs.openjdk.java.net/browse/JDK-8246291 Thanks, -Joe --- a/src/java.compiler/share/classes/javax/lang/model/element/Modifier.java Mon Jun 01 17:00:40 2020 -0400 +++ b/src/java.compiler/share/classes/javax/lang/model/element/Modifier.java Mon Jun 01 18:17:47 2020 -0700 @@ -38,6 +38,12 @@ ? *

Note that it is possible additional modifiers will be added in ? * future versions of the platform. ? * + * @jls 8.1.1 Class Modifiers + * @jls 8.3.1 Field Modifiers + * @jls 8.4.3 Method Modifiers + * @jls 8.8.3 Constructor Modifiers + * @jls 9.1.1 Interface Modifiers + * ? * @author Joseph D. Darcy ? * @author Scott Seligman ? * @author Peter von der Ahé @@ -46,8 +52,7 @@ ?public enum Modifier { -??? // See JLS sections 8.1.1, 8.3.1, 8.4.3, 8.8.3, and 9.1.1. -??? // java.lang.reflect.Modifier includes INTERFACE, but that's a VMism. +??? // Note java.lang.reflect.Modifier includes INTERFACE, but that's a VMism. ???? /** The modifier {@code public} */????????? PUBLIC, ???? /** The modifier {@code protected} */?????? PROTECTED, @@ -101,7 +106,10 @@ ???? /** The modifier {@code strictfp} */??????? STRICTFP; ???? /** -???? * Returns this modifier's name in lowercase. +???? * Returns this modifier's name as defined in The +???? * Java™ Language Specification. +???? * Note the modifier name is typically the {@linkplain #name() +???? * name of the enum constant} in lowercase. ????? */ ???? public String toString() { ???????? return name().toLowerCase(java.util.Locale.US); From adam.sotona at oracle.com Tue Jun 2 13:41:43 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 2 Jun 2020 15:41:43 +0200 Subject: RFR: 8236108 tools/javac/lambda/LambdaParserTest.java timed out Message-ID: <58F620C3-6B8D-4C12-8625-F62AAA635607@oracle.com> Hi, I would like to ask for review of LambdaParserTest.java timed out fix. This particular test is very complex and intensive. It includes 573696 test actions, each parsing a source fragment. As this single test takes on my powerful machine approx. 1 minute and the default timeout is 2 minutes, so I can imagine situations where it timeouts. Target machine scale factor was 4, so the default timeout was 480s, however the test elapsed time was 523s. Proposed patch extends the timeout by 50% to 180s, so multiplied by the machine-specific timeout scale factor it will give enough time to finish successfully. JBS: https://bugs.openjdk.java.net/browse/JDK-8236108 webrev: http://cr.openjdk.java.net/~asotona/8236108/webrev.00/ The test is a part of Tier 4 and it is passing for me even without the extended timeout, so I cannot practically verify the patch effectivity unless it fails. Thanks, Adam From vicente.romero at oracle.com Tue Jun 2 14:06:23 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 2 Jun 2020 10:06:23 -0400 Subject: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes In-Reply-To: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> References: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> Message-ID: <518ad004-fa16-178d-a9cf-c4e81d1b00d6@oracle.com> thanks to all the reviewers, the code for sealed classes has already been pushed to mainline. Vicente On 5/18/20 6:42 PM, Vicente Romero wrote: > Hi, > > Please review this patch for the compiler, javadoc and > javax.lang.model support for the JEP 360 Sealed Classes (Preview). The > changes are provided at [1], which implements the latest JLS for > sealed types [2]. The patch also include the needed changes to javadoc > and javax.lang.model to support sealed types. The CSR witht the > changes in the javax.lang.model spec is at [3]. The sealed types JEP > is accessible at [4]. There is an ongoing review for the VM and > core-libs code of sealed types [5] and that code hasn't been included > in this webrev, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html > > [3] https://bugs.openjdk.java.net/browse/JDK-8244367 > [4] https://openjdk.java.net/jeps/360 > [5] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066440.html From jan.lahoda at oracle.com Wed Jun 3 10:16:48 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 3 Jun 2020 12:16:48 +0200 Subject: RFR: JDK-8246353: Sealed types not supported by jshell Message-ID: <725a51bd-1e23-a604-1ceb-b6f05a295a51@oracle.com> Hi, JShell does not support sealed types yet, this patch attempts to solve it. This patch: -adds "permits" clauses to header dependencies of the class that defines it (so that JShell correctly detects the permitted classes must be added before the class is defined) -JShell will not clear the final modifier, on any element (class, method, variable) before compiling the snippet -javac will not report the "no sealed superclass" error for cases like: non-sealed class I extends Undefined {} (this makes support for non-sealed in JShell much easier, and is the right thing to do, I believe.) Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8246353/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8246353 How does this look? Thanks, Jan From vicente.romero at oracle.com Wed Jun 3 16:33:24 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 3 Jun 2020 12:33:24 -0400 Subject: RFR: JDK-8246353: Sealed types not supported by jshell In-Reply-To: <725a51bd-1e23-a604-1ceb-b6f05a295a51@oracle.com> References: <725a51bd-1e23-a604-1ceb-b6f05a295a51@oracle.com> Message-ID: looks good to me, Thanks, Vicente On 6/3/20 6:16 AM, Jan Lahoda wrote: > Hi, > > JShell does not support sealed types yet, this patch attempts to solve > it. This patch: > -adds "permits" clauses to header dependencies of the class that > defines it (so that JShell correctly detects the permitted classes > must be added before the class is defined) > -JShell will not clear the final modifier, on any element (class, > method, variable) before compiling the snippet > -javac will not report the "no sealed superclass" error for cases like: > non-sealed class I extends Undefined {} > (this makes support for non-sealed in JShell much easier, and is the > right thing to do, I believe.) > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8246353/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8246353 > > How does this look? > > Thanks, > ?? Jan From vicente.romero at oracle.com Wed Jun 3 20:22:00 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 3 Jun 2020 16:22:00 -0400 Subject: RFR: JDK-8246486: javac doesn't allow a subclass to be declared before a sealed superclass with no permits clause Message-ID: <1bfeea59-7be7-bb66-88b1-df003934624b@oracle.com> Please review the fix for [1] at [2], this patch if fixing the following issue, javac doesn't accept code like: final class B extends A {} sealed class A {}? // no permits clause the reason is that when analyzing the permits clause of the sealed class, the permitted list was overwritten without checking if it wasn't empty. This is fixed now. Also as the presence of annotation processors can provoke several iterations on the same code, now it is necessary to clean out the `permitted` list if annotations processors are present. This avoid that an iteration can find symbols stored in this list by a previous iteration. Given this new dependency on annotation processors of the sealed classes code, test SealedCompilationTests has been modified to be executed twice: with and without a simple annotations processor to stress this dependency. There is a change that is not strictly related to the main theme of the patch which is this one liner: diff -r 0a32396f7a69 -r 3a73b52df56b src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java Wed Jun 03 12:09:04 2020 -0400 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java Wed Jun 03 15:25:41 2020 -0400 @@ -717,7 +717,6 @@ ???????????? ListBuffer permittedSubtypeSymbols = new ListBuffer<>(); ???????????? List permittedTrees = tree.permitting; ???????????? for (JCExpression permitted : permittedTrees) { -??????????????? permitted = clearTypeParams(permitted); ???????????????? Type pt = attr.attribBase(permitted, baseEnv, false, false, false); ???????????????? permittedSubtypeSymbols.append(pt.tsym); ???????????? } permitted subclasses can't have type parameters thus this line is a no-op, but given that the bug was related to the permits clause I found this issue and addressed it as part of the patch, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8246486 [2] http://cr.openjdk.java.net/~vromero/8246486/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Jun 4 18:28:52 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 4 Jun 2020 14:28:52 -0400 Subject: RFR JDK-8246199: 'permits' is a restricted identifier Message-ID: <05da5cea-d56b-ea4e-6020-f47d76bbc7b6@oracle.com> Please review fix for [1] at [2], `permits` is a restricted identifier according to the sealed classes spec [3]. This patch will sync the compiler with that part of the spec, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8246199 [2] http://cr.openjdk.java.net/~vromero/8246199/webrev.00/ [3] http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200526/specs/sealed-classes-jls.html From maurizio.cimadamore at oracle.com Thu Jun 4 21:24:32 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 4 Jun 2020 22:24:32 +0100 Subject: RFR: JDK-8246486: javac doesn't allow a subclass to be declared before a sealed superclass with no permits clause In-Reply-To: <1bfeea59-7be7-bb66-88b1-df003934624b@oracle.com> References: <1bfeea59-7be7-bb66-88b1-df003934624b@oracle.com> Message-ID: <9ca54c69-c554-ccc8-eaa8-3d3d4e70393c@oracle.com> Changes look good. Maurizio On 03/06/2020 21:22, Vicente Romero wrote: > Please review the fix for [1] at [2], this patch if fixing the > following issue, javac doesn't accept code like: > > final class B extends A {} > sealed class A {}? // no permits clause > > the reason is that when analyzing the permits clause of the sealed > class, the permitted list was overwritten without checking if it > wasn't empty. This is fixed now. Also as the presence of annotation > processors can provoke several iterations on the same code, now it is > necessary to clean out the `permitted` list if annotations processors > are present. This avoid that an iteration can find symbols stored in > this list by a previous iteration. Given this new dependency on > annotation processors of the sealed classes code, test > SealedCompilationTests has been modified to be executed twice: with > and without a simple annotations processor to stress this dependency. > There is a change that is not strictly related to the main theme of > the patch which is this one liner: > > diff -r 0a32396f7a69 -r 3a73b52df56b > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java > Wed Jun 03 12:09:04 2020 -0400 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java > Wed Jun 03 15:25:41 2020 -0400 > @@ -717,7 +717,6 @@ > ???????????? ListBuffer permittedSubtypeSymbols = new > ListBuffer<>(); > ???????????? List permittedTrees = tree.permitting; > ???????????? for (JCExpression permitted : permittedTrees) { > -??????????????? permitted = clearTypeParams(permitted); > ???????????????? Type pt = attr.attribBase(permitted, baseEnv, false, > false, false); > permittedSubtypeSymbols.append(pt.tsym); > ???????????? } > > permitted subclasses can't have type parameters thus this line is a > no-op, but given that the bug was related to the permits clause I > found this issue and addressed it as part of the patch, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8246486 > [2] http://cr.openjdk.java.net/~vromero/8246486/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Jun 4 21:26:42 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 4 Jun 2020 22:26:42 +0100 Subject: RFR JDK-8246199: 'permits' is a restricted identifier In-Reply-To: <05da5cea-d56b-ea4e-6020-f47d76bbc7b6@oracle.com> References: <05da5cea-d56b-ea4e-6020-f47d76bbc7b6@oracle.com> Message-ID: <3204d240-033a-02c5-2954-30ac3cf67034@oracle.com> Looks good Maurizio On 04/06/2020 19:28, Vicente Romero wrote: > Please review fix for [1] at [2], `permits` is a restricted identifier > according to the sealed classes spec [3]. This patch will sync the > compiler with that part of the spec, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8246199 > [2] http://cr.openjdk.java.net/~vromero/8246199/webrev.00/ > [3] > http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200526/specs/sealed-classes-jls.html From maurizio.cimadamore at oracle.com Thu Jun 4 21:28:23 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 4 Jun 2020 22:28:23 +0100 Subject: RFR: JDK-8246486: javac doesn't allow a subclass to be declared before a sealed superclass with no permits clause In-Reply-To: <9ca54c69-c554-ccc8-eaa8-3d3d4e70393c@oracle.com> References: <1bfeea59-7be7-bb66-88b1-df003934624b@oracle.com> <9ca54c69-c554-ccc8-eaa8-3d3d4e70393c@oracle.com> Message-ID: <611f3c33-e2f6-2577-059e-d8779bfdfcbe@oracle.com> Hit "send" too fast - small tweak suggested - instead of: sym.permitted = !permittedSubtypeSymbols.isEmpty() ? + permittedSubtypeSymbols.toList() : + sym.permitted; Just go for: if (!permittedSubtypeSymbols.isEmpty()) { sym.permitted = permittedSubtypeSymbols.toList(); } Maurizio On 04/06/2020 22:24, Maurizio Cimadamore wrote: > > Changes look good. > > Maurizio > > > On 03/06/2020 21:22, Vicente Romero wrote: >> Please review the fix for [1] at [2], this patch if fixing the >> following issue, javac doesn't accept code like: >> >> final class B extends A {} >> sealed class A {}? // no permits clause >> >> the reason is that when analyzing the permits clause of the sealed >> class, the permitted list was overwritten without checking if it >> wasn't empty. This is fixed now. Also as the presence of annotation >> processors can provoke several iterations on the same code, now it is >> necessary to clean out the `permitted` list if annotations processors >> are present. This avoid that an iteration can find symbols stored in >> this list by a previous iteration. Given this new dependency on >> annotation processors of the sealed classes code, test >> SealedCompilationTests has been modified to be executed twice: with >> and without a simple annotations processor to stress this dependency. >> There is a change that is not strictly related to the main theme of >> the patch which is this one liner: >> >> diff -r 0a32396f7a69 -r 3a73b52df56b >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java >> Wed Jun 03 12:09:04 2020 -0400 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java >> Wed Jun 03 15:25:41 2020 -0400 >> @@ -717,7 +717,6 @@ >> ???????????? ListBuffer permittedSubtypeSymbols = new >> ListBuffer<>(); >> ???????????? List permittedTrees = tree.permitting; >> ???????????? for (JCExpression permitted : permittedTrees) { >> -??????????????? permitted = clearTypeParams(permitted); >> ???????????????? Type pt = attr.attribBase(permitted, baseEnv, false, >> false, false); >> permittedSubtypeSymbols.append(pt.tsym); >> ???????????? } >> >> permitted subclasses can't have type parameters thus this line is a >> no-op, but given that the bug was related to the permits clause I >> found this issue and addressed it as part of the patch, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8246486 >> [2] http://cr.openjdk.java.net/~vromero/8246486/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Jun 4 23:01:46 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 4 Jun 2020 19:01:46 -0400 Subject: RFR: JDK-8246486: javac doesn't allow a subclass to be declared before a sealed superclass with no permits clause In-Reply-To: <611f3c33-e2f6-2577-059e-d8779bfdfcbe@oracle.com> References: <1bfeea59-7be7-bb66-88b1-df003934624b@oracle.com> <9ca54c69-c554-ccc8-eaa8-3d3d4e70393c@oracle.com> <611f3c33-e2f6-2577-059e-d8779bfdfcbe@oracle.com> Message-ID: <693559fa-394c-412c-f4f4-9c4c22bf5451@oracle.com> thanks for the review, I will update the code with your proposed change before pushing Vicente On 6/4/20 5:28 PM, Maurizio Cimadamore wrote: > > Hit "send" too fast - small tweak suggested - instead of: > > sym.permitted = !permittedSubtypeSymbols.isEmpty() ? > + permittedSubtypeSymbols.toList() : > + sym.permitted; > Just go for: > > if (!permittedSubtypeSymbols.isEmpty()) { sym.permitted = > permittedSubtypeSymbols.toList(); } > > Maurizio > > On 04/06/2020 22:24, Maurizio Cimadamore wrote: >> >> Changes look good. >> >> Maurizio >> >> >> On 03/06/2020 21:22, Vicente Romero wrote: >>> Please review the fix for [1] at [2], this patch if fixing the >>> following issue, javac doesn't accept code like: >>> >>> final class B extends A {} >>> sealed class A {}? // no permits clause >>> >>> the reason is that when analyzing the permits clause of the sealed >>> class, the permitted list was overwritten without checking if it >>> wasn't empty. This is fixed now. Also as the presence of annotation >>> processors can provoke several iterations on the same code, now it >>> is necessary to clean out the `permitted` list if annotations >>> processors are present. This avoid that an iteration can find >>> symbols stored in this list by a previous iteration. Given this new >>> dependency on annotation processors of the sealed classes code, test >>> SealedCompilationTests has been modified to be executed twice: with >>> and without a simple annotations processor to stress this >>> dependency. There is a change that is not strictly related to the >>> main theme of the patch which is this one liner: >>> >>> diff -r 0a32396f7a69 -r 3a73b52df56b >>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java >>> --- >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java >>> Wed Jun 03 12:09:04 2020 -0400 >>> +++ >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java >>> Wed Jun 03 15:25:41 2020 -0400 >>> @@ -717,7 +717,6 @@ >>> ???????????? ListBuffer permittedSubtypeSymbols = new >>> ListBuffer<>(); >>> ???????????? List permittedTrees = tree.permitting; >>> ???????????? for (JCExpression permitted : permittedTrees) { >>> -??????????????? permitted = clearTypeParams(permitted); >>> ???????????????? Type pt = attr.attribBase(permitted, baseEnv, >>> false, false, false); >>> permittedSubtypeSymbols.append(pt.tsym); >>> ???????????? } >>> >>> permitted subclasses can't have type parameters thus this line is a >>> no-op, but given that the bug was related to the permits clause I >>> found this issue and addressed it as part of the patch, >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8246486 >>> [2] http://cr.openjdk.java.net/~vromero/8246486/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Fri Jun 5 08:22:35 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Fri, 5 Jun 2020 10:22:35 +0200 Subject: RFR: JDK-8236697 Stack overflow with cyclic hierarchy in class file In-Reply-To: <3F9B3770-318A-4827-AD7A-F9D30FC0D79C@oracle.com> References: <3F9B3770-318A-4827-AD7A-F9D30FC0D79C@oracle.com> Message-ID: Hi, c.s.t.j.code.Types::asSuper causes stack overflow when there is involved a class with cyclic hierarchy. Proposed fix (option #2 below) performs minimal necessary cycle detection to avoid stack overflow by breaking the loop, using LOCKED flag as a part of c.s.t.j.code.Types::asSuper execution. Proposed test simulates the situation using JCOD. Tier 1, 2 and 3 tests passed and performance benchmarks found no significant regression. webrev: http://cr.openjdk.java.net/~asotona/8236697/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8236697 Thanks, Adam > On 28 May 2020, at 16:28, Adam Sotona wrote: > > Hi, > I would like to ask for help with decision and review fix of JDK-8236697 Stack overflow with cyclic hierarchy in class file. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8236697 > > First important information is that the Stack overflow is caused by artificially corrupted library class file. > The reproducible case described in the issue can be significantly simplified and I've transformed it into a test case (a part of the patches below). > > Now I'm considering three possible options: > > Option #1 - complete detection and reporting of dependency cycles as a part of c.s.t.j.code.Types::asSuper by call of c.s.t.j.comp.Check::checkNonCyclic method, with positive impact on cycle detection and reporting, with minimal negative impact on performance and with negative impact on EagerInterfaceCompletionTest, which does not expect that by calling asSuper will be updated error status of all ancestors. > Here is related patch in webrev: http://cr.openjdk.java.net/~asotona/8236697/webrev.00/ > > Option #2 - minimal necessary cycle detection just to avoid stack overflow, using LOCKED flag as a part of c.s.t.j.code.Types::asSuper execution, without any error reporting, just to avoid erroneous state, with almost no impact on performance and no detected impact on other parts of javac and tests. > webrev: http://cr.openjdk.java.net/~asotona/8236697/webrev.01/ > > Option #3 - do not fix it, as artificially corrupted cyclic class file is an extreme case, where Stack overflow from javac might be considered as relevant response > > I've run Tier 1, 2 and 3 tests for options #1 and #2 and also javac compilation benchmarks comparing javac performance against JDK 15 build 25. > > I propose to use option #2, however please let me know your opinion and/or review. > > Thanks, > Adam > > From jan.lahoda at oracle.com Fri Jun 5 15:20:15 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 5 Jun 2020 17:20:15 +0200 Subject: RFR: JDK-8235564: javac crashes while compiling incorrect method invocation with member reference Message-ID: Hi, Consider code like: public class Test { static void test() { existingWithoutFunctional(Test::undefined); } private static void existingWithoutFunctional(String parameter) {} } javac crashes on this (please see the bug for the stack trace). The reason for this is that while there are two errors in the source code: a) passing member reference to a parameter that is not of a functional type; b) the member reference refers to a method that does not exist, no error is reported. The first error is suppressed because the parameter is erroneous, and it is expected an error was already issued for it (this is fine). The second error is mostly accidentally suppressed because Attr.visitReference will get "String" and pt(), and hence getTargetInfo() will fail to find the functional type, and most of the processing/verification is skipped, and this causes the problem. The problem is while doing recovery DeferredAttr.RecoveryDeferredTypeMap.recover will use the non-functional formal parameter type as the expected target type. This was an attempt to improve error recovery, but seems to go too far. The proposal is to use the formal parameter type only if it is a functional type. As a result, for the example above, the javac reponse will be: $ javac Test.java Test.java:3: error: invalid method reference existingWithoutFunctional(Test::undefined); ^ cannot find symbol symbol: method undefined() location: class Test 1 error Which is the same as in JDK 11. cr.openjdk.java.net/~jlahoda/8235564/webrev.00/ Proposed webrev: JBS: https://bugs.openjdk.java.net/browse/JDK-8235564 How does this look? Thanks, Jan From vicente.romero at oracle.com Fri Jun 5 18:22:59 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 5 Jun 2020 14:22:59 -0400 Subject: RFR: JDK-8235564: javac crashes while compiling incorrect method invocation with member reference In-Reply-To: References: Message-ID: <89d4c27c-fcad-62e1-69a9-cdd67d4ccd49@oracle.com> Hi, looks good, my only question is if this: Type ptRecovery = pt != null && types.isFunctionalInterface(pt) ? pt : Type.recoveryType; wont be a too strict semantic change, but given that this is recovery code anyway I guess that users won't see a difference in the printed diagnostics, Vicente On 6/5/20 11:20 AM, Jan Lahoda wrote: > Hi, > > Consider code like: > public class Test { > ??? static void test() { > ??????? existingWithoutFunctional(Test::undefined); > ??? } > > ??? private static void existingWithoutFunctional(String parameter) {} > } > > javac crashes on this (please see the bug for the stack trace). The > reason for this is that while there are two errors in the source code: > a) passing member reference to a parameter that is not of a functional > type; b) the member reference refers to a method that does not exist, > no error is reported. The first error is suppressed because the > parameter is erroneous, and it is expected an error was already issued > for it (this is fine). > > The second error is mostly accidentally suppressed because > Attr.visitReference will get "String" and pt(), and hence > getTargetInfo() will fail to find the functional type, and most of the > processing/verification is skipped, and this causes the problem. The > problem is while doing recovery > DeferredAttr.RecoveryDeferredTypeMap.recover will use the > non-functional formal parameter type as the expected target type. This > was an attempt to improve error recovery, but seems to go too far. The > proposal is to use the formal parameter type only if it is a > functional type. > > As a result, for the example above, the javac reponse will be: > $ javac Test.java > Test.java:3: error: invalid method reference > ??????? existingWithoutFunctional(Test::undefined); > ????????????????????????????????? ^ > ? cannot find symbol > ??? symbol:?? method undefined() > ??? location: class Test > 1 error > > Which is the same as in JDK 11. > cr.openjdk.java.net/~jlahoda/8235564/webrev.00/ > > Proposed webrev: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235564 > > How does this look? > > Thanks, > ??? Jan > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Jun 5 18:36:34 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 5 Jun 2020 14:36:34 -0400 Subject: RFR: JDK-8236697 Stack overflow with cyclic hierarchy in class file In-Reply-To: References: <3F9B3770-318A-4827-AD7A-F9D30FC0D79C@oracle.com> Message-ID: <83c92a97-8354-f11e-2ab7-98e51cb0816f@oracle.com> looks sensible to me, Vicente On 6/5/20 4:22 AM, Adam Sotona wrote: > Hi, > c.s.t.j.code.Types::asSuper causes stack overflow when there is involved a class with cyclic hierarchy. > Proposed fix (option #2 below) performs minimal necessary cycle detection to avoid stack overflow by breaking the loop, using LOCKED flag as a part of c.s.t.j.code.Types::asSuper execution. > Proposed test simulates the situation using JCOD. > Tier 1, 2 and 3 tests passed and performance benchmarks found no significant regression. > > webrev: http://cr.openjdk.java.net/~asotona/8236697/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8236697 > > Thanks, > Adam > > >> On 28 May 2020, at 16:28, Adam Sotona wrote: >> >> Hi, >> I would like to ask for help with decision and review fix of JDK-8236697 Stack overflow with cyclic hierarchy in class file. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8236697 >> >> First important information is that the Stack overflow is caused by artificially corrupted library class file. >> The reproducible case described in the issue can be significantly simplified and I've transformed it into a test case (a part of the patches below). >> >> Now I'm considering three possible options: >> >> Option #1 - complete detection and reporting of dependency cycles as a part of c.s.t.j.code.Types::asSuper by call of c.s.t.j.comp.Check::checkNonCyclic method, with positive impact on cycle detection and reporting, with minimal negative impact on performance and with negative impact on EagerInterfaceCompletionTest, which does not expect that by calling asSuper will be updated error status of all ancestors. >> Here is related patch in webrev: http://cr.openjdk.java.net/~asotona/8236697/webrev.00/ >> >> Option #2 - minimal necessary cycle detection just to avoid stack overflow, using LOCKED flag as a part of c.s.t.j.code.Types::asSuper execution, without any error reporting, just to avoid erroneous state, with almost no impact on performance and no detected impact on other parts of javac and tests. >> webrev: http://cr.openjdk.java.net/~asotona/8236697/webrev.01/ >> >> Option #3 - do not fix it, as artificially corrupted cyclic class file is an extreme case, where Stack overflow from javac might be considered as relevant response >> >> I've run Tier 1, 2 and 3 tests for options #1 and #2 and also javac compilation benchmarks comparing javac performance against JDK 15 build 25. >> >> I propose to use option #2, however please let me know your opinion and/or review. >> >> Thanks, >> Adam >> >> From jan.lahoda at oracle.com Fri Jun 5 19:04:46 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 5 Jun 2020 21:04:46 +0200 Subject: RFR: JDK-8235564: javac crashes while compiling incorrect method invocation with member reference In-Reply-To: <89d4c27c-fcad-62e1-69a9-cdd67d4ccd49@oracle.com> References: <89d4c27c-fcad-62e1-69a9-cdd67d4ccd49@oracle.com> Message-ID: <4803842f-aa7a-e853-e89b-9058bd81aa89@oracle.com> Hi Vicente, On 05. 06. 20 20:22, Vicente Romero wrote: > Hi, > > looks good, my only question is if this: > > Type ptRecovery = pt != null && types.isFunctionalInterface(pt) ? pt : Type.recoveryType; > > > wont be a too strict semantic change, but given that this is recovery > code anyway I guess that users won't see a difference in the printed > diagnostics, Thanks for the comment! I guess you might be right - I'll limit check for the function interface only to DeferredTypes that represent lambdas and member references (where we really need a functional target type). Will send a new webrev early next week. Thanks, Jan > > Vicente > > On 6/5/20 11:20 AM, Jan Lahoda wrote: >> Hi, >> >> Consider code like: >> public class Test { >> ??? static void test() { >> ??????? existingWithoutFunctional(Test::undefined); >> ??? } >> >> ??? private static void existingWithoutFunctional(String parameter) {} >> } >> >> javac crashes on this (please see the bug for the stack trace). The >> reason for this is that while there are two errors in the source code: >> a) passing member reference to a parameter that is not of a functional >> type; b) the member reference refers to a method that does not exist, >> no error is reported. The first error is suppressed because the >> parameter is erroneous, and it is expected an error was already issued >> for it (this is fine). >> >> The second error is mostly accidentally suppressed because >> Attr.visitReference will get "String" and pt(), and hence >> getTargetInfo() will fail to find the functional type, and most of the >> processing/verification is skipped, and this causes the problem. The >> problem is while doing recovery >> DeferredAttr.RecoveryDeferredTypeMap.recover will use the >> non-functional formal parameter type as the expected target type. This >> was an attempt to improve error recovery, but seems to go too far. The >> proposal is to use the formal parameter type only if it is a >> functional type. >> >> As a result, for the example above, the javac reponse will be: >> $ javac Test.java >> Test.java:3: error: invalid method reference >> ??????? existingWithoutFunctional(Test::undefined); >> ????????????????????????????????? ^ >> ? cannot find symbol >> ??? symbol:?? method undefined() >> ??? location: class Test >> 1 error >> >> Which is the same as in JDK 11. >> cr.openjdk.java.net/~jlahoda/8235564/webrev.00/ >> >> Proposed webrev: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235564 >> >> How does this look? >> >> Thanks, >> ??? Jan >> >> >> >> >> > From vicente.romero at oracle.com Fri Jun 5 19:51:23 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 5 Jun 2020 15:51:23 -0400 Subject: RFR: JDK-8235564: javac crashes while compiling incorrect method invocation with member reference In-Reply-To: <4803842f-aa7a-e853-e89b-9058bd81aa89@oracle.com> References: <89d4c27c-fcad-62e1-69a9-cdd67d4ccd49@oracle.com> <4803842f-aa7a-e853-e89b-9058bd81aa89@oracle.com> Message-ID: <04197993-4c72-efb1-e0c3-9eccdf868d85@oracle.com> sounds good, Thanks, Vicente On 6/5/20 3:04 PM, Jan Lahoda wrote: > Hi Vicente, > > On 05. 06. 20 20:22, Vicente Romero wrote: >> Hi, >> >> looks good, my only question is if this: >> >> Type ptRecovery = pt != null && types.isFunctionalInterface(pt) ? pt >> : Type.recoveryType; >> >> >> wont be a too strict semantic change, but given that this is recovery >> code anyway I guess that users won't see a difference in the printed >> diagnostics, > > Thanks for the comment! > > I guess you might be right - I'll limit check for the function > interface only to DeferredTypes that represent lambdas and member > references (where we really need a functional target type). Will send > a new webrev early next week. > > Thanks, > ??? Jan > >> >> Vicente >> >> On 6/5/20 11:20 AM, Jan Lahoda wrote: >>> Hi, >>> >>> Consider code like: >>> public class Test { >>> ??? static void test() { >>> ??????? existingWithoutFunctional(Test::undefined); >>> ??? } >>> >>> ??? private static void existingWithoutFunctional(String parameter) {} >>> } >>> >>> javac crashes on this (please see the bug for the stack trace). The >>> reason for this is that while there are two errors in the source >>> code: a) passing member reference to a parameter that is not of a >>> functional type; b) the member reference refers to a method that >>> does not exist, no error is reported. The first error is suppressed >>> because the parameter is erroneous, and it is expected an error was >>> already issued for it (this is fine). >>> >>> The second error is mostly accidentally suppressed because >>> Attr.visitReference will get "String" and pt(), and hence >>> getTargetInfo() will fail to find the functional type, and most of >>> the processing/verification is skipped, and this causes the problem. >>> The problem is while doing recovery >>> DeferredAttr.RecoveryDeferredTypeMap.recover will use the >>> non-functional formal parameter type as the expected target type. >>> This was an attempt to improve error recovery, but seems to go too >>> far. The proposal is to use the formal parameter type only if it is >>> a functional type. >>> >>> As a result, for the example above, the javac reponse will be: >>> $ javac Test.java >>> Test.java:3: error: invalid method reference >>> ??????? existingWithoutFunctional(Test::undefined); >>> ????????????????????????????????? ^ >>> ? cannot find symbol >>> ??? symbol:?? method undefined() >>> ??? location: class Test >>> 1 error >>> >>> Which is the same as in JDK 11. >>> cr.openjdk.java.net/~jlahoda/8235564/webrev.00/ >>> >>> Proposed webrev: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235564 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >>> >>> >>> >>> >>> >> From jan.lahoda at oracle.com Mon Jun 8 13:35:50 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 8 Jun 2020 15:35:50 +0200 Subject: RFR: JDK-8235564: javac crashes while compiling incorrect method invocation with member reference In-Reply-To: <04197993-4c72-efb1-e0c3-9eccdf868d85@oracle.com> References: <89d4c27c-fcad-62e1-69a9-cdd67d4ccd49@oracle.com> <4803842f-aa7a-e853-e89b-9058bd81aa89@oracle.com> <04197993-4c72-efb1-e0c3-9eccdf868d85@oracle.com> Message-ID: <034456a7-344c-b8fc-8031-6f1de1c02ae1@oracle.com> Hi, Updated patch which will only check whether the type is a functional interface for lambdas and member references. Full updated patch: http://cr.openjdk.java.net/~jlahoda/8235564/webrev.01/ Delta from previous patch: http://cr.openjdk.java.net/~jlahoda/8235564/webrev.delta.00-01/ Does this look OK? Thanks, Jan On 05. 06. 20 21:51, Vicente Romero wrote: > sounds good, > > Thanks, > Vicente > > On 6/5/20 3:04 PM, Jan Lahoda wrote: >> Hi Vicente, >> >> On 05. 06. 20 20:22, Vicente Romero wrote: >>> Hi, >>> >>> looks good, my only question is if this: >>> >>> Type ptRecovery = pt != null && types.isFunctionalInterface(pt) ? pt >>> : Type.recoveryType; >>> >>> >>> wont be a too strict semantic change, but given that this is recovery >>> code anyway I guess that users won't see a difference in the printed >>> diagnostics, >> >> Thanks for the comment! >> >> I guess you might be right - I'll limit check for the function >> interface only to DeferredTypes that represent lambdas and member >> references (where we really need a functional target type). Will send >> a new webrev early next week. >> >> Thanks, >> ??? Jan >> >>> >>> Vicente >>> >>> On 6/5/20 11:20 AM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Consider code like: >>>> public class Test { >>>> ??? static void test() { >>>> ??????? existingWithoutFunctional(Test::undefined); >>>> ??? } >>>> >>>> ??? private static void existingWithoutFunctional(String parameter) {} >>>> } >>>> >>>> javac crashes on this (please see the bug for the stack trace). The >>>> reason for this is that while there are two errors in the source >>>> code: a) passing member reference to a parameter that is not of a >>>> functional type; b) the member reference refers to a method that >>>> does not exist, no error is reported. The first error is suppressed >>>> because the parameter is erroneous, and it is expected an error was >>>> already issued for it (this is fine). >>>> >>>> The second error is mostly accidentally suppressed because >>>> Attr.visitReference will get "String" and pt(), and hence >>>> getTargetInfo() will fail to find the functional type, and most of >>>> the processing/verification is skipped, and this causes the problem. >>>> The problem is while doing recovery >>>> DeferredAttr.RecoveryDeferredTypeMap.recover will use the >>>> non-functional formal parameter type as the expected target type. >>>> This was an attempt to improve error recovery, but seems to go too >>>> far. The proposal is to use the formal parameter type only if it is >>>> a functional type. >>>> >>>> As a result, for the example above, the javac reponse will be: >>>> $ javac Test.java >>>> Test.java:3: error: invalid method reference >>>> ??????? existingWithoutFunctional(Test::undefined); >>>> ????????????????????????????????? ^ >>>> ? cannot find symbol >>>> ??? symbol:?? method undefined() >>>> ??? location: class Test >>>> 1 error >>>> >>>> Which is the same as in JDK 11. >>>> cr.openjdk.java.net/~jlahoda/8235564/webrev.00/ >>>> >>>> Proposed webrev: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235564 >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>> >>>> >>>> >>>> >>> > From vicente.romero at oracle.com Mon Jun 8 15:09:37 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 8 Jun 2020 11:09:37 -0400 Subject: RFR JDK-8246199: 'permits' is a restricted identifier In-Reply-To: <3204d240-033a-02c5-2954-30ac3cf67034@oracle.com> References: <05da5cea-d56b-ea4e-6020-f47d76bbc7b6@oracle.com> <3204d240-033a-02c5-2954-30ac3cf67034@oracle.com> Message-ID: <891a308e-84a5-f260-9538-4d7f60dd7325@oracle.com> thanks for the review, Vicente On 6/4/20 5:26 PM, Maurizio Cimadamore wrote: > Looks good > > Maurizio > > On 04/06/2020 19:28, Vicente Romero wrote: >> Please review fix for [1] at [2], `permits` is a restricted >> identifier according to the sealed classes spec [3]. This patch will >> sync the compiler with that part of the spec, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8246199 >> [2] http://cr.openjdk.java.net/~vromero/8246199/webrev.00/ >> [3] >> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200526/specs/sealed-classes-jls.html From sietse.au at booking.com Mon Jun 8 19:34:25 2020 From: sietse.au at booking.com (Sietse Au) Date: Mon, 8 Jun 2020 21:34:25 +0200 Subject: BUG: local type inference -> symbol not found Message-ID: Hi, I've run into a compilation error on OpenJDK 11.06 (see attachment) where there is some interaction between local type inference and method reference. Haven't been able to create a clean project to reproduce the problem. Inside a larger code-base it is reproducible: final var someDao = ... someRequest.map(item -> SomeBuilder.builder() ... .build() ).forEach(someDao::create); the combination of the local type inference `final var` and the `someDao::create` method reference lead to the stacktrace in the attachment. When we rewrite the above to not use type inference and declare the type explicitly: final SomeDao someDao = ... OR rewrite the forEach not using the method reference: forEach(x -> someDao.create(x)) the code compiles. As the stack trace itself was kind of unhelpful, hooking up to a debugger found that when the code hits `someDao::create` a SymbolNotFound error is thrown. Best regards, -- Sietse Au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- compiler message file broken: key=compiler.misc.msg.bug arguments=11.0.6, {1}, {2}, {3}, {4}, {5}, {6}, {7} java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$2$1.setOverloadKind(DeferredAttr.java:172) at jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr.visitReference(ArgumentAttr.java:277) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMemberReference.accept(JCTree.java:2195) at jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr.attribArg(ArgumentAttr.java:197) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:653) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:751) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1997) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:702) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitExec(Attr.java:1773) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1452) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:724) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:743) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1294) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:724) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitIf(Attr.java:1762) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIf.accept(JCTree.java:1421) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:724) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:743) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1294) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:724) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:743) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1294) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:498) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:481) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr.attribSpeculativeLambda(DeferredAttr.java:456) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$DeferredAttrNode$StructuralStuckChecker.canLambdaBodyCompleteNormally(DeferredAttr.java:900) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$DeferredAttrNode$StructuralStuckChecker.visitLambda(DeferredAttr.java:878) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1811) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$DeferredAttrNode$StructuralStuckChecker.complete(DeferredAttr.java:832) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$DeferredType.check(DeferredAttr.java:335) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$DeferredAttrNode.process(DeferredAttr.java:779) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$DeferredAttrContext.complete(DeferredAttr.java:626) at jdk.compiler/com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:620) at jdk.compiler/com.sun.tools.javac.comp.Resolve.selectBest(Resolve.java:1563) at jdk.compiler/com.sun.tools.javac.comp.Resolve.findMethodInScope(Resolve.java:1733) at jdk.compiler/com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1802) at jdk.compiler/com.sun.tools.javac.comp.Resolve.findMethod(Resolve.java:1776) at jdk.compiler/com.sun.tools.javac.comp.Resolve$10.doLookup(Resolve.java:2654) at jdk.compiler/com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(Resolve.java:3293) at jdk.compiler/com.sun.tools.javac.comp.Resolve.lookupMethod(Resolve.java:3543) at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(Resolve.java:2651) at jdk.compiler/com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(Resolve.java:2645) at jdk.compiler/com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3721) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3601) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2114) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2006) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:695) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitVarDef(Attr.java:1174) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:956) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:724) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:743) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitLambda(Attr.java:2598) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1811) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$4.complete(DeferredAttr.java:374) at jdk.compiler/com.sun.tools.javac.comp.ArgumentAttr$ArgumentType.complete(ArgumentAttr.java:364) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$DeferredType.check(DeferredAttr.java:335) at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr$DeferredType.check(DeferredAttr.java:321) at jdk.compiler/com.sun.tools.javac.comp.Resolve$MethodResultInfo.check(Resolve.java:1060) at jdk.compiler/com.sun.tools.javac.comp.Resolve$4.checkArg(Resolve.java:887) at jdk.compiler/com.sun.tools.javac.comp.Resolve$AbstractMethodCheck.argumentsAcceptable(Resolve.java:775) at jdk.compiler/com.sun.tools.javac.comp.Resolve$4.argumentsAcceptable(Resolve.java:896) at jdk.compiler/com.sun.tools.javac.comp.Infer.instantiateMethod(Infer.java:181) at jdk.compiler/com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:605) at jdk.compiler/com.sun.tools.javac.comp.Resolve.checkMethod(Resolve.java:644) at jdk.compiler/com.sun.tools.javac.comp.Attr.checkMethod(Attr.java:4120) at jdk.compiler/com.sun.tools.javac.comp.Attr.checkIdInternal(Attr.java:3913) at jdk.compiler/com.sun.tools.javac.comp.Attr.checkMethodIdInternal(Attr.java:3814) at jdk.compiler/com.sun.tools.javac.comp.Attr.checkId(Attr.java:3803) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3696) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2114) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitApply(Attr.java:2006) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitReturn(Attr.java:1866) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1546) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:724) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:743) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1294) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:724) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1098) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:724) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:4683) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4574) at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4503) at jdk.compiler/com.sun.tools.javac.comp.Attr.attrib(Attr.java:4448) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1341) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:147) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94) at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174) at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1134) at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:187) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) at org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347) at org.codehaus.classworlds.Launcher.main(Launcher.java:47) From adam.sotona at oracle.com Mon Jun 8 20:31:41 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 8 Jun 2020 22:31:41 +0200 Subject: RFR: 8236108 tools/javac/lambda/LambdaParserTest.java timed out In-Reply-To: <58F620C3-6B8D-4C12-8625-F62AAA635607@oracle.com> References: <58F620C3-6B8D-4C12-8625-F62AAA635607@oracle.com> Message-ID: <1265D531-5497-4230-B7C2-DE546D7E6882@oracle.com> Hi, First thanks for the feedback in the JDK-8236108. I would like to ask for review of a new patch for the time-outing LambdaParserTest. The patch filters redundant or non-sense combinations of lambdas and it reduces the number of performed sub-tests from 573 696 to 285 334, which should be suitable to fit into a default timeout even on slow or busy machines. Filtered are: - several combinations of parentheses, which generated the same source code (in combination with empty sub-expression) - all combinations of non-empty lambda sub-expressions with lambda statements, which generated non-sense source code - all parameters not used in the actual lambda expression template, which also generated the same source code multiple times JBS: https://bugs.openjdk.java.net/browse/JDK-8236108 webrev: http://cr.openjdk.java.net/~asotona/8236108/webrev.01/ Thanks for the review, Adam > On 2 Jun 2020, at 15:41, Adam Sotona wrote: > > Hi, > I would like to ask for review of LambdaParserTest.java timed out fix. > This particular test is very complex and intensive. > It includes 573696 test actions, each parsing a source fragment. > As this single test takes on my powerful machine approx. 1 minute and the default timeout is 2 minutes, so I can imagine situations where it timeouts. > > Target machine scale factor was 4, so the default timeout was 480s, however the test elapsed time was 523s. > > Proposed patch extends the timeout by 50% to 180s, so multiplied by the machine-specific timeout scale factor it will give enough time to finish successfully. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8236108 > webrev: http://cr.openjdk.java.net/~asotona/8236108/webrev.00/ > > The test is a part of Tier 4 and it is passing for me even without the extended timeout, so I cannot practically verify the patch effectivity unless it fails. > > Thanks, > Adam From vicente.romero at oracle.com Mon Jun 8 20:34:33 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 8 Jun 2020 16:34:33 -0400 Subject: RFR: 8236108 tools/javac/lambda/LambdaParserTest.java timed out In-Reply-To: <58F620C3-6B8D-4C12-8625-F62AAA635607@oracle.com> References: <58F620C3-6B8D-4C12-8625-F62AAA635607@oracle.com> Message-ID: <916c20d4-df4a-583d-0d15-76e5ab876560@oracle.com> Hi Adam, webrev.01 looks good to me, Thanks, Vicente On 6/2/20 9:41 AM, Adam Sotona wrote: > Hi, > I would like to ask for review of LambdaParserTest.java timed out fix. > This particular test is very complex and intensive. > It includes 573696 test actions, each parsing a source fragment. > As this single test takes on my powerful machine approx. 1 minute and the default timeout is 2 minutes, so I can imagine situations where it timeouts. > > Target machine scale factor was 4, so the default timeout was 480s, however the test elapsed time was 523s. > > Proposed patch extends the timeout by 50% to 180s, so multiplied by the machine-specific timeout scale factor it will give enough time to finish successfully. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8236108 > webrev: http://cr.openjdk.java.net/~asotona/8236108/webrev.00/ > > The test is a part of Tier 4 and it is passing for me even without the extended timeout, so I cannot practically verify the patch effectivity unless it fails. > > Thanks, > Adam From adam.sotona at oracle.com Mon Jun 8 20:43:55 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 8 Jun 2020 22:43:55 +0200 Subject: RFR: 8236108 tools/javac/lambda/LambdaParserTest.java timed out In-Reply-To: <916c20d4-df4a-583d-0d15-76e5ab876560@oracle.com> References: <58F620C3-6B8D-4C12-8625-F62AAA635607@oracle.com> <916c20d4-df4a-583d-0d15-76e5ab876560@oracle.com> Message-ID: <3C32F616-20E1-49B4-A1E7-B5E7DDB4D643@oracle.com> Thanks for the review, Adam > On 8 Jun 2020, at 22:34, Vicente Romero wrote: > > Hi Adam, > > webrev.01 looks good to me, > > Thanks, > Vicente > > On 6/2/20 9:41 AM, Adam Sotona wrote: >> Hi, >> I would like to ask for review of LambdaParserTest.java timed out fix. >> This particular test is very complex and intensive. >> It includes 573696 test actions, each parsing a source fragment. >> As this single test takes on my powerful machine approx. 1 minute and the default timeout is 2 minutes, so I can imagine situations where it timeouts. >> >> Target machine scale factor was 4, so the default timeout was 480s, however the test elapsed time was 523s. >> >> Proposed patch extends the timeout by 50% to 180s, so multiplied by the machine-specific timeout scale factor it will give enough time to finish successfully. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8236108 >> webrev: http://cr.openjdk.java.net/~asotona/8236108/webrev.00/ >> >> The test is a part of Tier 4 and it is passing for me even without the extended timeout, so I cannot practically verify the patch effectivity unless it fails. >> >> Thanks, >> Adam > From maurizio.cimadamore at oracle.com Mon Jun 8 20:54:47 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 8 Jun 2020 21:54:47 +0100 Subject: BUG: local type inference -> symbol not found In-Reply-To: References: Message-ID: It would be interesting to know what is the inferred type for `someDao` - here's a dirty trick that you can use to let the compiler cough that up: final var someDao = ... String s = (String)someDao; This should hopefully cause a type mismatch and the compiler should tell you which type it tried to convert to String. I'm suspecting that this type might be a non-denotable type (e.g. anonymous class type, or intersection type) - which might be something that might trip javac up? when used as a method reference receivers? Maurizio On 08/06/2020 20:34, Sietse Au wrote: > > Hi, > > I've run into a compilation error on OpenJDK 11.06 (see attachment) > where there?is some interaction between local type?inference and > method reference. > > Haven't been able to create a clean project to reproduce the problem. > > Inside a larger code-base it is reproducible: > > final var someDao = ... > someRequest.map(item -> SomeBuilder.builder() > ? ?... > ? ?.build() > ).forEach(someDao::create); > > the combination of the local type inference `final var` and the > `someDao::create`?method reference lead to the stacktrace?in the > attachment. > > When we rewrite the?above to not use type inference and declare the > type explicitly: > final SomeDao someDao?= ... > > OR > > rewrite the forEach not using the method reference: > forEach(x -> someDao.create(x)) > > the code compiles. > > As the stack trace itself was kind of unhelpful, hooking up to a > debugger found that when the code hits `someDao::create` a > SymbolNotFound error is thrown. > > > Best regards, > -- > Sietse Au > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sietse.au at booking.com Tue Jun 9 12:49:55 2020 From: sietse.au at booking.com (Sietse Au) Date: Tue, 9 Jun 2020 14:49:55 +0200 Subject: [External] Re: BUG: local type inference -> symbol not found In-Reply-To: References: Message-ID: I've created a small project where the problem can be reproduced consistently: https://github.com/stau-booking/jdk11-reproduce-type-infer-bug In this case the inferred type in the project is still `Anything`. On Mon, Jun 8, 2020 at 10:55 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > It would be interesting to know what is the inferred type for `someDao` - > here's a dirty trick that you can use to let the compiler cough that up: > > final var someDao = ... > String s = (String)someDao; > > This should hopefully cause a type mismatch and the compiler should tell > you which type it tried to convert to String. > > I'm suspecting that this type might be a non-denotable type (e.g. > anonymous class type, or intersection type) - which might be something that > might trip javac up when used as a method reference receivers? > > Maurizio > On 08/06/2020 20:34, Sietse Au wrote: > > > Hi, > > I've run into a compilation error on OpenJDK 11.06 (see attachment) where > there is some interaction between local type inference and method > reference. > > Haven't been able to create a clean project to reproduce the problem. > > Inside a larger code-base it is reproducible: > > final var someDao = ... > someRequest.map(item -> SomeBuilder.builder() > ... > .build() > ).forEach(someDao::create); > > the combination of the local type inference `final var` and the > `someDao::create` method reference lead to the stacktrace in the attachment. > > When we rewrite the above to not use type inference and declare the type > explicitly: > final SomeDao someDao = ... > > OR > > rewrite the forEach not using the method reference: > forEach(x -> someDao.create(x)) > > the code compiles. > > As the stack trace itself was kind of unhelpful, hooking up to a debugger > found that when the code hits `someDao::create` a SymbolNotFound error is > thrown. > > > Best regards, > -- > Sietse Au > > -- Sietse Au -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Jun 9 13:13:26 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Jun 2020 14:13:26 +0100 Subject: [External] Re: BUG: local type inference -> symbol not found In-Reply-To: References: Message-ID: <7082077e-709f-c59c-6b19-41e967184d73@oracle.com> Hi - I've managed to reproduce; it seems a duplicate of this bug: https://bugs.openjdk.java.net/browse/JDK-8210483 That said, JIRA says this bug has been fixed in 11.04, so I'm not sure why you are seeing it. On my ubuntu, which comes with 11.06 the bug cannot be reproduced, and I have to use an older JDK 11 build to do that. To reproduce I've created this single file: import java.util.function.*; class Handle { ??? public? T attach(Class extensionType) { return null; } } class BugReproduction { ? public void doesNotCompile() { ??? final Anything anything = null; ??? anything.executeOuter(() -> { ????? anything.executeInner((handle) -> { ??????? final var inferredAnything = handle.attach(Anything.class); ??????? consume(inferredAnything::create); ??????? return null; ????? }); ????? return null; ??? }); ? } ? public void consume(Consumer noop) { ??? noop.accept(1L); ? } } interface Anything { ? Long create(Long object); ? default T executeOuter(final Supplier callback) { ??? return callback.get(); ? } ? default Long executeInner(Function onSuccess) { ??? return onSuccess.apply(null); ? } } Maurizio On 09/06/2020 13:49, Sietse Au wrote: > I've created a small project where the problem can be reproduced > consistently: > https://github.com/stau-booking/jdk11-reproduce-type-infer-bug > > In this case the inferred type in the project is still `Anything`. > > On Mon, Jun 8, 2020 at 10:55 PM Maurizio Cimadamore > > wrote: > > It would be interesting to know what is the inferred type for > `someDao` - here's a dirty trick that you can use to let the > compiler cough that up: > > final var someDao = ... > String s = (String)someDao; > > This should hopefully cause a type mismatch and the compiler > should tell you which type it tried to convert to String. > > I'm suspecting that this type might be a non-denotable type (e.g. > anonymous class type, or intersection type) - which might be > something that might trip javac up? when used as a method > reference receivers? > > Maurizio > > On 08/06/2020 20:34, Sietse Au wrote: >> >> Hi, >> >> I've run into a compilation error on OpenJDK 11.06 (see >> attachment) where there?is some interaction between local >> type?inference and method reference. >> >> Haven't been able to create a clean project to reproduce the problem. >> >> Inside a larger code-base it is reproducible: >> >> final var someDao = ... >> someRequest.map(item -> SomeBuilder.builder() >> ? ?... >> ? ?.build() >> ).forEach(someDao::create); >> >> the combination of the local type inference `final var` and the >> `someDao::create`?method reference lead to the stacktrace?in the >> attachment. >> >> When we rewrite the?above to not use type inference and declare >> the type explicitly: >> final SomeDao someDao?= ... >> >> OR >> >> rewrite the forEach not using the method reference: >> forEach(x -> someDao.create(x)) >> >> the code compiles. >> >> As the stack trace itself was kind of unhelpful, hooking up to a >> debugger found that when the code hits `someDao::create` a >> SymbolNotFound error is thrown. >> >> >> Best regards, >> -- >> Sietse Au >> > > > -- > Sietse Au -------------- next part -------------- An HTML attachment was scrubbed... URL: From sietse.au at booking.com Tue Jun 9 14:17:11 2020 From: sietse.au at booking.com (Sietse Au) Date: Tue, 9 Jun 2020 16:17:11 +0200 Subject: [External] Re: BUG: local type inference -> symbol not found In-Reply-To: <7082077e-709f-c59c-6b19-41e967184d73@oracle.com> References: <7082077e-709f-c59c-6b19-41e967184d73@oracle.com> Message-ID: That's indeed strange. javac Test.java An exception has occurred in the compiler (11.0.6). Please file a bug against the Java compiler via the Java bug reporting page ( http://bugreport.java.com) after checking the Bug Database ( http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. I'm on archlinux, I can see that on 11.0.7 the problem is gone: https://www.archlinux.org/packages/extra/x86_64/jdk11-openjdk/ However https://git.archlinux.org/svntogit/packages.git/diff/trunk?h=packages/java11-openjdk&id=2465fb7c7852484ea8c6649e30e0f2ff82130a73 Seems like the source was: https://hg.openjdk.java.net/jdk-updates/jdk11u/archive/jdk-11.0.6+10.tar.gz Building this from scratch yields the same results: x86_64-normal-server-release/jdk/bin % ./javac ~/Test.java An exception has occurred in the compiler (11.0.6). Please file a bug against the Java compiler via the Java bug reporting page ( http://bugreport.java.com) after checking the Bug Database ( http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. On Tue, Jun 9, 2020 at 3:13 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi - I've managed to reproduce; it seems a duplicate of this bug: > > https://bugs.openjdk.java.net/browse/JDK-8210483 > > > That said, JIRA says this bug has been fixed in 11.04, so I'm not sure why > you are seeing it. > > On my ubuntu, which comes with 11.06 the bug cannot be reproduced, and I > have to use an older JDK 11 build to do that. > > To reproduce I've created this single file: > > import java.util.function.*; > > class Handle { > public T attach(Class extensionType) { return null; } > } > > > class BugReproduction { > > > public void doesNotCompile() { > final Anything anything = null; > > anything.executeOuter(() -> { > anything.executeInner((handle) -> { > final var inferredAnything = handle.attach(Anything.class); > consume(inferredAnything::create); > return null; > }); > return null; > }); > } > > public void consume(Consumer noop) { > noop.accept(1L); > } > > } > > interface Anything { > > Long create(Long object); > > default T executeOuter(final Supplier callback) { > return callback.get(); > } > > default Long executeInner(Function onSuccess) { > return onSuccess.apply(null); > } > } > > > Maurizio > On 09/06/2020 13:49, Sietse Au wrote: > > I've created a small project where the problem can be reproduced > consistently: > https://github.com/stau-booking/jdk11-reproduce-type-infer-bug > > > In this case the inferred type in the project is still `Anything`. > > On Mon, Jun 8, 2020 at 10:55 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> It would be interesting to know what is the inferred type for `someDao` - >> here's a dirty trick that you can use to let the compiler cough that up: >> >> final var someDao = ... >> String s = (String)someDao; >> >> This should hopefully cause a type mismatch and the compiler should tell >> you which type it tried to convert to String. >> >> I'm suspecting that this type might be a non-denotable type (e.g. >> anonymous class type, or intersection type) - which might be something that >> might trip javac up when used as a method reference receivers? >> >> Maurizio >> On 08/06/2020 20:34, Sietse Au wrote: >> >> >> Hi, >> >> I've run into a compilation error on OpenJDK 11.06 (see attachment) where >> there is some interaction between local type inference and method >> reference. >> >> Haven't been able to create a clean project to reproduce the problem. >> >> Inside a larger code-base it is reproducible: >> >> final var someDao = ... >> someRequest.map(item -> SomeBuilder.builder() >> ... >> .build() >> ).forEach(someDao::create); >> >> the combination of the local type inference `final var` and the >> `someDao::create` method reference lead to the stacktrace in the attachment. >> >> When we rewrite the above to not use type inference and declare the type >> explicitly: >> final SomeDao someDao = ... >> >> OR >> >> rewrite the forEach not using the method reference: >> forEach(x -> someDao.create(x)) >> >> the code compiles. >> >> As the stack trace itself was kind of unhelpful, hooking up to a debugger >> found that when the code hits `someDao::create` a SymbolNotFound error is >> thrown. >> >> >> Best regards, >> -- >> Sietse Au >> >> > > -- > Sietse Au > > -- Sietse Au -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Jun 9 14:55:27 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Jun 2020 15:55:27 +0100 Subject: [External] Re: BUG: local type inference -> symbol not found In-Reply-To: References: <7082077e-709f-c59c-6b19-41e967184d73@oracle.com> Message-ID: Mystery solved. First I did not check the version correctly on my machine; my Ubuntu has 11.0.7, not 11.0.6 as previously stated. So what I'm getting is consistent with your findings. There was a followup fix, for a similar problem which was backported in 11.0.7: https://bugs.openjdk.java.net/browse/JDK-8213908 I think this is the variant which ultimately hit you. Cheers Maurizio On 09/06/2020 15:17, Sietse Au wrote: > That's indeed strange. > > javac Test.java > An exception has occurred in the compiler (11.0.6). Please file a bug > against the Java compiler via the Java bug reporting page > (http://bugreport.java.com) after checking the Bug Database > (http://bugs.java.com) for duplicates. Include your program and the > following diagnostic in your report. Thank you. > > I'm on archlinux, I can see that on 11.0.7 the problem is gone: > https://www.archlinux.org/packages/extra/x86_64/jdk11-openjdk/ > > However > https://git.archlinux.org/svntogit/packages.git/diff/trunk?h=packages/java11-openjdk&id=2465fb7c7852484ea8c6649e30e0f2ff82130a73 > > Seems like the source was: > https://hg.openjdk.java.net/jdk-updates/jdk11u/archive/jdk-11.0.6+10.tar.gz > > Building this from scratch yields the same results: > x86_64-normal-server-release/jdk/bin % ./javac ~/Test.java > An exception has occurred in the compiler (11.0.6). Please file a bug > against the Java compiler via the Java bug reporting page > (http://bugreport.java.com) after checking the Bug Database > (http://bugs.java.com) for duplicates. Include your program and the > following diagnostic in your report. Thank you. > > > On Tue, Jun 9, 2020 at 3:13 PM Maurizio Cimadamore > > wrote: > > Hi - I've managed to reproduce; it seems a duplicate of this bug: > > https://bugs.openjdk.java.net/browse/JDK-8210483 > > > That said, JIRA says this bug has been fixed in 11.04, so I'm not > sure why you are seeing it. > > On my ubuntu, which comes with 11.06 the bug cannot be reproduced, > and I have to use an older JDK 11 build to do that. > > To reproduce I've created this single file: > > import java.util.function.*; > > class Handle { > ??? public? T attach(Class extensionType) { return null; } > } > > > class BugReproduction { > > > ? public void doesNotCompile() { > ??? final Anything anything = null; > > ??? anything.executeOuter(() -> { > ????? anything.executeInner((handle) -> { > ??????? final var inferredAnything = handle.attach(Anything.class); > ??????? consume(inferredAnything::create); > ??????? return null; > ????? }); > ????? return null; > ??? }); > ? } > > ? public void consume(Consumer noop) { > ??? noop.accept(1L); > ? } > > } > > interface Anything { > > ? Long create(Long object); > > ? default T executeOuter(final Supplier callback) { > ??? return callback.get(); > ? } > > ? default Long executeInner(Function onSuccess) { > ??? return onSuccess.apply(null); > ? } > } > > > Maurizio > > On 09/06/2020 13:49, Sietse Au wrote: >> I've created a small project where the problem can be reproduced >> consistently: >> https://github.com/stau-booking/jdk11-reproduce-type-infer-bug >> >> >> In this case the inferred type in the project is still `Anything`. >> >> On Mon, Jun 8, 2020 at 10:55 PM Maurizio Cimadamore >> > > wrote: >> >> It would be interesting to know what is the inferred type for >> `someDao` - here's a dirty trick that you can use to let the >> compiler cough that up: >> >> final var someDao = ... >> String s = (String)someDao; >> >> This should hopefully cause a type mismatch and the compiler >> should tell you which type it tried to convert to String. >> >> I'm suspecting that this type might be a non-denotable type >> (e.g. anonymous class type, or intersection type) - which >> might be something that might trip javac up? when used as a >> method reference receivers? >> >> Maurizio >> >> On 08/06/2020 20:34, Sietse Au wrote: >>> >>> Hi, >>> >>> I've run into a compilation error on OpenJDK 11.06 (see >>> attachment) where there?is some interaction between local >>> type?inference and method reference. >>> >>> Haven't been able to create a clean project to reproduce the >>> problem. >>> >>> Inside a larger code-base it is reproducible: >>> >>> final var someDao = ... >>> someRequest.map(item -> SomeBuilder.builder() >>> ? ?... >>> ? ?.build() >>> ).forEach(someDao::create); >>> >>> the combination of the local type inference `final var` and >>> the `someDao::create`?method reference lead to the >>> stacktrace?in the attachment. >>> >>> When we rewrite the?above to not use type inference and >>> declare the type explicitly: >>> final SomeDao someDao?= ... >>> >>> OR >>> >>> rewrite the forEach not using the method reference: >>> forEach(x -> someDao.create(x)) >>> >>> the code compiles. >>> >>> As the stack trace itself was kind of unhelpful, hooking up >>> to a debugger found that when the code hits >>> `someDao::create` a SymbolNotFound error is thrown. >>> >>> >>> Best regards, >>> -- >>> Sietse Au >>> >> >> >> -- >> Sietse Au > > > > -- > Sietse Au -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jun 9 17:05:17 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 9 Jun 2020 13:05:17 -0400 Subject: RFR: JDK-8246257: Annotated record's vararg type component started to be uncompilable with JDK15b24 Message-ID: Hi, Please review fix for [1] at [2]. If a record component is declared as a varargs, then the corresponding argument in the canonical constructor needs to be a varargs too. This assertion is failing in the case the record component has annotations. This is because the corresponding array type was being recreated to attach the annotations but the fact that it was a varargs wasn't being preserved. This patch fixes that issue, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8246257 [2] http://cr.openjdk.java.net/~vromero/8246257/webrev.00/ From vicente.romero at oracle.com Tue Jun 9 18:01:06 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 9 Jun 2020 14:01:06 -0400 Subject: RFR: JDK-8235564: javac crashes while compiling incorrect method invocation with member reference In-Reply-To: <034456a7-344c-b8fc-8031-6f1de1c02ae1@oracle.com> References: <89d4c27c-fcad-62e1-69a9-cdd67d4ccd49@oracle.com> <4803842f-aa7a-e853-e89b-9058bd81aa89@oracle.com> <04197993-4c72-efb1-e0c3-9eccdf868d85@oracle.com> <034456a7-344c-b8fc-8031-6f1de1c02ae1@oracle.com> Message-ID: looks good, Vicente On 6/8/20 9:35 AM, Jan Lahoda wrote: > Hi, > > Updated patch which will only check whether the type is a functional > interface for lambdas and member references. Full updated patch: > http://cr.openjdk.java.net/~jlahoda/8235564/webrev.01/ > > Delta from previous patch: > http://cr.openjdk.java.net/~jlahoda/8235564/webrev.delta.00-01/ > > Does this look OK? > > Thanks, > ??? Jan > > On 05. 06. 20 21:51, Vicente Romero wrote: >> sounds good, >> >> Thanks, >> Vicente >> >> On 6/5/20 3:04 PM, Jan Lahoda wrote: >>> Hi Vicente, >>> >>> On 05. 06. 20 20:22, Vicente Romero wrote: >>>> Hi, >>>> >>>> looks good, my only question is if this: >>>> >>>> Type ptRecovery = pt != null && types.isFunctionalInterface(pt) ? >>>> pt : Type.recoveryType; >>>> >>>> >>>> wont be a too strict semantic change, but given that this is >>>> recovery code anyway I guess that users won't see a difference in >>>> the printed diagnostics, >>> >>> Thanks for the comment! >>> >>> I guess you might be right - I'll limit check for the function >>> interface only to DeferredTypes that represent lambdas and member >>> references (where we really need a functional target type). Will >>> send a new webrev early next week. >>> >>> Thanks, >>> ??? Jan >>> >>>> >>>> Vicente >>>> >>>> On 6/5/20 11:20 AM, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> Consider code like: >>>>> public class Test { >>>>> ??? static void test() { >>>>> ??????? existingWithoutFunctional(Test::undefined); >>>>> ??? } >>>>> >>>>> ??? private static void existingWithoutFunctional(String >>>>> parameter) {} >>>>> } >>>>> >>>>> javac crashes on this (please see the bug for the stack trace). >>>>> The reason for this is that while there are two errors in the >>>>> source code: a) passing member reference to a parameter that is >>>>> not of a functional type; b) the member reference refers to a >>>>> method that does not exist, no error is reported. The first error >>>>> is suppressed because the parameter is erroneous, and it is >>>>> expected an error was already issued for it (this is fine). >>>>> >>>>> The second error is mostly accidentally suppressed because >>>>> Attr.visitReference will get "String" and pt(), and hence >>>>> getTargetInfo() will fail to find the functional type, and most of >>>>> the processing/verification is skipped, and this causes the >>>>> problem. The problem is while doing recovery >>>>> DeferredAttr.RecoveryDeferredTypeMap.recover will use the >>>>> non-functional formal parameter type as the expected target type. >>>>> This was an attempt to improve error recovery, but seems to go too >>>>> far. The proposal is to use the formal parameter type only if it >>>>> is a functional type. >>>>> >>>>> As a result, for the example above, the javac reponse will be: >>>>> $ javac Test.java >>>>> Test.java:3: error: invalid method reference >>>>> ??????? existingWithoutFunctional(Test::undefined); >>>>> ????????????????????????????????? ^ >>>>> ? cannot find symbol >>>>> ??? symbol:?? method undefined() >>>>> ??? location: class Test >>>>> 1 error >>>>> >>>>> Which is the same as in JDK 11. >>>>> cr.openjdk.java.net/~jlahoda/8235564/webrev.00/ >>>>> >>>>> Proposed webrev: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235564 >>>>> >>>>> How does this look? >>>>> >>>>> Thanks, >>>>> ??? Jan >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >> From behrangsa at gmail.com Wed Jun 10 14:27:27 2020 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Thu, 11 Jun 2020 00:27:27 +1000 Subject: Add an option to javac to disable inlining of static final variables (to be used by programmers during development phase) Message-ID: Hi, I guess inlining of static variables [1] is one of the main causes that during our day to day coding activities, we have to do a full recompile (e.g. `mvn clean ...`) every time a constant that is referenced throughout the code is changed. There are a few ugly tricks to prevent the constants from getting inlined, but a compiler option that we can pass to javac that produces a warning message that can be used while we program locally could reduce the need to run `mvn clean ...`, `gradle clean ...`, etc. Another option could be [2] adding some metadata to classes that reference constants to record where the constant is coming from that could allow build tools recompile all such classes when the constant changes. [1] https://docs.oracle.com/javase/specs/jls/se14/html/jls-13.html#jls-13.4.9. [2] If the class file format permits that. -- Best regards, Behrang Saeedzadeh -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Jun 10 15:04:10 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 10 Jun 2020 17:04:10 +0200 (CEST) Subject: Add an option to javac to disable inlining of static final variables (to be used by programmers during development phase) In-Reply-To: References: Message-ID: <1818852709.2015969.1591801450448.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Behrang Saeedzadeh" > ?: "compiler-dev" , "discuss" > Envoy?: Mercredi 10 Juin 2020 16:27:27 > Objet: Add an option to javac to disable inlining of static final variables (to be used by programmers during > development phase) > Hi, Hi, > > I guess inlining of static variables [1] is one of the main causes that > during our day to day coding activities, we have to do a full recompile > (e.g. `mvn clean ...`) every time a constant that is referenced throughout > the code is changed. > > There are a few ugly tricks to prevent the constants from getting inlined, > but a compiler option that we can pass to javac that produces a warning > message that can be used while we program locally could reduce the need to > run `mvn clean ...`, `gradle clean ...`, etc. > > Another option could be [2] adding some metadata to classes that reference > constants to record where the constant is coming from that could allow > build tools recompile all such classes when the constant changes. > [1] > https://docs.oracle.com/javase/specs/jls/se14/html/jls-13.html#jls-13.4.9. > [2] If the class file format permits that. It's already done by javac, it register all the classes of the static final fields it depends in the constant pool (the dictionary pat of the classfile format). Gradle (the recent versions) uses this information but not Maven, so the question is more how to improve Maven to compute the graph of dependencies at the file level. There is also a kind of quick hack if you have a multi-modules project, you can read the module-info.java to get the graph of modules to find the dependency at module level, you can then use javac to read the module-info.java and the JDK API to create the module and let the JDK resolve the graph for you. The build of the OpenJDK does that with great success. > > > -- > Best regards, > Behrang Saeedzadeh regards, R?mi From jan.lahoda at oracle.com Wed Jun 10 16:24:19 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 10 Jun 2020 18:24:19 +0200 Subject: RFR: JDK-8247334: Trees.getScope crashes for annotated local records Message-ID: <20dfbae6-ba4b-246c-36c8-c0478e0654c2@oracle.com> Hi, Consider code like this: --- class Test { void t() { record R(@Annotation int i) {} } } @interface Annotation {} --- Calling Trees.getScope for a TreePath pointing at @Annotation in "@Annotation int i" will crash with an exception. The reason is that when the class is first attributed, a synthetic canonical constructor is created for the record. And when the scope is being computed, a copy of the method's body is created (including the synthetic constructor), and re-attributed. And, since this is a record, the constructors are entered first, then a default constructor is possibly created, and then members not entered in the first phase are entered. But the detection of these "other members" fails to detect the default constructor was already entered in the first phase, and as a consequence this default constructor is entered twice, which ultimately leads to the exception. The proposed solution is to simply keep track if a constructor has been added and avoid entering any constructor except the added one during the second stage. I was trying other fix directions, but those typically changed the order of members, either in Element.getEnclosedElements() or in the classfile, which seemed inappropriate for this fix. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8247334/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8247334 How does this look? Thanks! Jan From vicente.romero at oracle.com Wed Jun 10 17:44:52 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 10 Jun 2020 13:44:52 -0400 Subject: RFR: JDK-8247334: Trees.getScope crashes for annotated local records In-Reply-To: <20dfbae6-ba4b-246c-36c8-c0478e0654c2@oracle.com> References: <20dfbae6-ba4b-246c-36c8-c0478e0654c2@oracle.com> Message-ID: <9c594e84-ffdb-789d-35f4-db25c3ae24ec@oracle.com> looks good, Vicente On 6/10/20 12:24 PM, Jan Lahoda wrote: > Hi, > > Consider code like this: > --- > class Test { > ??? void t() { > ??????? record R(@Annotation int i) {} > ??? } > } > @interface Annotation {} > --- > > Calling Trees.getScope for a TreePath pointing at @Annotation in > "@Annotation int i" will crash with an exception. > > The reason is that when the class is first attributed, a synthetic > canonical constructor is created for the record. And when the scope is > being computed, a copy of the method's body is created (including the > synthetic constructor), and re-attributed. And, since this is a > record, the constructors are entered first, then a default constructor > is possibly created, and then members not entered in the first phase > are entered. But the detection of these "other members" fails to > detect the default constructor was already entered in the first phase, > and as a consequence this default constructor is entered twice, which > ultimately leads to the exception. > > The proposed solution is to simply keep track if a constructor has > been added and avoid entering any constructor except the added one > during the second stage. > > I was trying other fix directions, but those typically changed the > order of members, either in Element.getEnclosedElements() or in the > classfile, which seemed inappropriate for this fix. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8247334/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8247334 > > How does this look? > > Thanks! > ??? Jan > From vicente.romero at oracle.com Wed Jun 10 17:46:33 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 10 Jun 2020 13:46:33 -0400 Subject: RFR: JDK-8247334: Trees.getScope crashes for annotated local records In-Reply-To: <20dfbae6-ba4b-246c-36c8-c0478e0654c2@oracle.com> References: <20dfbae6-ba4b-246c-36c8-c0478e0654c2@oracle.com> Message-ID: Hi, Sorry I hit the send button too fast. Why is this only happening to local records? in any case could you please add a similar test for a non local record just to cover it? Thanks, Vicente On 6/10/20 12:24 PM, Jan Lahoda wrote: > Hi, > > Consider code like this: > --- > class Test { > ??? void t() { > ??????? record R(@Annotation int i) {} > ??? } > } > @interface Annotation {} > --- > > Calling Trees.getScope for a TreePath pointing at @Annotation in > "@Annotation int i" will crash with an exception. > > The reason is that when the class is first attributed, a synthetic > canonical constructor is created for the record. And when the scope is > being computed, a copy of the method's body is created (including the > synthetic constructor), and re-attributed. And, since this is a > record, the constructors are entered first, then a default constructor > is possibly created, and then members not entered in the first phase > are entered. But the detection of these "other members" fails to > detect the default constructor was already entered in the first phase, > and as a consequence this default constructor is entered twice, which > ultimately leads to the exception. > > The proposed solution is to simply keep track if a constructor has > been added and avoid entering any constructor except the added one > during the second stage. > > I was trying other fix directions, but those typically changed the > order of members, either in Element.getEnclosedElements() or in the > classfile, which seemed inappropriate for this fix. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8247334/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8247334 > > How does this look? > > Thanks! > ??? Jan > From vicente.romero at oracle.com Wed Jun 10 19:23:17 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 10 Jun 2020 15:23:17 -0400 Subject: RFR: JDK-8246257: Annotated record's vararg type component started to be uncompilable with JDK15b24 In-Reply-To: References: Message-ID: <86e0c2bc-338d-e10a-37a8-f8fa56d94fb3@oracle.com> ping On 6/9/20 1:05 PM, Vicente Romero wrote: > Hi, > > Please review fix for [1] at [2]. If a record component is declared as > a varargs, then the corresponding argument in the canonical > constructor needs to be a varargs too. This assertion is failing in > the case the record component has annotations. This is because the > corresponding array type was being recreated to attach the annotations > but the fact that it was a varargs wasn't being preserved. This patch > fixes that issue, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8246257 > [2] http://cr.openjdk.java.net/~vromero/8246257/webrev.00/ From jan.lahoda at oracle.com Wed Jun 10 20:07:15 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 10 Jun 2020 22:07:15 +0200 Subject: RFR: JDK-8247334: Trees.getScope crashes for annotated local records In-Reply-To: References: <20dfbae6-ba4b-246c-36c8-c0478e0654c2@oracle.com> Message-ID: Hi Vicente, On 10. 06. 20 19:46, Vicente Romero wrote: > Hi, > > Sorry I hit the send button too fast. Why is this only happening to > local records? in any case could you please add a similar test for a non Thanks for the comment. I don't think this can happen for records that are not local, because the scopes are computed differently - for code inside method bodies (and variable initializers), a copy of the code is created and re-attributed; for other points in the program, either an existing scope (Env) is used, (Enter.getClassEnv for classes), or a scope is synthetized without re-attributing the code, like for methods MemberEnter.getMethodEnv, or Enter.getTopLevelEnv. I've added another test case for top-level record (the content of the resulting scope is a little different, which is due to the differences in the scope construction, and is the same for classes). Delta webrev: http://cr.openjdk.java.net/~jlahoda/8247334/webrev.delta.00-01/ Full webrev: http://cr.openjdk.java.net/~jlahoda/8247334/webrev.01/ What do you think? Thanks, Jan > local record just to cover it? > > Thanks, > Vicente > > On 6/10/20 12:24 PM, Jan Lahoda wrote: >> Hi, >> >> Consider code like this: >> --- >> class Test { >> ??? void t() { >> ??????? record R(@Annotation int i) {} >> ??? } >> } >> @interface Annotation {} >> --- >> >> Calling Trees.getScope for a TreePath pointing at @Annotation in >> "@Annotation int i" will crash with an exception. >> >> The reason is that when the class is first attributed, a synthetic >> canonical constructor is created for the record. And when the scope is >> being computed, a copy of the method's body is created (including the >> synthetic constructor), and re-attributed. And, since this is a >> record, the constructors are entered first, then a default constructor >> is possibly created, and then members not entered in the first phase >> are entered. But the detection of these "other members" fails to >> detect the default constructor was already entered in the first phase, >> and as a consequence this default constructor is entered twice, which >> ultimately leads to the exception. >> >> The proposed solution is to simply keep track if a constructor has >> been added and avoid entering any constructor except the added one >> during the second stage. >> >> I was trying other fix directions, but those typically changed the >> order of members, either in Element.getEnclosedElements() or in the >> classfile, which seemed inappropriate for this fix. >> >> Proposed webrev: >> http://cr.openjdk.java.net/~jlahoda/8247334/webrev.00/ >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8247334 >> >> How does this look? >> >> Thanks! >> ??? Jan >> > From jonathan.gibbons at oracle.com Thu Jun 11 04:07:54 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 10 Jun 2020 21:07:54 -0700 Subject: RFR: [15,doc] JDK-8247382 : doclint errors (missing comments) in jdk.compiler and jdk.javadoc Message-ID: <0fb07dc2-c3bf-4a35-778e-e9df8a40655f@oracle.com> Please review a trivial doc-only change to fix 3 missing doc comments detected by doclint. The new comments do not add any semantically new or interesting information, so no CSR. For the javac case, a preferable solution would have been to remove the undocumented `throws Exception`, except that would be an incompatible signature change for anyone unlikely enough to be calling the method directly. For now, the `throws` is just documented, even though in practice the exception will never be thrown. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8247382 Webrev: http://cr.openjdk.java.net/~jjg/8247382/webrev.00/ From joe.darcy at oracle.com Thu Jun 11 04:31:20 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 10 Jun 2020 21:31:20 -0700 Subject: RFR: [15, doc] JDK-8247382 : doclint errors (missing comments) in jdk.compiler and jdk.javadoc In-Reply-To: <0fb07dc2-c3bf-4a35-778e-e9df8a40655f@oracle.com> References: <0fb07dc2-c3bf-4a35-778e-e9df8a40655f@oracle.com> Message-ID: <62c4af62-f7d3-b24d-44e6-504056e174b5@oracle.com> Looks fine Jon; cheers, -Joe On 6/10/2020 9:07 PM, Jonathan Gibbons wrote: > Please review a trivial doc-only change to fix 3 missing doc comments > detected by doclint. The new comments do not add any semantically > new or interesting information, so no CSR. > > For the javac case, a preferable solution would have been to remove > the undocumented `throws Exception`, except that would be an > incompatible signature change for anyone unlikely enough to be calling > the method directly. For now, the `throws` is just documented, even > though in practice the exception will never be thrown. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8247382 > Webrev: http://cr.openjdk.java.net/~jjg/8247382/webrev.00/ > From behrangsa at gmail.com Thu Jun 11 07:07:10 2020 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Thu, 11 Jun 2020 17:07:10 +1000 Subject: Add an option to javac to disable inlining of static final variables (to be used by programmers during development phase) In-Reply-To: <1818852709.2015969.1591801450448.JavaMail.zimbra@u-pem.fr> References: <1818852709.2015969.1591801450448.JavaMail.zimbra@u-pem.fr> Message-ID: I see. Thanks for the information. Best regards, Behrang Saeedzadeh (Sent from my cellphone.) On Thu, Jun 11, 2020, 1:04 AM Remi Forax wrote: > ----- Mail original ----- > > De: "Behrang Saeedzadeh" > > ?: "compiler-dev" , "discuss" < > discuss at openjdk.java.net> > > Envoy?: Mercredi 10 Juin 2020 16:27:27 > > Objet: Add an option to javac to disable inlining of static final > variables (to be used by programmers during > > development phase) > > > Hi, > > Hi, > > > > > I guess inlining of static variables [1] is one of the main causes that > > during our day to day coding activities, we have to do a full recompile > > (e.g. `mvn clean ...`) every time a constant that is referenced > throughout > > the code is changed. > > > > There are a few ugly tricks to prevent the constants from getting > inlined, > > but a compiler option that we can pass to javac that produces a warning > > message that can be used while we program locally could reduce the need > to > > run `mvn clean ...`, `gradle clean ...`, etc. > > > > Another option could be [2] adding some metadata to classes that > reference > > constants to record where the constant is coming from that could allow > > build tools recompile all such classes when the constant changes. > > [1] > > > https://docs.oracle.com/javase/specs/jls/se14/html/jls-13.html#jls-13.4.9. > > [2] If the class file format permits that. > > It's already done by javac, it register all the classes of the static > final fields it depends in the constant pool (the dictionary pat of the > classfile format). > Gradle (the recent versions) uses this information but not Maven, so the > question is more how to improve Maven to compute the graph of dependencies > at the file level. > > There is also a kind of quick hack if you have a multi-modules project, > you can read the module-info.java to get the graph of modules to find the > dependency at module level, > you can then use javac to read the module-info.java and the JDK API to > create the module and let the JDK resolve the graph for you. > The build of the OpenJDK does that with great success. > > > > > > > -- > > Best regards, > > Behrang Saeedzadeh > > regards, > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jun 11 13:26:42 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 11 Jun 2020 15:26:42 +0200 Subject: RFR: JDK-8246704: --release => "unknown enum constant PreviewFeature$Feature.TEXT_BLOCKS" Message-ID: Hi, When compiling with --release 14, warnings like this may be printed: warning: unknown enum constant PreviewFeature$Feature.TEXT_BLOCKS reason: class file for jdk.internal.PreviewFeature$Feature not found The cause is fairly simple - the APIs associated with preview features (like new methods in j.l.String) are annotated with a JDK-internal annotation, which allows javac to detect them a provide an error/warning as appropriate. The issues is that the internal annotation is not inside the ct.sym, and loading an element annotated with it leads to resolution of the annotation, and to the warning above. Unfortunately, this is not very trivial to fix, as javac needs the annotation to detect the API elements associated with preview features (and so the annotation needs to be in ct.sym). And, when compiling without --release, not resolving an annotation that is part of the classfile would provide inconsistent results. So, the proposal is to use a different, synthetic, "annotation" (or rather name) inside ct.sym, and use that name only for detection of APIs associated with preview features and not resolve that annotation. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8246704/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8246704 Any comments on this? Thanks, Jan From james.laskey at oracle.com Thu Jun 11 13:49:59 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 11 Jun 2020 10:49:59 -0300 Subject: RFR: JDK-8246704: --release => "unknown enum constant PreviewFeature$Feature.TEXT_BLOCKS" In-Reply-To: References: Message-ID: <6F8D8D63-449E-439C-B236-C04CF22C070E@oracle.com> Seems like a reasonable approach. Code looks good. > On Jun 11, 2020, at 10:26 AM, Jan Lahoda wrote: > > Hi, > > When compiling with --release 14, warnings like this may be printed: > warning: unknown enum constant PreviewFeature$Feature.TEXT_BLOCKS > reason: class file for jdk.internal.PreviewFeature$Feature not found > > > The cause is fairly simple - the APIs associated with preview features (like new methods in j.l.String) are annotated with a JDK-internal annotation, which allows javac to detect them a provide an error/warning as appropriate. The issues is that the internal annotation is not inside the ct.sym, and loading an element annotated with it leads to resolution of the annotation, and to the warning above. > > Unfortunately, this is not very trivial to fix, as javac needs the annotation to detect the API elements associated with preview features (and so the annotation needs to be in ct.sym). And, when compiling without --release, not resolving an annotation that is part of the classfile would provide inconsistent results. > > So, the proposal is to use a different, synthetic, "annotation" (or rather name) inside ct.sym, and use that name only for detection of APIs associated with preview features and not resolve that annotation. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8246704/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8246704 > > Any comments on this? > > Thanks, > Jan From vicente.romero at oracle.com Thu Jun 11 13:56:33 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 11 Jun 2020 09:56:33 -0400 Subject: RFR: JDK-8247334: Trees.getScope crashes for annotated local records In-Reply-To: References: <20dfbae6-ba4b-246c-36c8-c0478e0654c2@oracle.com> Message-ID: <0ff0f335-8351-3b62-21e8-b794557d9e5a@oracle.com> looks good, Thanks, Vicente On 6/10/20 4:07 PM, Jan Lahoda wrote: > Hi Vicente, > > On 10. 06. 20 19:46, Vicente Romero wrote: >> Hi, >> >> Sorry I hit the send button too fast. Why is this only happening to >> local records? in any case could you please add a similar test for a non > > Thanks for the comment. > > I don't think this can happen for records that are not local, because > the scopes are computed differently - for code inside method bodies > (and variable initializers), a copy of the code is created and > re-attributed; for other points in the program, either an existing > scope (Env) is used, (Enter.getClassEnv for classes), or a scope is > synthetized without re-attributing the code, like for methods > MemberEnter.getMethodEnv, or Enter.getTopLevelEnv. > > I've added another test case for top-level record (the content of the > resulting scope is a little different, which is due to the differences > in the scope construction, and is the same for classes). > > Delta webrev: > http://cr.openjdk.java.net/~jlahoda/8247334/webrev.delta.00-01/ > > Full webrev: > http://cr.openjdk.java.net/~jlahoda/8247334/webrev.01/ > > What do you think? > > Thanks, > ??? Jan > >> local record just to cover it? >> >> Thanks, >> Vicente >> >> On 6/10/20 12:24 PM, Jan Lahoda wrote: >>> Hi, >>> >>> Consider code like this: >>> --- >>> class Test { >>> ??? void t() { >>> ??????? record R(@Annotation int i) {} >>> ??? } >>> } >>> @interface Annotation {} >>> --- >>> >>> Calling Trees.getScope for a TreePath pointing at @Annotation in >>> "@Annotation int i" will crash with an exception. >>> >>> The reason is that when the class is first attributed, a synthetic >>> canonical constructor is created for the record. And when the scope >>> is being computed, a copy of the method's body is created (including >>> the synthetic constructor), and re-attributed. And, since this is a >>> record, the constructors are entered first, then a default >>> constructor is possibly created, and then members not entered in the >>> first phase are entered. But the detection of these "other members" >>> fails to detect the default constructor was already entered in the >>> first phase, and as a consequence this default constructor is >>> entered twice, which ultimately leads to the exception. >>> >>> The proposed solution is to simply keep track if a constructor has >>> been added and avoid entering any constructor except the added one >>> during the second stage. >>> >>> I was trying other fix directions, but those typically changed the >>> order of members, either in Element.getEnclosedElements() or in the >>> classfile, which seemed inappropriate for this fix. >>> >>> Proposed webrev: >>> http://cr.openjdk.java.net/~jlahoda/8247334/webrev.00/ >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8247334 >>> >>> How does this look? >>> >>> Thanks! >>> ??? Jan >>> >> From vicente.romero at oracle.com Thu Jun 11 14:57:27 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 11 Jun 2020 10:57:27 -0400 Subject: RFR JDK-8245842: provide tests for binary compatibility assertions for sealed classes Message-ID: <589a71f1-2e3b-c2be-2dce-6633d31efeb1@oracle.com> Hi, Please review fix for [1] at [2], this patch provides test coverage for Chapter 13 Binary Compatibility of the Sealed Classes spec [3]. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8245842 [2] http://cr.openjdk.java.net/~vromero/8245842/webrev.00/ [3] http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200526/specs/sealed-classes-jls.html From christoph.dreis at freenet.de Thu Jun 11 17:08:39 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Thu, 11 Jun 2020 19:08:39 +0200 Subject: Directly initialized final field is not constant folded later when prefix with "this" Message-ID: <35A135A0-A8FF-45B6-A40E-B4B9FA6A5791@freenet.de> Hi, I hope this is the correct mailing list and hopefully not a too stupid mail. Today I experimented around with constant folding and created the following class: private final String world = "world"; public String world() { return "Hello " + "world"; } public String worldField() { return "Hello " + world; } public String worldFieldThis() { // This is not constant folded return "Hello " + this.world; } To my surprise javap showed the following bytecode (excerpts only): private final java.lang.String world; descriptor: Ljava/lang/String; flags: (0x0012) ACC_PRIVATE, ACC_FINAL ConstantValue: String world public java.lang.String worldField(); Code: 0: ldc #14 // String Hello world 2: areturn public java.lang.String worldFieldThis(); Code: 0: aload_0 1: invokestatic #16 // Method java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object; 4: pop 5: ldc #7 // String world 7: invokedynamic #22, 0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String; 12: areturn I would have expected to actually see things in worldFieldThis to be constant folded as well. Especially since the field is initialized directly and not anywhere else (e.g. in the constructor). Why is "this" making a difference here? Is this a bug or a known deficit? I wonder if it would be possible to constant fold these cases, too, or why they're maybe not constant foldable? After all, even with reflection I can't change the field (to the best of my knowledge). Also the spec [1] would lead me to the conclusion that those cases might be constant foldable. Serialization also shouldn't be an issue here, shouldn't it? > If a final field is initialized to a constant expression (?15.29) in the field declaration, > changes to the final field may not be observed, since uses of that final field are replaced at compile time with the value of the constant expression. Thanks in advance for any information on the topic. Cheers, Christoph [1] https://docs.oracle.com/javase/specs/jls/se14/html/jls-17.html#jls-17.5.3 From alex.buckley at oracle.com Thu Jun 11 17:53:54 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 11 Jun 2020 10:53:54 -0700 Subject: Directly initialized final field is not constant folded later when prefix with "this" In-Reply-To: <35A135A0-A8FF-45B6-A40E-B4B9FA6A5791@freenet.de> References: <35A135A0-A8FF-45B6-A40E-B4B9FA6A5791@freenet.de> Message-ID: On 6/11/2020 10:08 AM, Christoph Dreis wrote: > Today I experimented around with constant folding and created the following class: > > private final String world = "world"; > > public String world() { > return "Hello " + "world"; > } > > public String worldField() { > return "Hello " + world; > } > > public String worldFieldThis() { > // This is not constant folded > return "Hello " + this.world; > } ... > public java.lang.String worldField(); > Code: > 0: ldc #14 // String Hello world > 2: areturn > > public java.lang.String worldFieldThis(); > Code: > 0: aload_0 > 1: invokestatic #16 // Method java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object; > 4: pop > 5: ldc #7 // String world > 7: invokedynamic #22, 0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String; > 12: areturn > > I would have expected to actually see things in worldFieldThis to be constant folded as well. > Especially since the field is initialized directly and not anywhere else (e.g. in the constructor). > Why is "this" making a difference here? `this.world` is not a constant expression. String interning is driven by the rules of constant expressions, which are set up for predictability in all scenarios not just string concat/interning. Alex From forax at univ-mlv.fr Thu Jun 11 18:29:10 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 11 Jun 2020 20:29:10 +0200 (CEST) Subject: Directly initialized final field is not constant folded later when prefix with "this" In-Reply-To: References: <35A135A0-A8FF-45B6-A40E-B4B9FA6A5791@freenet.de> Message-ID: <56675450.668088.1591900150594.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alex Buckley" > ?: "compiler-dev" > Envoy?: Jeudi 11 Juin 2020 19:53:54 > Objet: Re: Directly initialized final field is not constant folded later when prefix with "this" > On 6/11/2020 10:08 AM, Christoph Dreis wrote: >> Today I experimented around with constant folding and created the following >> class: >> >> private final String world = "world"; >> >> public String world() { >> return "Hello " + "world"; >> } >> >> public String worldField() { >> return "Hello " + world; >> } >> >> public String worldFieldThis() { >> // This is not constant folded >> return "Hello " + this.world; >> } > ... >> public java.lang.String worldField(); >> Code: >> 0: ldc #14 // String Hello world >> 2: areturn >> >> public java.lang.String worldFieldThis(); >> Code: >> 0: aload_0 >> 1: invokestatic #16 // Method >> java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object; >> 4: pop >> 5: ldc #7 // String world >> 7: invokedynamic #22, 0 // InvokeDynamic >> #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String; >> 12: areturn >> >> I would have expected to actually see things in worldFieldThis to be constant >> folded as well. >> Especially since the field is initialized directly and not anywhere else (e.g. >> in the constructor). >> Why is "this" making a difference here? > > `this.world` is not a constant expression. String interning is driven by > the rules of constant expressions, which are set up for predictability > in all scenarios not just string concat/interning. > > Alex and Christoph, you can change the value of a final field by reflection :( R?mi From christoph.dreis at freenet.de Thu Jun 11 19:00:33 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Thu, 11 Jun 2020 21:00:33 +0200 Subject: Directly initialized final field is not constant folded later when prefix with "this" In-Reply-To: <56675450.668088.1591900150594.JavaMail.zimbra@u-pem.fr> References: <35A135A0-A8FF-45B6-A40E-B4B9FA6A5791@freenet.de> <56675450.668088.1591900150594.JavaMail.zimbra@u-pem.fr> Message-ID: <20C9BB35-42C4-45A9-8DCB-E39BF3BC1AB9@freenet.de> Hi Remi, > and Christoph, you can change the value of a final field by reflection :( if I put this to the test with the following: public class Main { public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { Hello hello = new Hello(); Field field = Hello.class.getDeclaredField("world"); field.setAccessible(true); field.set(hello, "Reflection"); System.out.println(hello.worldField()); } } public class Hello { private final String world = "world"; public String world() { return "Hello " + "world"; } public String worldField() { return "Hello " + world; } public String worldFieldThis() { // This is not constant folded return "Hello " + this.world; } } It will print "Hello world" instead of "Hello Reflection". Keep in mind that the final field is already initialized. The original mail included the following from the spec [1]: > If a final field is initialized to a constant expression (?15.29) in the field declaration, > changes to the final field may not be observed, since uses of that final field are replaced at compile time with the value of the constant expression. Am I missing something? Based on reading spec, my belief was that it doesn't actually matter if it's prefixed with "this" or not. Especially, the "uses of that final field" part. Cheers, Christoph [1] https://docs.oracle.com/javase/specs/jls/se14/html/jls-17.html#jls-17.5.3 From roland.illig at gmx.de Thu Jun 11 19:18:57 2020 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 11 Jun 2020 21:18:57 +0200 Subject: Directly initialized final field is not constant folded later when prefix with "this" In-Reply-To: References: <35A135A0-A8FF-45B6-A40E-B4B9FA6A5791@freenet.de> Message-ID: On 11.06.2020 19:53, Alex Buckley wrote: > On 6/11/2020 10:08 AM, Christoph Dreis wrote: >> Today I experimented around with constant folding and created the >> following class: >> >> ????private final String world = "world"; >> >> ????public String worldField() { >> ??????? return "Hello " + world; >> ????} >> >> ????public String worldFieldThis() { >> ??????? // This is not constant folded >> ??????? return "Hello " + this.world; >> ????} > > `this.world` is not a constant expression. String interning is driven by > the rules of constant expressions, which are set up for predictability > in all scenarios not just string concat/interning. I had thought that `world` were semantically the same as `this.world`, but JLS 14 says in "15.29 Constant Expressions": > A constant expression is ... > > * Simple names (?6.5.6.1) that refer to constant variables > (?4.12.4). > > * Qualified names (?6.5.6.2) of the form TypeName.Identifier > that refer to constant variables (?4.12.4). I wouldn't have expected that this makes a difference, but since `this` is not a TypeName, the compiler works as specified. This leaves the question why `this.field` was not defined to be equivalent to the unqualified `field` in the first place? Can anyone shed a light on this? Roland From forax at univ-mlv.fr Thu Jun 11 19:35:03 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 11 Jun 2020 21:35:03 +0200 (CEST) Subject: Directly initialized final field is not constant folded later when prefix with "this" In-Reply-To: <20C9BB35-42C4-45A9-8DCB-E39BF3BC1AB9@freenet.de> References: <35A135A0-A8FF-45B6-A40E-B4B9FA6A5791@freenet.de> <56675450.668088.1591900150594.JavaMail.zimbra@u-pem.fr> <20C9BB35-42C4-45A9-8DCB-E39BF3BC1AB9@freenet.de> Message-ID: <1422474589.698545.1591904103690.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Christoph Dreis" > ?: "Remi Forax" > Cc: "compiler-dev" , "Alex Buckley" > Envoy?: Jeudi 11 Juin 2020 21:00:33 > Objet: Re: Directly initialized final field is not constant folded later when prefix with "this" > Hi Remi, > >> and Christoph, you can change the value of a final field by reflection :( > > if I put this to the test with the following: > > public class Main { > > public static void main(String[] args) throws NoSuchFieldException, > IllegalAccessException { > Hello hello = new Hello(); > Field field = Hello.class.getDeclaredField("world"); > field.setAccessible(true); > > field.set(hello, "Reflection"); > System.out.println(hello.worldField()); > } > > } > > public class Hello { > > private final String world = "world"; > > public String world() { > return "Hello " + "world"; > } > > public String worldField() { > return "Hello " + world; > } > > public String worldFieldThis() { > // This is not constant folded > return "Hello " + this.world; > } > > } > > It will print "Hello world" instead of "Hello Reflection". > Keep in mind that the final field is already initialized. > > The original mail included the following from the spec [1]: > >> If a final field is initialized to a constant expression (?15.29) in the field >> declaration, >> changes to the final field may not be observed, since uses of that final field >> are replaced at compile time with the value of the constant expression. > > Am I missing something? > Based on reading spec, my belief was that it doesn't actually matter if it's > prefixed with "this" or not. Especially, the "uses of that final field" part. in your example, the field is changed but you don't access it because you try to access it using javac which as you said consider it as a constant expression, try using reflection or a VarHandle to acces to the field System.out.println(field.get(hello)); > > Cheers, > Christoph regards, R?mi > > > [1] https://docs.oracle.com/javase/specs/jls/se14/html/jls-17.html#jls-17.5.3 From joe.darcy at oracle.com Fri Jun 12 19:40:19 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 12 Jun 2020 12:40:19 -0700 Subject: JDK 16 RFR of JDK-8246222: Rename javac test T6395981.java to be more informative Message-ID: Hello, One of the langtools tests which gets updated on each release is T6395981.java and I'd like to give it the more descriptive name TestGetSourceVersions.java. Please review the webrev for this: ??? http://cr.openjdk.java.net/~darcy/8246222.0/ Thanks, -Joe From jonathan.gibbons at oracle.com Fri Jun 12 20:10:56 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 12 Jun 2020 13:10:56 -0700 Subject: JDK 16 RFR of JDK-8246222: Rename javac test T6395981.java to be more informative In-Reply-To: References: Message-ID: <7f1a5a68-50c2-fd44-abab-130bc2ae6485@oracle.com> I dunno, Joe, seems like a big deal to me! Maybe you need a second and third opinion. Just kidding. +1 -- Jon On 6/12/20 12:40 PM, Joe Darcy wrote: > Hello, > > One of the langtools tests which gets updated on each release is > T6395981.java and I'd like to give it the more descriptive name > TestGetSourceVersions.java. Please review the webrev for this: > > ??? http://cr.openjdk.java.net/~darcy/8246222.0/ > > Thanks, > > -Joe > From vicente.romero at oracle.com Tue Jun 16 18:57:36 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 16 Jun 2020 14:57:36 -0400 Subject: RFR JDK-8245842: provide tests for binary compatibility assertions for sealed classes In-Reply-To: <589a71f1-2e3b-c2be-2dce-6633d31efeb1@oracle.com> References: <589a71f1-2e3b-c2be-2dce-6633d31efeb1@oracle.com> Message-ID: <01dfd1a7-756a-2e8a-1cff-be2701bfd3e7@oracle.com> ping, I need a review for this patch, Thanks, Vicente On 6/11/20 10:57 AM, Vicente Romero wrote: > Hi, > > Please review fix for [1] at [2], this patch provides test coverage > for Chapter 13 Binary Compatibility of the Sealed Classes spec [3]. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8245842 > [2] http://cr.openjdk.java.net/~vromero/8245842/webrev.00/ > [3] > http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200526/specs/sealed-classes-jls.html From vicente.romero at oracle.com Tue Jun 16 19:02:50 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 16 Jun 2020 15:02:50 -0400 Subject: RFR: JDK-8246257: Annotated record's vararg type component started to be uncompilable with JDK15b24 In-Reply-To: References: Message-ID: <207d3a61-f1bb-d478-bae1-e41d55f4c1be@oracle.com> I need a reviewer for this one, Thanks, Vicente On 6/9/20 1:05 PM, Vicente Romero wrote: > Hi, > > Please review fix for [1] at [2]. If a record component is declared as > a varargs, then the corresponding argument in the canonical > constructor needs to be a varargs too. This assertion is failing in > the case the record component has annotations. This is because the > corresponding array type was being recreated to attach the annotations > but the fact that it was a varargs wasn't being preserved. This patch > fixes that issue, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8246257 > [2] http://cr.openjdk.java.net/~vromero/8246257/webrev.00/ From adam.sotona at oracle.com Wed Jun 17 07:37:14 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 17 Jun 2020 09:37:14 +0200 Subject: RFR: 8238735 NPE compiling lambda expression within conditional expression In-Reply-To: <57806482-3960-438F-85C0-5BF17AC5F2B2@oracle.com> References: <2C56102B-9EA8-41A7-BD93-0383D50DAAD0@oracle.com> <57806482-3960-438F-85C0-5BF17AC5F2B2@oracle.com> Message-ID: <4F940771-4AEB-4C01-BE35-515DE6195942@oracle.com> Hi, I've spent some time deep debugging of the javac NPE caused by lambda recovery process and here is an alternate patch (in contrast to the previous proposed patch skipping the recovery for the case). webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 This patch runs the recovery round in case of invalid FunctionDescriptor, however to avoid return of result containing Type.recoveryType (which has no tsym and so causing the NPE and compiler crash) the final returned type is saved error type from the first round of visitLambda. The patch also contains new test for this NPE case. The patch passes all Tier1, Tier2 and Tier 3 tests. Thanks for the review, Adam > On 20 May 2020, at 17:25, Adam Sotona wrote: > > Hi, > in this situation the second "recovery" round completely messes the results. > In the first run the result is correctly filled: result = that.type = types.createErrorType(pt()); and suppose to be returned, > however then another recovery is triggered and it re-enters the whole visitLambda with totally messed initial values. > As a result the second evaluation returns Type.recoveryType constant, which I expect should be never returned and with no indication that the evaluation failed. > Type.recoveryType has missing .tsym field and that is causing NPE. > My original idea was to simply avoid NPE by appropriate check, however I do not see any such similar code across javac. > I see many direct calls of Type.tsymin the code however no NPE protection anywhere. How it is guaranteed that instances of JCNoType (with null tsym) will never reach the code? > > Then I tried to fix it by correcting the result of the recovery round, however that seems to be very complex as the initial values of the recovery may vary a lot and detect the "messed" situation and find what suppose to be returned in that case is very complex. > > Then I realized that this is the situation where recovery should not happen as lambda without its FunctionDescriptor can hardly continue in compilation as it does not know anything about the expected content. > > The two error messages I had to remove from the test after the fix didn't make any sense to me. From all aspect there are two errors in the two lambdas, however second round of recovery listed two more nonsense errors: "compiler.err.cant.resolve.location: kindname.class, NonExistentClass, , , (compiler.misc.location: kindname.class, TargetType43, null)" > > BTW: Impact of the NPE is not just when used within conditional expression (as described in the 8238735), however it is silently killing javac with NPE anywhere you try to cast lambda expression that fails to lookup its FunctionDescriptor. For example just try to compile: class A {boolean b = (boolean)(() -> false);} > > Thanks, > Adam > >> On 20 May 2020, at 10:19, Adam Sotona > wrote: >> >> Hi, >> I would like to add results from Corpus compilation regression testing: the patch caused no regression in compilation of all Corpus sources :) >> >> Thanks for review, >> Adam >> >>> On 18 May 2020, at 17:47, Adam Sotona > wrote: >>> >>> Hi, >>> I would like to ask for review of the patch fixing NPE while compiling lambda expression within conditional expression. >>> The fix removes obsolete recovery cycle in com.sun.tools.javac.comp.Attr.visitLambda method when Types.FunctionDescriptorLookupError happens and it adds new test. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >>> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.00/ >>> >>> Mach 5 build with the patch passes all Tier1, Tier2 and Tier3 tests. >>> >>> >>> Thank you, >>> Adam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jun 17 09:54:36 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 17 Jun 2020 10:54:36 +0100 Subject: RFR: 8238735 NPE compiling lambda expression within conditional expression In-Reply-To: <4F940771-4AEB-4C01-BE35-515DE6195942@oracle.com> References: <2C56102B-9EA8-41A7-BD93-0383D50DAAD0@oracle.com> <57806482-3960-438F-85C0-5BF17AC5F2B2@oracle.com> <4F940771-4AEB-4C01-BE35-515DE6195942@oracle.com> Message-ID: <9ea4d452-8fad-7104-a22b-93ae0d6c60ae@oracle.com> The patch looks less invasive/more pragmatic. Looks good. Maurizio On 17/06/2020 08:37, Adam Sotona wrote: > Hi, > I've spent some time deep debugging of the javac NPE caused by lambda > recovery process and here is an alternate patch (in contrast to the > previous proposed patch skipping the recovery for the case). > webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 > > This patch runs the recovery round in case of invalid > FunctionDescriptor, however to avoid return of result containing > Type.recoveryType (which has no tsym and so causing the NPE and > compiler crash) the final returned type is saved error type from the > first round of visitLambda. The patch also contains new test for this > NPE case. > > The patch passes all Tier1, Tier2 and Tier 3 tests. > > Thanks for the review, > Adam > > >> On 20 May 2020, at 17:25, Adam Sotona > > wrote: >> >> Hi, >> in this situation the second "recovery" round completely messes the >> results. >> In the first run the result is correctly filled: result = that.type = >> types.createErrorType(pt()); and suppose to be returned, >> however then another recovery is triggered and it ?re-enters the >> whole visitLambda with totally messed initial values. >> As a result the second evaluation returns Type.recoveryType constant, >> which I expect should be never returned and with no indication that >> the evaluation failed. >> Type.recoveryType has missing?.tsym field and that is causing NPE. >> My original idea was to simply avoid NPE by appropriate check, >> however I do not see any such similar code across javac. >> I see many direct calls of Type.tsymin the code however no NPE >> protection anywhere. How it is guaranteed that instances of?JCNoType >> (with null tsym) will never reach the code? >> >> Then I tried to fix it by correcting the result of the recovery >> round, however that seems to be very complex as the initial values of >> the recovery may vary a lot and detect the "messed" situation and >> find what suppose to be returned in that case is very complex. >> >> Then I realized that this is the situation where recovery should not >> happen as lambda without its FunctionDescriptor can hardly continue >> in compilation as it does not know anything about the expected content. >> >> The two error messages I had to remove from the test after the fix >> didn't make any sense to me. From all aspect there are two errors in >> the two lambdas, however second round of recovery listed two more >> nonsense errors: "compiler.err.cant.resolve.location: kindname.class, >> NonExistentClass, , , (compiler.misc.location: kindname.class, >> TargetType43, null)" >> >> BTW: Impact of the NPE is not just when used within conditional >> expression (as described in the 8238735), however it is silently >> killing javac with NPE anywhere you try to cast lambda expression >> that fails to lookup its FunctionDescriptor. For example just try to >> compile: class A {boolean b = (boolean)(() -> false);} >> >> Thanks, >> Adam >> >>> On 20 May 2020, at 10:19, Adam Sotona >> > wrote: >>> >>> Hi, >>> I would like to add results from Corpus compilation regression >>> testing: the patch caused no regression in compilation of all Corpus >>> sources :) >>> >>> Thanks for review, >>> Adam >>> >>>> On 18 May 2020, at 17:47, Adam Sotona >>> > wrote: >>>> >>>> Hi, >>>> I would like to ask for review of the patch fixing NPE while >>>> compiling lambda expression within conditional expression. >>>> The fix removes obsolete recovery cycle in >>>> com.sun.tools.javac.comp.Attr.visitLambda method when >>>> Types.FunctionDescriptorLookupError happens and it adds new test. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >>>> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.00/ >>>> >>>> Mach 5 build with the patch passes all Tier1, Tier2 and Tier3 tests. >>>> >>>> >>>> Thank you, >>>> Adam >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Wed Jun 17 11:23:26 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 17 Jun 2020 13:23:26 +0200 Subject: RFR: 8238735 NPE compiling lambda expression within conditional expression In-Reply-To: <9ea4d452-8fad-7104-a22b-93ae0d6c60ae@oracle.com> References: <2C56102B-9EA8-41A7-BD93-0383D50DAAD0@oracle.com> <57806482-3960-438F-85C0-5BF17AC5F2B2@oracle.com> <4F940771-4AEB-4C01-BE35-515DE6195942@oracle.com> <9ea4d452-8fad-7104-a22b-93ae0d6c60ae@oracle.com> Message-ID: <7AFFC7BD-93CF-44F4-8CC0-D075E5CBC786@oracle.com> Hi Maurizio, thanks for the review. May I ask you to push the patch? Here is the changeset version of the patch in webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.01b/ Thank you, Adam > On 17 Jun 2020, at 11:54, Maurizio Cimadamore wrote: > > The patch looks less invasive/more pragmatic. > > Looks good. > > Maurizio > > On 17/06/2020 08:37, Adam Sotona wrote: >> Hi, >> I've spent some time deep debugging of the javac NPE caused by lambda recovery process and here is an alternate patch (in contrast to the previous proposed patch skipping the recovery for the case). >> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >> >> This patch runs the recovery round in case of invalid FunctionDescriptor, however to avoid return of result containing Type.recoveryType (which has no tsym and so causing the NPE and compiler crash) the final returned type is saved error type from the first round of visitLambda. The patch also contains new test for this NPE case. >> >> The patch passes all Tier1, Tier2 and Tier 3 tests. >> >> Thanks for the review, >> Adam >> >> >>> On 20 May 2020, at 17:25, Adam Sotona > wrote: >>> >>> Hi, >>> in this situation the second "recovery" round completely messes the results. >>> In the first run the result is correctly filled: result = that.type = types.createErrorType(pt()); and suppose to be returned, >>> however then another recovery is triggered and it re-enters the whole visitLambda with totally messed initial values. >>> As a result the second evaluation returns Type.recoveryType constant, which I expect should be never returned and with no indication that the evaluation failed. >>> Type.recoveryType has missing .tsym field and that is causing NPE. >>> My original idea was to simply avoid NPE by appropriate check, however I do not see any such similar code across javac. >>> I see many direct calls of Type.tsymin the code however no NPE protection anywhere. How it is guaranteed that instances of JCNoType (with null tsym) will never reach the code? >>> >>> Then I tried to fix it by correcting the result of the recovery round, however that seems to be very complex as the initial values of the recovery may vary a lot and detect the "messed" situation and find what suppose to be returned in that case is very complex. >>> >>> Then I realized that this is the situation where recovery should not happen as lambda without its FunctionDescriptor can hardly continue in compilation as it does not know anything about the expected content. >>> >>> The two error messages I had to remove from the test after the fix didn't make any sense to me. From all aspect there are two errors in the two lambdas, however second round of recovery listed two more nonsense errors: "compiler.err.cant.resolve.location: kindname.class, NonExistentClass, , , (compiler.misc.location: kindname.class, TargetType43, null)" >>> >>> BTW: Impact of the NPE is not just when used within conditional expression (as described in the 8238735), however it is silently killing javac with NPE anywhere you try to cast lambda expression that fails to lookup its FunctionDescriptor. For example just try to compile: class A {boolean b = (boolean)(() -> false);} >>> >>> Thanks, >>> Adam >>> >>>> On 20 May 2020, at 10:19, Adam Sotona > wrote: >>>> >>>> Hi, >>>> I would like to add results from Corpus compilation regression testing: the patch caused no regression in compilation of all Corpus sources :) >>>> >>>> Thanks for review, >>>> Adam >>>> >>>>> On 18 May 2020, at 17:47, Adam Sotona > wrote: >>>>> >>>>> Hi, >>>>> I would like to ask for review of the patch fixing NPE while compiling lambda expression within conditional expression. >>>>> The fix removes obsolete recovery cycle in com.sun.tools.javac.comp.Attr.visitLambda method when Types.FunctionDescriptorLookupError happens and it adds new test. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >>>>> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.00/ >>>>> >>>>> Mach 5 build with the patch passes all Tier1, Tier2 and Tier3 tests. >>>>> >>>>> >>>>> Thank you, >>>>> Adam >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jun 17 13:15:07 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 17 Jun 2020 15:15:07 +0200 Subject: RFR (15): JDK-8242214: NullPointerException in JDK 14 javac compiling a method reference Message-ID: Hi, There is a tricky issue related to unbound instance method references to a protected method in a superclass. Consider: ---base/Base.java: package base; public class Base { protected void test() {} } ---impl/Impl.java: package impl; import base.Base; import java.util.function.Consumer; public class Impl extends Base { Consumer consumer() { return Impl::test; } } --- Since JDK-8234729, javac tries to expand the method reference to a lambda: (/*synthetic*/ Object rec$)->((Base)rec$).test() But this is not quite right (and crashes javac) - Impl cannot invoke test on "Base": ((Base) rec$).test(); it needs to invoke (if I understand JLS 6.6.2.1. correctly) test on "Impl": ((Impl) rec$).test(); So, the expanded lambda for the method reference should be: (/*synthetic*/ Object rec$)->((Impl)rec$).test() Which is what the proposed patch is trying to do. Webrev: http://cr.openjdk.java.net/~jlahoda/8242214/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8242214 How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Wed Jun 17 13:51:10 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 17 Jun 2020 14:51:10 +0100 Subject: RFR: 8238735 NPE compiling lambda expression within conditional expression In-Reply-To: <7AFFC7BD-93CF-44F4-8CC0-D075E5CBC786@oracle.com> References: <2C56102B-9EA8-41A7-BD93-0383D50DAAD0@oracle.com> <57806482-3960-438F-85C0-5BF17AC5F2B2@oracle.com> <4F940771-4AEB-4C01-BE35-515DE6195942@oracle.com> <9ea4d452-8fad-7104-a22b-93ae0d6c60ae@oracle.com> <7AFFC7BD-93CF-44F4-8CC0-D075E5CBC786@oracle.com> Message-ID: <8b784158-bddd-5358-737f-af1cad9062f6@oracle.com> On 17/06/2020 12:23, Adam Sotona wrote: > Hi Maurizio, > thanks for the review. > > May I ask you to push the patch? > Here is the changeset version of the patch in webrev: > http://cr.openjdk.java.net/~asotona/8238735/webrev.01b/ I can push - I assume this needs to go straight into jdk/jdk15 and not to jdk/jdk, right? Maurizio > > Thank you, > Adam > >> On 17 Jun 2020, at 11:54, Maurizio Cimadamore >> > > wrote: >> >> The patch looks less invasive/more pragmatic. >> >> Looks good. >> >> Maurizio >> >> On 17/06/2020 08:37, Adam Sotona wrote: >>> Hi, >>> I've spent some time deep debugging of the javac NPE caused by >>> lambda recovery process and here is an alternate patch (in contrast >>> to the previous proposed patch skipping the recovery for the case). >>> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.01/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >>> >>> This patch runs the recovery round in case of invalid >>> FunctionDescriptor, however to avoid return of result containing >>> Type.recoveryType (which has no tsym and so causing the NPE and >>> compiler crash) the final returned type is saved error type from the >>> first round of visitLambda. The patch also contains new test for >>> this NPE case. >>> >>> The patch passes all Tier1, Tier2 and Tier 3 tests. >>> >>> Thanks for the review, >>> Adam >>> >>> >>>> On 20 May 2020, at 17:25, Adam Sotona >>> > wrote: >>>> >>>> Hi, >>>> in this situation the second "recovery" round completely messes the >>>> results. >>>> In the first run the result is correctly filled: result = that.type >>>> = types.createErrorType(pt()); and suppose to be returned, >>>> however then another recovery is triggered and it ?re-enters the >>>> whole visitLambda with totally messed initial values. >>>> As a result the second evaluation returns Type.recoveryType >>>> constant, which I expect should be never returned and with no >>>> indication that the evaluation failed. >>>> Type.recoveryType has missing?.tsym field and that is causing NPE. >>>> My original idea was to simply avoid NPE by appropriate check, >>>> however I do not see any such similar code across javac. >>>> I see many direct calls of Type.tsymin the code however no NPE >>>> protection anywhere. How it is guaranteed that instances >>>> of?JCNoType (with null tsym) will never reach the code? >>>> >>>> Then I tried to fix it by correcting the result of the recovery >>>> round, however that seems to be very complex as the initial values >>>> of the recovery may vary a lot and detect the "messed" situation >>>> and find what suppose to be returned in that case is very complex. >>>> >>>> Then I realized that this is the situation where recovery should >>>> not happen as lambda without its FunctionDescriptor can hardly >>>> continue in compilation as it does not know anything about the >>>> expected content. >>>> >>>> The two error messages I had to remove from the test after the fix >>>> didn't make any sense to me. From all aspect there are two errors >>>> in the two lambdas, however second round of recovery listed two >>>> more nonsense errors: "compiler.err.cant.resolve.location: >>>> kindname.class, NonExistentClass, , , (compiler.misc.location: >>>> kindname.class, TargetType43, null)" >>>> >>>> BTW: Impact of the NPE is not just when used within conditional >>>> expression (as described in the 8238735), however it is silently >>>> killing javac with NPE anywhere you try to cast lambda expression >>>> that fails to lookup its FunctionDescriptor. For example just try >>>> to compile: class A {boolean b = (boolean)(() -> false);} >>>> >>>> Thanks, >>>> Adam >>>> >>>>> On 20 May 2020, at 10:19, Adam Sotona >>>> > wrote: >>>>> >>>>> Hi, >>>>> I would like to add results from Corpus compilation regression >>>>> testing: the patch caused no regression in compilation of all >>>>> Corpus sources :) >>>>> >>>>> Thanks for review, >>>>> Adam >>>>> >>>>>> On 18 May 2020, at 17:47, Adam Sotona >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> I would like to ask for review of the patch fixing NPE while >>>>>> compiling lambda expression within conditional expression. >>>>>> The fix removes obsolete recovery cycle in >>>>>> com.sun.tools.javac.comp.Attr.visitLambda method when >>>>>> Types.FunctionDescriptorLookupError happens and it adds new test. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >>>>>> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.00/ >>>>>> >>>>>> Mach 5 build with the patch passes all Tier1, Tier2 and Tier3 tests. >>>>>> >>>>>> >>>>>> Thank you, >>>>>> Adam >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Wed Jun 17 14:15:34 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 17 Jun 2020 16:15:34 +0200 Subject: RFR: 8238735 NPE compiling lambda expression within conditional expression In-Reply-To: <8b784158-bddd-5358-737f-af1cad9062f6@oracle.com> References: <2C56102B-9EA8-41A7-BD93-0383D50DAAD0@oracle.com> <57806482-3960-438F-85C0-5BF17AC5F2B2@oracle.com> <4F940771-4AEB-4C01-BE35-515DE6195942@oracle.com> <9ea4d452-8fad-7104-a22b-93ae0d6c60ae@oracle.com> <7AFFC7BD-93CF-44F4-8CC0-D075E5CBC786@oracle.com> <8b784158-bddd-5358-737f-af1cad9062f6@oracle.com> Message-ID: Yes, into jdk/jdk15 Thanks, Adam > On 17 Jun 2020, at 15:51, Maurizio Cimadamore wrote: > > > > On 17/06/2020 12:23, Adam Sotona wrote: >> Hi Maurizio, >> thanks for the review. >> >> May I ask you to push the patch? >> Here is the changeset version of the patch in webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.01b/ I can push - I assume this needs to go straight into jdk/jdk15 and not to jdk/jdk, right? > > Maurizio > >> >> Thank you, >> Adam >> >>> On 17 Jun 2020, at 11:54, Maurizio Cimadamore > wrote: >>> >>> The patch looks less invasive/more pragmatic. >>> >>> Looks good. >>> >>> Maurizio >>> >>> On 17/06/2020 08:37, Adam Sotona wrote: >>>> Hi, >>>> I've spent some time deep debugging of the javac NPE caused by lambda recovery process and here is an alternate patch (in contrast to the previous proposed patch skipping the recovery for the case). >>>> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.01/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >>>> >>>> This patch runs the recovery round in case of invalid FunctionDescriptor, however to avoid return of result containing Type.recoveryType (which has no tsym and so causing the NPE and compiler crash) the final returned type is saved error type from the first round of visitLambda. The patch also contains new test for this NPE case. >>>> >>>> The patch passes all Tier1, Tier2 and Tier 3 tests. >>>> >>>> Thanks for the review, >>>> Adam >>>> >>>> >>>>> On 20 May 2020, at 17:25, Adam Sotona > wrote: >>>>> >>>>> Hi, >>>>> in this situation the second "recovery" round completely messes the results. >>>>> In the first run the result is correctly filled: result = that.type = types.createErrorType(pt()); and suppose to be returned, >>>>> however then another recovery is triggered and it re-enters the whole visitLambda with totally messed initial values. >>>>> As a result the second evaluation returns Type.recoveryType constant, which I expect should be never returned and with no indication that the evaluation failed. >>>>> Type.recoveryType has missing .tsym field and that is causing NPE. >>>>> My original idea was to simply avoid NPE by appropriate check, however I do not see any such similar code across javac. >>>>> I see many direct calls of Type.tsymin the code however no NPE protection anywhere. How it is guaranteed that instances of JCNoType (with null tsym) will never reach the code? >>>>> >>>>> Then I tried to fix it by correcting the result of the recovery round, however that seems to be very complex as the initial values of the recovery may vary a lot and detect the "messed" situation and find what suppose to be returned in that case is very complex. >>>>> >>>>> Then I realized that this is the situation where recovery should not happen as lambda without its FunctionDescriptor can hardly continue in compilation as it does not know anything about the expected content. >>>>> >>>>> The two error messages I had to remove from the test after the fix didn't make any sense to me. From all aspect there are two errors in the two lambdas, however second round of recovery listed two more nonsense errors: "compiler.err.cant.resolve.location: kindname.class, NonExistentClass, , , (compiler.misc.location: kindname.class, TargetType43, null)" >>>>> >>>>> BTW: Impact of the NPE is not just when used within conditional expression (as described in the 8238735), however it is silently killing javac with NPE anywhere you try to cast lambda expression that fails to lookup its FunctionDescriptor. For example just try to compile: class A {boolean b = (boolean)(() -> false);} >>>>> >>>>> Thanks, >>>>> Adam >>>>> >>>>>> On 20 May 2020, at 10:19, Adam Sotona > wrote: >>>>>> >>>>>> Hi, >>>>>> I would like to add results from Corpus compilation regression testing: the patch caused no regression in compilation of all Corpus sources :) >>>>>> >>>>>> Thanks for review, >>>>>> Adam >>>>>> >>>>>>> On 18 May 2020, at 17:47, Adam Sotona > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> I would like to ask for review of the patch fixing NPE while compiling lambda expression within conditional expression. >>>>>>> The fix removes obsolete recovery cycle in com.sun.tools.javac.comp.Attr.visitLambda method when Types.FunctionDescriptorLookupError happens and it adds new test. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >>>>>>> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.00/ >>>>>>> >>>>>>> Mach 5 build with the patch passes all Tier1, Tier2 and Tier3 tests. >>>>>>> >>>>>>> >>>>>>> Thank you, >>>>>>> Adam >>>>>> >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jun 17 15:06:17 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 17 Jun 2020 16:06:17 +0100 Subject: RFR: 8238735 NPE compiling lambda expression within conditional expression In-Reply-To: References: <2C56102B-9EA8-41A7-BD93-0383D50DAAD0@oracle.com> <57806482-3960-438F-85C0-5BF17AC5F2B2@oracle.com> <4F940771-4AEB-4C01-BE35-515DE6195942@oracle.com> <9ea4d452-8fad-7104-a22b-93ae0d6c60ae@oracle.com> <7AFFC7BD-93CF-44F4-8CC0-D075E5CBC786@oracle.com> <8b784158-bddd-5358-737f-af1cad9062f6@oracle.com> Message-ID: Pushed Maurizio On 17/06/2020 15:15, Adam Sotona wrote: > Yes, into jdk/jdk15 > > Thanks, > Adam > >> On 17 Jun 2020, at 15:51, Maurizio Cimadamore >> > > wrote: >> >> >> On 17/06/2020 12:23, Adam Sotona wrote: >>> Hi Maurizio, >>> thanks for the review. >>> >>> May I ask you to push the patch? >>> Here is the changeset version of the patch in webrev: >>> http://cr.openjdk.java.net/~asotona/8238735/webrev.01b/ >> >> I can push - I assume this needs to go straight into jdk/jdk15 and >> not to jdk/jdk, right? >> >> Maurizio >> >>> >>> Thank you, >>> Adam >>> >>>> On 17 Jun 2020, at 11:54, Maurizio Cimadamore >>>> >>> > wrote: >>>> >>>> The patch looks less invasive/more pragmatic. >>>> >>>> Looks good. >>>> >>>> Maurizio >>>> >>>> On 17/06/2020 08:37, Adam Sotona wrote: >>>>> Hi, >>>>> I've spent some time deep debugging of the javac NPE caused by >>>>> lambda recovery process and here is an alternate patch (in >>>>> contrast to the previous proposed patch skipping the recovery for >>>>> the case). >>>>> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.01/ >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >>>>> >>>>> This patch runs the recovery round in case of invalid >>>>> FunctionDescriptor, however to avoid return of result containing >>>>> Type.recoveryType (which has no tsym and so causing the NPE and >>>>> compiler crash) the final returned type is saved error type from >>>>> the first round of visitLambda. The patch also contains new test >>>>> for this NPE case. >>>>> >>>>> The patch passes all Tier1, Tier2 and Tier 3 tests. >>>>> >>>>> Thanks for the review, >>>>> Adam >>>>> >>>>> >>>>>> On 20 May 2020, at 17:25, Adam Sotona >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> in this situation the second "recovery" round completely messes >>>>>> the results. >>>>>> In the first run the result is correctly filled: result = >>>>>> that.type = types.createErrorType(pt()); and suppose to be returned, >>>>>> however then another recovery is triggered and it ?re-enters the >>>>>> whole visitLambda with totally messed initial values. >>>>>> As a result the second evaluation returns Type.recoveryType >>>>>> constant, which I expect should be never returned and with no >>>>>> indication that the evaluation failed. >>>>>> Type.recoveryType has missing?.tsym field and that is causing NPE. >>>>>> My original idea was to simply avoid NPE by appropriate check, >>>>>> however I do not see any such similar code across javac. >>>>>> I see many direct calls of Type.tsymin the code however no NPE >>>>>> protection anywhere. How it is guaranteed that instances >>>>>> of?JCNoType (with null tsym) will never reach the code? >>>>>> >>>>>> Then I tried to fix it by correcting the result of the recovery >>>>>> round, however that seems to be very complex as the initial >>>>>> values of the recovery may vary a lot and detect the "messed" >>>>>> situation and find what suppose to be returned in that case is >>>>>> very complex. >>>>>> >>>>>> Then I realized that this is the situation where recovery should >>>>>> not happen as lambda without its FunctionDescriptor can hardly >>>>>> continue in compilation as it does not know anything about the >>>>>> expected content. >>>>>> >>>>>> The two error messages I had to remove from the test after the >>>>>> fix didn't make any sense to me. From all aspect there are two >>>>>> errors in the two lambdas, however second round of recovery >>>>>> listed two more nonsense errors: >>>>>> "compiler.err.cant.resolve.location: kindname.class, >>>>>> NonExistentClass, , , (compiler.misc.location: kindname.class, >>>>>> TargetType43, null)" >>>>>> >>>>>> BTW: Impact of the NPE is not just when used within conditional >>>>>> expression (as described in the 8238735), however it is silently >>>>>> killing javac with NPE anywhere you try to cast lambda expression >>>>>> that fails to lookup its FunctionDescriptor. For example just try >>>>>> to compile: class A {boolean b = (boolean)(() -> false);} >>>>>> >>>>>> Thanks, >>>>>> Adam >>>>>> >>>>>>> On 20 May 2020, at 10:19, Adam Sotona >>>>>> > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> I would like to add results from Corpus compilation regression >>>>>>> testing: the patch caused no regression in compilation of all >>>>>>> Corpus sources :) >>>>>>> >>>>>>> Thanks for review, >>>>>>> Adam >>>>>>> >>>>>>>> On 18 May 2020, at 17:47, Adam Sotona >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> I would like to ask for review of the patch fixing NPE while >>>>>>>> compiling lambda expression within conditional expression. >>>>>>>> The fix removes obsolete recovery cycle in >>>>>>>> com.sun.tools.javac.comp.Attr.visitLambda method when >>>>>>>> Types.FunctionDescriptorLookupError happens and it adds new test. >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238735 >>>>>>>> webrev: http://cr.openjdk.java.net/~asotona/8238735/webrev.00/ >>>>>>>> >>>>>>>> Mach 5 build with the patch passes all Tier1, Tier2 and Tier3 >>>>>>>> tests. >>>>>>>> >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Adam >>>>>>> >>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jun 17 16:15:47 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 17 Jun 2020 12:15:47 -0400 Subject: RFR (15): JDK-8242214: NullPointerException in JDK 14 javac compiling a method reference In-Reply-To: References: Message-ID: <57b62f41-06c0-8e03-6ec3-241dd7df53bb@oracle.com> Hi Jan, Out of curiosity, as this is a regression, do we know what was the change that introduced the issue and what was the related code like before the change that provoked the regression? Thanks, Vicente On 6/17/20 9:15 AM, Jan Lahoda wrote: > Hi, > > There is a tricky issue related to unbound instance method references > to a protected method in a superclass. > > Consider: > ---base/Base.java: > package base; > > public class Base { > ??? protected void test() {} > } > ---impl/Impl.java: > package impl; > > import base.Base; > import java.util.function.Consumer; > > public class Impl extends Base { > ??? Consumer consumer() { > ??????? return Impl::test; > ??? } > } > --- > > Since JDK-8234729, javac tries to expand the method reference to a > lambda: > (/*synthetic*/ Object rec$)->((Base)rec$).test() > > But this is not quite right (and crashes javac) - Impl cannot invoke > test on "Base": > ((Base) rec$).test(); > > it needs to invoke (if I understand JLS 6.6.2.1. correctly) test on > "Impl": > ((Impl) rec$).test(); > > So, the expanded lambda for the method reference should be: > (/*synthetic*/ Object rec$)->((Impl)rec$).test() > > Which is what the proposed patch is trying to do. > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8242214/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8242214 > > How does this look? > > Thanks, > ??? Jan From jonathan.gibbons at oracle.com Wed Jun 17 16:29:25 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 17 Jun 2020 09:29:25 -0700 Subject: RFR: JDK-8246257: Annotated record's vararg type component started to be uncompilable with JDK15b24 In-Reply-To: References: Message-ID: <1e5148a1-cb67-4107-bc26-aa636a98ccd0@oracle.com> Looks good to me. -- Jon On 6/9/20 10:05 AM, Vicente Romero wrote: > Hi, > > Please review fix for [1] at [2]. If a record component is declared as > a varargs, then the corresponding argument in the canonical > constructor needs to be a varargs too. This assertion is failing in > the case the record component has annotations. This is because the > corresponding array type was being recreated to attach the annotations > but the fact that it was a varargs wasn't being preserved. This patch > fixes that issue, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8246257 > [2] http://cr.openjdk.java.net/~vromero/8246257/webrev.00/ From james.laskey at oracle.com Wed Jun 17 16:45:26 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 17 Jun 2020 13:45:26 -0300 Subject: RFR: JDK-8246257: Annotated record's vararg type component started to be uncompilable with JDK15b24 In-Reply-To: References: Message-ID: <60574888-4D47-4FD8-8361-C61989B4942A@oracle.com> +1 > On Jun 9, 2020, at 2:05 PM, Vicente Romero wrote: > > Hi, > > Please review fix for [1] at [2]. If a record component is declared as a varargs, then the corresponding argument in the canonical constructor needs to be a varargs too. This assertion is failing in the case the record component has annotations. This is because the corresponding array type was being recreated to attach the annotations but the fact that it was a varargs wasn't being preserved. This patch fixes that issue, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8246257 > [2] http://cr.openjdk.java.net/~vromero/8246257/webrev.00/ From jonathan.gibbons at oracle.com Wed Jun 17 17:01:51 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 17 Jun 2020 10:01:51 -0700 Subject: RFR JDK-8245842: provide tests for binary compatibility assertions for sealed classes In-Reply-To: <589a71f1-2e3b-c2be-2dce-6633d31efeb1@oracle.com> References: <589a71f1-2e3b-c2be-2dce-6633d31efeb1@oracle.com> Message-ID: <3760a9af-51b2-1657-e836-223e23254057@oracle.com> Looks good to me. A slightly different way of handling the test cases, instead of passing in two complete source definitions, would be to pass in a template with a marker string where the sources differ, together with the values to substitute.? This would make it slightly easier to discern the similarities and differences in the source files. Separately, as a separate RFE for toolbox tasks, we might want to add a 'enablePreview' method to the task that cases the right underlying options to be set. This could be a method on AbstractTask, with possible overrides in the specific task classes.? This would make it easier to mark a task as needing preview features, and for the method call to be removed, eventually, when the preview feature becomes standard. -- Jon On 6/11/20 7:57 AM, Vicente Romero wrote: > Hi, > > Please review fix for [1] at [2], this patch provides test coverage > for Chapter 13 Binary Compatibility of the Sealed Classes spec [3]. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8245842 > [2] http://cr.openjdk.java.net/~vromero/8245842/webrev.00/ > [3] > http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200526/specs/sealed-classes-jls.html From vicente.romero at oracle.com Wed Jun 17 17:29:30 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 17 Jun 2020 13:29:30 -0400 Subject: RFR JDK-8245842: provide tests for binary compatibility assertions for sealed classes In-Reply-To: <3760a9af-51b2-1657-e836-223e23254057@oracle.com> References: <589a71f1-2e3b-c2be-2dce-6633d31efeb1@oracle.com> <3760a9af-51b2-1657-e836-223e23254057@oracle.com> Message-ID: Hi, Thanks for the review, On 6/17/20 1:01 PM, Jonathan Gibbons wrote: > Looks good to me. > > A slightly different way of handling the test cases, instead of > passing in two complete source definitions, would be to pass in a > template with a marker string where the sources differ, together with > the values to substitute.? This would make it slightly easier to > discern the similarities and differences in the source files. right that could be a future improvement, the door is not closed for this test as this part of the record's spec is still being mulled over > > Separately, as a separate RFE for toolbox tasks, we might want to add > a 'enablePreview' method to the task that cases the right underlying > options to be set. This could be a method on AbstractTask, with > possible overrides in the specific task classes.? This would make it > easier to mark a task as needing preview features, and for the method > call to be removed, eventually, when the preview feature becomes > standard. yep this could be done although it won't be a big change compared to the current situation I guess > > -- Jon Vicente > > On 6/11/20 7:57 AM, Vicente Romero wrote: >> Hi, >> >> Please review fix for [1] at [2], this patch provides test coverage >> for Chapter 13 Binary Compatibility of the Sealed Classes spec [3]. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8245842 >> [2] http://cr.openjdk.java.net/~vromero/8245842/webrev.00/ >> [3] >> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200526/specs/sealed-classes-jls.html From jonathan.gibbons at oracle.com Wed Jun 17 18:01:54 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 17 Jun 2020 11:01:54 -0700 Subject: RFR JDK-8245842: provide tests for binary compatibility assertions for sealed classes In-Reply-To: References: <589a71f1-2e3b-c2be-2dce-6633d31efeb1@oracle.com> <3760a9af-51b2-1657-e836-223e23254057@oracle.com> Message-ID: <4250380f-958b-34db-def1-afbacec8c8c1@oracle.com> On 6/17/20 10:29 AM, Vicente Romero wrote: > > >> >> Separately, as a separate RFE for toolbox tasks, we might want to add >> a 'enablePreview' method to the task that cases the right underlying >> options to be set. This could be a method on AbstractTask, with >> possible overrides in the specific task classes.? This would make it >> easier to mark a task as needing preview features, and for the method >> call to be removed, eventually, when the preview feature becomes >> standard. > > yep this could be done although it won't be a big change compared to > the current situation I guess Agreed it is not a big deal, but it just simplifies (a bit) the work to update tests like these when the feature becomes standard. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jun 17 19:23:40 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 17 Jun 2020 15:23:40 -0400 Subject: RFR JDK-8245842: provide tests for binary compatibility assertions for sealed classes In-Reply-To: <4250380f-958b-34db-def1-afbacec8c8c1@oracle.com> References: <589a71f1-2e3b-c2be-2dce-6633d31efeb1@oracle.com> <3760a9af-51b2-1657-e836-223e23254057@oracle.com> <4250380f-958b-34db-def1-afbacec8c8c1@oracle.com> Message-ID: <66c4cbd8-5d25-d513-a866-6f63175d62aa@oracle.com> On 6/17/20 2:01 PM, Jonathan Gibbons wrote: > > > On 6/17/20 10:29 AM, Vicente Romero wrote: >> >> >>> >>> Separately, as a separate RFE for toolbox tasks, we might want to >>> add a 'enablePreview' method to the task that cases the right >>> underlying options to be set. This could be a method on >>> AbstractTask, with possible overrides in the specific task classes.? >>> This would make it easier to mark a task as needing preview >>> features, and for the method call to be removed, eventually, when >>> the preview feature becomes standard. >> >> yep this could be done although it won't be a big change compared to >> the current situation I guess > > > Agreed it is not a big deal, but it just simplifies (a bit) the work > to update tests like these when the feature becomes standard. > yep that's a good point > -- Jon > Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jun 17 21:06:58 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 17 Jun 2020 23:06:58 +0200 Subject: RFR (15): JDK-8242214: NullPointerException in JDK 14 javac compiling a method reference In-Reply-To: <57b62f41-06c0-8e03-6ec3-241dd7df53bb@oracle.com> References: <57b62f41-06c0-8e03-6ec3-241dd7df53bb@oracle.com> Message-ID: <2c2361fa-d1dd-b3c5-6336-de34b834522e@oracle.com> The patch that provoked this was JDK-8234729: https://bugs.openjdk.java.net/browse/JDK-8234729 Before that, a method reference like this would not be unrolled into a lambda, and all would work. But now more method references are unrolled into lambdas, which is triggering the bug. Jan On 17. 06. 20 18:15, Vicente Romero wrote: > Hi Jan, > > Out of curiosity, as this is a regression, do we know what was the > change that introduced the issue and what was the related code like > before the change that provoked the regression? > > Thanks, > Vicente > > On 6/17/20 9:15 AM, Jan Lahoda wrote: >> Hi, >> >> There is a tricky issue related to unbound instance method references >> to a protected method in a superclass. >> >> Consider: >> ---base/Base.java: >> package base; >> >> public class Base { >> ??? protected void test() {} >> } >> ---impl/Impl.java: >> package impl; >> >> import base.Base; >> import java.util.function.Consumer; >> >> public class Impl extends Base { >> ??? Consumer consumer() { >> ??????? return Impl::test; >> ??? } >> } >> --- >> >> Since JDK-8234729, javac tries to expand the method reference to a >> lambda: >> (/*synthetic*/ Object rec$)->((Base)rec$).test() >> >> But this is not quite right (and crashes javac) - Impl cannot invoke >> test on "Base": >> ((Base) rec$).test(); >> >> it needs to invoke (if I understand JLS 6.6.2.1. correctly) test on >> "Impl": >> ((Impl) rec$).test(); >> >> So, the expanded lambda for the method reference should be: >> (/*synthetic*/ Object rec$)->((Impl)rec$).test() >> >> Which is what the proposed patch is trying to do. >> >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8242214/webrev.00/ >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8242214 >> >> How does this look? >> >> Thanks, >> ??? Jan > From vicente.romero at oracle.com Thu Jun 18 13:13:36 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 18 Jun 2020 09:13:36 -0400 Subject: RFR (15): JDK-8242214: NullPointerException in JDK 14 javac compiling a method reference In-Reply-To: <2c2361fa-d1dd-b3c5-6336-de34b834522e@oracle.com> References: <57b62f41-06c0-8e03-6ec3-241dd7df53bb@oracle.com> <2c2361fa-d1dd-b3c5-6336-de34b834522e@oracle.com> Message-ID: <49363538-dfda-acba-c2cf-43f6d1d75bfa@oracle.com> thanks for the research, the patch looks good, Vicente On 6/17/20 5:06 PM, Jan Lahoda wrote: > The patch that provoked this was JDK-8234729: > https://bugs.openjdk.java.net/browse/JDK-8234729 > > Before that, a method reference like this would not be unrolled into a > lambda, and all would work. But now more method references are > unrolled into lambdas, which is triggering the bug. > > Jan > > On 17. 06. 20 18:15, Vicente Romero wrote: >> Hi Jan, >> >> Out of curiosity, as this is a regression, do we know what was the >> change that introduced the issue and what was the related code like >> before the change that provoked the regression? >> >> Thanks, >> Vicente >> >> On 6/17/20 9:15 AM, Jan Lahoda wrote: >>> Hi, >>> >>> There is a tricky issue related to unbound instance method >>> references to a protected method in a superclass. >>> >>> Consider: >>> ---base/Base.java: >>> package base; >>> >>> public class Base { >>> ??? protected void test() {} >>> } >>> ---impl/Impl.java: >>> package impl; >>> >>> import base.Base; >>> import java.util.function.Consumer; >>> >>> public class Impl extends Base { >>> ??? Consumer consumer() { >>> ??????? return Impl::test; >>> ??? } >>> } >>> --- >>> >>> Since JDK-8234729, javac tries to expand the method reference to a >>> lambda: >>> (/*synthetic*/ Object rec$)->((Base)rec$).test() >>> >>> But this is not quite right (and crashes javac) - Impl cannot invoke >>> test on "Base": >>> ((Base) rec$).test(); >>> >>> it needs to invoke (if I understand JLS 6.6.2.1. correctly) test on >>> "Impl": >>> ((Impl) rec$).test(); >>> >>> So, the expanded lambda for the method reference should be: >>> (/*synthetic*/ Object rec$)->((Impl)rec$).test() >>> >>> Which is what the proposed patch is trying to do. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8242214/webrev.00/ >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8242214 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >> From vicente.romero at oracle.com Thu Jun 18 17:33:47 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 18 Jun 2020 13:33:47 -0400 Subject: RFR: JDK-8247849: permits clause of sealed interfaces should not allow parameterized types Message-ID: Please review fix for [1] at [2]. I forgot to check that the `permits` clause of interfaces can't list any parameterized type, which is already done for classes. Now I have extracted the common code for classes and interfaces, the one that takes care of the `permits` clause, to avoid this kind of issues in the future, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8247849 [2] http://cr.openjdk.java.net/~vromero/8247849/webrev.00/ From jan.lahoda at oracle.com Thu Jun 18 20:04:28 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 18 Jun 2020 22:04:28 +0200 Subject: RFR: JDK-8247849: permits clause of sealed interfaces should not allow parameterized types In-Reply-To: References: Message-ID: <97eb9667-e6f9-c24e-ba38-29b721bb1ee8@oracle.com> Hi Vicente, Overall looks good to me. My only comment for JavacParser is that maybe we could pass the string "class"/"interface" to the permitsClause method, instead of the boolean, although I do not feel strongly about that. In tests, in the second part that should verify that primitive types are not allowed, should there be the '#' markers instead of "Sub[]" in e.g.: sealed class C permits Sub[] {} => sealed class C permits # {} ;; (Tests for arrays of primitive types might also be included, for good measure.) Jan On 18. 06. 20 19:33, Vicente Romero wrote: > Please review fix for [1] at [2]. I forgot to check that the `permits` > clause of interfaces can't list any parameterized type, which is already > done for classes. Now I have extracted the common code for classes and > interfaces, the one that takes care of the `permits` clause, to avoid > this kind of issues in the future, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8247849 > [2] http://cr.openjdk.java.net/~vromero/8247849/webrev.00/ From vicente.romero at oracle.com Thu Jun 18 23:15:07 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 18 Jun 2020 19:15:07 -0400 Subject: RFR: JDK-8247849: permits clause of sealed interfaces should not allow parameterized types In-Reply-To: <97eb9667-e6f9-c24e-ba38-29b721bb1ee8@oracle.com> References: <97eb9667-e6f9-c24e-ba38-29b721bb1ee8@oracle.com> Message-ID: <5feeca64-f84e-94cc-19f2-e0c361f9de85@oracle.com> Hi Jan, On 6/18/20 4:04 PM, Jan Lahoda wrote: > Hi Vicente, > > Overall looks good to me. My only comment for JavacParser is that > maybe we could pass the string "class"/"interface" to the > permitsClause method, instead of the boolean, although I do not feel > strongly about that. sure will do > > In tests, in the second part that should verify that primitive types > are not allowed, should there be the '#' markers instead of "Sub[]" in > e.g.: > sealed class C permits Sub[] {} > => > sealed class C permits # {} sure, I rushed it sorry, > ;; > > (Tests for arrays of primitive types might also be included, for good > measure.) ok > > Jan Vicente > > On 18. 06. 20 19:33, Vicente Romero wrote: >> Please review fix for [1] at [2]. I forgot to check that the >> `permits` clause of interfaces can't list any parameterized type, >> which is already done for classes. Now I have extracted the common >> code for classes and interfaces, the one that takes care of the >> `permits` clause, to avoid this kind of issues in the future, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8247849 >> [2] http://cr.openjdk.java.net/~vromero/8247849/webrev.00/ From vicente.romero at oracle.com Thu Jun 18 23:30:16 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 18 Jun 2020 19:30:16 -0400 Subject: RFR: JDK-8247849: permits clause of sealed interfaces should not allow parameterized types In-Reply-To: <97eb9667-e6f9-c24e-ba38-29b721bb1ee8@oracle.com> References: <97eb9667-e6f9-c24e-ba38-29b721bb1ee8@oracle.com> Message-ID: what about [1]? Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8247849/webrev.01/ On 6/18/20 4:04 PM, Jan Lahoda wrote: > Hi Vicente, > > Overall looks good to me. My only comment for JavacParser is that > maybe we could pass the string "class"/"interface" to the > permitsClause method, instead of the boolean, although I do not feel > strongly about that. > > In tests, in the second part that should verify that primitive types > are not allowed, should there be the '#' markers instead of "Sub[]" in > e.g.: > sealed class C permits Sub[] {} > => > sealed class C permits # {} > ;; > > (Tests for arrays of primitive types might also be included, for good > measure.) > > Jan > > On 18. 06. 20 19:33, Vicente Romero wrote: >> Please review fix for [1] at [2]. I forgot to check that the >> `permits` clause of interfaces can't list any parameterized type, >> which is already done for classes. Now I have extracted the common >> code for classes and interfaces, the one that takes care of the >> `permits` clause, to avoid this kind of issues in the future, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8247849 >> [2] http://cr.openjdk.java.net/~vromero/8247849/webrev.00/ From jan.lahoda at oracle.com Mon Jun 22 14:19:53 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 22 Jun 2020 16:19:53 +0200 Subject: RFR: JDK-8247849: permits clause of sealed interfaces should not allow parameterized types In-Reply-To: References: <97eb9667-e6f9-c24e-ba38-29b721bb1ee8@oracle.com> Message-ID: <9b5cdc63-4172-6601-4c14-a7aa3739d509@oracle.com> Looks good to me. Jan On 19. 06. 20 1:30, Vicente Romero wrote: > what about [1]? > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8247849/webrev.01/ > > On 6/18/20 4:04 PM, Jan Lahoda wrote: >> Hi Vicente, >> >> Overall looks good to me. My only comment for JavacParser is that >> maybe we could pass the string "class"/"interface" to the >> permitsClause method, instead of the boolean, although I do not feel >> strongly about that. >> >> In tests, in the second part that should verify that primitive types >> are not allowed, should there be the '#' markers instead of "Sub[]" in >> e.g.: >> sealed class C permits Sub[] {} >> => >> sealed class C permits # {} >> ;; >> >> (Tests for arrays of primitive types might also be included, for good >> measure.) >> >> Jan >> >> On 18. 06. 20 19:33, Vicente Romero wrote: >>> Please review fix for [1] at [2]. I forgot to check that the >>> `permits` clause of interfaces can't list any parameterized type, >>> which is already done for classes. Now I have extracted the common >>> code for classes and interfaces, the one that takes care of the >>> `permits` clause, to avoid this kind of issues in the future, >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8247849 >>> [2] http://cr.openjdk.java.net/~vromero/8247849/webrev.00/ > From vicente.romero at oracle.com Mon Jun 22 22:29:33 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 22 Jun 2020 18:29:33 -0400 Subject: RFR: JDK-8247790: javac shouldn't allow type variable references from local static declarations Message-ID: <38331418-c8a5-8f63-b4cc-3ccc66a8138d@oracle.com> Hi, Please review the fix for [1] at [2]. The issue here is that local interfaces, enums and records shouldn't be allow to refer to type variables defined in an enclosing context. The compiler was checking for this if the type variables were defined by the enclosing class but references to type variables defined by the enclosing method were allowed. This patch is covering this gap, Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8247790 From jan.lahoda at oracle.com Tue Jun 23 09:12:06 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 23 Jun 2020 11:12:06 +0200 Subject: RFR: JDK-8247790: javac shouldn't allow type variable references from local static declarations In-Reply-To: <38331418-c8a5-8f63-b4cc-3ccc66a8138d@oracle.com> References: <38331418-c8a5-8f63-b4cc-3ccc66a8138d@oracle.com> Message-ID: <13097ca3-2fed-bcc3-9e63-0f8113c198af@oracle.com> Hi Vicente, I think this is a good direction, but probably not sufficient. My question would be if it is possible to piggy back more on the existing "staticOnly" flag, instead of checking the innermost environment. Specifically, consider this example: --- package javaapplication29; public class JavaApplication29 { public static void main(String[] args) { String hello = "hello"; interface I { public default void test1() { class X { public void test2() { System.err.println(hello); T t = null; } } new X().test2(); } } record R(int i) { public void test1() { class X { public void test2() { System.err.println(hello); T t = null; } } new X().test2(); } } enum E { A; public void test1() { class X { public void test2() { System.err.println(hello); T t = null; } } new X().test2(); } } new I() {}.test1(); new R(0).test1(); E.A.test1(); } } --- The behavior here does not seem to be quite right - there are no errors reported, but javac crashes on "E", produces wrong classfile for "I" and suspicious (but working) classfile for "R". Jan On 23. 06. 20 0:29, Vicente Romero wrote: > Hi, > > Please review the fix for [1] at [2]. The issue here is that local > interfaces, enums and records shouldn't be allow to refer to type > variables defined in an enclosing context. The compiler was checking for > this if the type variables were defined by the enclosing class but > references to type variables defined by the enclosing method were > allowed. This patch is covering this gap, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8247790 From adam.sotona at oracle.com Tue Jun 23 10:55:50 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 23 Jun 2020 12:55:50 +0200 Subject: RFR: [Backport] JDK11-8193367 annotated type variables bounds crash javac Message-ID: Hi, Please review backport of 8193367 into JDK 11. Original patch at http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5 has just minor conflicts in copyright headers and in one code fragment with JDK 11 repository. New patch differs in functionality with the original just in one block in src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java: < - if (tv.bound.getKind() == TypeKind.INTERSECTION) { < + if (tv.getUpperBound().getKind() == TypeKind.INTERSECTION) { versus: > - return isIntersectionOrUnionType(tv.bound); > + return isIntersectionOrUnionType(tv.getUpperBound()); Patched JDK 11 passed all Tier 1, 2 and 3 tests. Original JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 Webrev: http://cr.openjdk.java.net/~asotona/8193367/webrev.00/ Backport JBS: https://bugs.openjdk.java.net/browse/JDK-8248014 Thanks, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jun 23 16:59:53 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 23 Jun 2020 12:59:53 -0400 Subject: RFR: JDK-8247849: permits clause of sealed interfaces should not allow parameterized types In-Reply-To: <9b5cdc63-4172-6601-4c14-a7aa3739d509@oracle.com> References: <97eb9667-e6f9-c24e-ba38-29b721bb1ee8@oracle.com> <9b5cdc63-4172-6601-4c14-a7aa3739d509@oracle.com> Message-ID: thanks for the review, Vicente On 6/22/20 10:19 AM, Jan Lahoda wrote: > Looks good to me. > > Jan > > On 19. 06. 20 1:30, Vicente Romero wrote: >> what about [1]? >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8247849/webrev.01/ >> >> On 6/18/20 4:04 PM, Jan Lahoda wrote: >>> Hi Vicente, >>> >>> Overall looks good to me. My only comment for JavacParser is that >>> maybe we could pass the string "class"/"interface" to the >>> permitsClause method, instead of the boolean, although I do not feel >>> strongly about that. >>> >>> In tests, in the second part that should verify that primitive types >>> are not allowed, should there be the '#' markers instead of "Sub[]" >>> in e.g.: >>> sealed class C permits Sub[] {} >>> => >>> sealed class C permits # {} >>> ;; >>> >>> (Tests for arrays of primitive types might also be included, for >>> good measure.) >>> >>> Jan >>> >>> On 18. 06. 20 19:33, Vicente Romero wrote: >>>> Please review fix for [1] at [2]. I forgot to check that the >>>> `permits` clause of interfaces can't list any parameterized type, >>>> which is already done for classes. Now I have extracted the common >>>> code for classes and interfaces, the one that takes care of the >>>> `permits` clause, to avoid this kind of issues in the future, >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8247849 >>>> [2] http://cr.openjdk.java.net/~vromero/8247849/webrev.00/ >> From vicente.romero at oracle.com Thu Jun 25 19:57:37 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 25 Jun 2020 15:57:37 -0400 Subject: RFR: [Backport] JDK11-8193367 annotated type variables bounds crash javac In-Reply-To: References: Message-ID: Hi Adam, On 6/23/20 6:55 AM, Adam Sotona wrote: > Hi, > Please review backport of?8193367 into JDK 11. > > Original patch at > http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5?has just minor > conflicts in copyright headers and in one code fragment with JDK 11 > repository. > > New patch differs in functionality with the original just in one block > in > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java: > < -? ? ? ? ? ? ? ? ? ? ? ? ? ??if (tv.bound.getKind() == > TypeKind.INTERSECTION) { > < +? ? ? ? ? ? ? ? ? ? ? ? ? ??if (tv.getUpperBound().getKind() == > TypeKind.INTERSECTION) { this difference seems like an important semantic change compared to what the original patch is doing. I guess you will need to port method: `boolean isIntersectionOrUnionType(Type t)` too > versus: > > -? ? ? ? ? ? ? ? ? ? ? ??return isIntersectionOrUnionType(tv.bound); > > +? ? ? ? ? ? ? ? ? ? ? ??return > isIntersectionOrUnionType(tv.getUpperBound()); > > Patched JDK 11 passed all Tier 1, 2 and 3 tests. > > Original JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 > Webrev: http://cr.openjdk.java.net/~asotona/8193367/webrev.00/ > Backport JBS: https://bugs.openjdk.java.net/browse/JDK-8248014 > > Thanks, > Adam Thanks, Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Fri Jun 26 06:35:32 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Fri, 26 Jun 2020 08:35:32 +0200 Subject: RFR: [Backport] JDK11-8193367 annotated type variables bounds crash javac In-Reply-To: References: Message-ID: <929EA4BC-BD7F-4845-9F4D-D7910F0ECC82@oracle.com> Including jdk-update-dev Thanks, Adam > On 23 Jun 2020, at 12:55, Adam Sotona wrote: > > Hi, > Please review backport of 8193367 into JDK 11. > > Original patch at http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5 has just minor conflicts in copyright headers and in one code fragment with JDK 11 repository. > > New patch differs in functionality with the original just in one block in src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java: > < - if (tv.bound.getKind() == TypeKind.INTERSECTION) { > < + if (tv.getUpperBound().getKind() == TypeKind.INTERSECTION) { > versus: > > - return isIntersectionOrUnionType(tv.bound); > > + return isIntersectionOrUnionType(tv.getUpperBound()); > > Patched JDK 11 passed all Tier 1, 2 and 3 tests. > > Original JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 > Webrev: http://cr.openjdk.java.net/~asotona/8193367/webrev.00/ > Backport JBS: https://bugs.openjdk.java.net/browse/JDK-8248014 > > Thanks, > Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Fri Jun 26 06:39:17 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Fri, 26 Jun 2020 08:39:17 +0200 Subject: RFR: [Backport] JDK11-8193367 annotated type variables bounds crash javac In-Reply-To: References: Message-ID: <7BB770AF-AB6A-447F-A8F2-E850851F365D@oracle.com> Hi Vicente, I found the code isIntersectionOrUnionType(Type t) is already there - that is why the patch conflict appears. Thanks, Adam > On 25 Jun 2020, at 21:57, Vicente Romero wrote: > > Hi Adam, > > On 6/23/20 6:55 AM, Adam Sotona wrote: >> Hi, >> Please review backport of 8193367 into JDK 11. >> >> Original patch at http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5 has just minor conflicts in copyright headers and in one code fragment with JDK 11 repository. >> >> New patch differs in functionality with the original just in one block in src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java: >> < - if (tv.bound.getKind() == TypeKind.INTERSECTION) { >> < + if (tv.getUpperBound().getKind() == TypeKind.INTERSECTION) { > > this difference seems like an important semantic change compared to what the original patch is doing. I guess you will need to port method: `boolean isIntersectionOrUnionType(Type t)` too >> versus: >> > - return isIntersectionOrUnionType(tv.bound); >> > + return isIntersectionOrUnionType(tv.getUpperBound()); >> >> Patched JDK 11 passed all Tier 1, 2 and 3 tests. >> >> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 >> Webrev: http://cr.openjdk.java.net/~asotona/8193367/webrev.00/ >> Backport JBS: https://bugs.openjdk.java.net/browse/JDK-8248014 >> >> Thanks, >> Adam > > Thanks, > Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Fri Jun 26 10:40:43 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 26 Jun 2020 11:40:43 +0100 Subject: RFR and sponsor: 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8 Message-ID: Hi, Please can I request a sponsor and review for the fix to bug JDK-8248231? (https://bugs.openjdk.java.net/browse/JDK-8248231) webrev for review: http://cr.openjdk.java.net/~aleonard/8248231/webrev.00/ The problem with incorrect encoding of deserializeLambda was discovered by the openj9 VM team on a platform where the default encoding is not UTF-8 (eg.EBCDIC platforms), which eluded to the problem that the deserializeLambda was not been encoded correctly when the lambda char did not map to an ASCII compatible range. The fix testcase replicates the problem by using a suitable UTF-8 char that does not map. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Jun 26 13:13:06 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 26 Jun 2020 15:13:06 +0200 Subject: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3 In-Reply-To: <85933330-a0e2-74cf-876c-42b64eb28482@oracle.com> References: <87877fd1-5413-7518-a2e6-d6d2132f6356@oracle.com> <3f816bd3-bc9d-8f94-db98-94fd0423948d@oracle.com> <85933330-a0e2-74cf-876c-42b64eb28482@oracle.com> Message-ID: <4774b5e1-0b78-bba0-95f2-445cdcab72b3@oracle.com> Hi, I propose to split the data update (for JDK 15 and for backports) and the tool/CreateSymbols update (for JDK 16+). So I've created: https://bugs.openjdk.java.net/browse/JDK-8248405 for the latter. Lets keep JDK-8244763 only for the former, i.e. for this patch: http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-data/ I believe the data patch is reviewed, and is not controversial. Please let me know if you see any issues with this split. Thanks, Jan On 01. 06. 20 10:07, Jan Lahoda wrote: > Further testing revealed some issues with the patch, especially: > -use of un-encoded version when deleting the old data for the version > (so the data deletion failed for versions > 9) > -need to delete old module data as well > -when searching for existing methods and fields, we need to continue the > search to find the best existing candidate (the code still had a for > loop break, so only the first match was found). > > I apologize for missing those in the first review. > > Delta webrev: > http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-01-create-symbols/ > > Full updated webrev: > http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-create-symbols/ > > Does this look OK? > > Thanks! > ??? Jan > > On 28. 05. 20 16:47, Jonathan Gibbons wrote: >> Looks good to me. >> >> -- Jon >> >> On 5/18/20 9:36 AM, Jan Lahoda wrote: >>> I apologize, I used a wrong patch for the "data" webrev. The "class >>> name java/util/jar/Attributes$Name" entry in java.base-7.sym.txt is >>> first adding field descriptions, and then removing the old ones: >>> --- >>>> class name java/util/jar/Attributes$Name >>>> field name EXTENSION_INSTALLATION descriptor >>>> Ljava/util/jar/Attributes$Name; flags 19 >>>> field name IMPLEMENTATION_VENDOR_ID descriptor >>>> Ljava/util/jar/Attributes$Name; flags 19 >>>> field name IMPLEMENTATION_URL descriptor >>>> Ljava/util/jar/Attributes$Name; flags 19 >>>> -field name EXTENSION_INSTALLATION descriptor >>>> Ljava/util/jar/Attributes$Name; >>>> -field name IMPLEMENTATION_VENDOR_ID descriptor >>>> Ljava/util/jar/Attributes$Name; >>>> -field name IMPLEMENTATION_URL descriptor >>>> Ljava/util/jar/Attributes$Name;--- >>> >>> The correct order (and the order generated by the tool in the >>> webrev.00-create-symbols/ webrev) is to first remove the field >>> descriptions and then add the new ones: >>> --- >>>> class name java/util/jar/Attributes$Name >>>> -field name EXTENSION_INSTALLATION descriptor >>>> Ljava/util/jar/Attributes$Name; >>>> -field name IMPLEMENTATION_VENDOR_ID descriptor >>>> Ljava/util/jar/Attributes$Name; >>>> -field name IMPLEMENTATION_URL descriptor >>>> Ljava/util/jar/Attributes$Name; >>>> field name EXTENSION_INSTALLATION descriptor >>>> Ljava/util/jar/Attributes$Name; flags 19 >>>> field name IMPLEMENTATION_VENDOR_ID descriptor >>>> Ljava/util/jar/Attributes$Name; flags 19 >>>> field name IMPLEMENTATION_URL descriptor >>>> Ljava/util/jar/Attributes$Name; flags 19 >>> --- >>> >>> An updated webrev is the correct data is here: >>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-data/ >>> >>> The only change is the above difference in order of entries in >>> Attributes$Name. >>> >>> Sorry for trouble. >>> >>> Jan >>> >>> On 18. 05. 20 16:55, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Some new APIs have been introduced in JSR 337 MR3 (JDK 8). We should >>>> update the historical data for JDK 8 with these new APIs. >>>> >>>> As this was the first time we need to update data for a release that >>>> other release data use as a baseline, it was necessary to improve >>>> the CreateSymbols tool a little: >>>> -adding ability to ignore synchronized and native flags for methods >>>> (as these don't affect the API) >>>> -when analyzing a new entry (method/field/class), and multiple >>>> existing entries compatible with the new one exist, the existing >>>> entry that matches the baseline is chosen (this helps to eliminate >>>> unnecessary entries, esp. when the synchronized or native flag changes) >>>> -when replacing/updating a release data, the original approach was >>>> to remove the data for the release, and read them from classfiles, >>>> and build the record again from scratch. This does not work well for >>>> baseline data, so the new approach is: >>>> --keep all the existing data >>>> --the new data are load into a new auxiliary slot, called "$" >>>> --the old data for the given release are deleted >>>> --the auxiliary release is renamed from "$" to the correct release name >>>> >>>> Together these changes allow to minimize the updates to JDK 8 data, >>>> to mostly only changes in the MR3, with some extra changes like >>>> new/removed overrides (where the superclass has the method that >>>> is/was overridden). >>>> >>>> The proposed changes to CreateSymbols are: >>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-create-symbols/ >>>> >>>> The proposed updates to the historical data are: >>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-data/ >>>> >>>> Note the changes only apply for JDK 8 historical data, so JDK 8 data >>>> are updated, and JDK 7 and 9 data undo the changes. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244763 >>>> >>>> The intent is to backport to JDK 11u. >>>> >>>> How does this look? >>>> >>>> Thanks! >>>> >>>> Jan From vicente.romero at oracle.com Fri Jun 26 16:27:14 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 26 Jun 2020 12:27:14 -0400 Subject: RFR: [Backport] JDK11-8193367 annotated type variables bounds crash javac In-Reply-To: <7BB770AF-AB6A-447F-A8F2-E850851F365D@oracle.com> References: <7BB770AF-AB6A-447F-A8F2-E850851F365D@oracle.com> Message-ID: but isn't the case the the original patch is returning true if the upper bound of the type variable is a union or an intersection while the patch adapted to 11 is only returning true if that upper bound is an intersection? what would happen if is is an union? Vicente On 6/26/20 2:39 AM, Adam Sotona wrote: > Hi Vicente, > I found the code isIntersectionOrUnionType(Type t) is already there - > that is why the patch conflict appears. > > Thanks, > Adam > >> On 25 Jun 2020, at 21:57, Vicente Romero > > wrote: >> >> Hi Adam, >> >> On 6/23/20 6:55 AM, Adam Sotona wrote: >>> Hi, >>> Please review backport of?8193367 into JDK 11. >>> >>> Original patch at >>> http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5?has just minor >>> conflicts in copyright headers and in one code fragment with JDK 11 >>> repository. >>> >>> New patch differs in functionality with the original just in one >>> block in >>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java: >>> < -? ? ? ? ? ? ? ? ? ? ? ? ? ??if (tv.bound.getKind() == >>> TypeKind.INTERSECTION) { >>> < +? ? ? ? ? ? ? ? ? ? ? ? ? ??if (tv.getUpperBound().getKind() == >>> TypeKind.INTERSECTION) { >> >> this difference seems like an important semantic change compared to >> what the original patch is doing. I guess you will need to port >> method: `boolean isIntersectionOrUnionType(Type t)` too >>> versus: >>> > -? ? ? ? ? ? ? ? ? ? ? ??return isIntersectionOrUnionType(tv.bound); >>> > +? ? ? ? ? ? ? ? ? ? ? ??return >>> isIntersectionOrUnionType(tv.getUpperBound()); >>> >>> Patched JDK 11 passed all Tier 1, 2 and 3 tests. >>> >>> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 >>> Webrev: http://cr.openjdk.java.net/~asotona/8193367/webrev.00/ >>> Backport JBS: https://bugs.openjdk.java.net/browse/JDK-8248014 >>> >>> Thanks, >>> Adam >> >> Thanks, >> Vicente > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Jun 26 22:01:34 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 26 Jun 2020 15:01:34 -0700 Subject: =?UTF-8?Q?JDK_16_RFR_of_JDK-8248428=3a_Cleanup_pass_on_javax=2elang?= =?UTF-8?B?Lm1vZGVsIGRvY3PigIs=?= Message-ID: <08ee61cf-c95a-3be6-97e3-15d5ef90b496@oracle.com> Hello, Please review the changes for ??? JDK-8248428: Cleanup pass on javax.lang.model docs? ??? http://cr.openjdk.java.net/~darcy/8248428.0/ a small pass to polish the docs, many new @jls tags added in the type package. Thanks, -Joe From jonathan.gibbons at oracle.com Fri Jun 26 22:14:09 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 26 Jun 2020 15:14:09 -0700 Subject: =?UTF-8?Q?Re=3a_JDK_16_RFR_of_JDK-8248428=3a_Cleanup_pass_on_javax?= =?UTF-8?B?LmxhbmcubW9kZWwgZG9jc+KAiw==?= In-Reply-To: <08ee61cf-c95a-3be6-97e3-15d5ef90b496@oracle.com> References: <08ee61cf-c95a-3be6-97e3-15d5ef90b496@oracle.com> Message-ID: <36c4c314-441f-8dec-b79d-2659a1d11d01@oracle.com> +1. I didn't check the section numbers for their accuracy; let me know if you would like them checked as well.? We could/should try and automate that. -- Jon On 6/26/20 3:01 PM, Joe Darcy wrote: > Hello, > > Please review the changes for > > ??? JDK-8248428: Cleanup pass on javax.lang.model docs? > ??? http://cr.openjdk.java.net/~darcy/8248428.0/ > > a small pass to polish the docs, many new @jls tags added in the type > package. > > Thanks, > > -Joe > From alexfoster at hotmail.ca Sun Jun 28 22:08:20 2020 From: alexfoster at hotmail.ca (Alex Foster) Date: Sun, 28 Jun 2020 22:08:20 +0000 Subject: Close DelegatingJavaFileManager used with release argument Message-ID: Hi, When the --release option is used with JavacTool.getTask a DelegatingJavaFileManager is installed in the context. I don't see any way to close this file manager to close the jar files that its release file manager is holding. If there is a way to close it then how would I do that? Otherwise can a way please be added? Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Jun 29 01:09:59 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 28 Jun 2020 18:09:59 -0700 Subject: Close DelegatingJavaFileManager used with release argument In-Reply-To: References: Message-ID: <7aae2eb8-eb71-b5d9-3a92-6d826533361f@oracle.com> Hi Alex, Thanks for the report. Filed as https://bugs.openjdk.java.net/browse/JDK-8248449 -- Jon On 6/28/20 3:08 PM, Alex Foster wrote: > H i, > > When the --release option is used with JavacTool.getTask a > DelegatingJavaFileManager is installed in the context. I don't see any > way to close this file manager to close the jar files that its release > file manager is holding. If there is a way to close it then how would > I do that? Otherwise can a way please be added? > > Thanks, > Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Mon Jun 29 09:36:23 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 29 Jun 2020 11:36:23 +0200 Subject: RFR: [Backport] JDK11-8193367 annotated type variables bounds crash javac In-Reply-To: References: <7BB770AF-AB6A-447F-A8F2-E850851F365D@oracle.com> Message-ID: <21A12194-2F55-4E6D-8D30-B8143781DBFA@oracle.com> I've double-checked it, the patch is only replacing .bound with .getUpperBound() and implementing the .getUpperBound(). The semantical change by implementing .isIntersectionOrUnionType() comes from some other patch. Adam > On 26 Jun 2020, at 18:27, Vicente Romero wrote: > > but isn't the case the the original patch is returning true if the upper bound of the type variable is a union or an intersection while the patch adapted to 11 is only returning true if that upper bound is an intersection? what would happen if is is an union? > > Vicente > > On 6/26/20 2:39 AM, Adam Sotona wrote: >> Hi Vicente, >> I found the code isIntersectionOrUnionType(Type t) is already there - that is why the patch conflict appears. >> >> Thanks, >> Adam >> >>> On 25 Jun 2020, at 21:57, Vicente Romero > wrote: >>> >>> Hi Adam, >>> >>> On 6/23/20 6:55 AM, Adam Sotona wrote: >>>> Hi, >>>> Please review backport of 8193367 into JDK 11. >>>> >>>> Original patch at http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5 has just minor conflicts in copyright headers and in one code fragment with JDK 11 repository. >>>> >>>> New patch differs in functionality with the original just in one block in src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java: >>>> < - if (tv.bound.getKind() == TypeKind.INTERSECTION) { >>>> < + if (tv.getUpperBound().getKind() == TypeKind.INTERSECTION) { >>> >>> this difference seems like an important semantic change compared to what the original patch is doing. I guess you will need to port method: `boolean isIntersectionOrUnionType(Type t)` too >>>> versus: >>>> > - return isIntersectionOrUnionType(tv.bound); >>>> > + return isIntersectionOrUnionType(tv.getUpperBound()); >>>> >>>> Patched JDK 11 passed all Tier 1, 2 and 3 tests. >>>> >>>> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 >>>> Webrev: http://cr.openjdk.java.net/~asotona/8193367/webrev.00/ >>>> Backport JBS: https://bugs.openjdk.java.net/browse/JDK-8248014 >>>> >>>> Thanks, >>>> Adam >>> >>> Thanks, >>> Vicente >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Jun 29 14:01:58 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 29 Jun 2020 10:01:58 -0400 Subject: Directly initialized final field is not constant folded later when prefix with "this" In-Reply-To: References: <35A135A0-A8FF-45B6-A40E-B4B9FA6A5791@freenet.de> Message-ID: <600620d9-f05a-82ac-54a2-14722b4df19a@oracle.com> It goes back to the why we define constant expressions at all.? The goal in defining constant expression, and allowing certain static-compile-time optimizations regarding constant expressions, was _not_ to support every possible optimization that could be imagined regarding constants -- far from it.? It was to define a simple, easy to understand rule to address the most obvious of foldable constants, such as `1 + 1`, or `1 + staticFinalField`. Sure, we could patch this particular corner case, but where's the benefit?? So we can encourage people to use this long-discouraged idiom?? And, the more complex we make the definition of compile-time constant, the more new corner cases we create, the harder it is to reason about, and the more likely the _next_ corner case that comes along will say "well, you did it for `this.x`, and this is 10x more important, so ..."? Fast forward, and this rule has 100 clauses.? No thank you! Bottom line: there's negative value in changing it now.? The balance might have been different in 1995, but were I in that room, I would probably still draft it this way. On 6/11/2020 3:18 PM, Roland Illig wrote: > > A constant expression is ... > > > > *? Simple names (?6.5.6.1) that refer to constant variables > >??? (?4.12.4). > > > > *? Qualified names (?6.5.6.2) of the form TypeName.Identifier > >??? that refer to constant variables (?4.12.4). > > I wouldn't have expected that this makes a difference, but since `this` > is not a TypeName, the compiler works as specified. > > This leaves the question why `this.field` was not defined to be > equivalent to the unqualified `field` in the first place? Can anyone > shed a light on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Jun 29 14:56:20 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 29 Jun 2020 10:56:20 -0400 Subject: Directly initialized final field is not constant folded later when prefix with "this" In-Reply-To: <60759092-5b51-9761-3ec9-42eb8e2ab6d8@gmx.de> References: <35A135A0-A8FF-45B6-A40E-B4B9FA6A5791@freenet.de> <600620d9-f05a-82ac-54a2-14722b4df19a@oracle.com> <60759092-5b51-9761-3ec9-42eb8e2ab6d8@gmx.de> Message-ID: <4f1234db-ec39-a3c1-5898-c5addfbf5a39@oracle.com> That you can access static members through instances is widely acknowledged to be a mistake in the language design (and has caused problems as we have evolved the language.)? It is a good example of the harm one can do when you design language features with the attitude of "well, it's not actually sensible, but we know what the user meant, so we'll be nice."? Nothing wrong with being nice, but it creates big problems for future generations for the sake of a very small benefit in the present. For example, when we added static methods to interfaces in 8, this historical mistake left us with bad choices -- extending this behavior to multiple inheritance would have been terrible (multiple inheritance of static methods, among other things!), so we pruned this "feature" at its then-current boundary.? (But that is also not great, since the meaning of `x.m()` now depends on whether the static type of `x` is a class or interface, or on whether `m()` is declared in a class or interface.) On 6/29/2020 10:33 AM, Roland Illig wrote: > Thanks for the explanation, I wasn't aware that this idiom was > long-discouraged.? I agree that the existing definition of "constant > variable" and "constant expression" and "final variable" is already > confusing enough.? It's an interesting detail to remember, though > probably more suited for the Java Puzzlers book rather than daily > average code. > > On 29.06.2020 16:01, Brian Goetz wrote: >> [...] >> >> Sure, we could patch this particular corner case, but where's the >> benefit?? So we can encourage people to use this long-discouraged >> idiom?? [...] >> >> On 6/11/2020 3:18 PM, Roland Illig wrote: >>> > A constant expression is ... >>> > >>> > *? Simple names (?6.5.6.1) that refer to constant variables >>> >??? (?4.12.4). >>> > >>> > *? Qualified names (?6.5.6.2) of the form TypeName.Identifier >>> >??? that refer to constant variables (?4.12.4). >>> >>> I wouldn't have expected that this makes a difference, but since `this` >>> is not a TypeName, the compiler works as specified. >>> >>> This leaves the question why `this.field` was not defined to be >>> equivalent to the unqualified `field` in the first place? Can anyone >>> shed a light on this? >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jun 29 18:53:48 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 29 Jun 2020 14:53:48 -0400 Subject: RFR: JDK-8247790: javac shouldn't allow type variable references from local static declarations In-Reply-To: <13097ca3-2fed-bcc3-9e63-0f8113c198af@oracle.com> References: <38331418-c8a5-8f63-b4cc-3ccc66a8138d@oracle.com> <13097ca3-2fed-bcc3-9e63-0f8113c198af@oracle.com> Message-ID: Hi Jan, Thanks for your review, there have been a lot of internal discussion about the spec and the examples you proposed. Given that this spec is new, it is hard to see where the lines are. Your examples are good, thanks, and I have added them as additional tests. I didn't see how to leverage on the existing "staticOnly" flag. Instead in order to implement this assertion in the spec see [1]: * If the type name appears in a nested class or interface declaration of /C/, then the immediately enclosing class or interface declaration of the type name must specify an inner class (8.1.3 ) declared in the body of /m/, or an inner class of an inner class declared in the body of /m/. I added a helper method named: "isInnerClassOfMethod", but this one still needs the original environment, as an alternative I can pass the enclosing class relative to the original environment but still, what do you think? Thanks, Vicente [1] https://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/local-statics-jls.html#jls-6.5.5.1 new webrev: http://cr.openjdk.java.net/~vromero/8247790/webrev.01/ On 6/23/20 5:12 AM, Jan Lahoda wrote: > Hi Vicente, > > I think this is a good direction, but probably not sufficient. My > question would be if it is possible to piggy back more on the existing > "staticOnly" flag, instead of checking the innermost environment. > > Specifically, consider this example: > --- > package javaapplication29; > > public class JavaApplication29 { > > ??? public static void main(String[] args) { > ??????? String hello = "hello"; > ??????? interface I { > ??????????? public default void test1() { > ??????????????? class X { > ??????????????????? public void test2() { > ??????????????????????? System.err.println(hello); > ??????????????????????? T t = null; > ??????????????????? } > ??????????????? } > ??????????????? new X().test2(); > ??????????? } > ??????? } > ??????? record R(int i) { > ??????????? public void test1() { > ??????????????? class X { > ??????????????????? public void test2() { > ??????????????????????? System.err.println(hello); > ??????????????????????? T t = null; > ??????????????????? } > ??????????????? } > ??????????????? new X().test2(); > ??????????? } > ??????? } > ??????? enum E { > ??????????? A; > ??????????? public void test1() { > ??????????????? class X { > ??????????????????? public void test2() { > ??????????????????????? System.err.println(hello); > ??????????????????????? T t = null; > ??????????????????? } > ??????????????? } > ??????????????? new X().test2(); > ??????????? } > ??????? } > ??????? new I() {}.test1(); > ??????? new R(0).test1(); > ??????? E.A.test1(); > ??? } > > } > --- > > The behavior here does not seem to be quite right - there are no > errors reported, but javac crashes on "E", produces wrong classfile > for "I" and suspicious (but working) classfile for "R". > > Jan > > On 23. 06. 20 0:29, Vicente Romero wrote: >> Hi, >> >> Please review the fix for [1] at [2]. The issue here is that local >> interfaces, enums and records shouldn't be allow to refer to type >> variables defined in an enclosing context. The compiler was checking >> for this if the type variables were defined by the enclosing class >> but references to type variables defined by the enclosing method were >> allowed. This patch is covering this gap, >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8247790/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8247790 -------------- next part -------------- An HTML attachment was scrubbed... URL: