} tag. */ > 81: PREAMBLE, > 82: /** The initial part of a doc comment, or the rich-text content of a block tag. */ Curious: is "initial part of a doc comment" the same as what we now call [main description](https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html#main-description)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13431#discussion_r1171511438 From jjg at openjdk.org Wed Apr 19 15:37:52 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 19 Apr 2023 15:37:52 GMT Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and inlineContent [v6] In-Reply-To: <0gL8MnSPib75mKtDq3afmFbUMNv-vsUMMwPDPB2CXKw=.aced4c42-fb29-413d-86bb-50815041165f@github.com> References: <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com> <0gL8MnSPib75mKtDq3afmFbUMNv-vsUMMwPDPB2CXKw=.aced4c42-fb29-413d-86bb-50815041165f@github.com> Message-ID: On Wed, 19 Apr 2023 15:27:17 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> address review feedback > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 82: > >> 80: /** The initial part of an HTML file up to and including the {@code body} and possible {@code

} tag. */ >> 81: PREAMBLE, >> 82: /** The initial part of a doc comment, or the rich-text content of a block tag. */ > > Curious: is "initial part of a doc comment" the same as what we now call [main description](https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html#main-description)? Yes, will change, for clarification and to better distinguish it from the description for PREAMBLE ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13431#discussion_r1171522500 From vromero at openjdk.org Wed Apr 19 15:39:53 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 19 Apr 2023 15:39:53 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

Message-ID: <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com> On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: > > - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type. > - Reflecting review comments. > - Fixing exhaustiveness for unsealed supertype pattern. > - No need to enable features after error reported. > - SwitchBootstraps.typeSwitch should not initialize enum classes. > - A prototype of avoiding enum initialization. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279: > 277: } > 278: > 279: private static int lazyDoEnumSwitch(Enum target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class enumClass, MutableCallSite callSite) throws Throwable { out of curiosity, under what conditions the `startIndex` would be different from `0`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1171523963 From jjg at openjdk.org Wed Apr 19 15:48:51 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 19 Apr 2023 15:48:51 GMT Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and inlineContent [v6] In-Reply-To: References: <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com> <0gL8MnSPib75mKtDq3afmFbUMNv-vsUMMwPDPB2CXKw=.aced4c42-fb29-413d-86bb-50815041165f@github.com> Message-ID: On Wed, 19 Apr 2023 15:34:59 GMT, Jonathan Gibbons wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 82: >> >>> 80: /** The initial part of an HTML file up to and including the {@code body} and possible {@code

} tag. */ >>> 81: PREAMBLE, >>> 82: /** The initial part of a doc comment, or the rich-text content of a block tag. */ >> >> Curious: is "initial part of a doc comment" the same as what we now call [main description](https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html#main-description)? > > Yes, will change, for clarification and to better distinguish it from the description for PREAMBLE Or no. As a phase, it is the part between the PREAMBLE and POSTAMBLE. It is when reading the main description, and rich-text content of block tags, in both cases excluding the content of inline tags, which are read with INLINE phase. I'll definitely have to work on this text. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13431#discussion_r1171536298 From prappo at openjdk.org Wed Apr 19 15:52:48 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 19 Apr 2023 15:52:48 GMT Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and inlineContent [v6] In-Reply-To: <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com> References: <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com> Message-ID: On Wed, 19 Apr 2023 14:17:57 GMT, Jonathan Gibbons wrote: >> Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment. >> >> **Note:** This is dependent on PR #13362, to convert `DocCommentParser` to use enhanced switch. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > address review feedback src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 84: > 82: /** The initial part of a doc comment, or the rich-text content of a block tag. */ > 83: BODY, > 84: /** The end of an HTML file, from and including the {@code

} or {@code } tag. */ Shouldn't there be the adjective _possible_ similarly to PREAMBLE? I assume, the idea here is as follows. The `body` element encloses the optional `main` element. If the `main` element is enclosed, then the PREAMBLE phase ends with the `main` start tag and the POSTAMBLE phase starts with the `main` end tag. Otherwise, PREAMBLE ends with the `body` start tag and POSTAMBLE starts with the `body` end tag. Is this correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13431#discussion_r1171541012 From jjg at openjdk.org Wed Apr 19 16:33:48 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 19 Apr 2023 16:33:48 GMT Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and inlineContent [v6] In-Reply-To: References: <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com> <0gL8MnSPib75mKtDq3afmFbUMNv-vsUMMwPDPB2CXKw=.aced4c42-fb29-413d-86bb-50815041165f@github.com>

Message-ID: <7ltJQGZxz9f_uH3ye0idchLrzuh8fcW4AP65OkTiMU8=.e546be51-96c0-4562-9198-e65d6f703de1@github.com> On Wed, 19 Apr 2023 15:45:57 GMT, Jonathan Gibbons wrote: >> Yes, will change, for clarification and to better distinguish it from the description for PREAMBLE > > Or no. As a phase, it is the part between the PREAMBLE and POSTAMBLE. It is when reading the main description, and rich-text content of block tags, in both cases excluding the content of inline tags, which are read with INLINE phase. > > I'll definitely have to work on this text. Functionally, `BODY` is unchanged. The only change to `Phase` is to add `INLINE` -- as well as trying to document it all. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13431#discussion_r1171590092 From jjg at openjdk.org Wed Apr 19 16:40:47 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 19 Apr 2023 16:40:47 GMT Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and inlineContent [v6] In-Reply-To: References: <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com> Message-ID: <5Z8kU8frP7kTUSGLjXhw0CJgEo4XaPTW7dkYY5KU9WU=.cb203fbf-c008-4df0-8fbd-a0c5f94529ef@github.com> On Wed, 19 Apr 2023 15:49:44 GMT, Pavel Rappo wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> address review feedback > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 84: > >> 82: /** The initial part of a doc comment, or the rich-text content of a block tag. */ >> 83: BODY, >> 84: /** The end of an HTML file, from and including the {@code

} or {@code } tag. */ > > Shouldn't there be the adjective _possible_ similarly to PREAMBLE? I assume, the idea here is as follows. The `body` element encloses the optional `main` element. If the `main` element is enclosed, then the PREAMBLE phase ends with the `main` start tag and the POSTAMBLE phase starts with the `main` end tag. Otherwise, PREAMBLE ends with the `body` start tag and POSTAMBLE starts with the `body` end tag. Is this correct? Yes, that's essentially correct, but the code is somewhat more tolerant. The wording was trying to express the implementation detail that PREAMBLE goes up to the `` and then checks for `

`, whereas the BODY ends (and PREAMBLE begins) with _either_ `

` or ``, whichever is found first. In other words, we lazily accept a malformed file with `...

...`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13431#discussion_r1171597038 From vromero at openjdk.org Wed Apr 19 16:47:52 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 19 Apr 2023 16:47:52 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

Message-ID: On Tue, 18 Apr 2023 09:13:01 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: > > - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type. > - Reflecting review comments. > - Fixing exhaustiveness for unsealed supertype pattern. > - No need to enable features after error reported. > - SwitchBootstraps.typeSwitch should not initialize enum classes. > - A prototype of avoiding enum initialization. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 201: > 199: /** Are unconditional patterns in instanceof allowed > 200: */ > 201: private boolean allowUnconditionalPatternsInstanceOf; so I guess this field can be made final now src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 909: > 907: > 908: Set permitted = allPermittedSubTypes(clazz, csym -> { > 909: Type instantiated = infer.instantiatePatternType(selectorType, csym); for some cases, when there are no type parameters, this invocation is a no-op, do we really need inference at this point? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1171830887 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1171936405 From christoph.dreis at freenet.de Thu Apr 20 08:52:20 2023 From: christoph.dreis at freenet.de (christoph.dreis at freenet.de) Date: Thu, 20 Apr 2023 08:52:20 +0000 Subject: Reduce allocations in List.map() when it is empty Message-ID: Hi, I've been profiling our compilation tasks lately and noticed that List.map is under the top consumers. There are probably more aggressive options to optimize List.map , but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings. See https://github.com/openjdk/jdk/pull/13407 for more information and some screenshots. In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix. Let me know what you think. Cheers, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Thu Apr 20 13:35:56 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 13:35:56 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

Message-ID: On Wed, 19 Apr 2023 04:06:00 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: >> >> - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type. >> - Reflecting review comments. >> - Fixing exhaustiveness for unsealed supertype pattern. >> - No need to enable features after error reported. >> - SwitchBootstraps.typeSwitch should not initialize enum classes. >> - A prototype of avoiding enum initialization. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 170: > >> 168: } else if (label instanceof EnumDesc enumDesc) { >> 169: if (target.getClass().isEnum() && >> 170: ((Enum) target).describeConstable().stream().anyMatch(d -> d.equals(enumDesc))) { > > probably a matter of style but isn't it a bit too much to use streams here? there will be always only one element right? Technically, one element, but the type is optional, so formally could be no elements. I could use `.get()`, but that feels a bit ugly and against optional? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172599496 From jlahoda at openjdk.org Thu Apr 20 13:44:56 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 13:44:56 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: <-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com> References:

<-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com> Message-ID: On Wed, 19 Apr 2023 15:36:08 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: >> >> - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type. >> - Reflecting review comments. >> - Fixing exhaustiveness for unsealed supertype pattern. >> - No need to enable features after error reported. >> - SwitchBootstraps.typeSwitch should not initialize enum classes. >> - A prototype of avoiding enum initialization. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279: > >> 277: } >> 278: >> 279: private static int lazyDoEnumSwitch(Enum target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class enumClass, MutableCallSite callSite) throws Throwable { > > out of curiosity, under what conditions the `startIndex` would be different from `0`? also shouldn't we check that `startIndex` is `>= 0`? `startIndex` may be non-0 when there are guards in the switch. In the case of the `enumSwitch`, something like: enum E {A, B;} E e = E.B; switch (e) { case E ee when ee == E.A -> {} case E ee -> {} } the method will be called twice, one with `startIndex == 0` and once with `startIndex == 1`, after the guard fails/returns `false`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172609212 From vromero at openjdk.org Thu Apr 20 13:44:53 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Apr 2023 13:44:53 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

Message-ID: On Thu, 20 Apr 2023 13:33:17 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 170: >> >>> 168: } else if (label instanceof EnumDesc enumDesc) { >>> 169: if (target.getClass().isEnum() && >>> 170: ((Enum) target).describeConstable().stream().anyMatch(d -> d.equals(enumDesc))) { >> >> probably a matter of style but isn't it a bit too much to use streams here? there will be always only one element right? > > Technically, one element, but the type is optional, so formally could be no elements. I could use `.get()`, but that feels a bit ugly and against optional? yep I know, up to you I'm not strong on this, I guess I was thinking about performance but probably not using streams won't make a difference in this case ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172609916 From jlahoda at openjdk.org Thu Apr 20 13:51:52 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 13:51:52 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

Message-ID: On Wed, 19 Apr 2023 16:45:06 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: >> >> - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type. >> - Reflecting review comments. >> - Fixing exhaustiveness for unsealed supertype pattern. >> - No need to enable features after error reported. >> - SwitchBootstraps.typeSwitch should not initialize enum classes. >> - A prototype of avoiding enum initialization. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279: > >> 277: } >> 278: >> 279: private static int lazyDoEnumSwitch(Enum target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class enumClass, MutableCallSite callSite) throws Throwable { > > can `doEnumSwitch` be folded into `lazyDoEnumSwitch`? just a suggestion, I'm OK with either way just that now it is not clear that we need two methods here. Also in `doEnumSwitch` and out of curiosity what example of user code could hit this section: > > > if (label instanceof Class c) { > if (c.isAssignableFrom(targetClass)) > return i; > } > > EDIT: nvm I found one example The intent here is to avoid eager initialization of enums - so, until the enum is initialized, `lazyDoEnumSwitch` will be used (which, by itself, won't compute any results, except the result for `null`), which is then replaced with `doEnumSwitch` using the enum constants directly. The enum switches support patterns as well, so something like: enum E {A;} E e = ...; switch (e) { case E ee -> {} } is valid, and should trigger the part with Class labels. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172623143 From vromero at openjdk.org Thu Apr 20 14:09:51 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Apr 2023 14:09:51 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

<-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com> Message-ID: On Thu, 20 Apr 2023 13:41:05 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279: >> >>> 277: } >>> 278: >>> 279: private static int lazyDoEnumSwitch(Enum target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class enumClass, MutableCallSite callSite) throws Throwable { >> >> out of curiosity, under what conditions the `startIndex` would be different from `0`? also shouldn't we check that `startIndex` is `>= 0`? > > `startIndex` may be non-0 when there are guards in the switch. In the case of the `enumSwitch`, something like: > > enum E {A, B;} > E e = E.B; > switch (e) { > case E ee when ee == E.A -> {} > case E ee -> {} > } > > > the method will be called twice, one with `startIndex == 0` and once with `startIndex == 1`, after the guard fails/returns `false`. I see, thanks >> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279: >> >>> 277: } >>> 278: >>> 279: private static int lazyDoEnumSwitch(Enum target, int startIndex, Object[] labels, MethodHandles.Lookup lookup, Class enumClass, MutableCallSite callSite) throws Throwable { >> >> can `doEnumSwitch` be folded into `lazyDoEnumSwitch`? just a suggestion, I'm OK with either way just that now it is not clear that we need two methods here. Also in `doEnumSwitch` and out of curiosity what example of user code could hit this section: >> >> >> if (label instanceof Class c) { >> if (c.isAssignableFrom(targetClass)) >> return i; >> } >> >> EDIT: nvm I found one example > > The intent here is to avoid eager initialization of enums - so, until the enum is initialized, `lazyDoEnumSwitch` will be used (which, by itself, won't compute any results, except the result for `null`), which is then replaced with `doEnumSwitch` using the enum constants directly. > > The enum switches support patterns as well, so something like: > > enum E {A;} > E e = ...; > switch (e) { > case E ee -> {} > } > > is valid, and should trigger the part with Class labels. yep I found a similar test case triggering this code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172646957 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172647746 From duke at openjdk.org Thu Apr 20 15:18:43 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 20 Apr 2023 15:18:43 GMT Subject: RFR: 8305671: javac rejects semicolons in compilation units with no imports [v3] In-Reply-To: References:

<6ecE1A13Oq3SckPoWi7nRLH-CBXfYK9zAA6bU5zE_5k=.39610068-c6b7-417c-a208-97f8f9ce3ea7@github.com>

Message-ID: On Tue, 18 Apr 2023 03:56:54 GMT, Jonathan Gibbons wrote: >>> Doing what you suggest would probably be more straightforward >> >> "More straightforward" is the right long term solution for the code. The proposed patch is obscure and will confuse future developers working on this part of the code. >> >>> but would risk breaking that. >> >> You now have tests to ensure you don't break that. >> >> The previous round of fix was inadequate, for not handling the case of no import statements. It is reasonable to (re)consider the logic for that part of the code. And, it is reasonable to ensure the set of test cases covers all places where multiple semicolons are bad. > > Isn't the logic just > > * after a package declaration or import declaration, read and save excess semicolons > * before an import statement, check there are no saved excess semicolons and report if there were any > * (ignore any saved excess semicolons when you encounter the first type declaration (if any) or EOF) @jonathan-gibbons ... your thoughts? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13361#discussion_r1172746510 From vromero at openjdk.org Thu Apr 20 16:35:55 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Apr 2023 16:35:55 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

<-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>

Message-ID: On Thu, 20 Apr 2023 14:07:01 GMT, Vicente Romero wrote: >> The intent here is to avoid eager initialization of enums - so, until the enum is initialized, `lazyDoEnumSwitch` will be used (which, by itself, won't compute any results, except the result for `null`), which is then replaced with `doEnumSwitch` using the enum constants directly. >> >> The enum switches support patterns as well, so something like: >> >> enum E {A;} >> E e = ...; >> switch (e) { >> case E ee -> {} >> } >> >> is valid, and should trigger the part with Class labels. > > yep I found a similar test case triggering this code could you explain a bit more the relation between `lazyDoEnumSwitch` and `doEnumSwitch` because my understanding is that `lazyDoEnumSwitch` is invoking `doEnumSwitch` so to me whenever `lazyDoEnumSwitch` is invoked there will be an immediate invocation of `doEnumSwitch` that's why I thought they could be folded together >> `startIndex` may be non-0 when there are guards in the switch. In the case of the `enumSwitch`, something like: >> >> enum E {A, B;} >> E e = E.B; >> switch (e) { >> case E ee when ee == E.A -> {} >> case E ee -> {} >> } >> >> >> the method will be called twice, one with `startIndex == 0` and once with `startIndex == 1`, after the guard fails/returns `false`. > > I see, thanks and regarding checking that `startIndex` should be `>= 0`? shouldn't we check for that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172839418 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172840817 From jlahoda at openjdk.org Thu Apr 20 16:43:50 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 16:43:50 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

<-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>

Message-ID: <-LVQqa8s0ItYV8ckL06FtOHjo5pOe-g66JNi7yPmhVI=.33d74c7e-0232-4047-9cde-4a5af12eea61@github.com> On Thu, 20 Apr 2023 16:32:33 GMT, Vicente Romero wrote: >> I see, thanks > > and regarding checking that `startIndex` should be `>= 0`? shouldn't we check for that? That's in my upcoming update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172848770 From jlahoda at openjdk.org Thu Apr 20 16:56:53 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 16:56:53 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

<-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>

Message-ID: On Thu, 20 Apr 2023 16:31:33 GMT, Vicente Romero wrote: >> yep I found a similar test case triggering this code > > could you explain a bit more the relation between `lazyDoEnumSwitch` and `doEnumSwitch` because my understanding is that `lazyDoEnumSwitch` is invoking `doEnumSwitch` so to me whenever `lazyDoEnumSwitch` is invoked there will be an immediate invocation of `doEnumSwitch` that's why I thought they could be folded together So, when the `enumSwitch` bootstrap is called, the enum class may or may not be initialized. So, to avoid initialization, we only do lightweight checks, and construct a `MutableCallSite` with `lazyDoEnumSwitch` as a target. When the `CallSite` is invoked with an actual selector value, two options may arise: a) the selector value is null. The `lazyDoEnumSwitch` itself returns -1. b) the selector value is not null. The enum class must already be initialized (I believe). So, we create (hopefully) better structure to do the categorization, based on `doEnumSwitch`, and set that into the `CallSite`. Further calls will use this new `doEnumSwitch` based categorization directly, without calling `lazyDoEnumSwitch`. The current call will manually delegate to the `doEnumSwitch` version, but that should only happen "once" (or a small number of times, due to running in different threads, etc.). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172863795 From jlahoda at openjdk.org Thu Apr 20 17:05:15 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 17:05:15 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v3] In-Reply-To: References: Message-ID: > This is the first draft of a patch for JEP 440 and JEP 441. Changes included: > > - the pattern matching for switch and record patterns features are made final, together with updates to tests. > - parenthesized patterns are removed. > - qualified enum constants are supported for case labels. > > This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Reflecting review feedback. - Fixing infinite loop in exhaustiveness computation caused by re-adding bindings that are already in the list. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13074/files - new: https://git.openjdk.org/jdk/pull/13074/files/a6ba602b..bb59254e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=01-02 Stats: 343 lines in 7 files changed: 282 ins; 42 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/13074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074 PR: https://git.openjdk.org/jdk/pull/13074 From jlahoda at openjdk.org Thu Apr 20 17:11:01 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 17:11:01 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: <86wPks_z959-kxY0Kfp8nx6IK-OvI7k7GaTt9HU-tGE=.d8ace5b0-fd4f-4c25-aa38-b7fe354e1401@github.com> References:

<86wPks_z959-kxY0Kfp8nx6IK-OvI7k7GaTt9HU-tGE=.d8ace5b0-fd4f-4c25-aa38-b7fe354e1401@github.com> Message-ID: On Tue, 18 Apr 2023 20:24:33 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: >> >> - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type. >> - Reflecting review comments. >> - Fixing exhaustiveness for unsealed supertype pattern. >> - No need to enable features after error reported. >> - SwitchBootstraps.typeSwitch should not initialize enum classes. >> - A prototype of avoiding enum initialization. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 94: > >> 92: *

the element is of type {@code String} or {@code Integer} and >> 93: * equals to the target.

>> 94: *

the element is of type {@code EnumDesc}, that describes a constant that is > > I think that at ~line 76, up in this same javadoc you need to add a reference to EnumDesc in the general description. Where it says: > > > The static arguments are an array of case labels which must be non-null and of type > {@code String} or {@code Integer} or {@code Class}. > > also around line 107, where it says: > > @param labels case labels - {@code String} and {@code Integer} constants > and {@code Class} instances, in any combination Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 263: > >> 261: private static > void validateEnumLabel(Class enumClassTemplate, Object label) { >> 262: if (label == null) { >> 263: throw new IllegalArgumentException("null label found"); > > I think that this one is not hit by any test Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 271: > >> 269: ", expected the provided enum class: " + enumClassTemplate); >> 270: } >> 271: } else if (labelClass == String.class) { > > I think that if the condition is changed to `labelClass != String.class` then `throw` we can drop an `else` branch Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 274: > >> 272: //OK >> 273: } else { >> 274: throw new IllegalArgumentException("label with illegal type found: " + labelClass + > > I think that this code is not being tested by any test Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 201: > >> 199: /** Are unconditional patterns in instanceof allowed >> 200: */ >> 201: private boolean allowUnconditionalPatternsInstanceOf; > > so I guess this field can be made final now Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 909: > >> 907: >> 908: Set permitted = allPermittedSubTypes(clazz, csym -> { >> 909: Type instantiated = infer.instantiatePatternType(selectorType, csym); > > for some cases, when there are no type parameters, this invocation is a no-op, do we really need inference at this point? Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877205 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877482 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877294 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877401 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172878133 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172878329 From jlahoda at openjdk.org Thu Apr 20 17:11:04 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 17:11:04 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

Message-ID: On Tue, 18 Apr 2023 14:17:02 GMT, Maurizio Cimadamore wrote: >> I've also found an infinite loop with this: >> >> >> class Test { >> sealed interface I0 permits I1, I2 { } >> sealed interface I00 permits I1, I2 { } >> >> sealed interface I1 extends I0, I00 permits B, C { } >> sealed interface I2 extends I0, I00 permits B, C { } >> >> static final class B implements I1, I2 { } >> static final class C implements I1, I2 { } >> >> int test(Object o) { >> return switch (o) { >> case B c -> 2; >> case C d -> 3; >> }; >> } >> } > >> I've also found an infinite loop with this: > > I believe this has to do with the fact that the list of pattern is not a set - so we can end up adding the same pattern descriptions over and over. Thanks for the testcase! I've tried to fix this by (avoiding to add redundant binding patterns): https://github.com/openjdk/jdk/pull/13074/commits/7e6ed619d89784c49a96984c0f74176a9e0bcf63 Sets might be a good move eventually, but so far it seemed to hide problems, which quite probably needed to be solved anyway, so I kept the list impl for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172874262 From jlahoda at openjdk.org Thu Apr 20 17:11:09 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 17:11:09 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

Message-ID: On Tue, 18 Apr 2023 14:31:46 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1021: >> >>> 1019: * on patterns in the chosen column, as described above >>> 1020: */ >>> 1021: var grouppedPerRecordClass = >> >> Suggestion: >> >> var groupedPerRecordClass = > > or `patternsByRecordClass`, or `groupByRecordClass` (the latter would be consistent with `groupByHash` which is used below) Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172876875 From jlahoda at openjdk.org Thu Apr 20 17:11:02 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 17:11:02 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: <-LVQqa8s0ItYV8ckL06FtOHjo5pOe-g66JNi7yPmhVI=.33d74c7e-0232-4047-9cde-4a5af12eea61@github.com> References:

<-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>

<-LVQqa8s0ItYV8ckL06FtOHjo5pOe-g66JNi7yPmhVI=.33d74c7e-0232-4047-9cde-4a5af12eea61@github.com> Message-ID: <2luQpR-ObMOKeSrv_nZ9qtdA_M1WOWqLuCBx19hR5HY=.1421ec9a-4a24-4ffe-9854-9c3a14132f83@github.com> On Thu, 20 Apr 2023 16:40:31 GMT, Jan Lahoda wrote: >> and regarding checking that `startIndex` should be `>= 0`? shouldn't we check for that? > > That's in my upcoming update. The startIndex checks are part of this change: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877989 From jlahoda at openjdk.org Thu Apr 20 17:11:07 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 20 Apr 2023 17:11:07 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

Message-ID: On Tue, 18 Apr 2023 13:43:45 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with six additional commits since the last revision: >> >> - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type. >> - Reflecting review comments. >> - Fixing exhaustiveness for unsealed supertype pattern. >> - No need to enable features after error reported. >> - SwitchBootstraps.typeSwitch should not initialize enum classes. >> - A prototype of avoiding enum initialization. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 915: > >> 913: >> 914: for (PatternDescription pdOther : patterns) { >> 915: if (pdOther instanceof BindingPattern bpOther) { > > This code redundantly checks a pattern against itself, which I think we can avoid. Possibly, but the handling of the binding patterns is getting more complex, so I've opted to keep it uniform for now. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 927: > >> 925: it.remove(); >> 926: reduces = true; >> 927: continue PERMITTED; > > the label can be dropped here as there's no nested loop Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 953: > >> 951: } >> 952: >> 953: Set cleanedToRemove = new HashSet<>(toRemove); > > Another way to do this would be to compute the intersection between `toRemove` and `toAdd` (e.g. with `retainAll`), and then remove the intersection from both sets. The addition and removal of the same binding pattern should be completely avoided in the current version of the code. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1058: > >> 1056: for (int i = 0; i < rpOne.nested.length; i++) { >> 1057: if (i != mismatchingCandidate && >> 1058: !exactlyMatches(rpOne.nested[i], rpOther.nested[i])) { > > should `exactlyMatches` be the implementation of `equals` in the `PatternDescriptor` class? Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! > src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 847: > >> 845: /** Skip parens and return the enclosed expression >> 846: */ >> 847: //XXX: remove?? > > What about this? Should be resolved by: https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 Thanks for the comment! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172875982 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172876837 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172875031 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877099 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172877541 From duke at openjdk.org Thu Apr 20 17:38:45 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 20 Apr 2023 17:38:45 GMT Subject: RFR: 8305672: Surprising definite assignment error after JDK-8043179 [v2] In-Reply-To: References:

Message-ID: On Mon, 17 Apr 2023 22:24:44 GMT, Man Cao wrote: > Could any Reviewer from compiler-dev@ review this change? I'd like to second this request. This bug was exposed very recently (by another bug fix), so it's never been part of any JDK release. It would be nice to keep it that way. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13366#issuecomment-1516704850 From vromero at openjdk.org Thu Apr 20 18:24:54 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Apr 2023 18:24:54 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: <2luQpR-ObMOKeSrv_nZ9qtdA_M1WOWqLuCBx19hR5HY=.1421ec9a-4a24-4ffe-9854-9c3a14132f83@github.com> References:

<-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>

<-LVQqa8s0ItYV8ckL06FtOHjo5pOe-g66JNi7yPmhVI=.33d74c7e-0232-4047-9cde-4a5af12eea61@github.com> <2luQpR-ObMOKeSrv_nZ9qtdA_M1WOWqLuCBx19hR5HY=.1421ec9a-4a24-4ffe-9854-9c3a14132f83@github.com> Message-ID: On Thu, 20 Apr 2023 17:08:10 GMT, Jan Lahoda wrote: >> That's in my upcoming update. > > The startIndex checks are part of this change: > https://github.com/openjdk/jdk/pull/13074/commits/bb59254e409821c9b14287c73a35ebe2dd2cbda9 > > Thanks for the comment! Oh I see, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172946111 From vromero at openjdk.org Thu Apr 20 18:27:56 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 20 Apr 2023 18:27:56 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v2] In-Reply-To: References:

<-O7hctvQpZkBZ8M3nTC76dtvbB9wDAusKn7dP2hUAyU=.87fc1903-2321-4579-b696-6277786830ac@github.com>

Message-ID: On Thu, 20 Apr 2023 16:54:20 GMT, Jan Lahoda wrote: >> could you explain a bit more the relation between `lazyDoEnumSwitch` and `doEnumSwitch` because my understanding is that `lazyDoEnumSwitch` is invoking `doEnumSwitch` so to me whenever `lazyDoEnumSwitch` is invoked there will be an immediate invocation of `doEnumSwitch` that's why I thought they could be folded together > > So, when the `enumSwitch` bootstrap is called, the enum class may or may not be initialized. So, to avoid initialization, we only do lightweight checks, and construct a `MutableCallSite` with `lazyDoEnumSwitch` as a target. > > When the `CallSite` is invoked with an actual selector value, two options may arise: > a) the selector value is null. The `lazyDoEnumSwitch` itself returns -1. > b) the selector value is not null. The enum class must already be initialized (I believe). So, we create (hopefully) better structure to do the categorization, based on `doEnumSwitch`, and set that into the `CallSite`. Further calls will use this new `doEnumSwitch` based categorization directly, without calling `lazyDoEnumSwitch`. The current call will manually delegate to the `doEnumSwitch` version, but that should only happen "once" (or a small number of times, due to running in different threads, etc.). I see, thanks for the explanation, this is nice ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172949033 From jlahoda at openjdk.org Fri Apr 21 10:56:55 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 21 Apr 2023 10:56:55 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v4] In-Reply-To: References: Message-ID: > This is the first draft of a patch for JEP 440 and JEP 441. Changes included: > > - the pattern matching for switch and record patterns features are made final, together with updates to tests. > - parenthesized patterns are removed. > - qualified enum constants are supported for case labels. > > This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Replacing use of mutable callsite with a mutable state. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13074/files - new: https://git.openjdk.org/jdk/pull/13074/files/bb59254e..d3d9cc60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=02-03 Stats: 44 lines in 1 file changed: 15 ins; 23 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074 PR: https://git.openjdk.org/jdk/pull/13074 From duke at openjdk.org Fri Apr 21 13:55:58 2023 From: duke at openjdk.org (David Alayachew) Date: Fri, 21 Apr 2023 13:55:58 GMT Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running fully legitimate code [v7] In-Reply-To: References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com> Message-ID: On Sat, 25 Mar 2023 22:08:23 GMT, Archie L. Cobbs wrote: >> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice. >> >> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash: >> >> public class Test { >> interface Cafe\u0301 { >> } >> interface Caf\u00e9 { >> } >> } >> >> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct. >> >> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this: >> >> $ javac --help-extra >> ... >> --detect-output-file-clashes >> Generate an error if any output file is overwritten during compilation. This can occur, for example, >> on case-insensitive filesystems. This applies to class files, native header files, and source files. >> ... >> $ javac --detect-output-file-clashes Test.java >> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class >> interface Caf\u00e9 { >> ^ >> 1 error >> >> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error. >> >> **Outstanding Questions** >> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this? >> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into? > > Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add "compiler.warn.output.file.clash" to message example exclusion file. Thanks @archiecobbs and @vicente-romero-oracle Sorry for having sent this so late, it's hard to keep up with the traffic of the mailing lists. I only found this because I looked up my old JBS submission from last year on a whim. What's the best way I should go about testing this? I see instructions on how to build the JDK from the source code. Is that the best way? Or are there any prebuilt versions that contain this fix that you all can think of from the top of your head? Thanks again for your time, help, and patience! David Alayachew And just for context, I am the original submitter of 8287885 ------------- PR Comment: https://git.openjdk.org/jdk/pull/12754#issuecomment-1517868153 PR Comment: https://git.openjdk.org/jdk/pull/12754#issuecomment-1517868933 From liach at openjdk.org Fri Apr 21 14:23:52 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Apr 2023 14:23:52 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v2] In-Reply-To: <7sO9lIqHflWjNVdXxFVWdLkUBW0d6P1P8qnvRmEbKj8=.e4b05cec-7457-4fcb-a382-eddb3292992d@github.com> References:

<6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com> <7sO9lIqHflWjNVdXxFVWdLkUBW0d6P1P8qnvRmEbKj8=.e4b05cec-7457-4fcb-a382-eddb3292992d@github.com> Message-ID: On Sun, 19 Feb 2023 04:03:19 GMT, Vicente Romero wrote: >>> @vicente-romero-oracle , can you review the CSR for this? Thanks. >> >> sure, I added some suggestions in a comment in the CSR > >> @vicente-romero-oracle thank you for the feedback. As I don't have a JBS account, I can't incorporate it myself. @TheShermanTanker could you do that for me as you created the CSR? Thanks. > > I will incorporate the changes to the CSR, please let me know if you have any suggestions keep-alive. @vicente-romero-oracle was probably on break last when this patch was active. Can you take a look now that its associated CSR has been approved for release 21? ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1517909603 From mcimadamore at openjdk.org Fri Apr 21 15:20:55 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Apr 2023 15:20:55 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v4] In-Reply-To: References:

Message-ID: <284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com> On Fri, 21 Apr 2023 10:56:55 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Replacing use of mutable callsite with a mutable state. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 915: > 913: */ > 914: private List reduceBindingPatterns(Type selectorType, List patterns) { > 915: Set existingBindings = patterns.stream() Playing some more - I found this example: class Test { sealed interface I permits C, D { } non-sealed interface C extends I { } non-sealed interface D extends I { } interface F { } int test(Z o) { return switch (o) { case C c -> 1; case D d -> 2; }; } } Which compiles correctly, but it doesn't look exhaustive to me (because of F) ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173896399 From mcimadamore at openjdk.org Fri Apr 21 15:20:56 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Apr 2023 15:20:56 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v4] In-Reply-To: <284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com> References:

<284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com> Message-ID: On Fri, 21 Apr 2023 15:16:03 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Replacing use of mutable callsite with a mutable state. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 915: > >> 913: */ >> 914: private List reduceBindingPatterns(Type selectorType, List patterns) { >> 915: Set existingBindings = patterns.stream() > > Playing some more - I found this example: > > > class Test { > sealed interface I permits C, D { } > non-sealed interface C extends I { } > non-sealed interface D extends I { } > > interface F { } > > int test(Z o) { > return switch (o) { > case C c -> 1; > case D d -> 2; > }; > } > } > > > Which compiles correctly, but it doesn't look exhaustive to me (because of F) ? Also, surprisingly, if I make C and D classes (instead of interfaces): class Test { sealed interface I permits C, D { } final class C implements I { } final class D implements I { } interface F { } int test(Z o) { return switch (o) { case C c -> 1; case D d -> 2; }; } } I get errors like: Foo.java:10: error: incompatible types: Z cannot be converted to Test.C case C c -> 1; ^ where Z is a type-variable: Z extends I,F declared in method test(Z) Which seems odd? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173898106 From mcimadamore at openjdk.org Fri Apr 21 15:32:54 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Apr 2023 15:32:54 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v4] In-Reply-To: References:

<284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com> Message-ID: <3-HT9uluxlbN2tV0NlH7z_cBEtgpCvZi1QWl5cLamks=.0537eddc-f226-40ff-bc4f-2dcf4c5655d2@github.com> On Fri, 21 Apr 2023 15:17:37 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 915: >> >>> 913: */ >>> 914: private List reduceBindingPatterns(Type selectorType, List patterns) { >>> 915: Set existingBindings = patterns.stream() >> >> Playing some more - I found this example: >> >> >> class Test { >> sealed interface I permits C, D { } >> non-sealed interface C extends I { } >> non-sealed interface D extends I { } >> >> interface F { } >> >> int test(Z o) { >> return switch (o) { >> case C c -> 1; >> case D d -> 2; >> }; >> } >> } >> >> >> Which compiles correctly, but it doesn't look exhaustive to me (because of F) ? > > Also, surprisingly, if I make C and D classes (instead of interfaces): > > class Test { > sealed interface I permits C, D { } > final class C implements I { } > final class D implements I { } > > interface F { } > > int test(Z o) { > return switch (o) { > case C c -> 1; > case D d -> 2; > }; > } > } > > I get errors like: > > > Foo.java:10: error: incompatible types: Z cannot be converted to Test.C > case C c -> 1; > ^ > where Z is a type-variable: > Z extends I,F declared in method test(Z) > > > Which seems odd? Nevermind - these issues are due to a misunderstanding of the rules with intersection types - e.g. given A & B, if a pattern covers _any_ of A, B, then it covers A & B. Similarly, the second issue I reported is in reality caused by the fact that in the snippet with `class`, I also added `final` which then makes I & F a type with no concrete witnesses (so cast will always fail from there to either C/D). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173912165 From forax at openjdk.org Fri Apr 21 15:38:00 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 21 Apr 2023 15:38:00 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v4] In-Reply-To: <3-HT9uluxlbN2tV0NlH7z_cBEtgpCvZi1QWl5cLamks=.0537eddc-f226-40ff-bc4f-2dcf4c5655d2@github.com> References:

<284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com> <3-HT9uluxlbN2tV0NlH7z_cBEtgpCvZi1QWl5cLamks=.0537eddc-f226-40ff-bc4f-2dcf4c5655d2@github.com> Message-ID: On Fri, 21 Apr 2023 15:30:24 GMT, Maurizio Cimadamore wrote: >> Also, surprisingly, if I make C and D classes (instead of interfaces): >> >> class Test { >> sealed interface I permits C, D { } >> final class C implements I { } >> final class D implements I { } >> >> interface F { } >> >> int test(Z o) { >> return switch (o) { >> case C c -> 1; >> case D d -> 2; >> }; >> } >> } >> >> I get errors like: >> >> >> Foo.java:10: error: incompatible types: Z cannot be converted to Test.C >> case C c -> 1; >> ^ >> where Z is a type-variable: >> Z extends I,F declared in method test(Z) >> >> >> Which seems odd? > > Nevermind - these issues are due to a misunderstanding of the rules with intersection types - e.g. given A & B, if a pattern covers _any_ of A, B, then it covers A & B. > > Similarly, the second issue I reported is in reality caused by the fact that in the snippet with `class`, I also added `final` which then makes I & F a type with no concrete witnesses (so cast will always fail from there to either C/D). > Which compiles correctly, but it doesn't look exhaustive to me (because of F) ? Can you expand a little more, because for me a Z either implement C or D or both C and D. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173916081 From duke at openjdk.org Fri Apr 21 15:41:55 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 21 Apr 2023 15:41:55 GMT Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running fully legitimate code [v7] In-Reply-To: References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>

Message-ID: On Fri, 21 Apr 2023 13:52:43 GMT, David Alayachew wrote: > What's the best way I should go about testing this? Using whatever your original example was. Or some simple example like this on a case-insensitive filesystem: public class Test { interface Inner { } interface INNER { } } > I see instructions on how to build the JDK from the source code. Is that the best way? As far as I know that's the best way... but I could be unaware of pre-built preview images somewhere. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12754#issuecomment-1518013637 From duke at openjdk.org Fri Apr 21 15:50:59 2023 From: duke at openjdk.org (David Alayachew) Date: Fri, 21 Apr 2023 15:50:59 GMT Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running fully legitimate code [v7] In-Reply-To: References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com> Message-ID: On Sat, 25 Mar 2023 22:08:23 GMT, Archie L. Cobbs wrote: >> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice. >> >> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash: >> >> public class Test { >> interface Cafe\u0301 { >> } >> interface Caf\u00e9 { >> } >> } >> >> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct. >> >> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this: >> >> $ javac --help-extra >> ... >> --detect-output-file-clashes >> Generate an error if any output file is overwritten during compilation. This can occur, for example, >> on case-insensitive filesystems. This applies to class files, native header files, and source files. >> ... >> $ javac --detect-output-file-clashes Test.java >> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class >> interface Caf\u00e9 { >> ^ >> 1 error >> >> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error. >> >> **Outstanding Questions** >> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this? >> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into? > > Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add "compiler.warn.output.file.clash" to message example exclusion file. > > What's the best way I should go about testing this? > > Using whatever your original example was. Or some simple example like this on a case-insensitive filesystem: > > ```java > public class Test { > interface Inner { > } > interface INNER { > } > } > ``` > > > I see instructions on how to build the JDK from the source code. Is that the best way? > > As far as I know that's the best way... but I could be unaware of pre-built preview images somewhere. Ok, beautiful. I'll get on that now. Thanks again to you both! ------------- PR Comment: https://git.openjdk.org/jdk/pull/12754#issuecomment-1518022625 From mcimadamore at openjdk.org Fri Apr 21 16:11:58 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Apr 2023 16:11:58 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v4] In-Reply-To: References:

Message-ID: <02wmStB1KKnY10rIaGsCN6PWv_3k3ljH67zMFs1GBgQ=.0e83bd08-8160-4fa5-8c01-0dd0591ffa45@github.com> On Fri, 21 Apr 2023 10:56:55 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Replacing use of mutable callsite with a mutable state. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 971: > 969: it.remove(); > 970: reduces = true; > 971: continue ; This continue seems redundant ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173947054 From jlahoda at openjdk.org Fri Apr 21 16:25:08 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 21 Apr 2023 16:25:08 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v4] In-Reply-To: <02wmStB1KKnY10rIaGsCN6PWv_3k3ljH67zMFs1GBgQ=.0e83bd08-8160-4fa5-8c01-0dd0591ffa45@github.com> References:

<02wmStB1KKnY10rIaGsCN6PWv_3k3ljH67zMFs1GBgQ=.0e83bd08-8160-4fa5-8c01-0dd0591ffa45@github.com> Message-ID: <8fLo2qujFv8JPfTsmYOj5RXLqAFNYHsdu7oiWHma_GU=.a1468a74-e2a9-491e-baea-967e3fffc43c@github.com> On Fri, 21 Apr 2023 16:08:41 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Replacing use of mutable callsite with a mutable state. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 971: > >> 969: it.remove(); >> 970: reduces = true; >> 971: continue ; > > This continue seems redundant Thanks, fixed: https://github.com/openjdk/jdk/pull/13074/commits/8b1cfba6e4603d82836d889273855185165acd29 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173955311 From mcimadamore at openjdk.org Fri Apr 21 16:25:06 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Apr 2023 16:25:06 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v4] In-Reply-To: References:

<284vbkNQcyFoTr0o69JAdyVrWfhp7GQxXIywJMkc-hY=.b83c89e6-6f67-42ef-8d5d-e781f0f2c1aa@github.com> <3-HT9uluxlbN2tV0NlH7z_cBEtgpCvZi1QWl5cLamks=.0537eddc-f226-40ff-bc4f-2dcf4c5655d2@github.com> Message-ID: <9EqBP9NLmF-UEeArN1_NTKv6rMmpMdYaKoE2V49cAAA=.5713d036-c92a-41cd-94a9-06229ff16e04@github.com> On Fri, 21 Apr 2023 15:34:32 GMT, R?mi Forax wrote: > > Which compiles correctly, but it doesn't look exhaustive to me (because of F) ? > > Can you expand a little more, because for me a Z either implement C or D or both C and D. Please see my latest comment above. I was confused by the rules of coverage with intersection types. F is immaterial in this example - the only thing to show is that there is at least one of the component of the intersection (in this case I) that is fully covered. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173957437 From jlahoda at openjdk.org Fri Apr 21 16:25:04 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 21 Apr 2023 16:25:04 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v5] In-Reply-To: References: Message-ID: > This is the first draft of a patch for JEP 440 and JEP 441. Changes included: > > - the pattern matching for switch and record patterns features are made final, together with updates to tests. > - parenthesized patterns are removed. > - qualified enum constants are supported for case labels. > > This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Adding test. - Removing redundant continue, as noted on the review. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13074/files - new: https://git.openjdk.org/jdk/pull/13074/files/d3d9cc60..2cc3e11d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=03-04 Stats: 27 lines in 2 files changed: 24 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074 PR: https://git.openjdk.org/jdk/pull/13074 From vromero at openjdk.org Fri Apr 21 16:34:00 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 21 Apr 2023 16:34:00 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v4] In-Reply-To: References:

Message-ID: <7uCVXj5bqYXlEvCQK-ROxX_qKBd_0Agm6mtU0X60IfQ=.9413e290-fe1d-4087-a4b1-761381274662@github.com> On Fri, 21 Apr 2023 10:56:55 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Replacing use of mutable callsite with a mutable state. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 302: > 300: MethodHandles.Lookup lookup, Class enumClass, > 301: ResolvedEnumLabels resolvedLabels) { > 302: Objects.checkIndex(startIndex, unresolvedLabels.length + 1); I think that we should add a comment to the related API stating that IOOBE can be thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1173899355 From vromero at openjdk.org Fri Apr 21 16:52:57 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 21 Apr 2023 16:52:57 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v5] In-Reply-To: References:

Message-ID: On Fri, 21 Apr 2023 16:25:04 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: > > - Adding test. > - Removing redundant continue, as noted on the review. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 808: > 806: } > 807: > 808: public static int hashCode(int excludeComponent, Type recordType, Type[] fullComponentTypes, PatternDescription... nested) { this argument: `fullComponentTypes` is not being used in this method, could be removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1174066885 From cstein at openjdk.org Fri Apr 21 21:07:42 2023 From: cstein at openjdk.org (Christian Stein) Date: Fri, 21 Apr 2023 21:07:42 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein wrote: > This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): > - #11272 > > Changes: > - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` > - [x] Use shared `CommandLine.java` in `jdk.compiler` module > - [x] Use shared `CommandLine.java` in `jdk.javadoc` module > - [x] Remove `CommandLine.java` from `jdk.compiler` module Converted this PR to draft mode until boot JDK is updated to 20. - https://bugs.openjdk.org/browse/JDK-8296153 "Bump minimum boot jdk to JDK 20" ------------- PR Comment: https://git.openjdk.org/jdk/pull/12997#issuecomment-1465706849 From jjg at openjdk.org Fri Apr 21 21:07:42 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 21 Apr 2023 21:07:42 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein wrote: > This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): > - #11272 > > Changes: > - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` > - [x] Use shared `CommandLine.java` in `jdk.compiler` module > - [x] Use shared `CommandLine.java` in `jdk.javadoc` module > - [x] Remove `CommandLine.java` from `jdk.compiler` module Looks good, for when un-Draft-ed ------------- PR Comment: https://git.openjdk.org/jdk/pull/12997#issuecomment-1487214895 From cstein at openjdk.org Fri Apr 21 21:14:00 2023 From: cstein at openjdk.org (Christian Stein) Date: Fri, 21 Apr 2023 21:14:00 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v2] In-Reply-To: References: Message-ID: <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com> > This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): > - #11272 > > Changes: > - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` > - [x] Use shared `CommandLine.java` in `jdk.compiler` module > - [x] Use shared `CommandLine.java` in `jdk.javadoc` module > - [x] Remove `CommandLine.java` from `jdk.compiler` module Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8304036-reusable-command-line-part-2 - Add missing import - JDK-8304036: Use CommandLine class from shared module ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12997/files - new: https://git.openjdk.org/jdk/pull/12997/files/405091f9..7e05ad8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=00-01 Stats: 375645 lines in 3690 files changed: 296166 ins; 52578 del; 26901 mod Patch: https://git.openjdk.org/jdk/pull/12997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997 PR: https://git.openjdk.org/jdk/pull/12997 From jjg at openjdk.org Fri Apr 21 21:42:47 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 21 Apr 2023 21:42:47 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v2] In-Reply-To: <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com> References: <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com> Message-ID: On Fri, 21 Apr 2023 21:14:00 GMT, Christian Stein wrote: >> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): >> - #11272 >> >> Changes: >> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` >> - [x] Use shared `CommandLine.java` in `jdk.compiler` module >> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module >> - [x] Remove `CommandLine.java` from `jdk.compiler` module > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8304036-reusable-command-line-part-2 > - Add missing import > - JDK-8304036: Use CommandLine class from shared module Marked as reviewed by jjg (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/12997#pullrequestreview-1396422793 From mchung at openjdk.org Fri Apr 21 21:45:46 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 21 Apr 2023 21:45:46 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v2] In-Reply-To: <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com> References: <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com> Message-ID: On Fri, 21 Apr 2023 21:14:00 GMT, Christian Stein wrote: >> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): >> - #11272 >> >> Changes: >> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` >> - [x] Use shared `CommandLine.java` in `jdk.compiler` module >> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module >> - [x] Remove `CommandLine.java` from `jdk.compiler` module > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8304036-reusable-command-line-part-2 > - Add missing import > - JDK-8304036: Use CommandLine class from shared module src/jdk.internal.opt/share/classes/module-info.java line 33: > 31: module jdk.internal.opt { > 32: exports jdk.internal.joptsimple to jdk.jlink, jdk.jshell; > 33: exports jdk.internal.opt to jdk.compiler, jdk.jartool, jdk.javadoc, jdk.jlink, jdk.jpackage; Nit: line break at each module is easier to read and avoid long line like: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/module-info.java#L149 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12997#discussion_r1174181399 From cstein at openjdk.org Sat Apr 22 11:42:58 2023 From: cstein at openjdk.org (Christian Stein) Date: Sat, 22 Apr 2023 11:42:58 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v2] In-Reply-To: References: <8w871xPAhwGr0SRBhYkJKg6kpIZXHfPYaEbH4vP4hoM=.cb462f6e-d5cc-462b-8db3-898f39cd03dc@github.com> Message-ID: On Fri, 21 Apr 2023 21:42:58 GMT, Mandy Chung wrote: >> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8304036-reusable-command-line-part-2 >> - Add missing import >> - JDK-8304036: Use CommandLine class from shared module > > src/jdk.internal.opt/share/classes/module-info.java line 33: > >> 31: module jdk.internal.opt { >> 32: exports jdk.internal.joptsimple to jdk.jlink, jdk.jshell; >> 33: exports jdk.internal.opt to jdk.compiler, jdk.jartool, jdk.javadoc, jdk.jlink, jdk.jpackage; > > Nit: line break at each module is easier to read and avoid long line like: > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/module-info.java#L149 Yes, that's much nicer. Will reflow all other export directives as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12997#discussion_r1174387317 From cstein at openjdk.org Sat Apr 22 11:42:52 2023 From: cstein at openjdk.org (Christian Stein) Date: Sat, 22 Apr 2023 11:42:52 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v3] In-Reply-To: References: Message-ID: > This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): > - #11272 > > Changes: > - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` > - [x] Use shared `CommandLine.java` in `jdk.compiler` module > - [x] Use shared `CommandLine.java` in `jdk.javadoc` module > - [x] Remove `CommandLine.java` from `jdk.compiler` module Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Improve formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12997/files - new: https://git.openjdk.org/jdk/pull/12997/files/7e05ad8d..163fcbfe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=01-02 Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997 PR: https://git.openjdk.org/jdk/pull/12997 From cstein at openjdk.org Sat Apr 22 11:59:32 2023 From: cstein at openjdk.org (Christian Stein) Date: Sat, 22 Apr 2023 11:59:32 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v4] In-Reply-To: References: Message-ID: > This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): > - #11272 > > Changes: > - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` > - [x] Use shared `CommandLine.java` in `jdk.compiler` module > - [x] Use shared `CommandLine.java` in `jdk.javadoc` module > - [x] Remove `CommandLine.java` from `jdk.compiler` module Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update CompileInterimLangtools.gmk ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12997/files - new: https://git.openjdk.org/jdk/pull/12997/files/163fcbfe..39eb626c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997 PR: https://git.openjdk.org/jdk/pull/12997 From cstein at openjdk.org Sat Apr 22 12:15:38 2023 From: cstein at openjdk.org (Christian Stein) Date: Sat, 22 Apr 2023 12:15:38 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v5] In-Reply-To: References: Message-ID: > This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): > - #11272 > > Changes: > - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` > - [x] Use shared `CommandLine.java` in `jdk.compiler` module > - [x] Use shared `CommandLine.java` in `jdk.javadoc` module > - [x] Remove `CommandLine.java` from `jdk.compiler` module Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Export `jdk.internal.opt` to `jdk.javadoc.interim`, too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12997/files - new: https://git.openjdk.org/jdk/pull/12997/files/39eb626c..f9a94225 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997 PR: https://git.openjdk.org/jdk/pull/12997 From kcr at openjdk.org Sat Apr 22 13:37:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 22 Apr 2023 13:37:45 GMT Subject: RFR: 8305672: Surprising definite assignment error after JDK-8043179 [v2] In-Reply-To: References:

Message-ID: On Mon, 17 Apr 2023 21:56:39 GMT, Archie L. Cobbs wrote: >> The fix for [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) is to clear the DU flags for all variables when entering a lamba. This reflects the fact that the lamba's actual execution could be arbitrarily far in the future, so we can't assume anything that is DU when the lambda is created is still DU when the lambda actually executes. >> >> However, this fix created a new bug. The problem is that `visitLambda()` does not save & restore the `uninitsTry` bits, which are used by `visitTry()` to track DU variables within `try { }` blocks. So if there is a `try { }` block outside the lambda and a `try { }` block inside the lambda, the latter can "leak" DU state up to the former via this field. As a result, a final variable that should still be DU at the completion of the outer `try { }` block can be incorrectly recorded as not DU, leading to the bogus "might already have been assigned" error. >> >> This patch fixes that by adding the necessary save & restore logic. > > Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8305672 > - Fix failure of visitLambda() to save & restore uninitsTry bits. We just ran into this bug trying to compile JavaFX 21 with JDK 21. I raised the priority of the bug to P2, since this is a serious regression with no obvious workaround. @vicente-romero-oracle since you reviewed and sponsored the fix for [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) in PR #10381 would you be able to review this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13366#issuecomment-1518662118 From kcr at openjdk.org Sat Apr 22 14:19:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 22 Apr 2023 14:19:46 GMT Subject: RFR: 8305672: Surprising definite assignment error after JDK-8043179 [v2] In-Reply-To: References:

Message-ID: On Mon, 17 Apr 2023 21:56:39 GMT, Archie L. Cobbs wrote: >> The fix for [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) is to clear the DU flags for all variables when entering a lamba. This reflects the fact that the lamba's actual execution could be arbitrarily far in the future, so we can't assume anything that is DU when the lambda is created is still DU when the lambda actually executes. >> >> However, this fix created a new bug. The problem is that `visitLambda()` does not save & restore the `uninitsTry` bits, which are used by `visitTry()` to track DU variables within `try { }` blocks. So if there is a `try { }` block outside the lambda and a `try { }` block inside the lambda, the latter can "leak" DU state up to the former via this field. As a result, a final variable that should still be DU at the completion of the outer `try { }` block can be incorrectly recorded as not DU, leading to the bogus "might already have been assigned" error. >> >> This patch fixes that by adding the necessary save & restore logic. > > Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8305672 > - Fix failure of visitLambda() to save & restore uninitsTry bits. I don't know this code area at all (and am not a jdk Reviewer), but I can confirm that this PR fixes the bug for me. After applying this patch and building a local JDK, I am able to compile JavaFX again. ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/13366#pullrequestreview-1396745166 From liach at openjdk.org Sat Apr 22 21:34:48 2023 From: liach at openjdk.org (Chen Liang) Date: Sat, 22 Apr 2023 21:34:48 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v2] In-Reply-To: <7sO9lIqHflWjNVdXxFVWdLkUBW0d6P1P8qnvRmEbKj8=.e4b05cec-7457-4fcb-a382-eddb3292992d@github.com> References:

<6h4fb3uQb5CVMis_G5D7jDf-4EcPHveKtEIXF3mlvZw=.7a945163-3726-44cb-b884-c34318ecb5a3@github.com> <7sO9lIqHflWjNVdXxFVWdLkUBW0d6P1P8qnvRmEbKj8=.e4b05cec-7457-4fcb-a382-eddb3292992d@github.com> Message-ID: On Sun, 19 Feb 2023 04:03:19 GMT, Vicente Romero wrote: >>> @vicente-romero-oracle , can you review the CSR for this? Thanks. >> >> sure, I added some suggestions in a comment in the CSR > >> @vicente-romero-oracle thank you for the feedback. As I don't have a JBS account, I can't incorporate it myself. @TheShermanTanker could you do that for me as you created the CSR? Thanks. > > I will incorporate the changes to the CSR, please let me know if you have any suggestions @vicente-romero-oracle Would you take a look at this patch since you've reviewed the associated CSR already? This is a helpful fix that can allow core reflection to map annotations and signatures more accurately with the newly available MethodParameters information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1518829199 From mcimadamore at openjdk.org Mon Apr 24 08:59:03 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 24 Apr 2023 08:59:03 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v5] In-Reply-To: References:

Message-ID: On Mon, 24 Apr 2023 09:05:56 GMT, R?mi Forax wrote: > > I believe the exhaustiveness algorithm needs rules for union types, both in javac and in the JLS: > > ... > > I would expect the above switch to be exhaustive, since it covers all possible components of the union type. In other words, the union type should act as a sealed hierarchy which permits Foo and Bar - and the two cases should be merged together (e.g. `case Foo` + `case Bar` should cover `Foo | Bar`). For the records, I get same error on JDK 20. > > Precise exception type, here, `Foo | Bar` inside a catch is not an union, it's a way to merge catches when the body of catches are the same. In term of typing, `Foo | Bar` behave as the lub of Foo and Bar, apart in a throw. > > So the switch is not exhaustive here because `lub(Foo, Bar) = Exception`. > > We may add a special case in JLS for supporting precise exception type in switch given that this issue have been reported several times, but this is not something that should be fixed by this PR. I see the dance in 14.20 between: " A catch clause whose exception parameter is denoted as a union of types is called a multi-catch clause. " And "The declared type of an exception parameter that denotes its type as a union with alternatives D1 | D2 | ... | Dn is lub(D1, D2, ..., Dn). " (Which is required to make membership (and other properties) work) The reason I'm bringing this up in the context of the new exhaustiveness analysis is that this might add more ways to unify a pair of types in the exhaustiveness algorithm, hence leading to a more complex implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1520030010 From jlahoda at openjdk.org Mon Apr 24 12:56:55 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 24 Apr 2023 12:56:55 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v5] In-Reply-To: References:

Message-ID: <7xVX0OBbNW0m6KvSLSWGMablU96uP0atzt5XtFII6Qg=.36045555-1ac8-423c-9596-8dd16185bf01@github.com> On Mon, 24 Apr 2023 12:05:35 GMT, Maurizio Cimadamore wrote: > > > I believe the exhaustiveness algorithm needs rules for union types, both in javac and in the JLS: > > > ... > > > I would expect the above switch to be exhaustive, since it covers all possible components of the union type. In other words, the union type should act as a sealed hierarchy which permits Foo and Bar - and the two cases should be merged together (e.g. `case Foo` + `case Bar` should cover `Foo | Bar`). For the records, I get same error on JDK 20. > > > > > > Precise exception type, here, `Foo | Bar` inside a catch is not an union, it's a way to merge catches when the body of catches are the same. In term of typing, `Foo | Bar` behave as the lub of Foo and Bar, apart in a throw. > > So the switch is not exhaustive here because `lub(Foo, Bar) = Exception`. > > We may add a special case in JLS for supporting precise exception type in switch given that this issue have been reported several times, but this is not something that should be fixed by this PR. > > I see the dance in 14.20 between: > > " A catch clause whose exception parameter is denoted as a union of types is called a multi-catch clause. " > > And > > "The declared type of an exception parameter that denotes its type as a union with alternatives D1 | D2 | ... | Dn is lub(D1, D2, ..., Dn). " > > (Which is required to make membership (and other properties) work) > > The reason I'm bringing this up in the context of the new exhaustiveness analysis is that this might add more ways to unify a pair of types in the exhaustiveness algorithm, hence leading to a more complex implementation. In this case, as long as the union type could only be present at the top level (as opposed to e.g. a type of a record component), we could simply require all components to be covered for union types for exhaustiveness in `checkCovered`, no? We could do something different, if we had a good reason, but enhancing `checkCovered` should be enough, and shouldn't be too difficult (as long as the spec would say so). Do I miss something? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1520105514 From mcimadamore at openjdk.org Mon Apr 24 13:54:03 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 24 Apr 2023 13:54:03 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v5] In-Reply-To: <7xVX0OBbNW0m6KvSLSWGMablU96uP0atzt5XtFII6Qg=.36045555-1ac8-423c-9596-8dd16185bf01@github.com> References:

<7xVX0OBbNW0m6KvSLSWGMablU96uP0atzt5XtFII6Qg=.36045555-1ac8-423c-9596-8dd16185bf01@github.com> Message-ID: On Mon, 24 Apr 2023 12:53:59 GMT, Jan Lahoda wrote: > In this case, as long as the union type could only be present at the top level (as opposed to e.g. a type of a record component), we could simply require all components to be covered for union types for exhaustiveness in `checkCovered`, no? We could do something different, if we had a good reason, but enhancing `checkCovered` should be enough, and shouldn't be too difficult (as long as the spec would say so). Do I miss something? I believe that is a correct assessment. Technically speaking though, I'm not sure the JLS can be enhanced to do that - given that, as Remi reminded me, union types are not a thing. The _declaration_ of a union type parameter is a thing, but then the underlying declared type of the parameter is just the LUB. This means that the JLS can't track which expressions have union types. Note that saying stuff like `if the selector expression is a multi-catch parameter` won't work either, given that with `var` you can alias that on a different local. So, if things are not wired up a the type level (as it is currently the case), there's not much we can do I'm afraid. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13074#issuecomment-1520200078 From jlahoda at openjdk.org Mon Apr 24 13:54:05 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 24 Apr 2023 13:54:05 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v5] In-Reply-To: References:

Message-ID: On Fri, 21 Apr 2023 16:49:54 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: >> >> - Adding test. >> - Removing redundant continue, as noted on the review. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 315: > >> 313: Object[] labels = resolvedLabels.resolvedLabels; >> 314: >> 315: // Dumbest possible strategy > > I guess that given that we can't make any assumption about order here, this is the only possible strategy so I guess it makes sense to remove the comment I certainly hope we can do better. At very least, the current implementation is checking the type of the labels on each pass through the loop. The types of the labels don't change, so checking them again and again is not necessary. In some cases, it might be possible to improve even further, like e.g. in a case where all the labels are enum constants, then we could use a e.g. mapping table. There's a PR proposed that shows some of that: https://github.com/openjdk/jdk/pull/9779 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175260039 From jlahoda at openjdk.org Mon Apr 24 15:16:18 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 24 Apr 2023 15:16:18 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References: Message-ID: > This is the first draft of a patch for JEP 440 and JEP 441. Changes included: > > - the pattern matching for switch and record patterns features are made final, together with updates to tests. > - parenthesized patterns are removed. > - qualified enum constants are supported for case labels. > > This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review changes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13074/files - new: https://git.openjdk.org/jdk/pull/13074/files/2cc3e11d..f0584725 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=04-05 Stats: 12 lines in 2 files changed: 8 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074 PR: https://git.openjdk.org/jdk/pull/13074 From cstein at openjdk.org Mon Apr 24 15:31:53 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 24 Apr 2023 15:31:53 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v6] In-Reply-To: References: Message-ID: > This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): > - #11272 > > Changes: > - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` > - [x] Use shared `CommandLine.java` in `jdk.compiler` module > - [x] Use shared `CommandLine.java` in `jdk.javadoc` module > - [x] Remove `CommandLine.java` from `jdk.compiler` module Christian Stein has updated the pull request incrementally with five additional commits since the last revision: - Fix hard-coded test - Clean up configuration - Update test - Fix generation of API documentation - Add more export directives ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12997/files - new: https://git.openjdk.org/jdk/pull/12997/files/f9a94225..26d14f82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=04-05 Stats: 18 lines in 7 files changed: 13 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997 PR: https://git.openjdk.org/jdk/pull/12997 From mchung at openjdk.org Mon Apr 24 15:31:56 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 24 Apr 2023 15:31:56 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v5] In-Reply-To: References:

Message-ID: On Sat, 22 Apr 2023 12:15:38 GMT, Christian Stein wrote: >> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): >> - #11272 >> >> Changes: >> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` >> - [x] Use shared `CommandLine.java` in `jdk.compiler` module >> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module >> - [x] Remove `CommandLine.java` from `jdk.compiler` module > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Export `jdk.internal.opt` to `jdk.javadoc.interim`, too Converted this PR to draft mode again: interim langtools are not happy, yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12997#issuecomment-1518633910 From cstein at openjdk.org Mon Apr 24 15:40:04 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 24 Apr 2023 15:40:04 GMT Subject: Integrated: 8304896: Update to use jtreg 7.2 In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.2. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. This pull request has now been integrated. Changeset: 2763cf14 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/2763cf14e6a174511ae8af471690ef18b10b3998 Stats: 9 lines in 8 files changed: 0 ins; 0 del; 9 mod 8304896: Update to use jtreg 7.2 Reviewed-by: erikj, lmesnik, iris ------------- PR: https://git.openjdk.org/jdk/pull/13496 From vromero at openjdk.org Mon Apr 24 15:41:05 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 24 Apr 2023 15:41:05 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v5] In-Reply-To: References:

Message-ID: <03FNRCkfJCn9AntylkhNxEwopYUh5xwaDgOrh9tsAoU=.24c0d388-7726-49cf-82ce-3d3168cc724b@github.com> On Mon, 24 Apr 2023 13:08:44 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 315: >> >>> 313: Object[] labels = resolvedLabels.resolvedLabels; >>> 314: >>> 315: // Dumbest possible strategy >> >> I guess that given that we can't make any assumption about order here, this is the only possible strategy so I guess it makes sense to remove the comment > > I certainly hope we can do better. At very least, the current implementation is checking the type of the labels on each pass through the loop. The types of the labels don't change, so checking them again and again is not necessary. In some cases, it might be possible to improve even further, like e.g. in a case where all the labels are enum constants, then we could use a e.g. mapping table. > > There's a PR proposed that shows some of that: > https://github.com/openjdk/jdk/pull/9779 I see, interesting ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175471366 From duke at openjdk.org Mon Apr 24 16:18:05 2023 From: duke at openjdk.org (David Alayachew) Date: Mon, 24 Apr 2023 16:18:05 GMT Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running fully legitimate code [v7] In-Reply-To: References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com> Message-ID: On Sat, 25 Mar 2023 22:08:23 GMT, Archie Cobbs wrote: >> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice. >> >> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash: >> >> public class Test { >> interface Cafe\u0301 { >> } >> interface Caf\u00e9 { >> } >> } >> >> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct. >> >> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this: >> >> $ javac --help-extra >> ... >> --detect-output-file-clashes >> Generate an error if any output file is overwritten during compilation. This can occur, for example, >> on case-insensitive filesystems. This applies to class files, native header files, and source files. >> ... >> $ javac --detect-output-file-clashes Test.java >> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class >> interface Caf\u00e9 { >> ^ >> 1 error >> >> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error. >> >> **Outstanding Questions** >> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this? >> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into? > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add "compiler.warn.output.file.clash" to message example exclusion file. Finished building the jdk from source and tested the fix. It worked! Here is a demonstration for those who are following along. $ cat abc.java public class abc { public static class XYZ {} public static class xyz {} public static void main(String[] args) { System.out.println("abc"); XYZ a = new XYZ(); System.out.println("tuv"); xyz b = new xyz(); System.out.println("xyz"); } } $ javac abc.java -Xlint:output-file-clash warning: [output-file-clash] output file written more than once: C:\Users\david_WORKSPACE_PROGRAMMING_JAVA\abc$xyz.class 1 warning As you can see, if I use the -Xlint warning above, I now get a warning if any of my classes generate the same filename multiple times. This is perfect, as I now know at compile time that this is something to watch out for. Thank you for fixing this Archie/Vicente! ------------- PR Comment: https://git.openjdk.org/jdk/pull/12754#issuecomment-1520466345 From vromero at openjdk.org Mon Apr 24 16:22:09 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 24 Apr 2023 16:22:09 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References:

Message-ID: <2TAN9lBNny_FQKYr0xQrlBqFrlGJshAzJj6rCaQ_irA=.86823002-b715-40f7-9b4e-793db4afcd56@github.com> On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review changes. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 101: > 99: *

> 100: * The value of the {@code restart} index must be between {@code 0} and > 101: * the length of the {@code labels} array, of an {@link IndexOutOfBoundsException} typo: `of an` -> `or an` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175520267 From vromero at openjdk.org Mon Apr 24 16:43:08 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 24 Apr 2023 16:43:08 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review changes. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 220: > 218: *

> 219: * The value of the {@code restart} index must be between {@code 0} and > 220: * the length of the {@code labels} array, of an {@link IndexOutOfBoundsException} same as above ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175542100 From vromero at openjdk.org Mon Apr 24 18:09:02 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 24 Apr 2023 18:09:02 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review changes. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3212: > 3210: @Override > 3211: public void visitCase(JCCase tree) { > 3212: super.visitCase(tree); // Generated from nbfs://nbhost/SystemFileSystem/Templates/Classes/Code/OverriddenMethodBody do we need this comment? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 862: > 860: > 861: private LoadableConstant createEnumDesc(DiagnosticPosition pos, ClassSymbol enumClass, Name constant) { > 862: //ConstantBootstrap.invoke(..., EnumDesc.of(ConstantBootstrap.invoke(..., ClassDesc.of(enumClass)), constant)) I think this comment can be removed or probably reformatted ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175611723 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1175615234 From vromero at openjdk.org Mon Apr 24 18:14:40 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 24 Apr 2023 18:14:40 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review changes. I don't have any more comments. Great job! ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13074#pullrequestreview-1398560976 From mchung at openjdk.org Mon Apr 24 20:56:09 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 24 Apr 2023 20:56:09 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v6] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 15:31:53 GMT, Christian Stein wrote: >> This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): >> - #11272 >> >> Changes: >> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` >> - [x] Use shared `CommandLine.java` in `jdk.compiler` module >> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module >> - [x] Remove `CommandLine.java` from `jdk.compiler` module > > Christian Stein has updated the pull request incrementally with five additional commits since the last revision: > > - Fix hard-coded test > - Clean up configuration > - Update test > - Fix generation of API documentation > - Add more export directives Marked as reviewed by mchung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/12997#pullrequestreview-1398777346 From cstein at openjdk.org Tue Apr 25 03:59:12 2023 From: cstein at openjdk.org (Christian Stein) Date: Tue, 25 Apr 2023 03:59:12 GMT Subject: RFR: JDK-8304036: Use CommandLine class from shared module [v7] In-Reply-To: References: Message-ID: > This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): > - #11272 > > Changes: > - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` > - [x] Use shared `CommandLine.java` in `jdk.compiler` module > - [x] Use shared `CommandLine.java` in `jdk.javadoc` module > - [x] Remove `CommandLine.java` from `jdk.compiler` module Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update copyright year [skip ci] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12997/files - new: https://git.openjdk.org/jdk/pull/12997/files/26d14f82..0cc3d377 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=05-06 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12997/head:pull/12997 PR: https://git.openjdk.org/jdk/pull/12997 From cstein at openjdk.org Tue Apr 25 04:20:19 2023 From: cstein at openjdk.org (Christian Stein) Date: Tue, 25 Apr 2023 04:20:19 GMT Subject: Integrated: JDK-8304036: Use CommandLine class from shared module In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein wrote: > This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919): > - #11272 > > Changes: > - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc` > - [x] Use shared `CommandLine.java` in `jdk.compiler` module > - [x] Use shared `CommandLine.java` in `jdk.javadoc` module > - [x] Remove `CommandLine.java` from `jdk.compiler` module This pull request has now been integrated. Changeset: 24719190 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/2471919020169aac4499ef40ed37eabd98c90da7 Stats: 345 lines in 14 files changed: 29 ins; 297 del; 19 mod 8304036: Use CommandLine class from shared module Reviewed-by: jjg, mchung ------------- PR: https://git.openjdk.org/jdk/pull/12997 From mcimadamore at openjdk.org Tue Apr 25 09:44:22 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 25 Apr 2023 09:44:22 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References: Message-ID: <9CClgUB47HEkddcnlw7SSKfRHwlS4N-9QosvMgc7c-k=.c07ea842-12fb-4dbb-8ffa-31c163898cde@github.com> On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review changes. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 219: > 217: * the method of the call site return the length of the {@code labels} array. > 218: *

> 219: * The value of the {@code restart} index must be between {@code 0} and This description is a bit ambiguous - not clear whether it's `0 < x < length`, or `0 <= x < length`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176269340 From mcimadamore at openjdk.org Tue Apr 25 10:46:28 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 25 Apr 2023 10:46:28 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 15:16:18 GMT, Jan Lahoda wrote: >> This is the first draft of a patch for JEP 440 and JEP 441. Changes included: >> >> - the pattern matching for switch and record patterns features are made final, together with updates to tests. >> - parenthesized patterns are removed. >> - qualified enum constants are supported for case labels. >> >> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review changes. Added some comments in the exhaustiveness test test/langtools/tools/javac/patterns/Exhaustiveness.java line 1: > 1: /* Isn't `Isn't `testCoversType1` the same as `testExhaustiveStatement3` ? ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13074#pullrequestreview-1399606399 PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176314733 From mcimadamore at openjdk.org Tue Apr 25 10:46:30 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 25 Apr 2023 10:46:30 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 10:22:40 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflecting review changes. > > test/langtools/tools/javac/patterns/Exhaustiveness.java line 1: > >> 1: /* > > Isn't `Isn't `testCoversType1` the same as `testExhaustiveStatement3` ? Some of the tests called `testExhaustiveStatement` do not seem to test statements at all ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176315235 From mcimadamore at openjdk.org Tue Apr 25 10:46:30 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 25 Apr 2023 10:46:30 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 10:23:11 GMT, Maurizio Cimadamore wrote: >> test/langtools/tools/javac/patterns/Exhaustiveness.java line 1: >> >>> 1: /* >> >> Isn't `Isn't `testCoversType1` the same as `testExhaustiveStatement3` ? > > Some of the tests called `testExhaustiveStatement` do not seem to test statements at all In the two `testXYZExhaustiveIntersection` the class hierarchy seems the same - can we reuse it across multiple test cases? I see something similar done in `testOnlyApplicable`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176325272 From mcimadamore at openjdk.org Tue Apr 25 10:46:30 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 25 Apr 2023 10:46:30 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v6] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 10:33:33 GMT, Maurizio Cimadamore wrote: >> Some of the tests called `testExhaustiveStatement` do not seem to test statements at all > > In the two `testXYZExhaustiveIntersection` the class hierarchy seems the same - can we reuse it across multiple test cases? I see something similar done in `testOnlyApplicable`. The name `testX` doesn't seem very expressive - maybe `testRecords` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1176326319 From jlahoda at openjdk.org Tue Apr 25 11:47:47 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 25 Apr 2023 11:47:47 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v7] In-Reply-To: References: Message-ID: > This is the first draft of a patch for JEP 440 and JEP 441. Changes included: > > - the pattern matching for switch and record patterns features are made final, together with updates to tests. > - parenthesized patterns are removed. > - qualified enum constants are supported for case labels. > > This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits: - Merge branch 'master' into JDK-8300543 - Reflecting review changes. - Adding test. - Removing redundant continue, as noted on the review. - Replacing use of mutable callsite with a mutable state. - Reflecting review feedback. - Fixing infinite loop in exhaustiveness computation caused by re-adding bindings that are already in the list. - Fixing infinite loop where a binding pattern is replaced with a binding pattern for the same type. - Reflecting review comments. - Fixing exhaustiveness for unsealed supertype pattern. - ... and 28 more: https://git.openjdk.org/jdk/compare/a4a53858...35f51562 ------------- Changes: https://git.openjdk.org/jdk/pull/13074/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=06 Stats: 4160 lines in 158 files changed: 2033 ins; 1675 del; 452 mod Patch: https://git.openjdk.org/jdk/pull/13074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074 PR: https://git.openjdk.org/jdk/pull/13074 From abimpoudis at openjdk.org Tue Apr 25 12:14:14 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 25 Apr 2023 12:14:14 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables Message-ID: This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ ------------- Depends on: https://git.openjdk.org/jdk/pull/13074 Commit messages: - Fix indentation in JavacParser - Merge branch 'JDK-8300543' into unnamed - Fix top level type pattern with underscore - Introduce source in MemberEnter (javadoc uses MemberEnter) - Merge branch 'JDK-8300543' into unnamed - Fix parsePattern after merge - Fix - Implement cases with multiple unnamed patterns and guards - WIP: guards - Merge branch 'JDK-8300543' into unnamed - ... and 14 more: https://git.openjdk.org/jdk/compare/35f51562...6e3f495e Changes: https://git.openjdk.org/jdk/pull/13528/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302344 Stats: 767 lines in 32 files changed: 596 ins; 52 del; 119 mod Patch: https://git.openjdk.org/jdk/pull/13528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528 PR: https://git.openjdk.org/jdk/pull/13528 From volker.simonis at gmail.com Tue Apr 25 15:33:14 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 25 Apr 2023 17:33:14 +0200 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces Message-ID: Hi, I know that support for `-source 7` was removed in JDK 20 (by JDK-8173605), but I'd still like to kindly ask you for your opinion regarding the following issue described at https://bugs.openjdk.org/browse/JDK-8306854 and copy-pasted below for your convenience. Independently on wehter you support this fix, it would be great to hear if you agree that the described issue is indeed a bug and if the proposed fix (at https://github.com/openjdk/jdk17u-dev/pull/1296) is a valid solution for the problem? Thanks, Volker Consider the following example: ``` interface A { void foo(); } ``` ``` interface B extends A { @Override default void foo() { } } ``` ``` class C implements B { } ``` If we compile `A.java` and `B.java` with `javac -source 8` and `C.java` with `-source 7` we will get the following error: ``` $ javac -source 8 A.java $ javac -source 8 B.java $ javac -source 7 C.java C.java:1: error: C is not abstract and does not override abstract method foo() in A class C implements B { } ``` I think this is wrong, because `foo()` is implemented as a default method in `B`. The following, slightly simpler example works perfectly fine, although it also depends on a default method in an implemented interface: ``` interface D { default void bar() { } } ``` ``` class E implements D { } ``` ``` $ javac -source 8 D.java $ javac -source 7 E.java ``` In the second example, `javac` happily accepts the default implementation of `bar()` from interface `D`. Interestingly, `ecj` (the [Eclipse Compiler for Java](https://ftp.fau.de/eclipse/eclipse/downloads/drops4/R-4.27-202303020300/ecj-4.27.jar)) compiles both examples without any errors: ``` $ java -jar ecj-4.27.jar -cp . -source 8 A.java $ java -jar ecj-4.27.jar -cp . -source 8 B.java $ java -jar ecj-4.27.jar -cp . -source 7 C.java ``` I think the problem is in [`com.sun.tools.javac.code.Types::firstUnimplementedAbstractImpl()`](https://github.com/openjdk/jdk17u/blob/22cdf79dce8b2ec7c68e3ba71550d70e4eeb2c48/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L3110-L3129), specifically in line 3123: ``` 3123: if (allowDefaultMethods) { 3124: MethodSymbol prov = interfaceCandidates(impl.type, absmeth).head; 3125: if (prov != null && prov.overrides(absmeth, impl, this, true)) { 3126: implmeth = prov; 3127: } 3128 } ``` Here the check for imlementations of `A::foo()` (`absmeth` in the code snippet above) for class `C` (`impl` in the code snippet above) will only be performed if `allowDefaultMethods` is set to true, but `allowDefaultMethods` is globally set to false by `-source 7`. Instead of relying on the *global* `-source` setting, I think `firstUnimplementedAbstractImpl()` should rather rely on the class file version of the corresponing class (i.e. `B` in this case) and if that class file version is >= 8, it should consider its default method implementations. I even think that the check for `allowDefaultMethods` could be completely removed, because if the class dependency `B` wasn't compiled before, it will be compiled from source and fail for `-source 7` because it contains a default method. If on the other hand, the class dependency `B` was already compiled to a class file with `-source 8` it is OK to use it's default method. What do you think? From duke at openjdk.org Tue Apr 25 15:41:47 2023 From: duke at openjdk.org (Christoph Dreis) Date: Tue, 25 Apr 2023 15:41:47 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty Message-ID: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> Hi, I've been profiling our compilation tasks lately and noticed that `List.map` is under the top consumers. There are probably more aggressive options to optimize this, but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings. In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix. Let me know what you think. Cheers, Christoph ------------- Commit messages: - Reduce allocations in List.map() when it is empty Changes: https://git.openjdk.org/jdk/pull/13407/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13407&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306860 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13407/head:pull/13407 PR: https://git.openjdk.org/jdk/pull/13407 From duke at openjdk.org Tue Apr 25 15:41:47 2023 From: duke at openjdk.org (Lalit Prakash Vatsal) Date: Tue, 25 Apr 2023 15:41:47 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> Message-ID: <-jv6ch1tSvXcTTFjn_bd8aOFeMfCZCVy-KXXGVzj24g=.32a8e0ba-3c2d-405c-bbbf-c5d76898af6a@github.com> On Mon, 10 Apr 2023 14:40:00 GMT, Christoph Dreis wrote: > Hi, > > I've been profiling our compilation tasks lately and noticed that `List.map` is under the top consumers. > > > > There are probably more aggressive options to optimize this, but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings. > > > > In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix. > > Let me know what you think. > > Cheers, > Christoph Marked as reviewed by lprakashv at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/13407#pullrequestreview-1377884724 From duke at openjdk.org Tue Apr 25 15:41:51 2023 From: duke at openjdk.org (Christoph Dreis) Date: Tue, 25 Apr 2023 15:41:51 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> Message-ID: On Mon, 10 Apr 2023 17:14:00 GMT, ExE Boss wrote: >> Hi, >> >> I've been profiling our compilation tasks lately and noticed that `List.map` is under the top consumers. >> >> >> >> There are probably more aggressive options to optimize this, but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings. >> >> >> >> In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix. >> >> Let me know what you think. >> >> Cheers, >> Christoph > > src/jdk.compiler/share/classes/com/sun/tools/javac/util/List.java line 423: > >> 421: public List map(Function mapper) { >> 422: if (isEmpty()) { >> 423: return (List)this; > > Use?`List.nil()`?instead, in?case this?list gets?mutated?later: > Suggestion: > > return List.nil(); Wouldn't this change the logic compared to what it did before? If the list gets mutated later - e.g. via `setTail` - this would fail with `List.nil()`. Do I miss something here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1161912840 From duke at openjdk.org Tue Apr 25 15:41:53 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 25 Apr 2023 15:41:53 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> Message-ID: <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> On Mon, 10 Apr 2023 17:19:08 GMT, Christoph Dreis wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/util/List.java line 423: >> >>> 421: public List map(Function mapper) { >>> 422: if (isEmpty()) { >>> 423: return (List)this; >> >> Use?`List.nil()`?instead, in?case this?list gets?mutated?later: >> Suggestion: >> >> return List.nil(); > > Wouldn't this change the logic compared to what it did before? If the list gets mutated later - e.g. via `setTail` - this would fail with `List.nil()`. > Do I miss something here? I?meant the?list on?which `map(?)` is?called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1161924217 From duke at openjdk.org Tue Apr 25 15:41:54 2023 From: duke at openjdk.org (Christoph Dreis) Date: Tue, 25 Apr 2023 15:41:54 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> Message-ID: <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> On Mon, 10 Apr 2023 17:34:00 GMT, ExE Boss wrote: >> Wouldn't this change the logic compared to what it did before? If the list gets mutated later - e.g. via `setTail` - this would fail with `List.nil()`. >> Do I miss something here? > > I?meant the?list on?which `map(?)` is?called. Same "problem". This changes behaviour compared to what it does now. I don't have anything against that per se, but an optimization imho shouldn't really change the behaviour. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1161927479 From duke at openjdk.org Tue Apr 25 15:41:55 2023 From: duke at openjdk.org (Lalit Prakash Vatsal) Date: Tue, 25 Apr 2023 15:41:55 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> Message-ID: On Mon, 10 Apr 2023 17:38:23 GMT, Christoph Dreis wrote: >> I?meant the?list on?which `map(?)` is?called. > > Same "problem". This changes behaviour compared to what it does now. I don't have anything against that per se, but an optimization imho shouldn't really change the behaviour. I agree with @dreis2211 here. Someone might want to use/mutate the returned `List` later on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1161932177 From duke at openjdk.org Tue Apr 25 15:41:57 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 25 Apr 2023 15:41:57 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> Message-ID: On Mon, 10 Apr 2023 17:44:37 GMT, Lalit Prakash Vatsal wrote: >> Same "problem". This changes behaviour compared to what it does now. I don't have anything against that per se, but an optimization imho shouldn't really change the behaviour. > > I agree with @dreis2211 here. Someone might want to use/mutate the returned `List` later on. This?won?t?be a?change in?behaviour as?`ListBuffer::toList()` returns?`List.nil()` when?called on?an?empty `ListBuffer`. -------------------------------------------------------------------------------- e.g.: The?following evaluates to?`true`: new ListBuffer().toList() == List.nil() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1162591007 From acobbs at openjdk.org Tue Apr 25 15:41:59 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 25 Apr 2023 15:41:59 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> Message-ID: On Tue, 11 Apr 2023 10:07:20 GMT, ExE Boss wrote: >> I agree with @dreis2211 here. Someone might want to use/mutate the returned `List` later on. > > This?won?t?be a?change in?behaviour as?`ListBuffer::toList()` returns?`List.nil()` when?called on?an?empty `ListBuffer`. > > -------------------------------------------------------------------------------- > > e.g.: The?following evaluates to?`true`: > > new ListBuffer().toList() == List.nil() Jumping in here... I think what @ExE-Boss is getting at is that every empty `List` is the same object, i.e., `List.EMPTY_LIST`, i.e., `List.nil()`. In other words, it's not possible to ever have an empty `List` that's **not** `List.nil()`. So while it appears that replacing `(List)this` with `List.nil()` is a change in behavior, in the special case that `this.isEmpty()` is true (which is the case here), it's not a change in behavior. Of course this is only due to a quirk in the implementation, but the statement is still correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1172640189 From acobbs at openjdk.org Tue Apr 25 15:42:01 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 25 Apr 2023 15:42:01 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> Message-ID: <5RdKTpHZEcuKbju1rTiSXB8NeyUKpSZhAVItCBBlhDs=.041b2160-e1b2-4e8d-a8ec-3d90adc59648@github.com> On Thu, 20 Apr 2023 14:01:41 GMT, Archie Cobbs wrote: >> This?won?t?be a?change in?behaviour as?`ListBuffer::toList()` returns?`List.nil()` when?called on?an?empty `ListBuffer`. >> >> -------------------------------------------------------------------------------- >> >> e.g.: The?following evaluates to?`true`: >> >> new ListBuffer().toList() == List.nil() > > Jumping in here... I think what @ExE-Boss is getting at is that every empty `List` is the same object, i.e., `List.EMPTY_LIST`, i.e., `List.nil()`. In other words, it's not possible to ever have an empty `List` that's **not** `List.nil()`. > > So while it appears that replacing `(List)this` with `List.nil()` is a change in behavior, in the special case that `this.isEmpty()` is true (which is the case here), it's not a change in behavior. > > Of course this is only due to a quirk in the implementation, but the statement is still correct. Actually, having just said that, I think I'm wrong. It's possible to say `list.setTail(null)`. So I take back what I just said. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1172641936 From duke at openjdk.org Tue Apr 25 15:41:50 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 25 Apr 2023 15:41:50 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> Message-ID: On Mon, 10 Apr 2023 14:40:00 GMT, Christoph Dreis wrote: > Hi, > > I've been profiling our compilation tasks lately and noticed that `List.map` is under the top consumers. > > > > There are probably more aggressive options to optimize this, but I found that checking for empty lists already reduces the overall allocations by ~500MB for one of our compilation tasks with no measurable regressions (but also no noticeable improvements) in timings. > > > > In case you consider this worthwhile, I'd appreciate a sponsoring of this (including a ticket because I have no rights to create one, review etc.). I've found https://bugs.openjdk.org/browse/JDK-8032359 but this was closed as won't fix. > > Let me know what you think. > > Cheers, > Christoph src/jdk.compiler/share/classes/com/sun/tools/javac/util/List.java line 423: > 421: public List map(Function mapper) { > 422: if (isEmpty()) { > 423: return (List)this; Use?`List.nil()`?instead, in?case this?list gets?mutated?later: Suggestion: return List.nil(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1161908793 From duke at openjdk.org Tue Apr 25 15:41:58 2023 From: duke at openjdk.org (Christoph Dreis) Date: Tue, 25 Apr 2023 15:41:58 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> Message-ID: On Tue, 11 Apr 2023 10:07:20 GMT, ExE Boss wrote: >> I agree with @dreis2211 here. Someone might want to use/mutate the returned `List` later on. > > This?won?t?be a?change in?behaviour as?`ListBuffer::toList()` returns?`List.nil()` when?called on?an?empty `ListBuffer`. > > -------------------------------------------------------------------------------- > > e.g.: The?following evaluates to?`true`: > > new ListBuffer().toList() == List.nil() The behavior before returns the original list because `changed` is false. `ListBuffer::toList()` is never called in this scenario. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1162600691 From duke at openjdk.org Tue Apr 25 15:42:02 2023 From: duke at openjdk.org (Christoph Dreis) Date: Tue, 25 Apr 2023 15:42:02 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> <5RdKTpHZEcuKbju1rTiSXB8NeyUKpSZhAVItCBBlhDs=.041b2160-e1b2-4e8d-a8ec-3d90adc59648@github.com> Message-ID: On Mon, 24 Apr 2023 14:50:11 GMT, Archie Cobbs wrote: >> Thanks @archiecobbs for coming to the same conclusion as me earlier. Would you be willing to sponsor this change by any chance? > >> Would you be willing to sponsor this change by any chance? > > Yes except I'm a project "author" not a "committer" so can't do that yet. But you could already create a ticket? That would already help :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1176282198 From acobbs at openjdk.org Tue Apr 25 15:42:02 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 25 Apr 2023 15:42:02 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> <5RdKTpHZEcuKbju1rTiSXB8NeyUKpSZhAVItCBBlhDs=.041b2160-e1b2-4e8d-a8ec-3d90adc59648@github.com> Message-ID: On Mon, 24 Apr 2023 14:18:43 GMT, Christoph Dreis wrote: > Would you be willing to sponsor this change by any chance? Yes except I'm a project "author" not a "committer" so can't do that yet. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1175404506 From acobbs at openjdk.org Tue Apr 25 15:42:05 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 25 Apr 2023 15:42:05 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> <5RdKTpHZEcuKbju1rTiSXB8NeyUKpSZhAVItCBBlhDs=.041b2160-e1b2-4e8d-a8ec-3d90adc59648@github.com> Message-ID: On Tue, 25 Apr 2023 09:52:05 GMT, Christoph Dreis wrote: > But you could already create a ticket? That would already help :) Done: [JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty](https://bugs.openjdk.org/browse/JDK-8306860) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1176689951 From duke at openjdk.org Tue Apr 25 15:42:01 2023 From: duke at openjdk.org (Christoph Dreis) Date: Tue, 25 Apr 2023 15:42:01 GMT Subject: RFR: JDK-8306860: Avoid unnecessary allocation in List.map() when list is empty In-Reply-To: <5RdKTpHZEcuKbju1rTiSXB8NeyUKpSZhAVItCBBlhDs=.041b2160-e1b2-4e8d-a8ec-3d90adc59648@github.com> References: <3jIQ0qkZAADRK3wP7EhJsT7dnMmiwZPHwtObzv-ujp0=.6c42fd06-6026-4880-a494-2f20c8530400@github.com> <_tKVw276u_tW6da4UnWZwcPxF3mx-gwuZrr7rp0FAcA=.4bb2ca05-b5c2-4f4e-882e-096fa3a3a657@github.com> <13JQzQEM4yU0FbPzxplem8a4ssTt30SGGv2FJJ39bRc=.59867193-d780-4610-9a34-4985a5883a59@github.com> <5RdKTpHZEcuKbju1rTiSXB8NeyUKpSZhAVItCBBlhDs=.041b2160-e1b2-4e8d-a8ec-3d90adc59648@github.com> Message-ID: On Thu, 20 Apr 2023 14:02:57 GMT, Archie Cobbs wrote: >> Jumping in here... I think what @ExE-Boss is getting at is that every empty `List` is the same object, i.e., `List.EMPTY_LIST`, i.e., `List.nil()`. In other words, it's not possible to ever have an empty `List` that's **not** `List.nil()`. >> >> So while it appears that replacing `(List)this` with `List.nil()` is a change in behavior, in the special case that `this.isEmpty()` is true (which is the case here), it's not a change in behavior. >> >> Of course this is only due to a quirk in the implementation, but the statement is still correct. > > Actually, having just said that, I think I'm wrong. It's possible to say `list.setTail(null)`. So I take back what I just said. Thanks @archiecobbs for coming to the same conclusion as me earlier. Would you be willing to sponsor this change by any chance? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13407#discussion_r1175357793 From alex.buckley at oracle.com Tue Apr 25 17:09:41 2023 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 25 Apr 2023 10:09:41 -0700 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: References: Message-ID: <080e63b9-0168-f678-16ea-fb941bb9aa89@oracle.com> On 4/25/2023 8:33 AM, Volker Simonis wrote: > ``` > interface A { > void foo(); > } > ``` > > ``` > interface B extends A { > @Override default void foo() { } > } > ``` > > ``` > class C implements B { } > ``` > > If we compile `A.java` and `B.java` with `javac -source 8` and > `C.java` with `-source 7` we will get the following error: > ``` > $ javac -source 8 A.java > $ javac -source 8 B.java > $ javac -source 7 C.java > C.java:1: error: C is not abstract and does not override abstract > method foo() in A > class C implements B { } > ``` > > I think this is wrong, because `foo()` is implemented as a default > method in `B`. The Java language circa JLS7 does not have default methods, so the membership of C cannot possibly involve a default method inherited from B. The Java language is backward compatible, not forward compatible. A Java compiler that adheres to JLS7 (`-source 7`) is right to reject C.java -- either with the error given above, or with a more context-aware error along the lines of "C is written for Java 7, cannot inherit default method from B". > The following, slightly simpler example works perfectly fine, although > it also depends on a default method in an implemented interface: > > ``` > interface D { > default void bar() { } > } > ``` > > ``` > class E implements D { } > ``` > > ``` > $ javac -source 8 D.java > $ javac -source 7 E.java > ``` > > In the second example, `javac` happily accepts the default > implementation of `bar()` from interface `D`. It's hard to see how javac is processing class E, so I added a method declaration `@Override public void bar() {}` to E and `javac -source 7 E.java` accepted the code. That's improper, because in Java 7 there is no such thing as a default method in D to override from E. I then added a method invocation `D.super.bar();` as the body of E's bar method. In JLS8, this means "invoke my superinterface's default method". However, in JLS7, it means "invoke my enclosing class's method", but D isn't an enclosing class, so it's illegal (see https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.1-100-D) -- yet `javac -source 7 E.java` accepts it anyway. Highly improper on javac's part. Alex From forax at univ-mlv.fr Tue Apr 25 19:17:46 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 25 Apr 2023 21:17:46 +0200 (CEST) Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: <080e63b9-0168-f678-16ea-fb941bb9aa89@oracle.com> References: <080e63b9-0168-f678-16ea-fb941bb9aa89@oracle.com> Message-ID: <52851018.42407693.1682450266863.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Alex Buckley" > To: "compiler-dev" > Sent: Tuesday, April 25, 2023 7:09:41 PM > Subject: Re: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces > On 4/25/2023 8:33 AM, Volker Simonis wrote: >> ``` >> interface A { >> void foo(); >> } >> ``` >> >> ``` >> interface B extends A { >> @Override default void foo() { } >> } >> ``` >> >> ``` >> class C implements B { } >> ``` >> >> If we compile `A.java` and `B.java` with `javac -source 8` and >> `C.java` with `-source 7` we will get the following error: >> ``` >> $ javac -source 8 A.java >> $ javac -source 8 B.java >> $ javac -source 7 C.java >> C.java:1: error: C is not abstract and does not override abstract >> method foo() in A >> class C implements B { } >> ``` >> >> I think this is wrong, because `foo()` is implemented as a default >> method in `B`. > > The Java language circa JLS7 does not have default methods, so the > membership of C cannot possibly involve a default method inherited from > B. The Java language is backward compatible, not forward compatible. > > A Java compiler that adheres to JLS7 (`-source 7`) is right to reject > C.java -- either with the error given above, or with a more > context-aware error along the lines of "C is written for Java 7, cannot > inherit default method from B". > >> The following, slightly simpler example works perfectly fine, although >> it also depends on a default method in an implemented interface: >> >> ``` >> interface D { >> default void bar() { } >> } >> ``` >> >> ``` >> class E implements D { } >> ``` >> >> ``` >> $ javac -source 8 D.java >> $ javac -source 7 E.java >> ``` >> >> In the second example, `javac` happily accepts the default >> implementation of `bar()` from interface `D`. > > It's hard to see how javac is processing class E, so I added a method > declaration `@Override public void bar() {}` to E and `javac -source 7 > E.java` accepted the code. That's improper, because in Java 7 there is > no such thing as a default method in D to override from E. > > I then added a method invocation `D.super.bar();` as the body of E's bar > method. In JLS8, this means "invoke my superinterface's default method". > However, in JLS7, it means "invoke my enclosing class's method", but D > isn't an enclosing class, so it's illegal (see > https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.1-100-D) > -- yet `javac -source 7 E.java` accepts it anyway. Highly improper on > javac's part. > > Alex Alex, Java 8 adds a lot of default methods to the interfaces of the collection API, so javac8 -source 7 could not stop each time it sees a default methods, otherwise a lot of code will never have compiled. Which means that javac7 -source 7 and javac8 -source 7 have to have different behaviors. It was decided that javac8 -source 7 should skip default methods because it works well with the collection API even if it does not work that well in other cases as the one provided by Volker. Volker, I believe the behavior you see is not a bug, it's how javac should behave. But i don't think this behavior is specified somewhere, that why ecj has a different behavior. Moreover, javac never behaves differently depending on a specific classfile version of a specific classfile to preserve the sanity of the people trying to debug issues involving several versions. regards, R?mi From alex.buckley at oracle.com Tue Apr 25 19:23:36 2023 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 25 Apr 2023 12:23:36 -0700 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: References: Message-ID: <96542a00-461b-0f6b-9890-6d1b657cd98b@oracle.com> To put my earlier mail in concrete terms: On 4/25/2023 8:33 AM, Volker Simonis wrote: > Instead of relying on the *global* `-source` setting, I think > `firstUnimplementedAbstractImpl()` should rather rely on the class > file version of the corresponing class (i.e. `B` in this case) and if > that class file version is >= 8, it should consider its default method > implementations. I even think that the check for `allowDefaultMethods` > could be completely removed, because if the class dependency `B` > wasn't compiled before, it will be compiled from source and fail for > `-source 7` because it contains a default method. If on the other > hand, the class dependency `B` was already compiled to a class file > with `-source 8` it is OK to use it's default method. It's not OK to consider, use, or interpret a default method in B.class (version >= Java 8) when compiling C.java with `-source 7`. Arguably, javac with `-source 7` shouldn't even read class files whose version is > Java 7. Such class files will contain artifacts that have no meaning to a program written in the Java language specified by JLS7. Alex From joe.darcy at oracle.com Tue Apr 25 20:03:47 2023 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 25 Apr 2023 13:03:47 -0700 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: <52851018.42407693.1682450266863.JavaMail.zimbra@univ-eiffel.fr> References: <080e63b9-0168-f678-16ea-fb941bb9aa89@oracle.com> <52851018.42407693.1682450266863.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On a related point, among the many advantages of using ??? javac --release $OLD ... over something like ??? javac -source $OLD is that whole categories of version mismatches, how newer language structures should be presented to older source versions, are avoided with respect to the platform libraries. Compiling clients of libraries at -source/--release level no earlier than their dependencies seems like a reasonable build configuration constraint. -Joe On 4/25/2023 12:17 PM, Remi Forax wrote: > ----- Original Message ----- >> From: "Alex Buckley" >> To: "compiler-dev" >> Sent: Tuesday, April 25, 2023 7:09:41 PM >> Subject: Re: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces >> On 4/25/2023 8:33 AM, Volker Simonis wrote: >>> ``` >>> interface A { >>> void foo(); >>> } >>> ``` >>> >>> ``` >>> interface B extends A { >>> @Override default void foo() { } >>> } >>> ``` >>> >>> ``` >>> class C implements B { } >>> ``` >>> >>> If we compile `A.java` and `B.java` with `javac -source 8` and >>> `C.java` with `-source 7` we will get the following error: >>> ``` >>> $ javac -source 8 A.java >>> $ javac -source 8 B.java >>> $ javac -source 7 C.java >>> C.java:1: error: C is not abstract and does not override abstract >>> method foo() in A >>> class C implements B { } >>> ``` >>> >>> I think this is wrong, because `foo()` is implemented as a default >>> method in `B`. >> The Java language circa JLS7 does not have default methods, so the >> membership of C cannot possibly involve a default method inherited from >> B. The Java language is backward compatible, not forward compatible. >> >> A Java compiler that adheres to JLS7 (`-source 7`) is right to reject >> C.java -- either with the error given above, or with a more >> context-aware error along the lines of "C is written for Java 7, cannot >> inherit default method from B". >> >>> The following, slightly simpler example works perfectly fine, although >>> it also depends on a default method in an implemented interface: >>> >>> ``` >>> interface D { >>> default void bar() { } >>> } >>> ``` >>> >>> ``` >>> class E implements D { } >>> ``` >>> >>> ``` >>> $ javac -source 8 D.java >>> $ javac -source 7 E.java >>> ``` >>> >>> In the second example, `javac` happily accepts the default >>> implementation of `bar()` from interface `D`. >> It's hard to see how javac is processing class E, so I added a method >> declaration `@Override public void bar() {}` to E and `javac -source 7 >> E.java` accepted the code. That's improper, because in Java 7 there is >> no such thing as a default method in D to override from E. >> >> I then added a method invocation `D.super.bar();` as the body of E's bar >> method. In JLS8, this means "invoke my superinterface's default method". >> However, in JLS7, it means "invoke my enclosing class's method", but D >> isn't an enclosing class, so it's illegal (see >> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.1-100-D) >> -- yet `javac -source 7 E.java` accepts it anyway. Highly improper on >> javac's part. >> >> Alex > Alex, Java 8 adds a lot of default methods to the interfaces of the collection API, so javac8 -source 7 could not stop each time it sees a default methods, otherwise a lot of code will never have compiled. Which means that javac7 -source 7 and javac8 -source 7 have to have different behaviors. > > It was decided that javac8 -source 7 should skip default methods because it works well with the collection API even if it does not work that well in other cases as the one provided by Volker. > > Volker, I believe the behavior you see is not a bug, it's how javac should behave. But i don't think this behavior is specified somewhere, that why ecj has a different behavior. Moreover, javac never behaves differently depending on a specific classfile version of a specific classfile to preserve the sanity of the people trying to debug issues involving several versions. > > regards, > R?mi From acobbs at openjdk.org Tue Apr 25 20:47:57 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 25 Apr 2023 20:47:57 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() Message-ID: This is a first draft of a patch for JEP 447. Summary of changes: 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. ------------- Commit messages: - Use for() loop instead of stream for efficiency. - Fix typo in comment. - Merge branch 'master' into SuperInit - Fix Javadoc comment. - Merge branch 'master' into SuperInit - Merge branch 'master' into SuperInit - Merge branch 'master' into SuperInit - Merge branch 'master' into SuperInit - Merge branch 'master' into SuperInit - Merge branch 'master' into SuperInit - ... and 4 more: https://git.openjdk.org/jdk/compare/bad6aa68...0eac8b68 Changes: https://git.openjdk.org/jdk/pull/13656/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8194743 Stats: 1340 lines in 20 files changed: 1076 ins; 162 del; 102 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From duke at openjdk.org Wed Apr 26 01:22:23 2023 From: duke at openjdk.org (ExE Boss) Date: Wed, 26 Apr 2023 01:22:23 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 20:40:18 GMT, Archie Cobbs wrote: > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5591: > 5589: } > 5590: > 5591: // Check for proper placement of super()/init() calls. Suggestion: // Check for proper placement of super()/this() calls. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2859: > 2857: letInit(tree.pos(), sym); > 2858: } > 2859: } The?common `isConstructor`?check can?be?moved to?an?enclosing `if`?statement: Suggestion: if (isConstructor) { // If super(): at this point all initialization blocks will execute Name name = TreeInfo.name(tree.meth); if (name == names._super) { forEachInitializer(classDef, false, def -> { scan(def); clearPendingExits(false); }); } // If this(): at this point all final uninitialized fields will get initialized else if (name == names._this) { for (int address = firstadr; address < nextadr; address++) { VarSymbol sym = vardecls[address].sym; if (isFinalUninitializedField(sym) && !sym.isStatic()) letInit(tree.pos(), sym); } } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1177207245 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1177209992 From acobbs at openjdk.org Wed Apr 26 02:25:57 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 26 Apr 2023 02:25:57 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v2] In-Reply-To: References: Message-ID: <0iBw7BzPsaoSs-4C4n5imanznVXSwaiN4hfigr34H60=.af35031e-d089-4406-a82e-840fb3f01c72@github.com> > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Small refactoring to avoid redundant test. - Fix typo in comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13656/files - new: https://git.openjdk.org/jdk/pull/13656/files/0eac8b68..0e638da2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=00-01 Stats: 25 lines in 2 files changed: 10 ins; 6 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From acobbs at openjdk.org Wed Apr 26 02:27:24 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 26 Apr 2023 02:27:24 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v2] In-Reply-To: References: Message-ID: <5JSNfp3HQJp86bdSxKe0Zgl4TCZ9HgU44vvBtyqb9n0=.db9550dd-1a27-42ef-9534-7c65b1cafb43@github.com> On Wed, 26 Apr 2023 01:06:37 GMT, ExE Boss wrote: >> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Small refactoring to avoid redundant test. >> - Fix typo in comment. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5591: > >> 5589: } >> 5590: >> 5591: // Check for proper placement of super()/init() calls. > > Suggestion: > > // Check for proper placement of super()/this() calls. Thanks for catching that - fixed in 0e638da2daa. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2859: > >> 2857: letInit(tree.pos(), sym); >> 2858: } >> 2859: } > > The?common `isConstructor`?check can?be?moved to?an?enclosing `if`?statement: > > Suggestion: > > if (isConstructor) { > // If super(): at this point all initialization blocks will execute > Name name = TreeInfo.name(tree.meth); > if (name == names._super) { > forEachInitializer(classDef, false, def -> { > scan(def); > clearPendingExits(false); > }); > } > > // If this(): at this point all final uninitialized fields will get initialized > else if (name == names._this) { > for (int address = firstadr; address < nextadr; address++) { > VarSymbol sym = vardecls[address].sym; > if (isFinalUninitializedField(sym) && !sym.isStatic()) > letInit(tree.pos(), sym); > } > } > } Yep, thanks - applied in 0e638da2daa. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1177249124 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1177249633 From acobbs at openjdk.org Wed Apr 26 02:58:23 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 26 Apr 2023 02:58:23 GMT Subject: RFR: 8305671: javac rejects semicolons in compilation units with no imports [v4] In-Reply-To: References: Message-ID: > The fix for [JDK-8027682](https://bugs.openjdk.org/browse/JDK-8027682) created a new bug in which a program like this: > > package p;; > > would be rejected. > > This is due to the previous fix swallowing all the semicolons. Instead, in the case of semicolons followed by EOF, it needs to swallow all but the last one. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into JDK-8305671 - Consume extra semicolons in a more straightforward way. - Merge branch 'master' into JDK-8305671 - Use ToolBox and add more tests per review suggestion. - Allow a package declaration followed (only) by multiple commas. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13361/files - new: https://git.openjdk.org/jdk/pull/13361/files/f2de70cf..0561a6cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13361&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13361&range=02-03 Stats: 19380 lines in 404 files changed: 13989 ins; 3988 del; 1403 mod Patch: https://git.openjdk.org/jdk/pull/13361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13361/head:pull/13361 PR: https://git.openjdk.org/jdk/pull/13361 From acobbs at openjdk.org Wed Apr 26 02:59:53 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 26 Apr 2023 02:59:53 GMT Subject: RFR: 8305672: Surprising definite assignment error after JDK-8043179 [v3] In-Reply-To: References: Message-ID: > The fix for [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) is to clear the DU flags for all variables when entering a lamba. This reflects the fact that the lamba's actual execution could be arbitrarily far in the future, so we can't assume anything that is DU when the lambda is created is still DU when the lambda actually executes. > > However, this fix created a new bug. The problem is that `visitLambda()` does not save & restore the `uninitsTry` bits, which are used by `visitTry()` to track DU variables within `try { }` blocks. So if there is a `try { }` block outside the lambda and a `try { }` block inside the lambda, the latter can "leak" DU state up to the former via this field. As a result, a final variable that should still be DU at the completion of the outer `try { }` block can be incorrectly recorded as not DU, leading to the bogus "might already have been assigned" error. > > This patch fixes that by adding the necessary save & restore logic. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8305672 - Merge branch 'master' into JDK-8305672 - Fix failure of visitLambda() to save & restore uninitsTry bits. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13366/files - new: https://git.openjdk.org/jdk/pull/13366/files/a07bdb78..3fce25b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13366&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13366&range=01-02 Stats: 20571 lines in 488 files changed: 14268 ins; 4168 del; 2135 mod Patch: https://git.openjdk.org/jdk/pull/13366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13366/head:pull/13366 PR: https://git.openjdk.org/jdk/pull/13366 From volker.simonis at gmail.com Wed Apr 26 12:33:05 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Apr 2023 14:33:05 +0200 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: References: <080e63b9-0168-f678-16ea-fb941bb9aa89@oracle.com> <52851018.42407693.1682450266863.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On Tue, Apr 25, 2023 at 10:03?PM Joseph D. Darcy wrote: > > On a related point, among the many advantages of using > > javac --release $OLD ... > > over something like > > javac -source $OLD > > is that whole categories of version mismatches, how newer language > structures should be presented to older source versions, are avoided > with respect to the platform libraries. > In general I agree, but "--release" is not available for JDK 8 and as you've mentioned, it only works for the platform libraries but not for third party dependencies. Finally, it elegantly avoids the problem of how to "present newer language structures to older source versions" by not using class files at all but instead relying on purely symbolic information from the ct.sym file (but again, only for the platform classes). > Compiling clients of libraries at -source/--release level no earlier > than their dependencies seems like a reasonable build configuration > constraint. Again, I agree in general, but imagine that your client (and not the dependent library) has to be processed by an old library which doesn't understand the newer bytecode version. > > -Joe > > On 4/25/2023 12:17 PM, Remi Forax wrote: > > ----- Original Message ----- > >> From: "Alex Buckley" > >> To: "compiler-dev" > >> Sent: Tuesday, April 25, 2023 7:09:41 PM > >> Subject: Re: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces > >> On 4/25/2023 8:33 AM, Volker Simonis wrote: > >>> ``` > >>> interface A { > >>> void foo(); > >>> } > >>> ``` > >>> > >>> ``` > >>> interface B extends A { > >>> @Override default void foo() { } > >>> } > >>> ``` > >>> > >>> ``` > >>> class C implements B { } > >>> ``` > >>> > >>> If we compile `A.java` and `B.java` with `javac -source 8` and > >>> `C.java` with `-source 7` we will get the following error: > >>> ``` > >>> $ javac -source 8 A.java > >>> $ javac -source 8 B.java > >>> $ javac -source 7 C.java > >>> C.java:1: error: C is not abstract and does not override abstract > >>> method foo() in A > >>> class C implements B { } > >>> ``` > >>> > >>> I think this is wrong, because `foo()` is implemented as a default > >>> method in `B`. > >> The Java language circa JLS7 does not have default methods, so the > >> membership of C cannot possibly involve a default method inherited from > >> B. The Java language is backward compatible, not forward compatible. > >> > >> A Java compiler that adheres to JLS7 (`-source 7`) is right to reject > >> C.java -- either with the error given above, or with a more > >> context-aware error along the lines of "C is written for Java 7, cannot > >> inherit default method from B". > >> > >>> The following, slightly simpler example works perfectly fine, although > >>> it also depends on a default method in an implemented interface: > >>> > >>> ``` > >>> interface D { > >>> default void bar() { } > >>> } > >>> ``` > >>> > >>> ``` > >>> class E implements D { } > >>> ``` > >>> > >>> ``` > >>> $ javac -source 8 D.java > >>> $ javac -source 7 E.java > >>> ``` > >>> > >>> In the second example, `javac` happily accepts the default > >>> implementation of `bar()` from interface `D`. > >> It's hard to see how javac is processing class E, so I added a method > >> declaration `@Override public void bar() {}` to E and `javac -source 7 > >> E.java` accepted the code. That's improper, because in Java 7 there is > >> no such thing as a default method in D to override from E. > >> > >> I then added a method invocation `D.super.bar();` as the body of E's bar > >> method. In JLS8, this means "invoke my superinterface's default method". > >> However, in JLS7, it means "invoke my enclosing class's method", but D > >> isn't an enclosing class, so it's illegal (see > >> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.1-100-D) > >> -- yet `javac -source 7 E.java` accepts it anyway. Highly improper on > >> javac's part. > >> > >> Alex > > Alex, Java 8 adds a lot of default methods to the interfaces of the collection API, so javac8 -source 7 could not stop each time it sees a default methods, otherwise a lot of code will never have compiled. Which means that javac7 -source 7 and javac8 -source 7 have to have different behaviors. > > > > It was decided that javac8 -source 7 should skip default methods because it works well with the collection API even if it does not work that well in other cases as the one provided by Volker. > > > > Volker, I believe the behavior you see is not a bug, it's how javac should behave. But i don't think this behavior is specified somewhere, that why ecj has a different behavior. Moreover, javac never behaves differently depending on a specific classfile version of a specific classfile to preserve the sanity of the people trying to debug issues involving several versions. > > > > regards, > > R?mi From volker.simonis at gmail.com Wed Apr 26 12:54:48 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Apr 2023 14:54:48 +0200 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: <96542a00-461b-0f6b-9890-6d1b657cd98b@oracle.com> References: <96542a00-461b-0f6b-9890-6d1b657cd98b@oracle.com> Message-ID: On Tue, Apr 25, 2023 at 9:23?PM Alex Buckley wrote: > > To put my earlier mail in concrete terms: > > On 4/25/2023 8:33 AM, Volker Simonis wrote: > > Instead of relying on the *global* `-source` setting, I think > > `firstUnimplementedAbstractImpl()` should rather rely on the class > > file version of the corresponing class (i.e. `B` in this case) and if > > that class file version is >= 8, it should consider its default method > > implementations. I even think that the check for `allowDefaultMethods` > > could be completely removed, because if the class dependency `B` > > wasn't compiled before, it will be compiled from source and fail for > > `-source 7` because it contains a default method. If on the other > > hand, the class dependency `B` was already compiled to a class file > > with `-source 8` it is OK to use it's default method. > > It's not OK to consider, use, or interpret a default method in B.class > (version >= Java 8) when compiling C.java with `-source 7`. > > Arguably, javac with `-source 7` shouldn't even read class files whose > version is > Java 7. Such class files will contain artifacts that have > no meaning to a program written in the Java language specified by JLS7. That sounds good in an ideal world, but it is not how it has worked for more than a decade. javac from JDK N running with '-source M' (with M < N) has always accepted class files up to the class file version N. I'm just asking how to pragmatically handle an apparently unspecified conflict which arises when javac with `-source 7` is referring to class files of version 8 which contain default methods. As we've seen, the handling is already inconsistent in OpenJDK's javac implementation itself (i.e. compiling C.java from my example fails while compiling E.java succeeds) and differs even more between independent implementations of javac like e.g. ecj. What would be the downside of making the simple change I've proposed and accept default methods in Java 8+ classes as implementations for interface methods if compiling with '-source 7'? That change would only impact code generated with '-source 7' anyway and apparently other javac implementation already allow this without any issues since quite some time. Or am I missing some major problem? Thanks a lot for your comments, Volker > > Alex From volker.simonis at gmail.com Wed Apr 26 14:10:26 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Apr 2023 16:10:26 +0200 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: <52851018.42407693.1682450266863.JavaMail.zimbra@univ-eiffel.fr> References: <080e63b9-0168-f678-16ea-fb941bb9aa89@oracle.com> <52851018.42407693.1682450266863.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On Tue, Apr 25, 2023 at 9:17?PM Remi Forax wrote: > > ----- Original Message ----- > > From: "Alex Buckley" > > To: "compiler-dev" > > Sent: Tuesday, April 25, 2023 7:09:41 PM > > Subject: Re: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces > > > On 4/25/2023 8:33 AM, Volker Simonis wrote: > >> ``` > >> interface A { > >> void foo(); > >> } > >> ``` > >> > >> ``` > >> interface B extends A { > >> @Override default void foo() { } > >> } > >> ``` > >> > >> ``` > >> class C implements B { } > >> ``` > >> > >> If we compile `A.java` and `B.java` with `javac -source 8` and > >> `C.java` with `-source 7` we will get the following error: > >> ``` > >> $ javac -source 8 A.java > >> $ javac -source 8 B.java > >> $ javac -source 7 C.java > >> C.java:1: error: C is not abstract and does not override abstract > >> method foo() in A > >> class C implements B { } > >> ``` > >> > >> I think this is wrong, because `foo()` is implemented as a default > >> method in `B`. > > > > The Java language circa JLS7 does not have default methods, so the > > membership of C cannot possibly involve a default method inherited from > > B. The Java language is backward compatible, not forward compatible. > > > > A Java compiler that adheres to JLS7 (`-source 7`) is right to reject > > C.java -- either with the error given above, or with a more > > context-aware error along the lines of "C is written for Java 7, cannot > > inherit default method from B". > > > >> The following, slightly simpler example works perfectly fine, although > >> it also depends on a default method in an implemented interface: > >> > >> ``` > >> interface D { > >> default void bar() { } > >> } > >> ``` > >> > >> ``` > >> class E implements D { } > >> ``` > >> > >> ``` > >> $ javac -source 8 D.java > >> $ javac -source 7 E.java > >> ``` > >> > >> In the second example, `javac` happily accepts the default > >> implementation of `bar()` from interface `D`. > > > > It's hard to see how javac is processing class E, so I added a method > > declaration `@Override public void bar() {}` to E and `javac -source 7 > > E.java` accepted the code. That's improper, because in Java 7 there is > > no such thing as a default method in D to override from E. > > > > I then added a method invocation `D.super.bar();` as the body of E's bar > > method. In JLS8, this means "invoke my superinterface's default method". > > However, in JLS7, it means "invoke my enclosing class's method", but D > > isn't an enclosing class, so it's illegal (see > > https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.1-100-D) > > -- yet `javac -source 7 E.java` accepts it anyway. Highly improper on > > javac's part. > > > > Alex > > Alex, Java 8 adds a lot of default methods to the interfaces of the collection API, so javac8 -source 7 could not stop each time it sees a default methods, otherwise a lot of code will never have compiled. Which means that javac7 -source 7 and javac8 -source 7 have to have different behaviors. > > It was decided that javac8 -source 7 should skip default methods because it works well with the collection API even if it does not work that well in other cases as the one provided by Volker. What do you mean by "skip". 'javac8 -source 7' can make use of default methods quite well. E.g. in the following example: ``` interface D { default void bar() { } } ``` ``` class F implements D { void foo() { bar(); } } ``` ``` $ javac -source 8 D.java $ javac -source 7 F.java ``` javac will add an invokevirtual call to `bar()` into `F::foo()` (it basically generated the same code like with 'source 8'). The problem is that it doesn't recognize default methods in all cases as my first example demonstrated. > Volker, I believe the behavior you see is not a bug, it's how javac should behave. But i don't think this behavior is specified somewhere, that why ecj has a different behavior. Moreover, javac never behaves differently depending on a specific classfile version of a specific classfile to preserve the sanity of the people trying to debug issues involving several versions. I can accept that the current behavior isn't considered a bug (because without proper specification, how can we know what the correct behavior is :) But let me ask the other way round: would it be a bug if 'javac -source 7' would also handle my first example without emitting an error? The fix I've proposed is minimal, only affects 'javac -source 7' and doesn't seem to do any harm. Or am I missing some bigger problems? Thank you and best regards, Volker > > regards, > R?mi From brian.goetz at oracle.com Wed Apr 26 14:14:29 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 26 Apr 2023 10:14:29 -0400 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: References: <96542a00-461b-0f6b-9890-6d1b657cd98b@oracle.com> Message-ID: I was a little disappointed to wake up today and see that this thread was still going.? Two of the world's experts on conformance have told you "no, you can't do the thing you want to do", and "no, it's not a minor technical problem", and yet you're still treating this as a "surely there is some simple thing I can do" kind of thing. Alex said: >> It's not OK to consider, use, or interpret a default method in B.class >> (version >= Java 8) when compiling C.java with `-source 7`. This is as definitive an answer as you could possibly hope to get. > I'm just asking how to pragmatically handle an apparently unspecified > conflict There's that word again -- "just".? It's amazing how we instinctively put the word "just" into sentences like the above to make unreasonable things sound more reasonable. This is not an "apparently unspecified conflict"; this was a deeply considered issue when we evolved the platform to add default methods.? The thing that the compiler does currently in this situation -- ignore the parts of the Java 8 classfile that are not allowed in Java 7 -- was deemed to be absolutely the most that could possibly be done here.? Java 7 does not have default methods. That you're even trying to compile Java 7 source against later classfiles is, as Alex and Joe both point out, already on the hairy edge here.? But trying to go farther, and interpret those later classfiles _with later semantics_ is way, way over the line. > What would be the downside of making the simple change I've proposed > and accept default methods in Java 8+ classes as implementations for > interface methods if compiling with '-source 7'? That change would > only impact code generated with '-source 7' anyway and apparently > other javac implementation already allow this without any issues since > quite some time. Or am I missing some major problem? Yes, you're missing a major problem.? Your solution amounts to "It would be really convenient for me and my users if I could fork the language".?? While I'm not going to disagree with the convenience part of that, I think you're ignoring the "fork" part of that.? This is not a mere "implementation detail" or "bug to be fixed"; your gripe is with the language that is implemented by the compiler, and that language is specified by the Java SE 7 specification. The Java language specification is strongly versioned.? A Java 7 program has a meaning, given to it by the 7 specification, and default methods are not part of that meaning.? You're proposing hacking the compiler to accept a different language, and yet still call it Java; that is clearly a hostile fork.?? So yes, you're missing a major problem. I hope this is clear enough now! Cheers, -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Apr 26 14:40:46 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Apr 2023 16:40:46 +0200 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: References: <96542a00-461b-0f6b-9890-6d1b657cd98b@oracle.com> Message-ID: On Wed, Apr 26, 2023 at 4:14?PM Brian Goetz wrote: > > I was a little disappointed to wake up today and see that this thread was still going. Two of the world's experts on conformance have told you "no, you can't do the thing you want to do", and "no, it's not a minor technical problem", and yet you're still treating this as a "surely there is some simple thing I can do" kind of thing. > > Alex said: > > It's not OK to consider, use, or interpret a default method in B.class > (version >= Java 8) when compiling C.java with `-source 7`. > > > This is as definitive an answer as you could possibly hope to get. > > I'm just asking how to pragmatically handle an apparently unspecified > conflict > > > There's that word again -- "just". It's amazing how we instinctively put the word "just" into sentences like the above to make unreasonable things sound more reasonable. > > This is not an "apparently unspecified conflict"; this was a deeply considered issue when we evolved the platform to add default methods. The thing that the compiler does currently in this situation -- ignore the parts of the Java 8 classfile that are not allowed in Java 7 -- was deemed to be absolutely the most that could possibly be done here. Java 7 does not have default methods. > > That you're even trying to compile Java 7 source against later classfiles is, as Alex and Joe both point out, already on the hairy edge here. But trying to go farther, and interpret those later classfiles _with later semantics_ is way, way over the line. > > What would be the downside of making the simple change I've proposed > and accept default methods in Java 8+ classes as implementations for > interface methods if compiling with '-source 7'? That change would > only impact code generated with '-source 7' anyway and apparently > other javac implementation already allow this without any issues since > quite some time. Or am I missing some major problem? > > > Yes, you're missing a major problem. Your solution amounts to "It would be really convenient for me and my users if I could fork the language". While I'm not going to disagree with the convenience part of that, I think you're ignoring the "fork" part of that. This is not a mere "implementation detail" or "bug to be fixed"; your gripe is with the language that is implemented by the compiler, and that language is specified by the Java SE 7 specification. > > The Java language specification is strongly versioned. A Java 7 program has a meaning, given to it by the 7 specification, and default methods are not part of that meaning. You're proposing hacking the compiler to accept a different language, and yet still call it Java; that is clearly a hostile fork. So yes, you're missing a major problem. > > I hope this is clear enough now! Sorry Brian, but I have not introduced the "cross compiling" functionality of javac and it was not me who allowed 'javac -source 7' to read and process Java 8 class files. I could fully accept your answer if 'javac -source 7' would plainly reject to process Java 8 class files. But that's not and never was the case. As my examples clearly demonstrate, javac is already doing what you are demonizing, namely "interpreting later classfiles _with later semantics_" in some undocumented way. I'm truly sorry that I spoiled your morning and that I dared to ask the authors of javac why they have chosen to implemented the unspecified behavior of "interpreting later classfiles _with later semantics_" in a specific way and why doing it in a slightly different way would be inferior or superior. I promise to never do it again :) Best regards, Volker > Cheers, > -Brian From archie.cobbs at gmail.com Wed Apr 26 14:50:25 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 26 Apr 2023 09:50:25 -0500 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: References: <96542a00-461b-0f6b-9890-6d1b657cd98b@oracle.com> Message-ID: On Wed, Apr 26, 2023 at 9:41?AM Volker Simonis wrote: > On Wed, Apr 26, 2023 at 4:14?PM Brian Goetz > wrote: > > It's not OK to consider, use, or interpret a default method in B.class > > (version >= Java 8) when compiling C.java with `-source 7`. > > I could fully accept your answer if 'javac -source 7' would plainly reject > to process Java 8 class files. An observation from a neutral observer... I think there is a basic confusion here about what exactly the "-source" flag is supposed to mean. A basic question: what, if anything, does "-source" have to do with how CLASS files are interpreted?? Brian seems to be implying that it only affects how SOURCE files are interpreted. Volker seems to be implying that it should also affect how CLASS files are interpreted. Maybe clarifying this question would help. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From abimpoudis at openjdk.org Wed Apr 26 15:28:24 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 26 Apr 2023 15:28:24 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables [v2] In-Reply-To: References: Message-ID: > This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. > > Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Introduce new flag to track unnamed variables - Return underscore for Tree API and empty name for javax.lang.model.element.VariableElement.getSimpleName() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13528/files - new: https://git.openjdk.org/jdk/pull/13528/files/6e3f495e..624d3f4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=00-01 Stats: 308 lines in 16 files changed: 278 ins; 10 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/13528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528 PR: https://git.openjdk.org/jdk/pull/13528 From forax at univ-mlv.fr Wed Apr 26 16:16:50 2023 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 26 Apr 2023 18:16:50 +0200 (CEST) Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: References: <080e63b9-0168-f678-16ea-fb941bb9aa89@oracle.com> <52851018.42407693.1682450266863.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1863259394.42807231.1682525810568.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Volker Simonis" > To: "Remi Forax" > Cc: "Alex Buckley" , "compiler-dev" > Sent: Wednesday, April 26, 2023 4:10:26 PM > Subject: Re: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces > On Tue, Apr 25, 2023 at 9:17?PM Remi Forax wrote: >> >> ----- Original Message ----- >> > From: "Alex Buckley" >> > To: "compiler-dev" >> > Sent: Tuesday, April 25, 2023 7:09:41 PM >> > Subject: Re: 8306854: javac with '-source 7' should honor default methods in >> > implemented Java 8 interfaces >> >> > On 4/25/2023 8:33 AM, Volker Simonis wrote: >> >> ``` >> >> interface A { >> >> void foo(); >> >> } >> >> ``` >> >> >> >> ``` >> >> interface B extends A { >> >> @Override default void foo() { } >> >> } >> >> ``` >> >> >> >> ``` >> >> class C implements B { } >> >> ``` >> >> >> >> If we compile `A.java` and `B.java` with `javac -source 8` and >> >> `C.java` with `-source 7` we will get the following error: >> >> ``` >> >> $ javac -source 8 A.java >> >> $ javac -source 8 B.java >> >> $ javac -source 7 C.java >> >> C.java:1: error: C is not abstract and does not override abstract >> >> method foo() in A >> >> class C implements B { } >> >> ``` >> >> >> >> I think this is wrong, because `foo()` is implemented as a default >> >> method in `B`. >> > >> > The Java language circa JLS7 does not have default methods, so the >> > membership of C cannot possibly involve a default method inherited from >> > B. The Java language is backward compatible, not forward compatible. >> > >> > A Java compiler that adheres to JLS7 (`-source 7`) is right to reject >> > C.java -- either with the error given above, or with a more >> > context-aware error along the lines of "C is written for Java 7, cannot >> > inherit default method from B". >> > >> >> The following, slightly simpler example works perfectly fine, although >> >> it also depends on a default method in an implemented interface: >> >> >> >> ``` >> >> interface D { >> >> default void bar() { } >> >> } >> >> ``` >> >> >> >> ``` >> >> class E implements D { } >> >> ``` >> >> >> >> ``` >> >> $ javac -source 8 D.java >> >> $ javac -source 7 E.java >> >> ``` >> >> >> >> In the second example, `javac` happily accepts the default >> >> implementation of `bar()` from interface `D`. >> > >> > It's hard to see how javac is processing class E, so I added a method >> > declaration `@Override public void bar() {}` to E and `javac -source 7 >> > E.java` accepted the code. That's improper, because in Java 7 there is >> > no such thing as a default method in D to override from E. >> > >> > I then added a method invocation `D.super.bar();` as the body of E's bar >> > method. In JLS8, this means "invoke my superinterface's default method". >> > However, in JLS7, it means "invoke my enclosing class's method", but D >> > isn't an enclosing class, so it's illegal (see >> > https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.1-100-D) >> > -- yet `javac -source 7 E.java` accepts it anyway. Highly improper on >> > javac's part. >> > >> > Alex >> >> Alex, Java 8 adds a lot of default methods to the interfaces of the collection >> API, so javac8 -source 7 could not stop each time it sees a default methods, >> otherwise a lot of code will never have compiled. Which means that javac7 >> -source 7 and javac8 -source 7 have to have different behaviors. >> >> It was decided that javac8 -source 7 should skip default methods because it >> works well with the collection API even if it does not work that well in other >> cases as the one provided by Volker. > > What do you mean by "skip". 'javac8 -source 7' can make use of default > methods quite well. Skip the implementation part when considering overriding. >From the POV of the compiler javac8 -source 7, a default method behave like an abstract method. R?mi From volker.simonis at gmail.com Wed Apr 26 16:49:21 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Apr 2023 18:49:21 +0200 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: References: <96542a00-461b-0f6b-9890-6d1b657cd98b@oracle.com> Message-ID: On Wed, Apr 26, 2023 at 4:50?PM Archie Cobbs wrote: > > On Wed, Apr 26, 2023 at 9:41?AM Volker Simonis wrote: >> >> On Wed, Apr 26, 2023 at 4:14?PM Brian Goetz wrote: >> > It's not OK to consider, use, or interpret a default method in B.class >> > (version >= Java 8) when compiling C.java with `-source 7`. >> >> I could fully accept your answer if 'javac -source 7' would plainly reject to process Java 8 class files. > > > An observation from a neutral observer... > > I think there is a basic confusion here about what exactly the "-source" flag is supposed to mean. > > A basic question: what, if anything, does "-source" have to do with how CLASS files are interpreted?? > > Brian seems to be implying that it only affects how SOURCE files are interpreted. > > Volker seems to be implying that it should also affect how CLASS files are interpreted. > > Maybe clarifying this question would help. That's exactly the problem, that the semantics of the '-source' flag aren't specified anywhere else except in the implementation. So the discussion here is about how to exactly handle class files which are newer than the version given with '-source' because the fact that they are already handled in some way is a matter of fact. I'm not saying that the '-source X' flags is a great idea. I'm happy to remove it altogether or to restrict it to class files <=X because otherwise it is probably impossible to get its semantics right. The current documentation/implementation is just creating the wrong expectations among developers. > > -Archie > > -- > Archie L. Cobbs From darcy at openjdk.org Wed Apr 26 17:52:53 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 26 Apr 2023 17:52:53 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables [v2] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 15:28:24 GMT, Aggelos Biboudis wrote: >> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. >> >> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Introduce new flag to track unnamed variables > > - Return underscore for Tree API and empty name for javax.lang.model.element.VariableElement.getSimpleName() src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 716: > 714: * @since 21 > 715: */ > 716: default boolean hasEmptyName(Element element) { Updating some suggestions from an off-list discussion, ModuleElement and PackageElement both have an isUnnamed predicate. VariableElement could get an isUnnamed predicate (as a default method returning false and an implSpec tag requiring that) or Elements.isUnnamed(VariableElement) could be added similarly. Presumably, at least any newly-defined methods should get marked as some category of preview method. Also, please file a issue against core-libs/javax.lang.model for javax.lang.model support for this JEP; having a separate issue makes doing the JSR 269 maintenance release work easier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1178201512 From jlahoda at openjdk.org Wed Apr 26 20:12:23 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 26 Apr 2023 20:12:23 GMT Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for switch [v8] In-Reply-To: References: Message-ID: > This is the first draft of a patch for JEP 440 and JEP 441. Changes included: > > - the pattern matching for switch and record patterns features are made final, together with updates to tests. > - parenthesized patterns are removed. > - qualified enum constants are supported for case labels. > > This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Cleanup: reflecting review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13074/files - new: https://git.openjdk.org/jdk/pull/13074/files/35f51562..3b3bcbcc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=06-07 Stats: 135 lines in 4 files changed: 0 ins; 65 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/13074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074 PR: https://git.openjdk.org/jdk/pull/13074 From archie.cobbs at gmail.com Wed Apr 26 21:11:36 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 26 Apr 2023 16:11:36 -0500 Subject: 8306854: javac with '-source 7' should honor default methods in implemented Java 8 interfaces In-Reply-To: References: <96542a00-461b-0f6b-9890-6d1b657cd98b@oracle.com> Message-ID: On Wed, Apr 26, 2023 at 11:49?AM Volker Simonis wrote: > > Brian seems to be implying that it only affects how SOURCE files are > interpreted. > > > > Volker seems to be implying that it should also affect how CLASS files > are interpreted. > > > > Maybe clarifying this question would help. > > That's exactly the problem, that the semantics of the '-source' flag > aren't specified anywhere else except in the implementation. So the > discussion here is about how to exactly handle class files which are > newer than the version given with '-source' because the fact that they > are already handled in some way is a matter of fact. > > I'm not saying that the '-source X' flags is a great idea. I'm happy > to remove it altogether or to restrict it to class files <=X because > otherwise it is probably impossible to get its semantics right. The > current documentation/implementation is just creating the wrong > expectations among developers. > There indeed may be a documentation ambiguity... Regardless, let's pinpoint the problem: The intended semantic of "-source X" can be stated as: When processing a source file, the rules of JLS version X should apply to that source file. The problem is that class files populate the overall environment in which a source file is processed, and they might be from version Y > X. In other words, even though we are processing a version X source file, we might be doing it in the context of a version Y environment. So the question is, if JLS version X does not define some item (like a default method) that's only defined in version Y > X, how should that item, which was contributed to the environment by some version Y class file, affect the processing of a source file under the JLS rules of version X? It seems like the conservative and most reasonable answer is to keep that item out of the conversation entirely, which (I think) is what the compiler is doing. Trying to be more "helpful" seems like a laudable goal, but in practice will surely lead to a confusing mess, as the "Foo.super.method()" example demonstrates. But at this point you'd probably say: *Well the compiler is already trying to be "helpful" and has entered undefined waters by allowing a version X source file to be processed in a version Y environment in the first place. So how is trying to be even more helpful any worse?* Maybe the answer to that would be to say we've reached some inflexion point where going further is no longer worth the trade-off... -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjg at openjdk.org Wed Apr 26 21:18:24 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 26 Apr 2023 21:18:24 GMT Subject: RFR: JDK-8306952: improve generic signature of internal DCInlineTag class Message-ID: Please review a small update to the generic signature of the internal `DCInlineTag` class, to improve its use in chained method calls. ------------- Commit messages: - JDK-8306952: improve generic signature of internal DCInlineTag class Changes: https://git.openjdk.org/jdk/pull/13678/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13678&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306952 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13678/head:pull/13678 PR: https://git.openjdk.org/jdk/pull/13678 From iris at openjdk.org Thu Apr 27 01:10:55 2023 From: iris at openjdk.org (Iris Clark) Date: Thu, 27 Apr 2023 01:10:55 GMT Subject: RFR: JDK-8306952: improve generic signature of internal DCInlineTag class In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 21:03:16 GMT, Jonathan Gibbons wrote: > Please review a small update to the generic signature of the internal `DCInlineTag` class, to improve its use in chained method calls. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13678#pullrequestreview-1403028187 From jlaskey at openjdk.org Thu Apr 27 13:04:54 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 27 Apr 2023 13:04:54 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) Message-ID: Add flexible main methods and anonymous main classes to the Java language. ------------- Commit messages: - Clean up isPreview - Missing exception - Corrections - Update VM.java - Clean up testing - Update TestJavacTaskScanner.java - Merge branch 'master' into 8306112 - Clean up - remnant import - Revised main method lookup - ... and 2 more: https://git.openjdk.org/jdk/compare/98e8616a...cfe08f33 Changes: https://git.openjdk.org/jdk/pull/13689/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306112 Stats: 1265 lines in 29 files changed: 1111 ins; 62 del; 92 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jlaskey at openjdk.org Thu Apr 27 13:17:58 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 27 Apr 2023 13:17:58 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: PreviewFeatures.isEnabled() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/cfe08f33..a55af76c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=00-01 Stats: 32 lines in 3 files changed: 2 ins; 27 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From alanb at openjdk.org Thu Apr 27 13:49:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 27 Apr 2023 13:49:54 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 13:17:58 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > PreviewFeatures.isEnabled() src/java.base/share/classes/sun/launcher/LauncherHelper.java line 45: > 43: import java.lang.invoke.MethodHandles; > 44: import java.lang.invoke.MethodHandles.Lookup; > 45: import java.lang.invoke.MethodType; Left over from an earlier version? src/java.base/share/classes/sun/launcher/resources/launcher.properties line 240: > 238: Caused by: {1}: {2} > 239: java.launcher.cls.error8=\ > 240: Error: no non-private no argument constructor found in class {0} Since this feature is for new developers then the error messages will need to be understand, maybe it should be "zero argument" and give an example to help. src/java.base/share/native/libjli/java.c line 590: > 588: CHECK_EXCEPTION_NULL_LEAVE(mainID); > 589: (*env)->CallVoidMethod(env, mainObject, mainID); > 590: break; This calls into LauncherHelper to get the "main type", then calls the static or new/instance method. I'm wondering if you tried have a single entry point in LauncherHelper instead. I think the only downside might be that the trampoline would show up in stack traces but @Hidden could hide that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179174808 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179183719 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179172679 From jlaskey at openjdk.org Thu Apr 27 14:11:30 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 27 Apr 2023 14:11:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v64] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: - Merge branch 'master' into 8285932 - Spacing - Tidy up - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes - Typo - HexDigits -> OctalDigits - Remove preview feature on package private java.util.Digits - Recommended changes - Merge branch 'master' into 8285932 - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable. - ... and 73 more: https://git.openjdk.org/jdk/compare/96cdf93b...5c182232 ------------- Changes: https://git.openjdk.org/jdk/pull/10889/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=63 Stats: 9276 lines in 73 files changed: 9179 ins; 23 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From abimpoudis at openjdk.org Thu Apr 27 14:16:30 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 27 Apr 2023 14:16:30 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables [v3] In-Reply-To: References: Message-ID: > This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. > > Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Address javax.lang.model comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13528/files - new: https://git.openjdk.org/jdk/pull/13528/files/624d3f4f..19f1fc32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=01-02 Stats: 21 lines in 5 files changed: 18 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528 PR: https://git.openjdk.org/jdk/pull/13528 From abimpoudis at openjdk.org Thu Apr 27 14:35:53 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 27 Apr 2023 14:35:53 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables [v2] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 17:36:18 GMT, Joe Darcy wrote: >> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduce new flag to track unnamed variables >> >> - Return underscore for Tree API and empty name for javax.lang.model.element.VariableElement.getSimpleName() > > src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 716: > >> 714: * @since 21 >> 715: */ >> 716: default boolean hasEmptyName(Element element) { > > Updating some suggestions from an off-list discussion, ModuleElement and PackageElement both have an isUnnamed predicate. VariableElement could get an isUnnamed predicate (as a default method returning false and an implSpec tag requiring that) or Elements.isUnnamed(VariableElement) could be added similarly. > > Presumably, at least any newly-defined methods should get marked as some category of preview method. > > Also, please file a issue against core-libs/javax.lang.model for javax.lang.model support for this JEP; having a separate issue makes doing the JSR 269 maintenance release work easier. PR updated. Thanks for the review! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179253720 From abimpoudis at openjdk.org Thu Apr 27 14:56:53 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 27 Apr 2023 14:56:53 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v4] In-Reply-To: References: Message-ID: > This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. > > Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Update test files with JDK 8307007 bug id ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13528/files - new: https://git.openjdk.org/jdk/pull/13528/files/19f1fc32..cbe4c31b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528 PR: https://git.openjdk.org/jdk/pull/13528 From mcimadamore at openjdk.org Thu Apr 27 15:10:23 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 27 Apr 2023 15:10:23 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 13:17:58 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > PreviewFeatures.isEnabled() src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 432: > 430: > 431: // Restructure top level to be an top level anonymous class. > 432: public static void constructAnonymousMainClass(JCCompilationUnit tree, Question: any reason as to why this is done here and not in the parser? Typically we don't want to do tree transformation at parse time, as that messes up clients that want to access the "non-desugared" tree (such as IDE) and expect some mapping between source to AST. But if you do the rewriting in Enter, not much changes, that is, clients such as IDEs would still see something that doesn't resemble the source. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2433: > 2431: if (kind.contains(KindSelector.TYP)) { > 2432: sym = findType(env, name); > 2433: if ((sym.flags() & ANONYMOUS_MAIN_CLASS) != 0) { If `sym` is also `SYNTHTIC` (which it is) - do you need this? In what case? E.g. if there's a legitimate case for this I'm wondering if we should just test for `SYNTHETIC` rather than `ANONYMOUS_MAIN_CLASS`. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/VirtualParser.java line 191: > 189: * @param return type of parserAction > 190: */ > 191: public static Optional speculativeParse(JavacParser parser, Since this is never use, and because of the TODO - should we just drop it for the time being? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179286118 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179288860 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179292509 From vromero at openjdk.org Thu Apr 27 15:33:25 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 27 Apr 2023 15:33:25 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v3] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:16:30 GMT, Aggelos Biboudis wrote: >> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. >> >> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Address javax.lang.model comments src/jdk.compiler/share/classes/com/sun/source/tree/AnyPatternTree.java line 2: > 1: /* > 2: * Copyright (c) 2017, 2019, Oracle and/or its affiliates. All rights reserved. nit: copy year should be 2023? new file src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 278: > 276: > 277: /** > 278: * Flag that indicates that a local variable, a lambda parameter, or an unnamed pattern variable is unnamed. question: cant we infer this from the name itself instead of consuming a flag? src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 215: > 213: //When real preview features will be added, this method can be implemented to return 'true' > 214: //for those selected features, and 'false' for all the others. > 215: case UNNAMED_VARIABLES -> true; the comment above should apply to the default case I think ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179247824 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179251556 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179252709 From liangchenblue at gmail.com Thu Apr 27 15:58:06 2023 From: liangchenblue at gmail.com (-) Date: Thu, 27 Apr 2023 10:58:06 -0500 Subject: Requesting review for 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default Message-ID: Hello javac reviewers, I wish you can take a look at patch https://github.com/openjdk/jdk/pull/9862 with JBS issue at https://bugs.openjdk.org/browse/JDK-8292275 that fixes the problem where javac generates classfiles without sufficient information for core reflection to perform explicit to full parameter mappings. Why it matters: Even though the parameter information is always available with -parameters flag, most javac users will not opt-in to such a flag, and end up encountering problems with core reflection mismatching annotations or signatures. This patch generates minimal parameter information that can prevent such problems. Example: public class Outer { public class Inner { public Inner(Optional arg) {} // this constructor's parameterized types will be erased } } Without this patch, core reflection reports the arg as Optional than Optional, due to signature reporting one parameter while the actual method has two parameters, one mandated. Additionally, (from most to least important) 1. This patch has a CSR approved for release 21. Deferring the CSR and the helpful bugfix due to lack of reviews would be an unfortunate waste, especially that this patch is in a ready state. 2. A bug in the Classfile API, which this patch uses to write tests, causes one of the tests to fail. If you can approve the associated simple typo bugfix https://github.com/openjdk/jdk/pull/13167 to advance the main patch, I would be grateful as well. 3. I have submitted a patch utilizing the parameter information to the core reflection at https://github.com/openjdk/jdk/pull/13664 which would make the patch more useful as well. Sincerely, Chen Liang From darcy at openjdk.org Thu Apr 27 16:08:55 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 27 Apr 2023 16:08:55 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: <4Hor93HmsHBhXAvvBBJhqg0fnhw7AxoP2sIcT-WHfZI=.4622066f-8b6f-4350-a5cc-872ee2fc23a9@github.com> On Thu, 27 Apr 2023 13:17:58 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > PreviewFeatures.isEnabled() I assume future iterations of the PR will include handling and tests for the main class attribute of jar files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1525943897 From jlaskey at openjdk.org Thu Apr 27 17:21:23 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 27 Apr 2023 17:21:23 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v65] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: CSR recommendations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/5c182232..fb406d23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=64 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=63-64 Stats: 115 lines in 3 files changed: 71 ins; 27 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From darcy at openjdk.org Thu Apr 27 17:33:22 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 27 Apr 2023 17:33:22 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v4] In-Reply-To: References: Message-ID: <4UQim1BWRWMhwV7OeVCPnWOlM7KnoHSa_S8e_b4n40Y=.ef821c49-5ec5-443c-9c54-086915e440b7@github.com> On Thu, 27 Apr 2023 14:56:53 GMT, Aggelos Biboudis wrote: >> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. >> >> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Update test files with JDK 8307007 bug id src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java line 106: > 104: * false} otherwise} > 105: * > 106: * @jls 6.1 Declarations Please include an implSpec tag for returning false by default. src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 714: > 712: /** > 713: * {@return {@code true} if the element has an empty name, {@code false} otherwise} > 714: * Please include an implSpec tag for returning false by default. For testing the default method, see the use of VaccuousElements in tests in files like test/langtools/tools/javac/processing/model/util/elements/TestRecordPredicates.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179474266 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179481934 From jlaskey at openjdk.org Thu Apr 27 18:21:56 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 27 Apr 2023 18:21:56 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v3] In-Reply-To: References: Message-ID: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into 8306112 - PreviewFeatures.isEnabled() - Clean up isPreview - Missing exception - Corrections - Update VM.java - Clean up testing - Update TestJavacTaskScanner.java - Merge branch 'master' into 8306112 - Clean up - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d ------------- Changes: https://git.openjdk.org/jdk/pull/13689/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=02 Stats: 1240 lines in 29 files changed: 1086 ins; 62 del; 92 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jlaskey at openjdk.org Thu Apr 27 18:22:26 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 27 Apr 2023 18:22:26 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:55:01 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> PreviewFeatures.isEnabled() > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2433: > >> 2431: if (kind.contains(KindSelector.TYP)) { >> 2432: sym = findType(env, name); >> 2433: if ((sym.flags() & ANONYMOUS_MAIN_CLASS) != 0) { > > If `sym` is also `SYNTHTIC` (which it is) - do you need this? In what case? E.g. if there's a legitimate case for this I'm wondering if we should just test for `SYNTHETIC` rather than `ANONYMOUS_MAIN_CLASS`. Yes, this is a remnant from earlier work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179530497 From jlaskey at openjdk.org Thu Apr 27 18:22:23 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 27 Apr 2023 18:22:23 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: <5Gfuey8swtt5kH7aGU7aQNwU80KcoCFJ2hZxxGO2tnk=.75eb7117-299b-449a-b3a2-6ef27de44ac0@github.com> On Thu, 27 Apr 2023 13:39:37 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> PreviewFeatures.isEnabled() > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 45: > >> 43: import java.lang.invoke.MethodHandles; >> 44: import java.lang.invoke.MethodHandles.Lookup; >> 45: import java.lang.invoke.MethodType; > > Left over from an earlier version? Yep. > src/java.base/share/classes/sun/launcher/resources/launcher.properties line 240: > >> 238: Caused by: {1}: {2} >> 239: java.launcher.cls.error8=\ >> 240: Error: no non-private no argument constructor found in class {0} > > Since this feature is for new developers then the error messages will need to be understand, maybe it should be "zero argument" and give an example to help. java.launcher.cls.error8=\ Error: no non-private zero argument constructor found in class {0}\n\ remove private from existing constructor or define as:\n\ \ public {0}() {} > src/java.base/share/native/libjli/java.c line 590: > >> 588: CHECK_EXCEPTION_NULL_LEAVE(mainID); >> 589: (*env)->CallVoidMethod(env, mainObject, mainID); >> 590: break; > > This calls into LauncherHelper to get the "main type", then calls the static or new/instance method. I'm wondering if you tried have a single entry point in LauncherHelper instead. I think the only downside might be that the trampoline would show up in stack traces but @Hidden could hide that. Good idea. If @hidden doesn't work then we can eat the trace entries. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179518999 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179528956 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179517981 From jlaskey at openjdk.org Thu Apr 27 18:44:53 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 27 Apr 2023 18:44:53 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:53:21 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> PreviewFeatures.isEnabled() > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 432: > >> 430: >> 431: // Restructure top level to be an top level anonymous class. >> 432: public static void constructAnonymousMainClass(JCCompilationUnit tree, > > Question: any reason as to why this is done here and not in the parser? Typically we don't want to do tree transformation at parse time, as that messes up clients that want to access the "non-desugared" tree (such as IDE) and expect some mapping between source to AST. But if you do the rewriting in Enter, not much changes, that is, clients such as IDEs would still see something that doesn't resemble the source. The source file name is not available until after parsing. > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/VirtualParser.java line 191: > >> 189: * @param return type of parserAction >> 190: */ >> 191: public static Optional speculativeParse(JavacParser parser, > > Since this is never use, and because of the TODO - should we just drop it for the time being? dropping ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179543180 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179534229 From jjg at openjdk.org Thu Apr 27 19:32:53 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 27 Apr 2023 19:32:53 GMT Subject: Integrated: JDK-8306952: improve generic signature of internal DCInlineTag class In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 21:03:16 GMT, Jonathan Gibbons wrote: > Please review a small update to the generic signature of the internal `DCInlineTag` class, to improve its use in chained method calls. This pull request has now been integrated. Changeset: 78713909 Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/7871390930920f0acc0dacde77dafe01f9e6c865 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod 8306952: improve generic signature of internal DCInlineTag class Reviewed-by: iris ------------- PR: https://git.openjdk.org/jdk/pull/13678 From vromero at openjdk.org Thu Apr 27 19:55:24 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 27 Apr 2023 19:55:24 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 13:17:18 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: > > - Merge pull request #1 from liachmodded/methodparameters-flags > > - Update tests > - Parity for the parameter flag tests in javac and reflection > - Updated RequiredMethodParameterFlagTest, checks against Local classes as well > - Merge branch 'master' into methodparameters-flags > - Update copyright year > - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated > - address comments > - cleanup > - add annotation processing test > - ... and 16 more: https://git.openjdk.org/jdk/compare/2ad79128...5ac3a214 make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 2388: > 2386: for (MethodParameters_attribute.Entry e : params.method_parameter_table) { > 2387: String name = null; > 2388: if (e.name_index != 0) { could use ternary operator here, but tbh not sure why this change is necessary. The current code is supposed to fail with `ConstantPool.InvalidIndex` exception if the an index is `<= 0`, is this changing now? I mean can `name_index` be `0` now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/9862#discussion_r1179595556 From liach at openjdk.org Thu Apr 27 20:29:55 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 27 Apr 2023 20:29:55 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 19:27:49 GMT, Vicente Romero wrote: >> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: >> >> - Merge pull request #1 from liachmodded/methodparameters-flags >> >> - Update tests >> - Parity for the parameter flag tests in javac and reflection >> - Updated RequiredMethodParameterFlagTest, checks against Local classes as well >> - Merge branch 'master' into methodparameters-flags >> - Update copyright year >> - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated >> - address comments >> - cleanup >> - add annotation processing test >> - ... and 16 more: https://git.openjdk.org/jdk/compare/17e2d7c4...5ac3a214 > > make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 2388: > >> 2386: for (MethodParameters_attribute.Entry e : params.method_parameter_table) { >> 2387: String name = null; >> 2388: if (e.name_index != 0) { > > could use ternary operator here, but tbh not sure why this change is necessary. The current code is supposed to fail with `ConstantPool.InvalidIndex` exception if the an index is `<= 0`, is this changing now? I mean can `name_index` be `0` now? `name_index` could always have been 0 to indicate an absent parameter name: https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.24 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/9862#discussion_r1179631049 From mcimadamore at openjdk.org Thu Apr 27 20:49:54 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 27 Apr 2023 20:49:54 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 18:28:41 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 432: >> >>> 430: >>> 431: // Restructure top level to be an top level anonymous class. >>> 432: public static void constructAnonymousMainClass(JCCompilationUnit tree, >> >> Question: any reason as to why this is done here and not in the parser? Typically we don't want to do tree transformation at parse time, as that messes up clients that want to access the "non-desugared" tree (such as IDE) and expect some mapping between source to AST. But if you do the rewriting in Enter, not much changes, that is, clients such as IDEs would still see something that doesn't resemble the source. > > The source file name is not available until after parsing. I see that logic in JavaCompiler - I wonder if that's just the way it is, or if there's a deeper reason as to why the sourcefile is set on the toplevel unit *after* parsing (I don't think I can see any, in which case that might be changed if that makes the rest of the code simpler). @lahodaj what do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179650628 From mcimadamore at openjdk.org Thu Apr 27 21:01:54 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 27 Apr 2023 21:01:54 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v3] In-Reply-To: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> References: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> Message-ID: On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8306112 > - PreviewFeatures.isEnabled() > - Clean up isPreview > - Missing exception > - Corrections > - Update VM.java > - Clean up testing > - Update TestJavacTaskScanner.java > - Merge branch 'master' into 8306112 > - Clean up > - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d test/jdk/tools/launcher/OnrampMainTest.java line 31: > 29: * @run main OnrampMainTest > 30: */ > 31: public class OnrampMainTest extends TestHelper { Should more tests be added for inherited methods? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1179666410 From vromero at openjdk.org Fri Apr 28 02:45:24 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Apr 2023 02:45:24 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 20:10:56 GMT, Chen Liang wrote: >> make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 2388: >> >>> 2386: for (MethodParameters_attribute.Entry e : params.method_parameter_table) { >>> 2387: String name = null; >>> 2388: if (e.name_index != 0) { >> >> could use ternary operator here, but tbh not sure why this change is necessary. The current code is supposed to fail with `ConstantPool.InvalidIndex` exception if the an index is `<= 0`, is this changing now? I mean can `name_index` be `0` now? > > `name_index` could always have been 0 to indicate an absent parameter name: https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.24 I see, then this was a bug in the previous code, still I suggest using the ternary operator here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/9862#discussion_r1179872355 From dholmes at openjdk.org Fri Apr 28 04:32:24 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 28 Apr 2023 04:32:24 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v3] In-Reply-To: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> References: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> Message-ID: <_3okiv8d0MwpgpPDMA243D__1j6F89gd-aKF3fdu9Bo=.253bffb8-5b0f-443a-bbed-23677b0a160d@github.com> On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8306112 > - PreviewFeatures.isEnabled() > - Clean up isPreview > - Missing exception > - Corrections > - Update VM.java > - Clean up testing > - Update TestJavacTaskScanner.java > - Merge branch 'master' into 8306112 > - Clean up > - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d I don't see anything hotspot related here (no idea why the auto-mapping added it) so can we remove hotspot-runtime please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1526968745 From mcimadamore at openjdk.org Fri Apr 28 09:45:55 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Apr 2023 09:45:55 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v3] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:30:22 GMT, Vicente Romero wrote: >> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: >> >> Address javax.lang.model comments > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 278: > >> 276: >> 277: /** >> 278: * Flag that indicates that a local variable, a lambda parameter, or an unnamed pattern variable is unnamed. > > question: cant we infer this from the name itself instead of consuming a flag? I have the same feeling. Flags are a scarce resource - if we can avoid using one that would be best :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180155474 From mcimadamore at openjdk.org Fri Apr 28 09:46:53 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Apr 2023 09:46:53 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v4] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:56:53 GMT, Aggelos Biboudis wrote: >> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. >> >> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Update test files with JDK 8307007 bug id src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 240: > 238: RECORD_PATTERNS(JDK21, Fragments.FeatureDeconstructionPatterns, DiagKind.PLURAL), > 239: WARN_ON_ILLEGAL_UTF8(MIN, JDK21), > 240: UNNAMED_VARIABLES(JDK21, Fragments.FeatureUnnamedVariables, DiagKind.PLURAL), While the JEP unifies unnamed variables and unnamed patterns, would it make sense, at the code level, to split between the two? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1777: > 1775: log.error(guard.pos(), Errors.GuardHasConstantExpressionFalse); > 1776: } > 1777: } else if (guard != null) { I guess this is caused by something like: case _ when ... If now a guard can appear regardless of how many labels there are, should be refactor this code so that if `guard != null` it is always attributed? And then we do other stuff in case `labels.tail.isEmpty()` ? Note that the code for attributing the guard is slightly different in the two cases in this patch: the original code creates a nested scope - while the new code doesn't. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 746: > 744: > 745: sealed interface PatternDescription { > 746: public static PatternDescription from(Types types, Type selectorType, JCPattern pattern, Symtab syms) { Optional comment: the fact that this factory needs so much compiler state makes me think that perhaps a better place for it would be as an instance method of Flow, rather than a static method in PatternDescription. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java line 295: > 293: : tree.vartype.type; > 294: Name name; > 295: if (Feature.UNNAMED_VARIABLES.allowedInSource(source) && (tree.mods.flags & UNNAMED) != 0) { Not 100% sure what this code does. E.g. shouldn't we just set the name of the variable as the name stored in the tree? It seems more economical if we could just set in the parser the name as empty (if preview features are enabled etc.) - and then all these special cases can disappear. After all, you still have the flag (and even then, do we need a flag? Can't we just see whether the name is empty to see that it's unnamed?) src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 826: > 824: //type test pattern: > 825: UnnamedDetails result = identOrFlagUnderscore(mods); > 826: JCVariableDecl var = toP(F.at(result.varPos()).VarDef(mods, result.name(), e, null)); Do you think we can delegate to `variableDeclarator` here? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 839: > 837: } > 838: > 839: private UnnamedDetails identOrFlagUnderscore(JCModifiers mods) { I'm not 100% sure this is required - the main use seems to be in `variableDeclarator` - but in that method you already have a token to look at, and a set of modifiers that you can augment - so why not just doing everything in that method (instead of preprocessing it?) src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3555: > 3553: */ > 3554: JCVariableDecl variableDeclarator(JCModifiers mods, JCExpression type, boolean reqInit, Comment dc, boolean localDecl) { > 3555: UnnamedDetails result = identOrFlagUnderscore(mods); Why do we need to get the "unnamed details" here, instead of letting the code flow to `variableDeclaratorRest` and do it there? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3660: > 3658: int pos = token.pos; > 3659: Name name; > 3660: if (allowThisIdent || I note that now the error re. underscore on lambda is no longer given even if preview features are disabled. But I guess that's ok. (instead you will probably get an error that unnamed parameters are a preview feature) test/langtools/tools/javac/TryWithResources/TwrLintUnderscore.java line 22: > 20: return; > 21: } > 22: } Add a newline at the end of this file (also check others) test/langtools/tools/javac/patterns/Unnamed.java line 148: > 146: } > 147: > 148: // JEP This comment looks odd - either we also add JEP number, or we can just drop it. test/langtools/tools/javac/patterns/Unnamed.java line 153: > 151: record ColoredPoint(Point p, Color c) { } > 152: > 153: void jep(ColoredPoint r) { Same as above for this method name ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180130293 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180139794 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180158709 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180153920 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180123845 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180124901 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180125696 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180128207 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180164818 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180168228 PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180168421 From jlahoda at openjdk.org Fri Apr 28 13:33:25 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 28 Apr 2023 13:33:25 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v3] In-Reply-To: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> References: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> Message-ID: On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8306112 > - PreviewFeatures.isEnabled() > - Clean up isPreview > - Missing exception > - Corrections > - Update VM.java > - Clean up testing > - Update TestJavacTaskScanner.java > - Merge branch 'master' into 8306112 > - Clean up > - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 64: > 62: > 63: for (Method method : refc.getDeclaredMethods()) { > 64: int argc = method.getParameterCount(); Nit: unused variable? src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 147: > 145: } > 146: > 147: return mainClass.getMethod("main", String[].class); Nit: could return `mainMethod` here, correct? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 453: > 451: } > 452: if (!SourceVersion.isIdentifier(simplename) || SourceVersion.isKeyword(simplename)) { > 453: log.error(null, Errors.BadFileName(simplename)); Suggestion: log.error(tree.pos(), Errors.BadFileName(simplename)); src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 462: > 460: for (JCTree def : tree.defs) { > 461: if (def.hasTag(Tag.PACKAGEDEF)) { > 462: log.error(null, Errors.AnonymousMainClassShouldNotHavePackageDeclaration); Suggestion: log.error(def.pos(), Errors.AnonymousMainClassShouldNotHavePackageDeclaration); src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 438: > 436: Class appClass = Class.forName(mainClassName, true, cl); > 437: Method main = MainMethodFinder.findMainMethod(appClass); > 438: if (!PreviewFeatures.isEnabled() && (!isStatic(main) || !isPublic(main))) { It seems one can run a main method without parameters without `--enable-preview` using this codepath. That is presumably not intended. src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 627: > 625: } > 626: > 627: public boolean isAnonymousMainClass() { This method seems a bit confusing to me. I believe the fields and methods will be stripped from `defs` if/when the wrapping class is created, which will mean this method will start to return `false`, no? It overall does not seem like a generally useful predicate. (If I understand this correctly, if we created the wrapping class in parser neither of these two methods would be needed.) src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 640: > 638: // Find anonymous main class. > 639: for (JCTree def : defs) { > 640: if (def.hasTag(CLASSDEF)) { Nit, in cases like this, we lately tend to write `def instanceof JCClassDecl cls`, although we understand this way to check the AST is only safe inside javac. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180360702 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180360546 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180378753 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180378611 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180375691 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180389813 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180392123 From jlahoda at openjdk.org Fri Apr 28 13:33:28 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 28 Apr 2023 13:33:28 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 20:34:44 GMT, Maurizio Cimadamore wrote: >> The source file name is not available until after parsing. > > I see that logic in JavaCompiler - I wonder if that's just the way it is, or if there's a deeper reason as to why the sourcefile is set on the toplevel unit *after* parsing (I don't think I can see any, in which case that might be changed if that makes the rest of the code simpler). @lahodaj what do you think? I believe we were discussing this some time ago, and there were some problems. I don't recall the exact details, but I'll try to look into this later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180377062 From jlaskey at openjdk.org Fri Apr 28 14:34:24 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Apr 2023 14:34:24 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v3] In-Reply-To: References: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> Message-ID: On Fri, 28 Apr 2023 12:45:35 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - Merge branch 'master' into 8306112 >> - PreviewFeatures.isEnabled() >> - Clean up isPreview >> - Missing exception >> - Corrections >> - Update VM.java >> - Clean up testing >> - Update TestJavacTaskScanner.java >> - Merge branch 'master' into 8306112 >> - Clean up >> - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 64: > >> 62: >> 63: for (Method method : refc.getDeclaredMethods()) { >> 64: int argc = method.getParameterCount(); > > Nit: unused variable? Remnant. > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 147: > >> 145: } >> 146: >> 147: return mainClass.getMethod("main", String[].class); > > Nit: could return `mainMethod` here, correct? Yes > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 453: > >> 451: } >> 452: if (!SourceVersion.isIdentifier(simplename) || SourceVersion.isKeyword(simplename)) { >> 453: log.error(null, Errors.BadFileName(simplename)); > > Suggestion: > > log.error(tree.pos(), Errors.BadFileName(simplename)); Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 462: > >> 460: for (JCTree def : tree.defs) { >> 461: if (def.hasTag(Tag.PACKAGEDEF)) { >> 462: log.error(null, Errors.AnonymousMainClassShouldNotHavePackageDeclaration); > > Suggestion: > > log.error(def.pos(), Errors.AnonymousMainClassShouldNotHavePackageDeclaration); Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 438: > >> 436: Class appClass = Class.forName(mainClassName, true, cl); >> 437: Method main = MainMethodFinder.findMainMethod(appClass); >> 438: if (!PreviewFeatures.isEnabled() && (!isStatic(main) || !isPublic(main))) { > > It seems one can run a main method without parameters without `--enable-preview` using this codepath. That is presumably not intended. MainMethodFinder won't return a no arg method is without --enable-preview. The local testing here is to specialize the error massages. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180477997 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180477664 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180482962 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180482213 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180479992 From jlahoda at openjdk.org Fri Apr 28 14:35:53 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 28 Apr 2023 14:35:53 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v3] In-Reply-To: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> References: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> Message-ID: On Thu, 27 Apr 2023 18:21:56 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8306112 > - PreviewFeatures.isEnabled() > - Clean up isPreview > - Missing exception > - Corrections > - Update VM.java > - Clean up testing > - Update TestJavacTaskScanner.java > - Merge branch 'master' into 8306112 > - Clean up > - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3933: > 3931: if (Feature.ANONYMOUS_MAIN_CLASSES.allowedInSource(source) && > 3932: !isDeclaration() && > 3933: (token.kind == VOID || token.kind == IDENTIFIER)) { These checks (`token.kind == VOID || token.kind == IDENTIFIER`) for token kind will fail to parse fields of primitive types (or methods with primitive types as a return type)? Either the tests must include the primitive types, or (maybe) just this test can be avoided completely? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180481474 From jlaskey at openjdk.org Fri Apr 28 14:50:52 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Apr 2023 14:50:52 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v3] In-Reply-To: References: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> Message-ID: <83q-SFDWKgp-HNpYY63y7P9WDkYOUuMtXequYaRj4DY=.5295acd1-7c05-4fbd-9f7c-8f8ac6e7804d@github.com> On Fri, 28 Apr 2023 13:13:57 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - Merge branch 'master' into 8306112 >> - PreviewFeatures.isEnabled() >> - Clean up isPreview >> - Missing exception >> - Corrections >> - Update VM.java >> - Clean up testing >> - Update TestJavacTaskScanner.java >> - Merge branch 'master' into 8306112 >> - Clean up >> - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d > > src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 627: > >> 625: } >> 626: >> 627: public boolean isAnonymousMainClass() { > > This method seems a bit confusing to me. I believe the fields and methods will be stripped from `defs` if/when the wrapping class is created, which will mean this method will start to return `false`, no? It overall does not seem like a generally useful predicate. > > (If I understand this correctly, if we created the wrapping class in parser neither of these two methods would be needed.) Inlining > src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 640: > >> 638: // Find anonymous main class. >> 639: for (JCTree def : defs) { >> 640: if (def.hasTag(CLASSDEF)) { > > Nit, in cases like this, we lately tend to write `def instanceof JCClassDecl cls`, although we understand this way to check the AST is only safe inside javac. Changing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180491264 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180491108 From vromero at openjdk.org Fri Apr 28 15:10:55 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Apr 2023 15:10:55 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 13:17:18 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: > > - Merge pull request #1 from liachmodded/methodparameters-flags > > - Update tests > - Parity for the parameter flag tests in javac and reflection > - Updated RequiredMethodParameterFlagTest, checks against Local classes as well > - Merge branch 'master' into methodparameters-flags > - Update copyright year > - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated > - address comments > - cleanup > - add annotation processing test > - ... and 16 more: https://git.openjdk.org/jdk/compare/cf4bf187...5ac3a214 this test: jdk/classfile/CorpusTest.java is consistently failing with this fix applied ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1527678091 From liach at openjdk.org Fri Apr 28 15:11:24 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 28 Apr 2023 15:11:24 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: <3BLak8QZ_1s9wQnmb2Q7ghoZdm2cdYZgfXR-Z7HvNQw=.f8a58d27-0648-47f2-99af-d27fd0feef7c@github.com> On Fri, 28 Apr 2023 14:45:16 GMT, Vicente Romero wrote: > this test: jdk/classfile/CorpusTest.java is consistently failing with this fix applied This test reads the jdk image for its class files. Without #13167's fix to Classfile API, it will fail on the jdk image with MethodParameters with absent parameter names generated by this javac update. Can you test again with that patch integrated as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1527683858 From jlaskey at openjdk.org Fri Apr 28 15:30:29 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Apr 2023 15:30:29 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v4] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Recommended changes #1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/53a5321d..f66f6e49 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=02-03 Stats: 222 lines in 11 files changed: 58 ins; 126 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jlaskey at openjdk.org Fri Apr 28 15:30:55 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Apr 2023 15:30:55 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v3] In-Reply-To: References: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> Message-ID: On Fri, 28 Apr 2023 14:26:10 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - Merge branch 'master' into 8306112 >> - PreviewFeatures.isEnabled() >> - Clean up isPreview >> - Missing exception >> - Corrections >> - Update VM.java >> - Clean up testing >> - Update TestJavacTaskScanner.java >> - Merge branch 'master' into 8306112 >> - Clean up >> - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3933: > >> 3931: if (Feature.ANONYMOUS_MAIN_CLASSES.allowedInSource(source) && >> 3932: !isDeclaration() && >> 3933: (token.kind == VOID || token.kind == IDENTIFIER)) { > > These checks (`token.kind == VOID || token.kind == IDENTIFIER`) for token kind will fail to parse fields of primitive types (or methods with primitive types as a return type)? Either the tests must include the primitive types, or (maybe) just this test can be avoided completely? Things have moved on since. Changing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180512100 From jlaskey at openjdk.org Fri Apr 28 15:55:29 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Apr 2023 15:55:29 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v5] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Can't be invokeExact for instance main ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/f66f6e49..e5ca303a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From vromero at openjdk.org Fri Apr 28 16:04:54 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Apr 2023 16:04:54 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 13:17:18 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: > > - Merge pull request #1 from liachmodded/methodparameters-flags > > - Update tests > - Parity for the parameter flag tests in javac and reflection > - Updated RequiredMethodParameterFlagTest, checks against Local classes as well > - Merge branch 'master' into methodparameters-flags > - Update copyright year > - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated > - address comments > - cleanup > - add annotation processing test > - ... and 16 more: https://git.openjdk.org/jdk/compare/6d440560...5ac3a214 > sure will test with both fixes applied ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1527756870 From liach at openjdk.org Fri Apr 28 16:06:25 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 28 Apr 2023 16:06:25 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 13:17:18 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: > > - Merge pull request #1 from liachmodded/methodparameters-flags > > - Update tests > - Parity for the parameter flag tests in javac and reflection > - Updated RequiredMethodParameterFlagTest, checks against Local classes as well > - Merge branch 'master' into methodparameters-flags > - Update copyright year > - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated > - address comments > - cleanup > - add annotation processing test > - ... and 16 more: https://git.openjdk.org/jdk/compare/6d440560...5ac3a214 make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 2390: > 2388: if (e.name_index != 0) { > 2389: name = cf.constant_pool.getUTF8Value(e.name_index); > 2390: } Suggestion: String name = e.name_index == 0 ? null : cf.constant_pool.getUTF8Value(e.name_index); assuming a continuation indent of 8. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/9862#discussion_r1180573920 From abimpoudis at openjdk.org Fri Apr 28 16:20:30 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 28 Apr 2023 16:20:30 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v5] In-Reply-To: References: Message-ID: > This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. > > Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Fix field error detection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13528/files - new: https://git.openjdk.org/jdk/pull/13528/files/cbe4c31b..59910b94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=03-04 Stats: 32 lines in 3 files changed: 15 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/13528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528 PR: https://git.openjdk.org/jdk/pull/13528 From abimpoudis at openjdk.org Fri Apr 28 17:09:53 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 28 Apr 2023 17:09:53 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 09:17:29 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 278: >> >>> 276: >>> 277: /** >>> 278: * Flag that indicates that a local variable, a lambda parameter, or an unnamed pattern variable is unnamed. >> >> question: cant we infer this from the name itself instead of consuming a flag? > > I have the same feeling. Flags are a scarce resource - if we can avoid using one that would be best :-) Initially, the check was based on the name but that became confusing since the symbol may hold either the empty name or the underscore (coming from the tree) depending on whether we are in the new feature or not. The reason is that while the Tree API will continue to return (`_`), `VariableElement.getSimpleName()` needs to return `names.empty` ([JDK-8307007](https://bugs.openjdk.org/browse/JDK-8307007)). Up until here, everything is ok, however adding the `isUnnamed` in the Symbol we cannot simply return a boolean based on simply checking the name. We would need to check the version again but this time in the Symbol (to take account whether or not we are in the Unnamed feature). Thus the flag seems cleaner. WDYT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180629713 From vromero at openjdk.org Fri Apr 28 17:30:29 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Apr 2023 17:30:29 GMT Subject: RFR: 8305672: Surprising definite assignment error after JDK-8043179 [v3] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 02:59:53 GMT, Archie Cobbs wrote: >> The fix for [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) is to clear the DU flags for all variables when entering a lamba. This reflects the fact that the lamba's actual execution could be arbitrarily far in the future, so we can't assume anything that is DU when the lambda is created is still DU when the lambda actually executes. >> >> However, this fix created a new bug. The problem is that `visitLambda()` does not save & restore the `uninitsTry` bits, which are used by `visitTry()` to track DU variables within `try { }` blocks. So if there is a `try { }` block outside the lambda and a `try { }` block inside the lambda, the latter can "leak" DU state up to the former via this field. As a result, a final variable that should still be DU at the completion of the outer `try { }` block can be incorrectly recorded as not DU, leading to the bogus "might already have been assigned" error. >> >> This patch fixes that by adding the necessary save & restore logic. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8305672 > - Merge branch 'master' into JDK-8305672 > - Fix failure of visitLambda() to save & restore uninitsTry bits. the fix looks good to me, running regression tests now to make sure nothing breaks, will approve if all green ------------- PR Comment: https://git.openjdk.org/jdk/pull/13366#issuecomment-1527852365 From jlahoda at openjdk.org Fri Apr 28 18:05:54 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 28 Apr 2023 18:05:54 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 13:01:33 GMT, Jan Lahoda wrote: >> I see that logic in JavaCompiler - I wonder if that's just the way it is, or if there's a deeper reason as to why the sourcefile is set on the toplevel unit *after* parsing (I don't think I can see any, in which case that might be changed if that makes the rest of the code simpler). @lahodaj what do you think? > > I believe we were discussing this some time ago, and there were some problems. I don't recall the exact details, but I'll try to look into this later. I've sketched this: https://github.com/lahodaj/jdk/commit/efe55f7d354ed7bbf91077d058823d682db501b9 I don't have too strong opinion here, there might be more cleanup possible after a change like this, and might be a bit cleaner outside of the parser; but forces the parser to work with files which is somewhat less clean. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180673509 From jlaskey at openjdk.org Fri Apr 28 19:04:28 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Apr 2023 19:04:28 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v6] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Leave exception alone - Unused variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/e5ca303a..2c321834 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jlaskey at openjdk.org Fri Apr 28 19:04:30 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 28 Apr 2023 19:04:30 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 17:51:58 GMT, Jan Lahoda wrote: >> I believe we were discussing this some time ago, and there were some problems. I don't recall the exact details, but I'll try to look into this later. > > I've sketched this: > https://github.com/lahodaj/jdk/commit/efe55f7d354ed7bbf91077d058823d682db501b9 > > I don't have too strong opinion here, there might be more cleanup possible after a change like this, and might be a bit cleaner outside of the parser; but forces the parser to work with files which is somewhat less clean. This is basically what I did originally until I decided that I needed a distinct class name. `log.currentSourceFile()` is the magic in this code. I'm willing to move this way if we all agree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1180715358 From vromero at openjdk.org Fri Apr 28 22:35:23 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Apr 2023 22:35:23 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 13:17:18 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: > > - Merge pull request #1 from liachmodded/methodparameters-flags > > - Update tests > - Parity for the parameter flag tests in javac and reflection > - Updated RequiredMethodParameterFlagTest, checks against Local classes as well > - Merge branch 'master' into methodparameters-flags > - Update copyright year > - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated > - address comments > - cleanup > - add annotation processing test > - ... and 16 more: https://git.openjdk.org/jdk/compare/beeb1c99...5ac3a214 looks good I have approved: https://github.com/openjdk/jdk/pull/13167 ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/9862#pullrequestreview-1406653836 PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1528148150 From mcimadamore at openjdk.org Fri Apr 28 23:17:53 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Apr 2023 23:17:53 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 16:56:34 GMT, Aggelos Biboudis wrote: >> I have the same feeling. Flags are a scarce resource - if we can avoid using one that would be best :-) > > Initially, the check was based on the name but that became confusing since the symbol may hold either the empty name or the underscore (coming from the tree) depending on whether we are in the new feature or not. The reason is that while the Tree API will continue to return (`_`), `VariableElement.getSimpleName()` needs to return `names.empty` ([JDK-8307007](https://bugs.openjdk.org/browse/JDK-8307007)). > > Up until here, everything is ok, however adding the `isUnnamed` in the Symbol we cannot simply return a boolean based on simply checking the name. We would need to check the version again but this time in the Symbol (to take account whether or not we are in the Unnamed feature). > > Thus the flag seems cleaner. WDYT? I guess what I'm kind of questioning is: why are we using `_` for the variable name? The way I see it is that `_` is a token that is used to say "I don't want to specify a name". So the program element declared using `_` becomes effectively "unnamed" (as the JEP says). This would be consistent with looking for `_` in the parser, and then replace them with `names.empty` - which would then be consistent with the rest of the compiler (as you wouldn't need to filter out things). Or, is there a concrete use case where keeping the `_` around is useful? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180870835 From vromero at openjdk.org Sat Apr 29 02:59:01 2023 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 29 Apr 2023 02:59:01 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 13:17:18 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: > > - Merge pull request #1 from liachmodded/methodparameters-flags > > - Update tests > - Parity for the parameter flag tests in javac and reflection > - Updated RequiredMethodParameterFlagTest, checks against Local classes as well > - Merge branch 'master' into methodparameters-flags > - Update copyright year > - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated > - address comments > - cleanup > - add annotation processing test > - ... and 16 more: https://git.openjdk.org/jdk/compare/43712cd1...5ac3a214 please remember to wait for https://github.com/openjdk/jdk/pull/13167 to be integrated before integrating this one ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1528534076 From jwaters at openjdk.org Sat Apr 29 08:05:22 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 29 Apr 2023 08:05:22 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 13:17:18 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: > > - Merge pull request #1 from liachmodded/methodparameters-flags > > - Update tests > - Parity for the parameter flag tests in javac and reflection > - Updated RequiredMethodParameterFlagTest, checks against Local classes as well > - Merge branch 'master' into methodparameters-flags > - Update copyright year > - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated > - address comments > - cleanup > - add annotation processing test > - ... and 16 more: https://git.openjdk.org/jdk/compare/267a4e81...5ac3a214 Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/9862#pullrequestreview-1406894561 From abimpoudis at openjdk.org Sat Apr 29 08:05:24 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Sat, 29 Apr 2023 08:05:24 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v6] In-Reply-To: References: Message-ID: > This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. > > Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Address comments around javax.lang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13528/files - new: https://git.openjdk.org/jdk/pull/13528/files/59910b94..e95e4166 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=04-05 Stats: 44 lines in 6 files changed: 41 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528 PR: https://git.openjdk.org/jdk/pull/13528 From abimpoudis at openjdk.org Sat Apr 29 08:15:55 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Sat, 29 Apr 2023 08:15:55 GMT Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v7] In-Reply-To: References: Message-ID: > This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java. > > Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/ Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - Merge branch 'JDK-8300543' into unnamed - Address comments around javax.lang - Fix field error detection - Update test files with JDK 8307007 bug id - Address javax.lang.model comments - Introduce new flag to track unnamed variables - Return underscore for Tree API and empty name for javax.lang.model.element.VariableElement.getSimpleName() - Fix indentation in JavacParser - Merge branch 'JDK-8300543' into unnamed - Fix top level type pattern with underscore - Introduce source in MemberEnter (javadoc uses MemberEnter) - ... and 20 more: https://git.openjdk.org/jdk/compare/3b3bcbcc...e39dd6dd ------------- Changes: https://git.openjdk.org/jdk/pull/13528/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=06 Stats: 1132 lines in 44 files changed: 945 ins; 60 del; 127 mod Patch: https://git.openjdk.org/jdk/pull/13528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528 PR: https://git.openjdk.org/jdk/pull/13528 From vromero at openjdk.org Sat Apr 29 15:05:53 2023 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 29 Apr 2023 15:05:53 GMT Subject: RFR: 8305672: Surprising definite assignment error after JDK-8043179 [v3] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 02:59:53 GMT, Archie Cobbs wrote: >> The fix for [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) is to clear the DU flags for all variables when entering a lamba. This reflects the fact that the lamba's actual execution could be arbitrarily far in the future, so we can't assume anything that is DU when the lambda is created is still DU when the lambda actually executes. >> >> However, this fix created a new bug. The problem is that `visitLambda()` does not save & restore the `uninitsTry` bits, which are used by `visitTry()` to track DU variables within `try { }` blocks. So if there is a `try { }` block outside the lambda and a `try { }` block inside the lambda, the latter can "leak" DU state up to the former via this field. As a result, a final variable that should still be DU at the completion of the outer `try { }` block can be incorrectly recorded as not DU, leading to the bogus "might already have been assigned" error. >> >> This patch fixes that by adding the necessary save & restore logic. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8305672 > - Merge branch 'master' into JDK-8305672 > - Fix failure of visitLambda() to save & restore uninitsTry bits. looks good ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13366#pullrequestreview-1406991762 From acobbs at openjdk.org Sat Apr 29 15:16:53 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 29 Apr 2023 15:16:53 GMT Subject: RFR: 8305672: Surprising definite assignment error after JDK-8043179 [v3] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 17:12:44 GMT, Vicente Romero wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8305672 >> - Merge branch 'master' into JDK-8305672 >> - Fix failure of visitLambda() to save & restore uninitsTry bits. > > the fix looks good to me, running regression tests now to make sure nothing breaks, will approve if all green Thanks for the review @vicente-romero-oracle ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13366#issuecomment-1528806749 From duke at openjdk.org Sat Apr 29 19:03:23 2023 From: duke at openjdk.org (Hannes Greule) Date: Sat, 29 Apr 2023 19:03:23 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v8] In-Reply-To: References: Message-ID: > With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). > Parameter names are *not* emitted unless the `-parameter` flag is set. > > The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). > For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. > > The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. > I also had to update some tests as they got a new constant pool entry. > > Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. > Please let me know if you want tests for specific appearances of synthetic parameters. Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: Use ternary operator Co-authored-by: liach <7806504+liach at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9862/files - new: https://git.openjdk.org/jdk/pull/9862/files/5ac3a214..400e1ec9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9862.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/9862/head:pull/9862 PR: https://git.openjdk.org/jdk/pull/9862 From duke at openjdk.org Sat Apr 29 19:57:54 2023 From: duke at openjdk.org (Hannes Greule) Date: Sat, 29 Apr 2023 19:57:54 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v7] In-Reply-To: References: Message-ID: <-T83Wp4DcTUmTmwkzpCR6ni1o7s1sGj3Dik0QT1WjPk=.e1ce0464-a82c-4787-bc92-26464177ecea@github.com> On Sat, 29 Apr 2023 02:44:20 GMT, Vicente Romero wrote: >> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: >> >> - Merge pull request #1 from liachmodded/methodparameters-flags >> >> - Update tests >> - Parity for the parameter flag tests in javac and reflection >> - Updated RequiredMethodParameterFlagTest, checks against Local classes as well >> - Merge branch 'master' into methodparameters-flags >> - Update copyright year >> - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated >> - address comments >> - cleanup >> - add annotation processing test >> - ... and 16 more: https://git.openjdk.org/jdk/compare/ee1cb90a...5ac3a214 > > please remember to wait for https://github.com/openjdk/jdk/pull/13167 to be integrated before integrating this one Switched to the ternary operator as suggested, thanks for your review @vicente-romero-oracle. ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1528858826 From jwaters at openjdk.org Sat Apr 29 20:08:53 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 29 Apr 2023 20:08:53 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v8] In-Reply-To: References: Message-ID: <3s-rJ__81uZ_0pTSOdolFKzuzc9xtD18LzChQngeZbQ=.1a4352ee-f7aa-47a7-ab61-a837d96c8ae3@github.com> On Sat, 29 Apr 2023 19:03:23 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > Use ternary operator > > Co-authored-by: liach <7806504+liach at users.noreply.github.com> Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/9862#pullrequestreview-1407021067 From jwaters at openjdk.org Sat Apr 29 20:19:28 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 29 Apr 2023 20:19:28 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v8] In-Reply-To: References: Message-ID: On Sat, 29 Apr 2023 19:03:23 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > Use ternary operator > > Co-authored-by: liach <7806504+liach at users.noreply.github.com> Windows Failures are due to a longstanding (and annoying) build system bug that's been around for quite a while by this point, and aren't related to this PR in any way Shall I do the honours? ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1528861568 From liach at openjdk.org Sat Apr 29 22:49:28 2023 From: liach at openjdk.org (Chen Liang) Date: Sat, 29 Apr 2023 22:49:28 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v8] In-Reply-To: References: Message-ID: <-p-DGLGOZ--LJ6DqxbmkYKX8ndDCagLDjICz0OnCvpg=.ed57455c-4049-4785-b216-a1c91e66383c@github.com> On Sat, 29 Apr 2023 19:59:19 GMT, Julian Waters wrote: > Windows Failures are due to a longstanding (and annoying) build system bug that's been around for quite a while by this point, and aren't related to this PR in any way > > Shall I do the honours? If it's the vscode toolchain one, go for it. It fixes itself on github from time to time, and definitely doesn't break anything when built by openjdk or adoptium. ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1528887750 From jlaskey at openjdk.org Sun Apr 30 00:59:58 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sun, 30 Apr 2023 00:59:58 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v7] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Move AnonymousMainClass to parser - Revert java launch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/2c321834..a09a0a1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=05-06 Stats: 231 lines in 4 files changed: 111 ins; 108 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jwaters at openjdk.org Sun Apr 30 07:47:27 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 30 Apr 2023 07:47:27 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v8] In-Reply-To: References: Message-ID: On Sat, 29 Apr 2023 19:03:23 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > Use ternary operator > > Co-authored-by: liach <7806504+liach at users.noreply.github.com> Alright, here goes ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1528959621 From duke at openjdk.org Sun Apr 30 07:47:29 2023 From: duke at openjdk.org (Hannes Greule) Date: Sun, 30 Apr 2023 07:47:29 GMT Subject: Integrated: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 19:54:59 GMT, Hannes Greule wrote: > With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). > Parameter names are *not* emitted unless the `-parameter` flag is set. > > The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). > For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. > > The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. > I also had to update some tests as they got a new constant pool entry. > > Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. > Please let me know if you want tests for specific appearances of synthetic parameters. This pull request has now been integrated. Changeset: b3dbf28b Author: Hannes Greule Committer: Julian Waters URL: https://git.openjdk.org/jdk/commit/b3dbf28bc0614bee2f7137af95389134155c9511 Stats: 627 lines in 9 files changed: 520 ins; 23 del; 84 mod 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default Co-authored-by: Chen Liang Reviewed-by: vromero, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/9862 From liach at openjdk.org Sun Apr 30 07:58:53 2023 From: liach at openjdk.org (Chen Liang) Date: Sun, 30 Apr 2023 07:58:53 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v8] In-Reply-To: References: Message-ID: On Sat, 29 Apr 2023 19:03:23 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > Use ternary operator > > Co-authored-by: liach <7806504+liach at users.noreply.github.com> Nice! One of the most troubling java reflection bugs will be no more: public enum TestEnum { ; TestEnum(Optional genericParameter) {} } with this, `TestEnum.class.getDeclaredConstructors()[0].getParameters()[2].getParameterizedType()` will return `java.util.Optional` than `class java.util.Optional`, which is why I've been eager for this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1528961972 From jwaters at openjdk.org Sun Apr 30 09:13:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 30 Apr 2023 09:13:58 GMT Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default [v8] In-Reply-To: References: Message-ID: <9zxTtvwvKntdl1Cv01PD6OXwMNYInDfGlusMsVX1er8=.d6a40924-c18a-4263-9372-dbff6fc98a46@github.com> On Sat, 29 Apr 2023 19:03:23 GMT, Hannes Greule wrote: >> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue). >> Parameter names are *not* emitted unless the `-parameter` flag is set. >> >> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted). >> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`. >> >> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute. >> I also had to update some tests as they got a new constant pool entry. >> >> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS. >> Please let me know if you want tests for specific appearances of synthetic parameters. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > Use ternary operator > > Co-authored-by: liach <7806504+liach at users.noreply.github.com> Haha, glad to have been of help Now, if only someone would also take a look at my javac patch for the JNI header generator... :( ------------- PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1528974098 From ethan at mccue.dev Sun Apr 30 12:40:29 2023 From: ethan at mccue.dev (Ethan McCue) Date: Sun, 30 Apr 2023 08:40:29 -0400 Subject: Static methods of generic classes are treated differently Message-ID: I've run into either a corner case in type resolution or a compiler bug and I'm not sure which. In an expression context, if a static method is referenced from a generic class then it won't properly target overloads that require primitive wrapper unboxing. package org.example; import java.time.Month; import java.util.function.Supplier; interface A { static int f() { return 1; } } interface B { static int f() { return 2; } } final class C { static int f() { return 3; } } final class D { static int f() { return 4; } } public class Main { static void h(Month b) {} static void h(int b) {} static T g(Supplier d) { return d.get(); } public static void main(String[] args) { // Compiles h( g(A::f) ); // Doesn't compile h( g(B::f) ); // Compiles var r1 = g(B::f); h(r1); // Compiles h( g(C::f) ); // Doesn't compile h( g(D::f) ); // Compiles var r2 = g(D::f); h(r2); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun Apr 30 18:16:22 2023 From: duke at openjdk.org (Neal Gafter) Date: Sun, 30 Apr 2023 18:16:22 GMT Subject: RFR: 8305672: Surprising definite assignment error after JDK-8043179 [v3] In-Reply-To: References: Message-ID: <2FNuMOXdtT5r32ZrVCc47TZ5e0JRWqv3mPtsr7ablUk=.18d7df6f-8d96-49de-aaf0-b838944d39f5@github.com> On Wed, 26 Apr 2023 02:59:53 GMT, Archie Cobbs wrote: >> The fix for [JDK-8043179](https://bugs.openjdk.org/browse/JDK-8043179) is to clear the DU flags for all variables when entering a lamba. This reflects the fact that the lamba's actual execution could be arbitrarily far in the future, so we can't assume anything that is DU when the lambda is created is still DU when the lambda actually executes. >> >> However, this fix created a new bug. The problem is that `visitLambda()` does not save & restore the `uninitsTry` bits, which are used by `visitTry()` to track DU variables within `try { }` blocks. So if there is a `try { }` block outside the lambda and a `try { }` block inside the lambda, the latter can "leak" DU state up to the former via this field. As a result, a final variable that should still be DU at the completion of the outer `try { }` block can be incorrectly recorded as not DU, leading to the bogus "might already have been assigned" error. >> >> This patch fixes that by adding the necessary save & restore logic. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8305672 > - Merge branch 'master' into JDK-8305672 > - Fix failure of visitLambda() to save & restore uninitsTry bits. Looks good to me. ------------- Marked as reviewed by gafter at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/13366#pullrequestreview-1406622608 From jesper.wilhelmsson at oracle.com Thu Apr 13 15:05:11 2023 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 13 Apr 2023 15:05:11 -0000 Subject: Release notes formatting discrepancy In-Reply-To: References: Message-ID: <2C7B3CF1-2E9C-4C6A-9310-2C1EB0C7446C@oracle.com> Hi Archie, Moving to guide-dev which seems more appropriate for this discussion. Also including Marc who has more experience working with release notes. /Jesper > On 13 Apr 2023, at 15:31, Archie Cobbs wrote: > > Not sure where to send this question, so my apologies for any misdirection... > > There seems to be some discrepancy in the syntax specification for release notes, at least with regards to backslashes. > > Take JDK-8304995 for example. The end result is supposed to contain an example that looks like this: > > public class Test { > interface Cafe\u0301 { > } > interface Caf\u00e9 { > } > } > > Note the single backslashes in there. > > The corresponding JIRA issue description contains only single backslashes. > > The JDK developer's guide says: "While the markdown won?t be rendered in JBS, you can use dingus to see what the release note will look like." > > When the JIRA description text is copied and pasted into dingus (or the other dingus ) the single blackslashes appear correctly. > > However, in the current release notes the backslashes are missing. > > It appears that the statement "you can use dingus to see what the release note will look like" is not really correct. > > Where is the breakdown here? > > Thanks, > -Archie > > -- > Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: