From jzaugg at openjdk.org Tue Apr 1 00:59:57 2025 From: jzaugg at openjdk.org (Jason Zaugg) Date: Tue, 1 Apr 2025 00:59:57 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance [v2] In-Reply-To: References: Message-ID: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com> > 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: 8352642: Also pass zipinfo-time to the alternative newFileSystem call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24176/files - new: https://git.openjdk.org/jdk/pull/24176/files/eee2f613..e0d40f4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24176&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24176&range=00-01 Stats: 13 lines in 1 file changed: 8 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24176/head:pull/24176 PR: https://git.openjdk.org/jdk/pull/24176 From liach at openjdk.org Tue Apr 1 01:33:15 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Apr 2025 01:33:15 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance [v2] In-Reply-To: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com> References: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com> Message-ID: On Tue, 1 Apr 2025 00:59:57 GMT, Jason Zaugg wrote: >> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance > > Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: > > 8352642: Also pass zipinfo-time to the alternative newFileSystem call Consistently including this ignore timestamp flag for both paths is indeed better than doing so for only one path. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24176#pullrequestreview-2730858585 From duke at openjdk.org Tue Apr 1 12:20:46 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Apr 2025 12:20:46 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath [v8] In-Reply-To: References: Message-ID: > Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. > > This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Add final test for sourcepath entry (same behaviour). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23699/files - new: https://git.openjdk.org/jdk/pull/23699/files/1341c7c7..6fcea57f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23699&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23699&range=06-07 Stats: 21 lines in 1 file changed: 19 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23699/head:pull/23699 PR: https://git.openjdk.org/jdk/pull/23699 From jlahoda at openjdk.org Tue Apr 1 12:20:46 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 1 Apr 2025 12:20:46 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath [v8] In-Reply-To: References: Message-ID: <7rj7iYLyZ89QmptA_8-1dWRsKejxloc4BgLIFsX6p90=.a4f7f8d5-419a-4219-880e-24290b8f6254@github.com> On Tue, 1 Apr 2025 12:17:59 GMT, David Beaumont wrote: >> Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. >> >> This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Add final test for sourcepath entry (same behaviour). The new tests seems reasonable to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23699#pullrequestreview-2732490356 From duke at openjdk.org Tue Apr 1 12:20:46 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Apr 2025 12:20:46 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath [v7] In-Reply-To: References: <_O-rObil9n_4DlTZebVgctZ_WQmqqCseQg7ovMk3XfQ=.fc00072d-8c29-454e-9909-4adb56657bc5@github.com> Message-ID: On Mon, 31 Mar 2025 20:50:57 GMT, Joe Darcy wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused import. > > test/langtools/tools/javac/processing/filer/TestNoOverwriteJarFiles.java line 81: > >> 79: * an existing class file entry. This would be very problematic. >> 80: *

>> 81: * This test ensures javac will not modify JAR files on the classpath, even if > > Does something reasonable happen if the soucepath and classpath are both set to the same jar file? Behaviour is same for either/both. Jar file is never modified, sources appear in the working directory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r2022740166 From duke at openjdk.org Tue Apr 1 12:46:18 2025 From: duke at openjdk.org (duke) Date: Tue, 1 Apr 2025 12:46:18 GMT Subject: RFR: 8338675: javac shouldn't silently change .jar files on the classpath [v8] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 12:20:46 GMT, David Beaumont wrote: >> Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. >> >> This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Add final test for sourcepath entry (same behaviour). @david-beaumont Your change (at version 6fcea57f2925b2ed6f17f3b0d6b7239adb8e6168) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23699#issuecomment-2769236369 From cushon at google.com Tue Apr 1 16:48:31 2025 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 1 Apr 2025 09:48:31 -0700 Subject: expression type A is a subtype of pattern type B diagnostics Message-ID: Hi, I had a question about a change that was made to instanceof patterns as part of JEP 440. javac emits diagnostics for instanceof patterns where the expression type is a subtype of the pattern type in JDK 20, but the diagnostics were removed in 21 as part of the implementation of JEP 440. The spec diff for those changes removed language from 15.20 about If the type of the RelationalExpression is a subtype of the type of the > Pattern, then a compile-time error occurs. The implementation also updated test/langtools/tools/javac/patterns/NoSubtypeCheck.java to test for those diagnostics when --release 20 is passed. So all of this seems deliberate and working as intended, I was just curious what the rationale for the change was. Does anyone remember the history or have pointers to discussions about it on list? public class Z { class A {} class B extends A {} void f(B b) { if (b instanceof A a) {} } } Z.java:5: error: expression type Z.B is a subtype of pattern type Z.A if (b instanceof A a) {} ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Tue Apr 1 17:04:38 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 1 Apr 2025 12:04:38 -0500 Subject: expression type A is a subtype of pattern type B diagnostics In-Reply-To: References: Message-ID: On Tue, Apr 1, 2025 at 11:49?AM Liam Miller-Cushon wrote: > So all of this seems deliberate and working as intended, I was just > curious what the rationale for the change was. Does anyone remember the > history or have pointers to discussions about it on list? > I don't know what the stated rationale was at the time, but the change makes intuitive sense to me now: Why should "e instanceof Y x" generate an error when "e instanceof Y" does not? That is to say: the correctness of the type test itself, which is what the error is about, has nothing to do with whether or not you happen to be declaring a new variable that captures a successful outcome of that test. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Apr 1 17:23:06 2025 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 1 Apr 2025 10:23:06 -0700 Subject: expression type A is a subtype of pattern type B diagnostics In-Reply-To: References: Message-ID: I wondered if that was it: arguably it would be good if `e instanceof Y` was also an error in this case, but that ship has sailed. There's tension between trying to use new features to fix mistakes of the past, and having a smooth onramp to new features, and I know that's been discussed in other contexts. The surprising part to me was that the error was introduced, and then removed as part of the implementation of record patterns. On Tue, Apr 1, 2025 at 10:04?AM Archie Cobbs wrote: > On Tue, Apr 1, 2025 at 11:49?AM Liam Miller-Cushon > wrote: > >> So all of this seems deliberate and working as intended, I was just >> curious what the rationale for the change was. Does anyone remember the >> history or have pointers to discussions about it on list? >> > > I don't know what the stated rationale was at the time, but the change > makes intuitive sense to me now: Why should "e instanceof Y x" generate an > error when "e instanceof Y" does not? That is to say: the correctness of > the type test itself, which is what the error is about, has nothing to do > with whether or not you happen to be declaring a new variable that captures > a successful outcome of that test. > > -Archie > > -- > Archie L. Cobbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Tue Apr 1 17:35:16 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 1 Apr 2025 12:35:16 -0500 Subject: expression type A is a subtype of pattern type B diagnostics In-Reply-To: References: Message-ID: Yeah, so the new feature was new enough to change its behavior, but the old feature wasn't... I guess you'd call that age before beauty :) On Tue, Apr 1, 2025 at 12:23?PM Liam Miller-Cushon wrote: > I wondered if that was it: arguably it would be good if `e instanceof Y` > was also an error in this case, but that ship has sailed. There's tension > between trying to use new features to fix mistakes of the past, and having > a smooth onramp to new features, and I know that's been discussed in other > contexts. > > The surprising part to me was that the error was introduced, and then > removed as part of the implementation of record patterns. > > On Tue, Apr 1, 2025 at 10:04?AM Archie Cobbs > wrote: > >> On Tue, Apr 1, 2025 at 11:49?AM Liam Miller-Cushon >> wrote: >> >>> So all of this seems deliberate and working as intended, I was just >>> curious what the rationale for the change was. Does anyone remember the >>> history or have pointers to discussions about it on list? >>> >> >> I don't know what the stated rationale was at the time, but the change >> makes intuitive sense to me now: Why should "e instanceof Y x" generate an >> error when "e instanceof Y" does not? That is to say: the correctness of >> the type test itself, which is what the error is about, has nothing to do >> with whether or not you happen to be declaring a new variable that captures >> a successful outcome of that test. >> >> -Archie >> >> -- >> Archie L. Cobbs >> > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Tue Apr 1 22:30:37 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 1 Apr 2025 18:30:37 -0400 Subject: expression type A is a subtype of pattern type B diagnostics In-Reply-To: References: Message-ID: Was there any official announcement on this information? I bumped my head into this wall many times, and I just walked out of it confused the more I looked at it. I even made a post on both StackOverflow and the Amber Dev mailing list, and walked away with answers that made sense locally, but less so globally. I am under the assumption that this is all changing over time, so maybe that is what it is. Maybe the final result is fully one way or another. On Tue, Apr 1, 2025, 1:35?PM Archie Cobbs wrote: > Yeah, so the new feature was new enough to change its behavior, but the > old feature wasn't... > > I guess you'd call that age before beauty :) > > On Tue, Apr 1, 2025 at 12:23?PM Liam Miller-Cushon > wrote: > >> I wondered if that was it: arguably it would be good if `e instanceof Y` >> was also an error in this case, but that ship has sailed. There's tension >> between trying to use new features to fix mistakes of the past, and having >> a smooth onramp to new features, and I know that's been discussed in other >> contexts. >> >> The surprising part to me was that the error was introduced, and then >> removed as part of the implementation of record patterns. >> >> On Tue, Apr 1, 2025 at 10:04?AM Archie Cobbs >> wrote: >> >>> On Tue, Apr 1, 2025 at 11:49?AM Liam Miller-Cushon >>> wrote: >>> >>>> So all of this seems deliberate and working as intended, I was just >>>> curious what the rationale for the change was. Does anyone remember the >>>> history or have pointers to discussions about it on list? >>>> >>> >>> I don't know what the stated rationale was at the time, but the change >>> makes intuitive sense to me now: Why should "e instanceof Y x" generate an >>> error when "e instanceof Y" does not? That is to say: the correctness of >>> the type test itself, which is what the error is about, has nothing to do >>> with whether or not you happen to be declaring a new variable that captures >>> a successful outcome of that test. >>> >>> -Archie >>> >>> -- >>> Archie L. Cobbs >>> >> > > -- > Archie L. Cobbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acobbs at openjdk.org Wed Apr 2 13:45:01 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 2 Apr 2025 13:45:01 GMT Subject: RFR: 8349847: Support configuring individual lint categories as errors In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 20:52:49 GMT, Archie Cobbs wrote: > This PR refines the `-Werror` flag to support lint categories just like `-Xlint` does. So, for example `-Werror:all,-preview` would cause an error if any warning other than a `preview` warning occurred. > > A few notes: > * Some warnings emitted by the compiler do not have a corresponding `Lint` category. As always, they cause an error if `-Werror` is given, but what if `-Werror:all` is given instead? The answer given here is yes, an error will occur. > * The `-Werror` works the same way as before, i.e., any warning results in an error. That means if `-Werror` is given `-Werror:foo` flags have no effect. > * Refactoring has been done to allow `-Xlint` and `-Werror` to utilize the same "parsing" logic. The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` equals `-Xlint:all`). This behavior has been preserved and Javadocumented. > * A few minor cleanups are included Keepis Alivimus ------------- PR Comment: https://git.openjdk.org/jdk/pull/23622#issuecomment-2772607370 From forax at univ-mlv.fr Wed Apr 2 14:33:57 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Apr 2025 16:33:57 +0200 (CEST) Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) In-Reply-To: References: Message-ID: <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr> Hi Per, last week, at JChateau, we had a one hour session about stable values, I've build the JDK with this PR so we can discuss about it. To present the API, i start from the double check locking, rewriting it to use the StableValue API. The main remark was that methods like orElseSet() or isSet() are hard to used correctly. In my opinion, the current API is a mix of a high level API and a low-level API but it's too easy to misuse the low-level API. high level: - methods supplier(), list() and map() Those are easy to use low level: - methods: of, of(value), orElseSet, setOrThrow(), etc Those are hard to use properly. I think, not necessary in this PR, that the current API should be separated into two different classes, one in java.lang with the high level API (the static methods other than Of() and one in java.util.concurrent with the low level API where you have to know what you are doing (like with any classes of java.util.concurrent). regards, R?mi ----- Original Message ----- > From: "Per Minborg" > To: "compiler-dev" , "core-libs-dev" , "hotspot-dev" > , "security-dev" > Sent: Thursday, March 13, 2025 12:20:10 PM > Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) > Implement JEP 502. > > The PR passes tier1-tier3 tests. > > ------------- > > Commit messages: > - Use acquire semantics for reading rather than volatile semantics > - Add missing null check > - Simplify handling of sentinel, wrap, and unwrap > - Fix JavaDoc issues > - Fix members in StableEnumFunction > - Address some comments in the PR > - Merge branch 'master' into implement-jep502 > - Revert change > - Fix copyright issues > - Update JEP number > - ... and 231 more: https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6 > > Changes: https://git.openjdk.org/jdk/pull/23972/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8351565 > Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod > Patch: https://git.openjdk.org/jdk/pull/23972.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 > > PR: https://git.openjdk.org/jdk/pull/23972 From mcimadamore at openjdk.org Wed Apr 2 14:34:55 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 2 Apr 2025 14:34:55 GMT Subject: RFR: 8349847: Support configuring individual lint categories as errors In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 20:52:49 GMT, Archie Cobbs wrote: > This PR refines the `-Werror` flag to support lint categories just like `-Xlint` does. So, for example `-Werror:all,-preview` would cause an error if any warning other than a `preview` warning occurred. > > A few notes: > * Some warnings emitted by the compiler do not have a corresponding `Lint` category. As always, they cause an error if `-Werror` is given, but what if `-Werror:all` is given instead? The answer given here is yes, an error will occur. > * The `-Werror` works the same way as before, i.e., any warning results in an error. That means if `-Werror` is given `-Werror:foo` flags have no effect. > * Refactoring has been done to allow `-Xlint` and `-Werror` to utilize the same "parsing" logic. The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` equals `-Xlint:all`). This behavior has been preserved and Javadocumented. > * A few minor cleanups are included Can we please hold off on this for now? There's many `lint`-related improvements going on at the same time, and, while it's good to see some activity in this area, I'd like to proceed in a more incremental fashion. Let's try to clear up the queue before we add more to it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23622#issuecomment-2772759146 From acobbs at openjdk.org Wed Apr 2 14:43:56 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 2 Apr 2025 14:43:56 GMT Subject: RFR: 8349847: Support configuring individual lint categories as errors In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:32:27 GMT, Maurizio Cimadamore wrote: >> This PR refines the `-Werror` flag to support lint categories just like `-Xlint` does. So, for example `-Werror:all,-preview` would cause an error if any warning other than a `preview` warning occurred. >> >> A few notes: >> * Some warnings emitted by the compiler do not have a corresponding `Lint` category. As always, they cause an error if `-Werror` is given, but what if `-Werror:all` is given instead? The answer given here is yes, an error will occur. >> * The `-Werror` works the same way as before, i.e., any warning results in an error. That means if `-Werror` is given `-Werror:foo` flags have no effect. >> * Refactoring has been done to allow `-Xlint` and `-Werror` to utilize the same "parsing" logic. The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` equals `-Xlint:all`). This behavior has been preserved and Javadocumented. >> * A few minor cleanups are included > > Can we please hold off on this for now? There's many `lint`-related improvements going on at the same time, and, while it's good to see some activity in this area, I'd like to proceed in a more incremental fashion. Let's try to clear up the queue before we add more to it. Hi @mcimadamore, Certainly - I was only trying to stave off the bot, not implying impatience. Maybe we need a new bot command like `/keep-alive 8w` that could change the idle timeout setting... ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23622#issuecomment-2772785648 From vromero at openjdk.org Wed Apr 2 15:31:50 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 2 Apr 2025 15:31:50 GMT Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations [v3] In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 17:40:25 GMT, Jan Lahoda wrote: >> This is a patch to finalize the module imports feature. Please see: >> https://bugs.openjdk.org/browse/JDK-8344700 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing test. src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java line 340: > 338: */ > 339: static Startup defaultStartup(int sourceLevel, boolean preview, MessageHandler mh) { > 340: boolean startup24 = sourceLevel < 25; should we use a constant here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2025076240 From jlahoda at openjdk.org Wed Apr 2 16:59:16 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 2 Apr 2025 16:59:16 GMT Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations [v4] In-Reply-To: References: Message-ID: > This is a patch to finalize the module imports feature. Please see: > https://bugs.openjdk.org/browse/JDK-8344700 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review feedback - avoiding hardcoded constants. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23801/files - new: https://git.openjdk.org/jdk/pull/23801/files/067a0444..d66703c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=02-03 Stats: 19 lines in 3 files changed: 4 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/23801.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801 PR: https://git.openjdk.org/jdk/pull/23801 From jlahoda at openjdk.org Wed Apr 2 16:59:17 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 2 Apr 2025 16:59:17 GMT Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations [v3] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 15:23:54 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing test. > > src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java line 340: > >> 338: */ >> 339: static Startup defaultStartup(int sourceLevel, boolean preview, MessageHandler mh) { >> 340: boolean startup24 = sourceLevel < 25; > > should we use a constant here? Yes, there should be a constant. Done here: https://github.com/openjdk/jdk/pull/23801/commits/d66703c1cb4f9f532f9a98181b598fa45e55ef73 Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2025240134 From vromero at openjdk.org Wed Apr 2 17:11:52 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 2 Apr 2025 17:11:52 GMT Subject: RFR: 8351431: Type annotations on new class creation expressions can't be retrieved In-Reply-To: References: Message-ID: On Fri, 7 Mar 2025 17:26:25 GMT, Liam Miller-Cushon wrote: > Hello, > > Please consider this fix for [JDK-8351431](https://bugs.openjdk.org/browse/JDK-8351431), which allows type annotations on the class type of a `new` class creation expression to be retrieved by the Compiler Tree API. > > Currently `Attr` is skipping `annotateTypeSecondStage` for all new class types, but the special case only needs to be applied to anonymous new class creation expressions to be consistent with logic in `Annotate`: > > https://github.com/openjdk/jdk/blob/7c22b814d670deda6c2bb93b1e150975c27a165f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L1162-L1166 > > This also removes a check of `isNewClass` (now `isNewAnonymousClass`) in `InvalidCanonicalConstructorInRecord`, because the field was only set before descending into a `JCNewClass.clazz`, which can't contain return statements. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23946#pullrequestreview-2737011829 From cushon at openjdk.org Wed Apr 2 17:37:11 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 2 Apr 2025 17:37:11 GMT Subject: RFR: 8351431: Type annotations on new class creation expressions can't be retrieved [v2] In-Reply-To: References: Message-ID: <_WZ7IpNhCJ05znAnB8MovsxMZwopQl67bDwD03EpVt4=.1fa51ad9-e2f9-4249-97b0-6b4615c8bfb7@github.com> > Hello, > > Please consider this fix for [JDK-8351431](https://bugs.openjdk.org/browse/JDK-8351431), which allows type annotations on the class type of a `new` class creation expression to be retrieved by the Compiler Tree API. > > Currently `Attr` is skipping `annotateTypeSecondStage` for all new class types, but the special case only needs to be applied to anonymous new class creation expressions to be consistent with logic in `Annotate`: > > https://github.com/openjdk/jdk/blob/7c22b814d670deda6c2bb93b1e150975c27a165f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L1162-L1166 > > This also removes a check of `isNewClass` (now `isNewAnonymousClass`) in `InvalidCanonicalConstructorInRecord`, because the field was only set before descending into a `JCNewClass.clazz`, which can't contain return statements. Liam Miller-Cushon 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 remote-tracking branch 'origin/master' into JDK-8351431 - 8351431: Type annotations on new class creation expressions can't be retrieved ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23946/files - new: https://git.openjdk.org/jdk/pull/23946/files/84d34fd2..f604a9f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23946&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23946&range=00-01 Stats: 123852 lines in 2674 files changed: 49008 ins; 58144 del; 16700 mod Patch: https://git.openjdk.org/jdk/pull/23946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23946/head:pull/23946 PR: https://git.openjdk.org/jdk/pull/23946 From vromero at openjdk.org Wed Apr 2 17:43:51 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 2 Apr 2025 17:43:51 GMT Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations [v4] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 16:59:16 GMT, Jan Lahoda wrote: >> This is a patch to finalize the module imports feature. Please see: >> https://bugs.openjdk.org/browse/JDK-8344700 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback - avoiding hardcoded constants. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2737083010 From duke at openjdk.org Thu Apr 3 05:40:11 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 3 Apr 2025 05:40:11 GMT Subject: Integrated: 8338675: javac shouldn't silently change .jar files on the classpath In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 15:46:34 GMT, David Beaumont wrote: > Modifying `JavacFileManager` to skip creating sibling output class files for source files found in JARs. > > This should match older (JDK 8) behavior whereby the JAR was not writable, and results in any newly generated class files being written to the current working directory (the output of class files into current directory isn't good, but it should match the old behavior). This pull request has now been integrated. Changeset: bd749221 Author: David Beaumont Committer: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/bd74922157230c866802b4c5269da81e872525aa Stats: 329 lines in 3 files changed: 325 ins; 0 del; 4 mod 8338675: javac shouldn't silently change .jar files on the classpath Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/23699 From cushon at openjdk.org Thu Apr 3 16:12:04 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 3 Apr 2025 16:12:04 GMT Subject: Integrated: 8351431: Type annotations on new class creation expressions can't be retrieved In-Reply-To: References: Message-ID: <8KbvU7CXJ0z98GP_H0evtDM6WoYYDmW3Nu_1bcJhPFI=.c16e398e-fb5d-4e05-865c-df3af4c33e4b@github.com> On Fri, 7 Mar 2025 17:26:25 GMT, Liam Miller-Cushon wrote: > Hello, > > Please consider this fix for [JDK-8351431](https://bugs.openjdk.org/browse/JDK-8351431), which allows type annotations on the class type of a `new` class creation expression to be retrieved by the Compiler Tree API. > > Currently `Attr` is skipping `annotateTypeSecondStage` for all new class types, but the special case only needs to be applied to anonymous new class creation expressions to be consistent with logic in `Annotate`: > > https://github.com/openjdk/jdk/blob/7c22b814d670deda6c2bb93b1e150975c27a165f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L1162-L1166 > > This also removes a check of `isNewClass` (now `isNewAnonymousClass`) in `InvalidCanonicalConstructorInRecord`, because the field was only set before descending into a `JCNewClass.clazz`, which can't contain return statements. This pull request has now been integrated. Changeset: 6b7b3247 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/6b7b3247b1b247ca38ba51a2c2de924eea9b2aba Stats: 160 lines in 3 files changed: 153 ins; 1 del; 6 mod 8351431: Type annotations on new class creation expressions can't be retrieved Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/23946 From henryjen at openjdk.org Fri Apr 4 00:44:18 2025 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 4 Apr 2025 00:44:18 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate Message-ID: This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. ------------- Commit messages: - 8345431: Detect duplicate entries in jar files with jar --validate Changes: https://git.openjdk.org/jdk/pull/24430/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24430&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345431 Stats: 118 lines in 4 files changed: 98 ins; 2 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/24430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430 PR: https://git.openjdk.org/jdk/pull/24430 From maurizio.cimadamore at oracle.com Fri Apr 4 10:32:34 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 4 Apr 2025 11:32:34 +0100 Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) In-Reply-To: References: <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr> Message-ID: In general I don't disagree. There is, however, at least _some_ cases where the imperative API is less difficult to use. In some cases you know that a class has a complex lifecycle -- perhaps it starts off in a simple "larval" state, where the instance only exist in a single thread. In this state, it's possible for the class to receive state updates. If parts of the class state are stable, using `trySet` might work very well. Perhaps only "friends" of this class can call such mutator methods on the larval instance. At some point later in the class lifetime, it becomes "frozen", and it is published to multiple threads. Of course, this is a corner case -- but if our goal is to model what `@Stable` can do, while surely a stable supplier, or using `orElseSet` are better no-worry alternatives to get there, there remain a number of use cases that would not be expressible if all we had was the high-level API. In a way, a big part of what this new API does is that it finds the right set of primitives, upon which we can build all the other interesting high-level stuff. I think your complaint is not that the primitive is wrong, but that in calling the primitive StableValue we're giving the "good name" to the stuff that is less likely to be widely used. (Note: a very minimalistic API approach -- which we considered -- would have been to just provide extra stable factories in Supplier/Function/IntFunction/List/Map and call it a day) Maurizio On 03/04/2025 12:20, Per-Ake Minborg wrote: > Hi Remi and thank you for the feedback from JChateau?(what a wonderful > name!). > > This is one of the issues we already have on the list for the next > round of preview. Now we know more folks are on the same page. > > Best, Per > ------------------------------------------------------------------------ > *From:* Remi Forax > *Sent:* Wednesday, April 2, 2025 4:33 PM > *To:* Per Minborg > *Cc:* compiler-dev ; core-libs-dev > ; hotspot-dev ; > security-dev > *Subject:* Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) > Hi Per, > last week, at JChateau, we had a one hour session about stable values, > I've build the JDK with this PR so we can discuss about it. > > To present the API, i start from the double check locking, rewriting > it to use the StableValue API. > > The main remark was that methods like orElseSet() or isSet() are hard > to used correctly. > > In my opinion, the current API is a mix of a high level API and a > low-level API but it's too easy to misuse the low-level API. > > > high level: > - methods supplier(), list() and map() > ? Those are easy to use > > low level: > - methods: of, of(value), orElseSet, setOrThrow(), etc > ? Those are hard to use properly. > > I think, not necessary in this PR, that the current API should be > separated into two different classes, one in java.lang with the high > level API (the static methods other than Of() and one in > java.util.concurrent with the low level API where you have to know > what you are doing (like with any classes of java.util.concurrent). > > regards, > R?mi > > ----- Original Message ----- > > From: "Per Minborg" > > To: "compiler-dev" , "core-libs-dev" > , "hotspot-dev" > > , "security-dev" > > Sent: Thursday, March 13, 2025 12:20:10 PM > > Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) > > > Implement JEP 502. > > > > The PR passes tier1-tier3 tests. > > > > ------------- > > > > Commit messages: > > - Use acquire semantics for reading rather than volatile semantics > > - Add missing null check > > - Simplify handling of sentinel, wrap, and unwrap > > - Fix JavaDoc issues > > - Fix members in StableEnumFunction > > - Address some comments in the PR > > - Merge branch 'master' into implement-jep502 > > - Revert change > > - Fix copyright issues > > - Update JEP number > > - ... and 231 more: > https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6 > > > > Changes: https://git.openjdk.org/jdk/pull/23972/files > >? Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00 > > >? Issue: https://bugs.openjdk.org/browse/JDK-8351565 > >? Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod > >? Patch: https://git.openjdk.org/jdk/pull/23972.diff > >? Fetch: git fetch https://git.openjdk.org/jdk.git > pull/23972/head:pull/23972 > > > > PR: https://git.openjdk.org/jdk/pull/23972 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lancea at openjdk.org Fri Apr 4 13:14:08 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 4 Apr 2025 13:14:08 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 00:39:04 GMT, Henry Jen wrote: > This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. Thank you for starting the work on this Henry. A few initial comments/improvements based on an initial pass of your PR: - Validate that the Entry names match between the LOC and CEN including the entry order within the headers (ZipOutputStream and most tools will write the LOC/CEN headers in the same order) - Warn of duplicate entries - Check that any LOC entry exists in the CEN and any CEN entry exists in the LOC - Be more specific in the warnings reported such as: Entry XXX found in the LOC but not the CEN - main.help.opt.main.validate in jar.properties should be updated to indicate additional validation - jar.md should also be updated for the same reason - I would use this as an opportunity to add some comments as to what the methods such as validate are now doing given the functions verification has been expanded It would also be good to validate that the MANIFEST returned ZipFile and ZipInputStream match (this could be follow on work) src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 66: > 64: private String mdName; > 65: private final ZipInputStream zis; > 66: private final Set entryNames = new HashSet<>(); Please rename this to represent the CEN entries. src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 80: > 78: } > 79: > 80: private void checkDuplicates(ZipEntry e) { Please add a general comment of the purpose as this method is only used with traversing the ZipFile and walking the CEN src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 86: > 84: } > 85: > 86: private void checkZipInputStream() { Please add a comment on the purpose of the method src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 92: > 90: ZipEntry e; > 91: while ((e = zis.getNextEntry()) != null) { > 92: var entryName = e.getName(); please rename to locEntryName src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 99: > 97: if (!entryNames.contains(entryName)) { > 98: missingEntryNames.add(entryName); > 99: } It looks like you are checking to see if the LOC entry contains within the CEN but I don't see if you are checking if the CEN entry is contained in the LOC Another facet of validation is to compare the ordering of entries between the LOC and CEN src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 147: > 145: in incompatible public interfaces > 146: warn.validator.duplicate.entry=\ > 147: Warning: More than one copy of {0} is detected How do we know if the duplicate entry is in the CEN or LOC? src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 149: > 147: Warning: More than one copy of {0} is detected > 148: warn.validator.inconsistent.content=\ > 149: Warning: The list of entries does not match the content This message could be more specific to the type of error found test/jdk/tools/jar/MultipleManifestTest.java line 26: > 24: /* > 25: * @test > 26: * @bug 8335912 8345431 I would suggesting moving the validation for multiple entries, LOC/CEN mismatches into a separate test ------------- PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2742819751 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028719761 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028722966 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028727832 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028730393 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028742286 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028755446 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028756250 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2028758898 From henryjen at openjdk.org Fri Apr 4 16:03:49 2025 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 4 Apr 2025 16:03:49 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 12:39:47 GMT, Lance Andersen wrote: >> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident. > > src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 99: > >> 97: if (!entryNames.contains(entryName)) { >> 98: missingEntryNames.add(entryName); >> 99: } > > It looks like you are checking to see if the LOC entry contains within the CEN but I don't see if you are checking if the CEN entry is contained in the LOC > > Another facet of validation is to compare the ordering of entries between the LOC and CEN Is the ordering required by ZIP or Jar format? We can certainly do that if that's under spec and not an implementation detail. > src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 147: > >> 145: in incompatible public interfaces >> 146: warn.validator.duplicate.entry=\ >> 147: Warning: More than one copy of {0} is detected > > How do we know if the duplicate entry is in the CEN or LOC? I can add more specific message if that's preferred. I am not expecting user/developer to know about file format details. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029080880 PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029083361 From henryjen at openjdk.org Fri Apr 4 16:08:58 2025 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 4 Apr 2025 16:08:58 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 15:59:47 GMT, Henry Jen wrote: >> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 99: >> >>> 97: if (!entryNames.contains(entryName)) { >>> 98: missingEntryNames.add(entryName); >>> 99: } >> >> It looks like you are checking to see if the LOC entry contains within the CEN but I don't see if you are checking if the CEN entry is contained in the LOC >> >> Another facet of validation is to compare the ordering of entries between the LOC and CEN > > Is the ordering required by ZIP or Jar format? We can certainly do that if that's under spec and not an implementation detail. As we checking entry uniqueness and the size match, and all LOC entries should be in CEN, that would means all CEN entries in LOC. But if we would like to be specific about the inconsistency, then we will have to do a little more work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029088848 From lancea at openjdk.org Fri Apr 4 16:16:48 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 4 Apr 2025 16:16:48 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 16:06:07 GMT, Henry Jen wrote: >> Is the ordering required by ZIP or Jar format? We can certainly do that if that's under spec and not an implementation detail. > > As we checking entry uniqueness and the size match, and all LOC entries should be in CEN, that would means all CEN entries in LOC. > But if we would like to be specific about the inconsistency, then we will have to do a little more work. Yes, in a perfect world there will be a 1 to 1 match but either way we should sanity check it in case something happened ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029097428 From lancea at openjdk.org Fri Apr 4 16:16:49 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 4 Apr 2025 16:16:49 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 16:01:40 GMT, Henry Jen wrote: >> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 147: >> >>> 145: in incompatible public interfaces >>> 146: warn.validator.duplicate.entry=\ >>> 147: Warning: More than one copy of {0} is detected >> >> How do we know if the duplicate entry is in the CEN or LOC? > > I can add more specific message if that's preferred. I am not expecting user/developer to know about file format details. It is useful to know where the error is for future analysis ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029098473 From lancea at openjdk.org Fri Apr 4 16:47:07 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 4 Apr 2025 16:47:07 GMT Subject: RFR: 8345431: Detect duplicate entries in jar files with jar --validate In-Reply-To: References: Message-ID: <-zMJMfesQZoXPso7UCC6fE6k0XN3KDtnIjjz7cEB9xQ=.ab47a4df-f3ac-4d00-9328-e29851789bfc@github.com> On Fri, 4 Apr 2025 16:12:56 GMT, Lance Andersen wrote: >> As we checking entry uniqueness and the size match, and all LOC entries should be in CEN, that would means all CEN entries in LOC. >> But if we would like to be specific about the inconsistency, then we will have to do a little more work. > > Yes, in a perfect world there will be a 1 to 1 match but either way we should sanity check it in case something happened > Is the ordering required by ZIP or Jar format? We can certainly do that if that's under spec and not an implementation detail. The Zip Spec states the following: > 4.3.2 Each file placed into a ZIP file MUST be preceded by a "local > file header" record for that file. Each "local file header" MUST be > accompanied by a corresponding "central directory header" record within > the central directory section of the ZIP file. That being said I am not aware of any implementations where the order is different given you have to generate the LOC prior to the CEN and End of CEN ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2029133374 From acobbs at openjdk.org Fri Apr 4 21:42:35 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 4 Apr 2025 21:42:35 GMT Subject: RFR: 8350212: Track source end positions of declarations that support @SuppressWarnings [v3] In-Reply-To: References: Message-ID: > This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. > > Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available. > > The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons. > > Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add missing variable decl end position. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23669/files - new: https://git.openjdk.org/jdk/pull/23669/files/e2352287..0f85a240 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23669&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23669&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23669.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23669/head:pull/23669 PR: https://git.openjdk.org/jdk/pull/23669 From acobbs at openjdk.org Fri Apr 4 21:42:35 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 4 Apr 2025 21:42:35 GMT Subject: RFR: 8350212: Track source end positions of declarations that support @SuppressWarnings [v2] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 03:46:52 GMT, Archie Cobbs wrote: >> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. >> >> Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available. >> >> The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons. >> >> Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add end position for variables coming from variableDeclaratorId(). After further review, this change is now on the table again; reopening this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2779772968 From acobbs at openjdk.org Fri Apr 4 22:10:58 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 4 Apr 2025 22:10:58 GMT Subject: RFR: 8353757: Log class should have a proper clear() method Message-ID: This is a simple refactoring to add a method `Log.clear()`, move `ReusableLog.clear()`'s clearing operations into it and invoke `super.clear()` instead, and add two more fields that should be included in the clear operation but were not because they were added to `Log` after `ReusableLog.clear()` was added and were missed. A natural question: Are there any other fields in `Log` that should be cleared in `Log.clear()`? The two I've added (`nsuppressederrors` and `nsuppressedwarns`) are the only two that weren't there when `ReusableLog` as added, so presumably not, but it's possible. ------------- Commit messages: - Add new method Log.clear(). Changes: https://git.openjdk.org/jdk/pull/24460/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24460&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353757 Stats: 19 lines in 2 files changed: 12 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24460.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24460/head:pull/24460 PR: https://git.openjdk.org/jdk/pull/24460 From acobbs at openjdk.org Fri Apr 4 22:20:28 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 4 Apr 2025 22:20:28 GMT Subject: RFR: 8353757: Log class should have a proper clear() method [v2] In-Reply-To: References: Message-ID: > This is a simple refactoring to add a method `Log.clear()`, move `ReusableLog.clear()`'s clearing operations into it and invoke `super.clear()` instead, and add two more fields that should be included in the clear operation but were not because they were added to `Log` after `ReusableLog.clear()` was added and were missed. > > A natural question: Are there any other fields in `Log` that should be cleared in `Log.clear()`? The two I've added (`nsuppressederrors` and `nsuppressedwarns`) are the only two that weren't there when `ReusableLog` as added, so presumably not, but it's possible. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Invoke Log.useSource() before recursing into attribution. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24460/files - new: https://git.openjdk.org/jdk/pull/24460/files/e9931f6d..a1108ac7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24460&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24460&range=00-01 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24460.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24460/head:pull/24460 PR: https://git.openjdk.org/jdk/pull/24460 From cushon at openjdk.org Sun Apr 6 04:52:12 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sun, 6 Apr 2025 04:52:12 GMT Subject: RFR: 8347291: Exhaustive switch over a generic sealed abstract class [v2] In-Reply-To: References: Message-ID: > This change avoids javac incorrectly reporting switches like the example in [JDK-8347291](https://bugs.openjdk.org/browse/JDK-8347291) as exhaustive. > > As Jan noted in the bug it seems like the inference behaviour here may not be correct. If it was able to infer a type without crashing that would also avoid the bug. > > However with the current inference behaviour, it's safer to assume that if inference crashes the subtype may need to be handled by the switch, instead of assuming that it doesn't. Liam Miller-Cushon 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 four additional commits since the last revision: - Handle error types in InferenceUnitTest - Merge remote-tracking branch 'origin/master' into JDK-8347291 - Merge remote-tracking branch 'origin/master' into JDK-8347291 - 8347291: Exhaustive switch over a generic sealed abstract class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23286/files - new: https://git.openjdk.org/jdk/pull/23286/files/d7029901..db7305a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23286&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23286&range=00-01 Stats: 100171 lines in 2710 files changed: 41499 ins; 47639 del; 11033 mod Patch: https://git.openjdk.org/jdk/pull/23286.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23286/head:pull/23286 PR: https://git.openjdk.org/jdk/pull/23286 From duke at openjdk.org Sun Apr 6 10:54:07 2025 From: duke at openjdk.org (Luca Kellermann) Date: Sun, 6 Apr 2025 10:54:07 GMT Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) [v57] In-Reply-To: References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: On Wed, 31 Jan 2024 10:03:23 GMT, Aggelos Biboudis wrote: >> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). >> >> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/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 78 commits: > > - Merge branch 'master' into primitive-patterns > - Update summary in ExactnessConversionsSupportTest > - Address review by Jan > - Remove redundant null check and introduce a const boolean for unconditionally exact pairs > - Small fix in Javadoc > - Tidy up Javadoc of Lower.visitTypeTest > - Tidy up Javadoc of IllegalArgumentException in typeSwitch > - Improve readability in SwitchBootstraps > - Update year > - Cleanup redundant clone > - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1 src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 676: > 674: } > 675: else if (selectorType.equals(targetType) || > 676: ((selectorType.equals(byte.class) && !targetType.equals(char.class)) || Suggestion: ((selectorType.equals(byte.class) && targetType.isPrimitve() && !targetType.equals(boolean.class) && !targetType.equals(char.class)) || Otherwise, `SwitchBootstraps.typeSwitch` produces wrong results for `byte`: var l = MethodHandles.lookup(); var shortType = MethodType.methodType(int.class, short.class, int.class); var byteType = MethodType.methodType(int.class, byte.class, int.class); CallSite shortSwitch = SwitchBootstraps.typeSwitch(l, "", shortType, String.class); CallSite byteSwitch = SwitchBootstraps.typeSwitch(l, "", byteType, String.class); int shortIndex = (int) shortSwitch.getTarget().invokeExact((short) 1, 0); int byteIndex = (int) byteSwitch.getTarget().invokeExact((byte) 1, 0); System.out.println(shortIndex == 1); // true System.out.println(byteIndex == 1); // false System.out.println(byteIndex); // 0 This would cause this code to misbehave (if it would compile, which it doesn't): byte b = 1; switch (b) { case String s -> System.out.println("How did we get here? byte is " + s.getClass()); } So it isn't really a problem with `javac` but could cause problems for other users of `SwitchBootstraps`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r2030113548 From jlahoda at openjdk.org Mon Apr 7 07:01:34 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 7 Apr 2025 07:01:34 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods Message-ID: This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) - `java. ... .IO` is no longer automatically imported in any compilation unit - the feature is finalized (i.e. no longer requires `--enable-preview`) ------------- Commit messages: - Moving tests as suggested, removing unused import. - Fixing test. - Fixing test. - Fixing test. - Removing unnecessary enable preview from tests. - Merge branch 'master' into finalize-concise-source-files - Merge remote-tracking branch 'stuart-marks/JavaLangIO' into finalize-concise-source-files - Responses to Alan's comments: clean up readln() and align with class spec. - Clean up some charset stuff, use stdin.encoding property. - Merge branch 'master' into JavaLangIO - ... and 16 more: https://git.openjdk.org/jdk/compare/1c2a5533...a5d223e1 Changes: https://git.openjdk.org/jdk/pull/24438/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344706 Stats: 962 lines in 56 files changed: 294 ins; 585 del; 83 mod Patch: https://git.openjdk.org/jdk/pull/24438.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438 PR: https://git.openjdk.org/jdk/pull/24438 From duke at openjdk.org Mon Apr 7 07:01:34 2025 From: duke at openjdk.org (Luca Kellermann) Date: Mon, 7 Apr 2025 07:01:34 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda wrote: > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) src/java.base/share/classes/java/lang/IO.java line 122: > 120: public static void print(Object obj) { > 121: System.out.print(obj); > 122: System.out.flush(); Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between? var out = System.out; out.print(obj); out.flush(); src/java.base/share/classes/java/lang/IO.java line 147: > 145: } catch (IOException ioe) { > 146: throw new IOError(ioe); > 147: } Was `UncheckedIOException` considered? It might be better for beginners to learn throwing exceptions instead of errors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029603325 PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029604846 From liach at openjdk.org Mon Apr 7 07:01:34 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Apr 2025 07:01:34 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods In-Reply-To: References: Message-ID: On Sat, 5 Apr 2025 00:55:55 GMT, Luca Kellermann wrote: >> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: >> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) >> - `java. ... .IO` is no longer automatically imported in any compilation unit >> - the feature is finalized (i.e. no longer requires `--enable-preview`) > > src/java.base/share/classes/java/lang/IO.java line 122: > >> 120: public static void print(Object obj) { >> 121: System.out.print(obj); >> 122: System.out.flush(); > > Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between? > > > var out = System.out; > out.print(obj); > out.flush(); This code is not that perf sensitive, guess it is fine as-is > src/java.base/share/classes/java/lang/IO.java line 147: > >> 145: } catch (IOException ioe) { >> 146: throw new IOError(ioe); >> 147: } > > Was `UncheckedIOException` considered? It might be better for beginners to learn throwing exceptions instead of errors. This implementation is not to be emulated by beginners. If an Exception.is thrown here, a user might be tempted to add handlers in their code, while this is an issue with the setup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029660072 PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029659899 From liach at openjdk.org Mon Apr 7 07:01:35 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Apr 2025 07:01:35 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods In-Reply-To: References: Message-ID: <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com> On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda wrote: > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) src/java.base/share/classes/java/lang/IO.java line 183: > 181: * @return the internal BufferedReader instance > 182: */ > 183: static synchronized BufferedReader reader() { Is the lock only inteneded for initialization, i.e. should it apply for simply getting the reader? test/jdk/java/io/IO/IO.java line 1: > 1: /* Shouldn't the package of this test be moved to java/lang? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029576244 PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2029576615 From jlahoda at openjdk.org Mon Apr 7 07:05:00 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 7 Apr 2025 07:05:00 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods In-Reply-To: <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com> References: <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com> Message-ID: On Sat, 5 Apr 2025 00:20:29 GMT, Chen Liang wrote: >> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: >> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) >> - `java. ... .IO` is no longer automatically imported in any compilation unit >> - the feature is finalized (i.e. no longer requires `--enable-preview`) > > src/java.base/share/classes/java/lang/IO.java line 183: > >> 181: * @return the internal BufferedReader instance >> 182: */ >> 183: static synchronized BufferedReader reader() { > > Is the lock only inteneded for initialization, i.e. should it apply for simply getting the reader? I believe there needs to be some barriers (at least `volatile`) even for getting the already initialized reader. And then, given the code here, it is probably fine and less error prone to simply use `synchronized` that something more complex. But, given we'll hopefully have `@StableValue` soon, maybe we could use that? What do you think @stuart-marks? Thanks! > test/jdk/java/io/IO/IO.java line 1: > >> 1: /* > > Shouldn't the package of this test be moved to java/lang? Done: https://github.com/openjdk/jdk/pull/24438/commits/a5d223e14cadeb0e331d66d9030b780651f0cd64 Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2030575903 PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2030576686 From cstein at openjdk.org Mon Apr 7 07:19:54 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 7 Apr 2025 07:19:54 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda wrote: > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) Changes in source launcher related tests look good. ------------- Marked as reviewed by cstein (Committer). PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2745745703 From mcimadamore at openjdk.org Mon Apr 7 09:00:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Apr 2025 09:00:54 GMT Subject: RFR: 8353757: Log class should have a proper clear() method [v2] In-Reply-To: References: Message-ID: <4tgepf3KhZC9fgsRY_UvHcqpBMsdDlY0XE_4skIcnME=.8de06b33-25f7-4e03-9734-badb716f1cb0@github.com> On Fri, 4 Apr 2025 22:20:28 GMT, Archie Cobbs wrote: >> This is a simple refactoring to add a method `Log.clear()`, move `ReusableLog.clear()`'s clearing operations into it and invoke `super.clear()` instead, and add two more fields that should be included in the clear operation but were not because they were added to `Log` after `ReusableLog.clear()` was added and were missed. >> >> A natural question: Are there any other fields in `Log` that should be cleared in `Log.clear()`? The two I've added (`nsuppressederrors` and `nsuppressedwarns`) are the only two that weren't there when `ReusableLog` as added, so presumably not, but it's possible. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Invoke Log.useSource() before recursing into attribution. src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 364: > 362: try { > 363: Env env = getAttrContext(path.getTreePath()); > 364: JavaFileObject prevSource = log.useSource(env.toplevel.sourcefile); These fixes are independent correct? (I'm ok with them being added here) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24460#discussion_r2030775918 From mcimadamore at openjdk.org Mon Apr 7 09:03:58 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Apr 2025 09:03:58 GMT Subject: RFR: 8353757: Log class should have a proper clear() method [v2] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 22:20:28 GMT, Archie Cobbs wrote: >> This is a simple refactoring to add a method `Log.clear()`, move `ReusableLog.clear()`'s clearing operations into it and invoke `super.clear()` instead, and add two more fields that should be included in the clear operation but were not because they were added to `Log` after `ReusableLog.clear()` was added and were missed. >> >> A natural question: Are there any other fields in `Log` that should be cleared in `Log.clear()`? The two I've added (`nsuppressederrors` and `nsuppressedwarns`) are the only two that weren't there when `ReusableLog` as added, so presumably not, but it's possible. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Invoke Log.useSource() before recursing into attribution. src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 696: > 694: */ > 695: public void clear() { > 696: recorded.clear(); I think the list here is good. There is more state in Log -- but that state seems to be set at creation (e.g. diag listener, writers), while the goal here is to clear up state that "accumulates" from a compilation task. The thing I'm unsure about is the `diagnosticHandler` field. I suppose we always call "clear" from a context where we already have popped all the installed alternate handlers -- but if not we should reset that too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24460#discussion_r2030783042 From alanb at openjdk.org Mon Apr 7 09:14:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 7 Apr 2025 09:14:52 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda wrote: > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) src/java.base/share/classes/java/lang/IO.java line 45: > 43: * UTF-8 is used instead. These internal objects are created upon the first call to > 44: * either of the {@code readln} methods and are stored for subsequent reuse by these > 45: * methods. @stuart-marks Can we rephrase this paragraph so that it doesn't use phrase "internal objects"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2030812095 From mcimadamore at openjdk.org Mon Apr 7 09:16:55 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Apr 2025 09:16:55 GMT Subject: RFR: 8350212: Track source end positions of declarations that support @SuppressWarnings [v3] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 21:42:35 GMT, Archie Cobbs wrote: >> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. >> >> Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available. >> >> The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons. >> >> Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add missing variable decl end position. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 704: > 702: protected void storeEnd(JCTree tree, int endpos) { > 703: endPosTable.storeEnd(tree, endpos); > 704: If this method was non-void, we could make clients more fluent? src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 645: > 643: public PackageSymbol packge; > 644: /** Position of closing semicolon, optional. */ > 645: public int endPos = Position.NOPOS; Your code seems consistent with what we already do with `JCBody`, `JCSwicthExpression` and `JCSwitch`. There's nothing wrong with this approach, although if end positions are enabled, this might be a little wasteful, as we'll store end positions both in the table and in the tree... a possible alternative would have been to construct a "minimal" end pos table which only contains positions for some "important" declarations (even when end positions are switched off) since these seems necessary for the compiler to work correctly. That would allow all code to flow through the end pos table and maybe simplify the implementation of the `TreeInfo` method (as well as `storeEnd` in the parser). But I'll leave that option for you to consider. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2030816614 PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2030813961 From alanb at openjdk.org Mon Apr 7 09:20:59 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 7 Apr 2025 09:20:59 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods In-Reply-To: References: Message-ID: On Sat, 5 Apr 2025 02:30:33 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/IO.java line 147: >> >>> 145: } catch (IOException ioe) { >>> 146: throw new IOError(ioe); >>> 147: } >> >> Was `UncheckedIOException` considered? It might be better for beginners to learn throwing exceptions instead of errors. > > This implementation is not to be emulated by beginners. If an Exception.is thrown here, a user might be tempted to add handlers in their code, while this is an issue with the setup. Someone is bound to ask why the readln method throw but the println methods don't. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2030830662 From jlahoda at openjdk.org Mon Apr 7 11:59:56 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 7 Apr 2025 11:59:56 GMT Subject: Integrated: 8352621: MatchException from backwards incompatible change to switch expressions In-Reply-To: <0AltGW3kEbkk0oV7Sxx72igWQNnW6D3y5ddKNH60HMU=.395dfbf9-1272-42db-bd62-6083f7e13daa@github.com> References: <0AltGW3kEbkk0oV7Sxx72igWQNnW6D3y5ddKNH60HMU=.395dfbf9-1272-42db-bd62-6083f7e13daa@github.com> Message-ID: On Wed, 26 Mar 2025 07:47:19 GMT, Jan Lahoda wrote: > Considering code like: > > record R2(int i1, int i2) {} > ... > case R2(int i1, int i2) when i1 == 0 -> 2; > case R2(int i1, int i2) -> 3; > .... > > > javac will compile this along these lines: > > case R2 $temp: int $c1 = $temp.i1(); > switch (i1) { > case int i1 when ... > ... > ... > > > The nested switch is a pattern matching switch, and uses `SwitchBootstraps.typeSwitch`, passing the case label types (classes) as static arguments. The problem is that since primitive type patterns have been introduced, `typeSwitch` accepts primitive types as case labels, and javac will use such types in this case. Which works OK on JDK 23+. > > But, on JDK 21 (and 22), `typeSwitch` cannot handle case labels of primitive types correctly, and the matching fails. > > The solution proposed herein is to not use the primitive type case labels when targeting JDK 21 and 22, which makes the behavior similar to what javac did for this code in JDK 21. This pull request has now been integrated. Changeset: 26bb1837 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/26bb18378737809542b1153f8f34d55d409ea4e2 Stats: 181 lines in 3 files changed: 178 ins; 0 del; 3 mod 8352621: MatchException from backwards incompatible change to switch expressions Reviewed-by: abimpoudis ------------- PR: https://git.openjdk.org/jdk/pull/24241 From acobbs at openjdk.org Mon Apr 7 14:39:53 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 7 Apr 2025 14:39:53 GMT Subject: RFR: 8353757: Log class should have a proper clear() method [v3] In-Reply-To: References: Message-ID: > This is a simple refactoring to add a method `Log.clear()`, move `ReusableLog.clear()`'s clearing operations into it and invoke `super.clear()` instead, and add two more fields that should be included in the clear operation but were not because they were added to `Log` after `ReusableLog.clear()` was added and were missed. > > A natural question: Are there any other fields in `Log` that should be cleared in `Log.clear()`? The two I've added (`nsuppressederrors` and `nsuppressedwarns`) are the only two that weren't there when `ReusableLog` as added, so presumably not, but it's possible. Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Reset the DiagnosticHandler stack in clear(). - Revert accidentally included unrelated changes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24460/files - new: https://git.openjdk.org/jdk/pull/24460/files/a1108ac7..a9d58450 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24460&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24460&range=01-02 Stats: 13 lines in 2 files changed: 2 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24460.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24460/head:pull/24460 PR: https://git.openjdk.org/jdk/pull/24460 From acobbs at openjdk.org Mon Apr 7 14:39:55 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 7 Apr 2025 14:39:55 GMT Subject: RFR: 8353757: Log class should have a proper clear() method [v2] In-Reply-To: <4tgepf3KhZC9fgsRY_UvHcqpBMsdDlY0XE_4skIcnME=.8de06b33-25f7-4e03-9734-badb716f1cb0@github.com> References: <4tgepf3KhZC9fgsRY_UvHcqpBMsdDlY0XE_4skIcnME=.8de06b33-25f7-4e03-9734-badb716f1cb0@github.com> Message-ID: On Mon, 7 Apr 2025 08:57:45 GMT, Maurizio Cimadamore wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Invoke Log.useSource() before recursing into attribution. > > src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 364: > >> 362: try { >> 363: Env env = getAttrContext(path.getTreePath()); >> 364: JavaFileObject prevSource = log.useSource(env.toplevel.sourcefile); > > These fixes are independent correct? (I'm ok with them being added here) Oops, you're right - those snuck in from an unrelated change. Fixed in 23447164d. > The thing I'm unsure about is the `diagnosticHandler` field. I suppose we always call "clear" from a context where we already have popped all the installed alternate handlers -- but if not we should reset that too? I was unsure as well. I think it is more correct to reset that field as well, but doing so raises the question: Will that change or break any existing code? In order to gain confidence that it won't, I ran a bunch of tests with this patch applied: --- i/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java +++ w/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java @@ -699,6 +699,7 @@ public void clear() { nwarnings = 0; nsuppressederrors = 0; nsuppressedwarns = 0; + Assert.check(diagnosticHandler.prev == null); } /** and didn't get any crashes. So I think that means it's safe to add this (because for now it's must effectively be a no-op): index e9da2efea9c..2167f471104 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java @@ -699,6 +699,8 @@ public void clear() { nwarnings = 0; nsuppressederrors = 0; nsuppressedwarns = 0; + while (diagnosticHandler.prev != null) + popDiagnosticHandler(diagnosticHandler); } /** This is done in a9d584508. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24460#discussion_r2031388696 PR Review Comment: https://git.openjdk.org/jdk/pull/24460#discussion_r2031388886 From smarks at openjdk.org Mon Apr 7 17:17:57 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 7 Apr 2025 17:17:57 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods In-Reply-To: References: Message-ID: On Sat, 5 Apr 2025 02:31:21 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/IO.java line 122: >> >>> 120: public static void print(Object obj) { >>> 121: System.out.print(obj); >>> 122: System.out.flush(); >> >> Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between? >> >> >> var out = System.out; >> out.print(obj); >> out.flush(); > > This code is not that perf sensitive, guess it is fine as-is I think there's a correctness angle. If you print something to a stream you want to flush the same stream. If System.out is changed in between (unlikely, but possible) then output destined for the old stream could be stranded in its buffer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031674696 From smarks at openjdk.org Mon Apr 7 17:28:52 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 7 Apr 2025 17:28:52 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods In-Reply-To: References: <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com> Message-ID: On Mon, 7 Apr 2025 07:01:56 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/java/lang/IO.java line 183: >> >>> 181: * @return the internal BufferedReader instance >>> 182: */ >>> 183: static synchronized BufferedReader reader() { >> >> Is the lock only inteneded for initialization, i.e. should it apply for simply getting the reader? > > I believe there needs to be some barriers (at least `volatile`) even for getting the already initialized reader. And then, given the code here, it is probably fine and less error prone to simply use `synchronized` that something more complex. > > But, given we'll hopefully have `@StableValue` soon, maybe we could use that? What do you think @stuart-marks? > > Thanks! It's even more complex than `volatile`. If a thread comes along and reads a null here, it still needs to take a lock (or something) to prevent more than one thread from creating the BufferedReader and storing it back into the field. This leads down the path of double-checked locking, initialize-on-demand holder, etc. It's not clear to me this is in such a critical path that it warrants adding any of this stuff. StableValue probably has the right semantics. However, it's not even in the JDK yet (though it is Targeted to 25 as of this moment). But I don't think we want to add a dependency on a Preview API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031689379 From vromero at openjdk.org Mon Apr 7 18:06:05 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 7 Apr 2025 18:06:05 GMT Subject: RFR: 8353757: Log class should have a proper clear() method [v3] In-Reply-To: References: Message-ID: <6PzG20Nh2Ug8tkVo2npq8QSm_XJMW4Cf7ITUEEZiM5s=.75649cb9-ddd1-407e-874c-78a42c4222ad@github.com> On Mon, 7 Apr 2025 14:39:53 GMT, Archie Cobbs wrote: >> This is a simple refactoring to add a method `Log.clear()`, move `ReusableLog.clear()`'s clearing operations into it and invoke `super.clear()` instead, and add two more fields that should be included in the clear operation but were not because they were added to `Log` after `ReusableLog.clear()` was added and were missed. >> >> A natural question: Are there any other fields in `Log` that should be cleared in `Log.clear()`? The two I've added (`nsuppressederrors` and `nsuppressedwarns`) are the only two that weren't there when `ReusableLog` as added, so presumably not, but it's possible. > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Reset the DiagnosticHandler stack in clear(). > - Revert accidentally included unrelated changes. this looks good ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24460#pullrequestreview-2747662139 From smarks at openjdk.org Mon Apr 7 18:13:30 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 7 Apr 2025 18:13:30 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2] In-Reply-To: References: Message-ID: On Sat, 5 Apr 2025 00:55:55 GMT, Luca Kellermann wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Use local variable for System.out in print(). > > src/java.base/share/classes/java/lang/IO.java line 122: > >> 120: public static void print(Object obj) { >> 121: System.out.print(obj); >> 122: System.out.flush(); > > Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between? > > > var out = System.out; > out.print(obj); > out.flush(); Updated as suggested; thanks @lukellmann . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031757221 From jlahoda at openjdk.org Mon Apr 7 18:13:29 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 7 Apr 2025 18:13:29 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2] In-Reply-To: References: Message-ID: > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Use local variable for System.out in print(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24438/files - new: https://git.openjdk.org/jdk/pull/24438/files/a5d223e1..be8846e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24438.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438 PR: https://git.openjdk.org/jdk/pull/24438 From naoto at openjdk.org Mon Apr 7 18:13:30 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 7 Apr 2025 18:13:30 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 18:10:20 GMT, Jan Lahoda wrote: >> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: >> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) >> - `java. ... .IO` is no longer automatically imported in any compilation unit >> - the feature is finalized (i.e. no longer requires `--enable-preview`) > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Use local variable for System.out in print(). test/jdk/java/lang/IO/IO/IO.java line 1: > 1: /* Is there reason to create a test subdirectory `IO` under `java.lang.IO` package? test/jdk/java/lang/IO/IO/IO.java line 53: > 51: /* > 52: * @test > 53: * @bug 8305457 8342936 8351435 Issue id needs to be added (and other test files too) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031735643 PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031750501 From smarks at openjdk.org Mon Apr 7 18:13:29 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 7 Apr 2025 18:13:29 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2] In-Reply-To: References: Message-ID: <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com> On Mon, 7 Apr 2025 09:12:27 GMT, Alan Bateman wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Use local variable for System.out in print(). > > src/java.base/share/classes/java/lang/IO.java line 45: > >> 43: * UTF-8 is used instead. These internal objects are created upon the first call to >> 44: * either of the {@code readln} methods and are stored for subsequent reuse by these >> 45: * methods. > > @stuart-marks Can we rephrase this paragraph so that it doesn't use phrase "internal objects"? The class does speak of buffering and how it might impact code that mixes use of System.in and IO.readln so I agree with that part it's just the "internal objects" phrase that is confusing to read in this class. I used "internal objects" because I wanted to avoid naming concrete classes, which might or might not be used. Previous drafts mentioned BufferedReader, InputStreamReader, and CharsetDecoder. I could replace "internal objects" with something more descriptive like "objects to handle buffering and charset decoding" but I'd still need a noun phrase to refer to them later. Maybe "buffering and decoding objects" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031754279 From smarks at openjdk.org Mon Apr 7 18:38:22 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 7 Apr 2025 18:38:22 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 09:18:37 GMT, Alan Bateman wrote: >> This implementation is not to be emulated by beginners. If an Exception.is thrown here, a user might be tempted to add handlers in their code, while this is an issue with the setup. > > Someone is bound to ask why the readln method throw but the println methods don't. The IOError was carried over from Console.readLine(), which throws IOError on error. Of course we're decoupled from Console now, but that was the original reason. My guess is that Console methods throw IOError because (a) they didn't want to make everybody catch IOException, (b) they didn't want to maintain an internal error state like PrintStream, and (c) they wanted to throw a throwable whose type conveyed the meaning that it wasn't expected to be handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning still applies here. UncheckedIOException wasn't added until JDK 1.8. Note also that UncheckedIOException has a cause of IOException, so it can't arise from some other throwable. This was used in the previous implementation, where IOError was thrown if Console was null. That doesn't apply anymore, but IOError is still somewhat more flexible than UncheckedIOException in this regard. I think we need to say something, implicitly or explicitly, about error handling. Note that PrintStream has this internal error state so output is covered already. For input it seems like IOError is reasonable, but maybe there's a better choice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031782109 From acobbs at openjdk.org Mon Apr 7 19:08:09 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 7 Apr 2025 19:08:09 GMT Subject: RFR: 8353757: Log class should have a proper clear() method [v3] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 14:39:53 GMT, Archie Cobbs wrote: >> This is a simple refactoring to add a method `Log.clear()`, move `ReusableLog.clear()`'s clearing operations into it and invoke `super.clear()` instead, and add two more fields that should be included in the clear operation but were not because they were added to `Log` after `ReusableLog.clear()` was added and were missed. >> >> A natural question: Are there any other fields in `Log` that should be cleared in `Log.clear()`? The two I've added (`nsuppressederrors` and `nsuppressedwarns`) are the only two that weren't there when `ReusableLog` as added, so presumably not, but it's possible. > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Reset the DiagnosticHandler stack in clear(). > - Revert accidentally included unrelated changes. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24460#issuecomment-2784294029 From vromero at openjdk.org Mon Apr 7 19:20:22 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 7 Apr 2025 19:20:22 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2] In-Reply-To: References: Message-ID: <6w1YXrCnHGH5VifP_2jWinbKd0sGMlUeR1KOC8FJWXg=.af36af50-a7e7-4e76-9470-6a89bf58cf3e@github.com> On Mon, 7 Apr 2025 18:13:29 GMT, Jan Lahoda wrote: >> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: >> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) >> - `java. ... .IO` is no longer automatically imported in any compilation unit >> - the feature is finalized (i.e. no longer requires `--enable-preview`) > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Use local variable for System.out in print(). javac compiler related code and tests lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2747868909 From liach at openjdk.org Mon Apr 7 19:25:19 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Apr 2025 19:25:19 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2] In-Reply-To: <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com> References: <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com> Message-ID: <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com> On Mon, 7 Apr 2025 18:08:29 GMT, Stuart Marks wrote: >> src/java.base/share/classes/java/lang/IO.java line 45: >> >>> 43: * UTF-8 is used instead. These internal objects are created upon the first call to >>> 44: * either of the {@code readln} methods and are stored for subsequent reuse by these >>> 45: * methods. >> >> @stuart-marks Can we rephrase this paragraph so that it doesn't use phrase "internal objects"? The class does speak of buffering and how it might impact code that mixes use of System.in and IO.readln so I agree with that part it's just the "internal objects" phrase that is confusing to read in this class. > > I used "internal objects" because I wanted to avoid naming concrete classes, which might or might not be used. Previous drafts mentioned BufferedReader, InputStreamReader, and CharsetDecoder. > > I could replace "internal objects" with something more descriptive like "objects to handle buffering and charset decoding" but I'd still need a noun phrase to refer to them later. Maybe "buffering and decoding objects" ? Can we rephrase the 1st sentence to read: "The `readln()` and `readln(String)` methods in this class decode bytes read from `System.in` into characters." And remove the last "these internal objects" sentence. And for the next paragraph, change the first line to: "The `readln` methods may buffer additional bytes..." So we remove references to "internal objects." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031815564 From smarks at openjdk.org Mon Apr 7 19:47:21 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 7 Apr 2025 19:47:21 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2] In-Reply-To: <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com> References: <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com> <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com> Message-ID: On Mon, 7 Apr 2025 18:49:33 GMT, Chen Liang wrote: >> I used "internal objects" because I wanted to avoid naming concrete classes, which might or might not be used. Previous drafts mentioned BufferedReader, InputStreamReader, and CharsetDecoder. >> >> I could replace "internal objects" with something more descriptive like "objects to handle buffering and charset decoding" but I'd still need a noun phrase to refer to them later. Maybe "buffering and decoding objects" ? > > Can we rephrase the 1st sentence to read: > "The `readln()` and `readln(String)` methods in this class decode bytes read from `System.in` into characters." > > And remove the last "these internal objects" sentence. > > And for the next paragraph, change the first line to: > "The `readln` methods may buffer additional bytes..." > > So we remove references to "internal objects." I'm in the midst of rewriting all of this stuff. The main concern here is that applications can use System.in more or less as they please (presumably without buffering) _until_ the first call to a `readln` method, at which time _something happens_ and effectively the application cannot use System.in anymore. I'll post the revision when I've finished it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2031907101 From jlahoda at openjdk.org Mon Apr 7 21:07:36 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 7 Apr 2025 21:07:36 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v3] In-Reply-To: References: Message-ID: > This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in any compilation unit > - the feature is finalized (i.e. no longer requires `--enable-preview`) Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Rewrite bits about charset decoding, removing mention of "internal objects." ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24438/files - new: https://git.openjdk.org/jdk/pull/24438/files/be8846e0..33e280df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=01-02 Stats: 27 lines in 1 file changed: 11 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/24438.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438 PR: https://git.openjdk.org/jdk/pull/24438 From smarks at openjdk.org Mon Apr 7 21:07:36 2025 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 7 Apr 2025 21:07:36 GMT Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v3] In-Reply-To: References: <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com> <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com> Message-ID: On Mon, 7 Apr 2025 19:44:40 GMT, Stuart Marks wrote: >> Can we rephrase the 1st sentence to read: >> "The `readln()` and `readln(String)` methods in this class decode bytes read from `System.in` into characters." >> >> And remove the last "these internal objects" sentence. >> >> And for the next paragraph, change the first line to: >> "The `readln` methods may buffer additional bytes..." >> >> So we remove references to "internal objects." > > I'm in the midst of rewriting all of this stuff. The main concern here is that applications can use System.in more or less as they please (presumably without buffering) _until_ the first call to a `readln` method, at which time _something happens_ and effectively the application cannot use System.in anymore. I'll post the revision when I've finished it. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2032003160 From mcimadamore at openjdk.org Mon Apr 7 21:23:12 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Apr 2025 21:23:12 GMT Subject: RFR: 8353757: Log class should have a proper clear() method [v3] In-Reply-To: References: Message-ID: <8X4LGDXH0vCW03_48niUsiDMlhG-sGTedzV2IHEebGA=.4fa9f11c-c9c2-4fd5-9d8c-68def465df22@github.com> On Mon, 7 Apr 2025 14:39:53 GMT, Archie Cobbs wrote: >> This is a simple refactoring to add a method `Log.clear()`, move `ReusableLog.clear()`'s clearing operations into it and invoke `super.clear()` instead, and add two more fields that should be included in the clear operation but were not because they were added to `Log` after `ReusableLog.clear()` was added and were missed. >> >> A natural question: Are there any other fields in `Log` that should be cleared in `Log.clear()`? The two I've added (`nsuppressederrors` and `nsuppressedwarns`) are the only two that weren't there when `ReusableLog` as added, so presumably not, but it's possible. > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Reset the DiagnosticHandler stack in clear(). > - Revert accidentally included unrelated changes. Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24460#pullrequestreview-2748140624 From liach at openjdk.org Mon Apr 7 21:28:39 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Apr 2025 21:28:39 GMT Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API Message-ID: Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile. Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews. Together with #24206, the old com.sun.tools.classfile can be removed from the JDK. ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols - Other references to remove - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols - FieldDescription.constantValue uses Integer for byte and short - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API Changes: https://git.openjdk.org/jdk/pull/24212/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24212&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310310 Stats: 1057 lines in 5 files changed: 42 ins; 696 del; 319 mod Patch: https://git.openjdk.org/jdk/pull/24212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24212/head:pull/24212 PR: https://git.openjdk.org/jdk/pull/24212 From liach at openjdk.org Mon Apr 7 21:58:10 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Apr 2025 21:58:10 GMT Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang wrote: > Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile. > > Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews. > > Together with #24206, the old com.sun.tools.classfile can be removed from the JDK. No worries - we will delete the whole com.sun.tools.classfile package, which will be another 10k+ lines removed ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2784718454 From acobbs at openjdk.org Mon Apr 7 21:58:09 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 7 Apr 2025 21:58:09 GMT Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang wrote: > Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile. > > Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews. > > Together with #24206, the old com.sun.tools.classfile can be removed from the JDK. Refactoring awesomeness ratio: 1011 deletions 357 additions RAR: 2.83 Impressive :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2784715392 From liach at openjdk.org Mon Apr 7 22:13:10 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Apr 2025 22:13:10 GMT Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang wrote: > Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile. > > Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews. > > Together with #24206, the old com.sun.tools.classfile can be removed from the JDK. @nizarbenalla Can you help run CreateSymbols from this patch and compare the results with baseline? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2784744589 From josiahnoel at gmail.com Tue Apr 8 02:12:16 2025 From: josiahnoel at gmail.com (Josiah Noel) Date: Mon, 7 Apr 2025 22:12:16 -0400 Subject: Cannot find symbol when using the current module as an import Message-ID: Hey team, So I tried to modify some annotation processors to use the current module as an import to see if I could reduce the number of imports I have to generate. Unfortunately, it looks like when I use the current module as an import, it can't read the imports of its dependencies. Suppose I have: module example { requires com.fasterxml.jackson.databind; } And I try: > import module example; > class Example { void main() { var mapper = new ObjectMapper(); //Cannot find symbol } } It fails to import the object mapper class. -- Cheers, Josiah. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Apr 8 06:24:36 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 8 Apr 2025 08:24:36 +0200 (CEST) Subject: Cannot find symbol when using the current module as an import In-Reply-To: References: Message-ID: <1787404324.214514290.1744093476180.JavaMail.zimbra@univ-eiffel.fr> > From: "Josiah Noel" > To: "compiler-dev" > Sent: Tuesday, April 8, 2025 4:12:16 AM > Subject: Cannot find symbol when using the current module as an import > Hey team, > So I tried to modify some annotation processors to use the current module as an > import to see if I could reduce the number of imports I have to generate. > Unfortunately, it looks like when I use the current module as an import, it > can't read the imports of its dependencies. > Suppose I have: >> module example { >> requires com.fasterxml.jackson.databind; >> } > And I try: >> import module example; >> class Example { >> void main() { >> var mapper = new ObjectMapper(); //Cannot find symbol >> } >> } > It fails to import the object mapper class. Hello, the require inside the module example should be a require transitive. Now, please beware of import module, like an import *, those means that the list of types you are importing is unbounded and may change in the future (for example, if the module of jackson is updated), so your class Example may fail to compile in the future. import module is nice for demos or for beginners, but if you have an import module in your code, updating a dependency becomes a source incompatible change, that why most company have a policy against import *, and i suppose this policy will be updated soon to include import module, which is a kind of import * on steroid. > -- > Cheers, Josiah. regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Apr 8 08:26:23 2025 From: duke at openjdk.org (Danish Nawab) Date: Tue, 8 Apr 2025 08:26:23 GMT Subject: RFR: 8353840: jnativescan should not throw error for missing system classes Message-ID: ## Description https://bugs.openjdk.org/browse/JDK-8353840 ### Existing behavior Log the error message and terminate in case of missing system class ### New behavior Still log the error message about the missing system class, but continue the analysis ## Design choices Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis ### Alternatives considered - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`. - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver` - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful ### stdout vs stderr One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed. ## Testing The existing test `TestMissingSystemClass#testSingleJarClassPath` has been adapted to test for successful execution, as well as verify the stdout output. I considered briefly to update the test setup in a way that we see some restricted methods on the stdout instead of just ``, but it was unclear if that would really add any additional value since the main purpose of this test is just to ascertain the missing system class (with successful execution from now onward). ------------- Commit messages: - 8353840: jnativescan should not throw error for missing system classes Changes: https://git.openjdk.org/jdk/pull/24499/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353840 Stats: 17 lines in 4 files changed: 6 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/24499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24499/head:pull/24499 PR: https://git.openjdk.org/jdk/pull/24499 From jpai at openjdk.org Tue Apr 8 09:25:13 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Apr 2025 09:25:13 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance [v2] In-Reply-To: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com> References: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com> Message-ID: On Tue, 1 Apr 2025 00:59:57 GMT, Jason Zaugg wrote: >> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance > > Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: > > 8352642: Also pass zipinfo-time to the alternative newFileSystem call src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 581: > 579: // Less common case is possible if the file manager was not initialized in JavacTask, > 580: // or if non "*.jar" files are on the classpath. At the time of writing, both `javac -cp a.zip` > 581: // and `javac -cp x.JAR` file would hit this branch which may warrant investigation. Hello Jason, do we need that second sentence to be added as a code comment? I feel it creates confusion on what's expected to be done. Perhaps just add that first sentence and remove the second? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2032773634 From jpai at openjdk.org Tue Apr 8 09:25:13 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Apr 2025 09:25:13 GMT Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance [v2] In-Reply-To: References: <8UqLlWwRDd27THNn3oXl2n3LNc6UODiKoPYJa7p3S_0=.c38e4afe-2823-4ffe-9557-01295137930f@github.com> Message-ID: <4YJv_Epumc0H6kV6HXamzgbBGQ4rqsgLF6_x3Zgs1OU=.4ae39a90-887e-4c6b-a95c-d29727848336@github.com> On Tue, 8 Apr 2025 09:21:50 GMT, Jaikiran Pai wrote: >> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision: >> >> 8352642: Also pass zipinfo-time to the alternative newFileSystem call > > src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 581: > >> 579: // Less common case is possible if the file manager was not initialized in JavacTask, >> 580: // or if non "*.jar" files are on the classpath. At the time of writing, both `javac -cp a.zip` >> 581: // and `javac -cp x.JAR` file would hit this branch which may warrant investigation. > > Hello Jason, do we need that second sentence to be added as a code comment? I feel it creates confusion on what's expected to be done. Perhaps just add that first sentence and remove the second? Could you also update the copyright year on this file from 2024 to 2025? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2032774982 From mcimadamore at openjdk.org Tue Apr 8 11:36:36 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Apr 2025 11:36:36 GMT Subject: RFR: 8344703: Compiler Implementation for Flexible Constructor Bodies Message-ID: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com> This PR finalizes the Flexible Constructor Bodies feature with no semantics changes. The main changes in this PR have to do with the various tests, which needed tweaking (e.g. to drop `@enablePreview` and fix corresponding golden files). We might, later on, incorporate a fix for [this issue](https://bugs.openjdk.org/browse/JDK-8349754) into this PR, depending on where the specification for this feature lands. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk/pull/24505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24505&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344703 Stats: 137 lines in 39 files changed: 1 ins; 39 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/24505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24505/head:pull/24505 PR: https://git.openjdk.org/jdk/pull/24505 From mcimadamore at openjdk.org Tue Apr 8 11:36:37 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Apr 2025 11:36:37 GMT Subject: RFR: 8344703: Compiler Implementation for Flexible Constructor Bodies In-Reply-To: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com> References: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com> Message-ID: On Tue, 8 Apr 2025 11:24:46 GMT, Maurizio Cimadamore wrote: > This PR finalizes the Flexible Constructor Bodies feature with no semantics changes. > The main changes in this PR have to do with the various tests, which needed tweaking (e.g. to drop `@enablePreview` and fix corresponding golden files). > > We might, later on, incorporate a fix for [this issue](https://bugs.openjdk.org/browse/JDK-8349754) into this PR, depending on where the specification for this feature lands. test/langtools/tools/javac/diags/examples/PreviewFeatureUse.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. I did a bit of reshuffling here -- we had a single diagnostic test called `PreviewFeatureUse` which was only testing the `warn.preview.feature.use.plural` diagnostic. As a consequence, when I changed flexible constructor bodies to no longer be a preview feature, I started getting failures in `CheckExamples` because there was no test covering `warn.preview.feature.use` (e.g. w/o the trailing `.plural`). So I've added a test for both diagnostics (and renamed the old one to `PreviewFeatureUsePlural`). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24505#discussion_r2032992109 From jvernee at openjdk.org Tue Apr 8 11:52:22 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Apr 2025 11:52:22 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab wrote: > ## Description > > https://bugs.openjdk.org/browse/JDK-8353840 > > ### Existing behavior > Log the error message and terminate in case of missing system class > > > $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" > > ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String > CAUSED BY: System class can not be found: sun.misc.JavaLangAccess > Exit code: 1 > > > ### New behavior > Still log the error message about the missing system class, but continue the analysis > > > $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" > > > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets > Exit code: 0 > > > ## Design choices > > Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis > > ### Alternatives considered > > - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`. > - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception > - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver` > - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful > > ### stdout vs stderr > > One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed. > > ## Testing > > The existing test `TestMissingSystemClass#testSingleJarClassPath` has ... I've updated the issue title to start with a capital letter. Also, note that there was some other cleanup I wanted to do in this area first: https://github.com/openjdk/jdk/pull/24493 which will likely result in merge conflicts. src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 91: > 89: err.println("Error while processing method: " + > 90: MethodRef.ofModel(methodModel) + ": " + e.getMessage()); > 91: } This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to `isRestricted`, which can fail. Then we can record the error and keep iterating over the other instructions. ------------- Changes requested by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24499#pullrequestreview-2749671492 PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2786176663 PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033007295 From jvernee at openjdk.org Tue Apr 8 11:52:23 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Apr 2025 11:52:23 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes In-Reply-To: References: Message-ID: <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com> On Tue, 8 Apr 2025 11:41:15 GMT, Jorn Vernee wrote: >> ## Description >> >> https://bugs.openjdk.org/browse/JDK-8353840 >> >> ### Existing behavior >> Log the error message and terminate in case of missing system class >> >> >> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" >> >> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String >> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess >> Exit code: 1 >> >> >> ### New behavior >> Still log the error message about the missing system class, but continue the analysis >> >> >> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" >> >> >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets >> Exit code: 0 >> >> >> ## Design choices >> >> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis >> >> ### Alternatives considered >> >> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`. >> - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception >> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver` >> - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful >> >> ### stdout vs stderr >> >> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.... > > src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 91: > >> 89: err.println("Error while processing method: " + >> 90: MethodRef.ofModel(methodModel) + ": " + e.getMessage()); >> 91: } > > This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to `isRestricted`, which can fail. Then we can record the error and keep iterating over the other instructions. Also, instead of passing `err` down to this code, I think we should define an interface for `NativeMethodFinder` to log diagnostics instead. e.g. something like: interface Diagnostics { void error(MethodRef context, JNativeScanFatalError error); } `JNativeScanTask` can then define the implementation how it wants. The benefit of that is that we have more freedom to print the errors how we want. For instance, I think we should first collect all the errors, and de-duplicate error messages before printing them, so that if there are 10 references to the same system class, we only print the error message once, and we can print a header like: `Errors while processing classes: ...` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033014629 From duke at openjdk.org Tue Apr 8 11:58:15 2025 From: duke at openjdk.org (Danish Nawab) Date: Tue, 8 Apr 2025 11:58:15 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes In-Reply-To: <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com> References: <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com> Message-ID: On Tue, 8 Apr 2025 11:45:49 GMT, Jorn Vernee wrote: >> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java line 91: >> >>> 89: err.println("Error while processing method: " + >>> 90: MethodRef.ofModel(methodModel) + ": " + e.getMessage()); >>> 91: } >> >> This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to `isRestricted`, which can fail. Then we can record the error and keep iterating over the other instructions. > > Also, instead of passing `err` down to this code, I think we should define an interface for `NativeMethodFinder` to log diagnostics instead. e.g. something like: > > > interface Diagnostics { > void error(MethodRef context, JNativeScanFatalError error); > } > > > `JNativeScanTask` can then define the implementation how it wants. The benefit of that is that we have more freedom to print the errors how we want. For instance, I think we should first collect all the errors, and de-duplicate error messages before printing them, so that if there are 10 references to the same system class, we only print the error message once, and we can print a header like: `Errors while processing classes: ...` > This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to isRestricted, which can fail. Then we can record the error and keep iterating over the other instructions. That makes a lot of sense. I will update it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033030209 From duke at openjdk.org Tue Apr 8 12:03:20 2025 From: duke at openjdk.org (Danish Nawab) Date: Tue, 8 Apr 2025 12:03:20 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes In-Reply-To: References: <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com> Message-ID: On Tue, 8 Apr 2025 11:55:58 GMT, Danish Nawab wrote: >> Also, instead of passing `err` down to this code, I think we should define an interface for `NativeMethodFinder` to log diagnostics instead. e.g. something like: >> >> >> interface Diagnostics { >> void error(MethodRef context, JNativeScanFatalError error); >> } >> >> >> `JNativeScanTask` can then define the implementation how it wants. The benefit of that is that we have more freedom to print the errors how we want. For instance, I think we should first collect all the errors, and de-duplicate error messages before printing them, so that if there are 10 references to the same system class, we only print the error message once, and we can print a header like: `Errors while processing classes: ...` > >> This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to isRestricted, which can fail. Then we can record the error and keep iterating over the other instructions. > > That makes a lot of sense. I will update it. > Also, instead of passing err down to this code, I think we should define an interface for NativeMethodFinder to log diagnostics instead. e.g. something like: This makes sense. I can update it, accordingly. Regarding deduplication: this means we would need to buffer the errors and print them all at the end, which would require coordination between different layers, and we might need to mark `Diagnostics` as `Closable/AutoClosable`. Would it be ok for you, if the buffering/deduplication can be done a follow-up and for now we just change the termination behavior? Or do you see that as an essential component that should be included with this change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033037953 From jvernee at openjdk.org Tue Apr 8 12:16:13 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Apr 2025 12:16:13 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes In-Reply-To: References: <-DMpfwwW1NzmpeOJuZJcgiv_Vhu-IvEMtt0tmvXLeJ0=.a8f6bedf-a293-4fef-b046-709ab46781f5@github.com> Message-ID: On Tue, 8 Apr 2025 12:00:41 GMT, Danish Nawab wrote: >>> This catch block is per-method. It means that if the rest of the method contained references to restricted methods, we would not see them. The catch block should be moved to be just around the call to isRestricted, which can fail. Then we can record the error and keep iterating over the other instructions. >> >> That makes a lot of sense. I will update it. > >> Also, instead of passing err down to this code, I think we should define an interface for NativeMethodFinder to log diagnostics instead. e.g. something like: > > This makes sense. I can update it, accordingly. > Regarding deduplication: this means we would need to buffer the errors and print them all at the end, which would require coordination between different layers, and we might need to mark `Diagnostics` as `Closable/AutoClosable`. > Would it be ok for you, if the buffering/deduplication can be done a follow-up and for now we just change the termination behavior? Or do you see that as an essential component that should be included with this change? The buffering shouldn't be hard to achieve? `JNativeScanTask::run` can just define a `Set` to which the error messages are added by the diagnostics callback. I don't see why `Diagnostics` would need to be `AutoCloseable`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033053788 From jvernee at openjdk.org Tue Apr 8 12:16:12 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Apr 2025 12:16:12 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes In-Reply-To: References: Message-ID: <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com> On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab wrote: > ## Description > > https://bugs.openjdk.org/browse/JDK-8353840 > > ### Existing behavior > Log the error message and terminate in case of missing system class > > > $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" > > ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String > CAUSED BY: System class can not be found: sun.misc.JavaLangAccess > Exit code: 1 > > > ### New behavior > Still log the error message about the missing system class, but continue the analysis > > > $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" > > > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets > Exit code: 0 > > > ## Design choices > > Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis > > ### Alternatives considered > > - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`. > - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception > - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver` > - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful > > ### stdout vs stderr > > One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed. > > ## Testing > > The existing test `TestMissingSystemClass#testSingleJarClassPath` has ... src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 79: > 77: try(ClassResolver classesToScan = ClassResolver.forClassFileSources(toScan, version); > 78: ClassResolver systemClassResolver = ClassResolver.forSystemModules(version)) { > 79: NativeMethodFinder finder = NativeMethodFinder.create(err, classesToScan, systemClassResolver); e.g. Suggestion: Set errors = new HashSet<>(); // print these at the end Diagnostics diagnostics = (context, error) -> errors.add("Error while processing " + context + ": " + error.getMessage(); NativeMethodFinder finder = NativeMethodFinder.create(diagnostics, classesToScan, systemClassResolver); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033057140 From duke at openjdk.org Tue Apr 8 12:22:18 2025 From: duke at openjdk.org (Danish Nawab) Date: Tue, 8 Apr 2025 12:22:18 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes In-Reply-To: <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com> References: <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com> Message-ID: On Tue, 8 Apr 2025 12:12:36 GMT, Jorn Vernee wrote: >> ## Description >> >> https://bugs.openjdk.org/browse/JDK-8353840 >> >> ### Existing behavior >> Log the error message and terminate in case of missing system class >> >> >> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" >> >> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String >> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess >> Exit code: 1 >> >> >> ### New behavior >> Still log the error message about the missing system class, but continue the analysis >> >> >> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" >> >> >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets >> Exit code: 0 >> >> >> ## Design choices >> >> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis >> >> ### Alternatives considered >> >> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`. >> - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception >> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver` >> - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful >> >> ### stdout vs stderr >> >> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.... > > src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 79: > >> 77: try(ClassResolver classesToScan = ClassResolver.forClassFileSources(toScan, version); >> 78: ClassResolver systemClassResolver = ClassResolver.forSystemModules(version)) { >> 79: NativeMethodFinder finder = NativeMethodFinder.create(err, classesToScan, systemClassResolver); > > e.g. > Suggestion: > > Set errors = new HashSet<>(); // print these at the end > Diagnostics diagnostics = (context, error) -> errors.add("Error while processing " + context + ": " + error.getMessage(); > NativeMethodFinder finder = NativeMethodFinder.create(diagnostics, classesToScan, systemClassResolver); I see what you mean. Let me take a crack at it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033070392 From jvernee at openjdk.org Tue Apr 8 12:25:20 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Apr 2025 12:25:20 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes In-Reply-To: References: <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com> Message-ID: <78kxMPeSeRBvpSxwEkYUiNxoz3lVeCSVUfNg1o1UROo=.c6866396-2762-41a2-ad00-c66f1eac066a@github.com> On Tue, 8 Apr 2025 12:20:02 GMT, Danish Nawab wrote: >> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 79: >> >>> 77: try(ClassResolver classesToScan = ClassResolver.forClassFileSources(toScan, version); >>> 78: ClassResolver systemClassResolver = ClassResolver.forSystemModules(version)) { >>> 79: NativeMethodFinder finder = NativeMethodFinder.create(err, classesToScan, systemClassResolver); >> >> e.g. >> Suggestion: >> >> Set errors = new HashSet<>(); // print these at the end >> Diagnostics diagnostics = (context, error) -> errors.add("Error while processing " + context + ": " + error.getMessage(); >> NativeMethodFinder finder = NativeMethodFinder.create(diagnostics, classesToScan, systemClassResolver); > > I see what you mean. Let me take a crack at it. One more though: I think we should only print the error messages as part of `dumpAll` and not `printNativeAccess`, so that the result of the latter can still be piped directly to `--enable-native-access`, even if there are errors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033074737 From nbenalla at openjdk.org Tue Apr 8 13:08:24 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 8 Apr 2025 13:08:24 GMT Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang wrote: > Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile. > > Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews. > > Together with #24206, the old com.sun.tools.classfile can be removed from the JDK. I compared the results with baseline a few times and they seem identical. I checked out the JDK repo at an earlier point and followed the same steps I used to create https://github.com/openjdk/jdk/pull/22867 and the result was identical. Great work! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2786377026 From duke at openjdk.org Tue Apr 8 13:47:09 2025 From: duke at openjdk.org (Danish Nawab) Date: Tue, 8 Apr 2025 13:47:09 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes [v2] In-Reply-To: References: Message-ID: > ## Description > > https://bugs.openjdk.org/browse/JDK-8353840 > > ### Existing behavior > Log the error message and terminate in case of missing system class > > > $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" > > ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String > CAUSED BY: System class can not be found: sun.misc.JavaLangAccess > Exit code: 1 > > > ### New behavior > Still log the error message about the missing system class, but continue the analysis > > > $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" > > > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets > Exit code: 0 > > > ## Design choices > > Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis > > ### Alternatives considered > > - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`. > - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception > - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver` > - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful > > ### stdout vs stderr > > One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed. > > ## Testing > > The existing test `TestMissingSystemClass#testSingleJarClassPath` has ... Danish Nawab has updated the pull request incrementally with one additional commit since the last revision: 8353840: improve error logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24499/files - new: https://git.openjdk.org/jdk/pull/24499/files/e658c466..3aaef9d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=00-01 Stats: 48 lines in 4 files changed: 20 ins; 2 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/24499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24499/head:pull/24499 PR: https://git.openjdk.org/jdk/pull/24499 From duke at openjdk.org Tue Apr 8 13:47:10 2025 From: duke at openjdk.org (Danish Nawab) Date: Tue, 8 Apr 2025 13:47:10 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes [v2] In-Reply-To: <78kxMPeSeRBvpSxwEkYUiNxoz3lVeCSVUfNg1o1UROo=.c6866396-2762-41a2-ad00-c66f1eac066a@github.com> References: <2vIyofGtkgiJZ_5CV-HowmoAWhbxmHDhzTlLXe7wCFE=.de31d29a-7218-4098-886b-aa2c787f6827@github.com> <78kxMPeSeRBvpSxwEkYUiNxoz3lVeCSVUfNg1o1UROo=.c6866396-2762-41a2-ad00-c66f1eac066a@github.com> Message-ID: On Tue, 8 Apr 2025 12:22:40 GMT, Jorn Vernee wrote: >> I see what you mean. Let me take a crack at it. > > One more thought: I think we should only print the error messages as part of `dumpAll` and not `printNativeAccess`, so that the result of the latter can still be piped directly to `--enable-native-access`, even if there are errors. @JornVernee updated in 3aaef9d4ee3b5e8208c66ed5e3096d1afc6d5dc1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033224439 From duke at openjdk.org Tue Apr 8 13:47:12 2025 From: duke at openjdk.org (Danish Nawab) Date: Tue, 8 Apr 2025 13:47:12 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes [v2] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 13:43:54 GMT, Danish Nawab wrote: >> ## Description >> >> https://bugs.openjdk.org/browse/JDK-8353840 >> >> ### Existing behavior >> Log the error message and terminate in case of missing system class >> >> >> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" >> >> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String >> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess >> Exit code: 1 >> >> >> ### New behavior >> Still log the error message about the missing system class, but continue the analysis >> >> >> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" >> >> >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets >> Exit code: 0 >> >> >> ## Design choices >> >> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis >> >> ### Alternatives considered >> >> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`. >> - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception >> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver` >> - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful >> >> ### stdout vs stderr >> >> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.... > > Danish Nawab has updated the pull request incrementally with one additional commit since the last revision: > > 8353840: improve error logging src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 205: > 203: } > 204: > 205: interface Diagnostics { Added as an inner type since there was already precedence for that with `com.sun.tools.jnativescan.JNativeScanTask.Action` test/langtools/tools/jnativescan/TestMissingSystemClass.java line 64: > 62: .stderrAsLines(); > 63: > 64: assertEquals(2, stderr.size(), "Unexpected number of lines in stderr"); To ensure that the two calls to `java.lang.Compiler.enable` have been de-duped into one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033227648 PR Review Comment: https://git.openjdk.org/jdk/pull/24499#discussion_r2033225623 From duke at openjdk.org Tue Apr 8 13:51:59 2025 From: duke at openjdk.org (Danish Nawab) Date: Tue, 8 Apr 2025 13:51:59 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes [v3] In-Reply-To: References: Message-ID: > ## Description > > https://bugs.openjdk.org/browse/JDK-8353840 > > ### Existing behavior > Log the error message and terminate in case of missing system class > > > $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" > > ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String > CAUSED BY: System class can not be found: sun.misc.JavaLangAccess > Exit code: 1 > > > ### New behavior > Still log the error message about the missing system class, but continue the analysis > > > $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" > > > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets > Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets > Exit code: 0 > > > ## Design choices > > Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis > > ### Alternatives considered > > - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`. > - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception > - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver` > - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful > > ### stdout vs stderr > > One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed. > > ## Testing > > The existing test `TestMissingSystemClass#testSingleJarClassPath` has ... Danish Nawab has updated the pull request incrementally with one additional commit since the last revision: 8353840: remove unnecessary final ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24499/files - new: https://git.openjdk.org/jdk/pull/24499/files/3aaef9d4..1de3feca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24499/head:pull/24499 PR: https://git.openjdk.org/jdk/pull/24499 From jvernee at openjdk.org Tue Apr 8 14:22:21 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Apr 2025 14:22:21 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes [v3] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 13:51:59 GMT, Danish Nawab wrote: >> ## Description >> >> https://bugs.openjdk.org/browse/JDK-8353840 >> >> ### Existing behavior >> Log the error message and terminate in case of missing system class >> >> >> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" >> >> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String >> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess >> Exit code: 1 >> >> >> ### New behavior >> Still log the error message about the missing system class, but continue the analysis >> >> >> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" >> >> >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets >> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets >> Exit code: 0 >> >> >> ## Design choices >> >> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis >> >> ### Alternatives considered >> >> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`. >> - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception >> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver` >> - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful >> >> ### stdout vs stderr >> >> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.... > > Danish Nawab has updated the pull request incrementally with one additional commit since the last revision: > > 8353840: remove unnecessary final Changes look good, thanks! Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well. ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24499#pullrequestreview-2750176260 From duke at openjdk.org Tue Apr 8 14:28:11 2025 From: duke at openjdk.org (Danish Nawab) Date: Tue, 8 Apr 2025 14:28:11 GMT Subject: RFR: 8353840: JNativeScan should not throw error for missing system classes [v3] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 14:19:07 GMT, Jorn Vernee wrote: > Changes look good, thanks! > > Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well. Great, thanks for your review! I will wait until tomorrow to issue the `/integrate` (as instructed by openjdk[bot]). Since I am not an OpenJDK committer, I will request you to please sponsor it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2786635915 From vromero at openjdk.org Tue Apr 8 14:51:19 2025 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 8 Apr 2025 14:51:19 GMT Subject: RFR: 8344703: Compiler Implementation for Flexible Constructor Bodies In-Reply-To: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com> References: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com> Message-ID: <7wd89DDMzp6slrNz-FRaN0mLoQkTZwMN2YKXXyKTHrQ=.9a2b46f0-9578-4624-a168-ee853c99c0c0@github.com> On Tue, 8 Apr 2025 11:24:46 GMT, Maurizio Cimadamore wrote: > This PR finalizes the Flexible Constructor Bodies feature with no semantics changes. > The main changes in this PR have to do with the various tests, which needed tweaking (e.g. to drop `@enablePreview` and fix corresponding golden files). > > We might, later on, incorporate a fix for [this issue](https://bugs.openjdk.org/browse/JDK-8349754) into this PR, depending on where the specification for this feature lands. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24505#pullrequestreview-2750289488 From jlahoda at openjdk.org Tue Apr 8 14:59:14 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 8 Apr 2025 14:59:14 GMT Subject: RFR: 8350212: Track source end positions of declarations that support @SuppressWarnings [v3] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 21:42:35 GMT, Archie Cobbs wrote: >> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. >> >> Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available. >> >> The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons. >> >> Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add missing variable decl end position. The new calls to `storeEnd` seem to partly duplicate existing `to`/`toP` calls. That feels a bit unfortunate - as we may be adding new places that create AST node for declarations, and one sometimes forgets to do `to`/`toP` - and forgetting `storeEnd` might lead to weird problems. I tried to re-write this part by putting the the set logic directly into the end pos tables here: https://github.com/archiecobbs/jdk/compare/JDK-8350212...lahodaj:jdk:JDK-8350212?expand=1 Notes: - I believe the fact that implictly declared classes don't have an end position was intentional at that time. I don't have an issue with changing that, just pointing it out. - for blocks, `endpos` is actually pointing at the start of the closing brace, not the end (I think, at least). So, I've renamed the field, but kept the semantics. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2786735601 From jlahoda at openjdk.org Tue Apr 8 15:02:32 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 8 Apr 2025 15:02:32 GMT Subject: RFR: 8344703: Compiler Implementation for Flexible Constructor Bodies In-Reply-To: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com> References: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com> Message-ID: <3cQpQbCqXsedAlJr92XZD-0Y7hgp0wCmtWecHClbYlk=.e4c3624d-e9ed-425b-b7fe-89e2a0f45108@github.com> On Tue, 8 Apr 2025 11:24:46 GMT, Maurizio Cimadamore wrote: > This PR finalizes the Flexible Constructor Bodies feature with no semantics changes. > The main changes in this PR have to do with the various tests, which needed tweaking (e.g. to drop `@enablePreview` and fix corresponding golden files). > > We might, later on, incorporate a fix for [this issue](https://bugs.openjdk.org/browse/JDK-8349754) into this PR, depending on where the specification for this feature lands. Looks good to me! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24505#pullrequestreview-2750328215 From acobbs at openjdk.org Tue Apr 8 15:40:25 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 8 Apr 2025 15:40:25 GMT Subject: RFR: 8350212: Track source end positions of declarations that support @SuppressWarnings [v3] In-Reply-To: References: Message-ID: <5Ggk9W_vLrMRqGdA4rmPuGvLdAnxTqVkvgvEDHWNUNg=.503bffdb-2829-4100-a524-d801f1810de1@github.com> On Tue, 8 Apr 2025 14:56:41 GMT, Jan Lahoda wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing variable decl end position. > > The new calls to `storeEnd` seem to partly duplicate existing `to`/`toP` calls. That feels a bit unfortunate - as we may be adding new places that create AST node for declarations, and one sometimes forgets to do `to`/`toP` - and forgetting `storeEnd` might lead to weird problems. > > I tried to re-write this part by putting the the set logic directly into the end pos tables here: > https://github.com/archiecobbs/jdk/compare/JDK-8350212...lahodaj:jdk:JDK-8350212?expand=1 > > Notes: > - I believe the fact that implictly declared classes don't have an end position was intentional at that time. I don't have an issue with changing that, just pointing it out. > - for blocks, `endpos` is actually pointing at the start of the closing brace, not the end (I think, at least). So, I've renamed the field, but kept the semantics. > > What do you think? Hi @lahodaj, Maurizio's comments got me looking into this more and I came to the same realizations... the `storeEnd()` calls are just doing the same thing as `to()` and `toP()` so they can be cleaned up. I also like his idea of making them fluent (and btw `attach()` can also be fluent). Finally, I agree that his idea of replacing `EmptyEndPosTable` with `MinimalEndPosTable` and not adding the duplicate, one-off `endPos` fields is also cleaner. So I'm working on a refactoring that will include the above ideas. I'll have an update soon. Thanks for clarifying the difference between `endPos` and `bracePos` - it's been causing me confusing test failures. I think that's the one "one-off" field we'll probably need to keep. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2786862657 From liach at openjdk.org Tue Apr 8 17:26:23 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Apr 2025 17:26:23 GMT Subject: RFR: 8352389: Remove incidental whitespace in pre/code content [v3] In-Reply-To: References: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com> Message-ID: On Thu, 20 Mar 2025 07:27:39 GMT, Hannes Walln?fer wrote: >> Please review a change to remove incidental whitespace commonly found at the beginning of `

` tags in API documentation. 
>> 
>> In a nutshell, using `
\n` or `
{@code\n` adds an extra empty line at the beginning of the content, compared to just using `
\n`. This is due to [HTML syntax](https://html.spec.whatwg.org/#the-pre-element:the-pre-element), which ignores a leading `\n` only if it immediately follows the opening `
` tag. It causes leading blank lines in several hundred JDK code samples, such as [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/stream/package-summary.html#Reduction) and [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/Map.html#computeIfAbsent(K,java.util.function.Function)).
>> 
>> What makes the problem a bit more complicated is that we also need to remove any horizontal whitespace between the `
` and `` tags, as that would otherwise add to the first content line line. 
>> 
>> The feature is implemented in `DocCommentParser` by parsing content of `
` elements into a separate list buffer, and filtering the content when we encounter the `
` close tag. This approach allows us to keep the logic in a single `normalizePreContent` method instead of spreading it all over `DocCommentParser`. The method uses a `DocTreeVisitor` in combination with a `State` enum to make sure pre content is only modified if all conditions are met (which involves inspecting up to the first three DocTrees).
>> 
>> Normalization is also performed for `
{@literal\n`. Although `{@literal}` by itself does not cause the problem described above as it does not produce an HTML tag, any horizontal whitespace between `
` and `{@literal` will cause the problem, so we err on the side of caution. 
>> 
>> This change solves the leading blank line issue in a lot of JDK code fragments, and probably many more in 3rd party Java code.
>
> Hannes Walln?fer 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 JDK-8352389
>  - Improve test
>  - Add comment
>  - 8352389: Remove incidental whitespace in pre/code content
>  - Whitespace normalization in PrettyCheck becomes simpler
>  - Rename method
>  - Update comment
>  - Clean up code, add comments, tests and @bug id
>  - Updated copyright year in testSourceTab breaks test
>  - Update remaining doctree tests & copyright headers
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/fb210e3a...5ec3bc04

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 503:

> 501:         if (mainTrees != null) {
> 502:             mainTrees.addAll(trees);
> 503:             trees = mainTrees;

Should we add `mainTrees = null;` after this line?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1224:

> 1222:     /**
> 1223:      * Removes a newline character following a , {@code or {@literal tag at the
> 1224:      * beginning of 
 element content, as well as any space/tabs between the pre

Consider converting this to a plain comment as these are not valid javadoc

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1309:

> 1307:         for (var tree : trees) {
> 1308:             var visited = visitor.visit(tree, cx);
> 1309:             if (visited != null) {

Should we just fail if `visited == null`? Can it happen with any user input?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24112#discussion_r2033694953
PR Review Comment: https://git.openjdk.org/jdk/pull/24112#discussion_r2033696724
PR Review Comment: https://git.openjdk.org/jdk/pull/24112#discussion_r2033700330

From hannesw at openjdk.org  Tue Apr  8 17:53:14 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 8 Apr 2025 17:53:14 GMT
Subject: RFR: 8352389: Remove incidental whitespace in pre/code content
 [v3]
In-Reply-To: 
References: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
 
 
Message-ID: 

On Tue, 8 Apr 2025 17:22:24 GMT, Chen Liang  wrote:

>> Hannes Walln?fer 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 JDK-8352389
>>  - Improve test
>>  - Add comment
>>  - 8352389: Remove incidental whitespace in pre/code content
>>  - Whitespace normalization in PrettyCheck becomes simpler
>>  - Rename method
>>  - Update comment
>>  - Clean up code, add comments, tests and @bug id
>>  - Updated copyright year in testSourceTab breaks test
>>  - Update remaining doctree tests & copyright headers
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/fb210e3a...5ec3bc04
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1309:
> 
>> 1307:         for (var tree : trees) {
>> 1308:             var visited = visitor.visit(tree, cx);
>> 1309:             if (visited != null) {
> 
> Should we just fail if `visited == null`? Can it happen with any user input?

I should have added a comment here: returning `null` from the visitor method means this tree should be dropped from the result. This happens for whitespace-only text between `
` and `` and is part of successful normalization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24112#discussion_r2033743314

From hannesw at openjdk.org  Tue Apr  8 18:14:53 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 8 Apr 2025 18:14:53 GMT
Subject: RFR: 8352389: Remove incidental whitespace in pre/code content
 [v4]
In-Reply-To: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
References: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
Message-ID: 

> Please review a change to remove incidental whitespace commonly found at the beginning of `
` tags in API documentation. 
> 
> In a nutshell, using `
\n` or `
{@code\n` adds an extra empty line at the beginning of the content, compared to just using `
\n`. This is due to [HTML syntax](https://html.spec.whatwg.org/#the-pre-element:the-pre-element), which ignores a leading `\n` only if it immediately follows the opening `
` tag. It causes leading blank lines in several hundred JDK code samples, such as [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/stream/package-summary.html#Reduction) and [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/Map.html#computeIfAbsent(K,java.util.function.Function)).
> 
> What makes the problem a bit more complicated is that we also need to remove any horizontal whitespace between the `
` and `` tags, as that would otherwise add to the first content line line. 
> 
> The feature is implemented in `DocCommentParser` by parsing content of `
` elements into a separate list buffer, and filtering the content when we encounter the `
` close tag. This approach allows us to keep the logic in a single `normalizePreContent` method instead of spreading it all over `DocCommentParser`. The method uses a `DocTreeVisitor` in combination with a `State` enum to make sure pre content is only modified if all conditions are met (which involves inspecting up to the first three DocTrees).
> 
> Normalization is also performed for `
{@literal\n`. Although `{@literal}` by itself does not cause the problem described above as it does not produce an HTML tag, any horizontal whitespace between `
` and `{@literal` will cause the problem, so we err on the side of caution. 
> 
> This change solves the leading blank line issue in a lot of JDK code fragments, and probably many more in 3rd party Java code.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24112/files
  - new: https://git.openjdk.org/jdk/pull/24112/files/5ec3bc04..69584152

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24112&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24112&range=02-03

  Stats: 8 lines in 1 file changed: 2 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24112/head:pull/24112

PR: https://git.openjdk.org/jdk/pull/24112

From weijun at openjdk.org  Tue Apr  8 18:19:46 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Apr 2025 18:19:46 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API
Message-ID: 

Finalize the KDF API.

-------------

Commit messages:
 - the change

Changes: https://git.openjdk.org/jdk/pull/24520/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353888
  Stats: 42 lines in 16 files changed: 0 ins; 30 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520

PR: https://git.openjdk.org/jdk/pull/24520

From liach at openjdk.org  Tue Apr  8 18:35:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 18:35:18 GMT
Subject: RFR: 8352389: Remove incidental whitespace in pre/code content
 [v4]
In-Reply-To: 
References: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
 
Message-ID: 

On Tue, 8 Apr 2025 18:14:53 GMT, Hannes Walln?fer  wrote:

>> Please review a change to remove incidental whitespace commonly found at the beginning of `
` tags in API documentation. 
>> 
>> In a nutshell, using `
\n` or `
{@code\n` adds an extra empty line at the beginning of the content, compared to just using `
\n`. This is due to [HTML syntax](https://html.spec.whatwg.org/#the-pre-element:the-pre-element), which ignores a leading `\n` only if it immediately follows the opening `
` tag. It causes leading blank lines in several hundred JDK code samples, such as [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/stream/package-summary.html#Reduction) and [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/Map.html#computeIfAbsent(K,java.util.function.Function)).
>> 
>> What makes the problem a bit more complicated is that we also need to remove any horizontal whitespace between the `
` and `` tags, as that would otherwise add to the first content line line. 
>> 
>> The feature is implemented in `DocCommentParser` by parsing content of `
` elements into a separate list buffer, and filtering the content when we encounter the `
` close tag. This approach allows us to keep the logic in a single `normalizePreContent` method instead of spreading it all over `DocCommentParser`. The method uses a `DocTreeVisitor` in combination with a `State` enum to make sure pre content is only modified if all conditions are met (which involves inspecting up to the first three DocTrees).
>> 
>> Normalization is also performed for `
{@literal\n`. Although `{@literal}` by itself does not cause the problem described above as it does not produce an HTML tag, any horizontal whitespace between `
` and `{@literal` will cause the problem, so we err on the side of caution. 
>> 
>> This change solves the leading blank line issue in a lot of JDK code fragments, and probably many more in 3rd party Java code.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

LGTM

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24112#pullrequestreview-2751060111

From hannesw at openjdk.org  Tue Apr  8 18:49:28 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 8 Apr 2025 18:49:28 GMT
Subject: Integrated: 8352389: Remove incidental whitespace in pre/code content
In-Reply-To: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
References: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
Message-ID: 

On Wed, 19 Mar 2025 11:26:32 GMT, Hannes Walln?fer  wrote:

> Please review a change to remove incidental whitespace commonly found at the beginning of `
` tags in API documentation. 
> 
> In a nutshell, using `
\n` or `
{@code\n` adds an extra empty line at the beginning of the content, compared to just using `
\n`. This is due to [HTML syntax](https://html.spec.whatwg.org/#the-pre-element:the-pre-element), which ignores a leading `\n` only if it immediately follows the opening `
` tag. It causes leading blank lines in several hundred JDK code samples, such as [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/stream/package-summary.html#Reduction) and [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/util/Map.html#computeIfAbsent(K,java.util.function.Function)).
> 
> What makes the problem a bit more complicated is that we also need to remove any horizontal whitespace between the `
` and `` tags, as that would otherwise add to the first content line line. 
> 
> The feature is implemented in `DocCommentParser` by parsing content of `
` elements into a separate list buffer, and filtering the content when we encounter the `
` close tag. This approach allows us to keep the logic in a single `normalizePreContent` method instead of spreading it all over `DocCommentParser`. The method uses a `DocTreeVisitor` in combination with a `State` enum to make sure pre content is only modified if all conditions are met (which involves inspecting up to the first three DocTrees).
> 
> Normalization is also performed for `
{@literal\n`. Although `{@literal}` by itself does not cause the problem described above as it does not produce an HTML tag, any horizontal whitespace between `
` and `{@literal` will cause the problem, so we err on the side of caution. 
> 
> This change solves the leading blank line issue in a lot of JDK code fragments, and probably many more in 3rd party Java code.

This pull request has now been integrated.

Changeset: 24ff96af
Author:    Hannes Walln?fer 
URL:       https://git.openjdk.org/jdk/commit/24ff96afe41b62275fe8635e477ecc04bff93123
Stats:     352 lines in 7 files changed: 340 ins; 3 del; 9 mod

8352389: Remove incidental whitespace in pre/code content

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/24112

From liach at openjdk.org  Tue Apr  8 19:37:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 19:37:19 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang  wrote:

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

Tests tier 1-3 all pass (except a tier 2 test already fixed by 8353945)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2787478035

From liach at openjdk.org  Tue Apr  8 19:39:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 19:39:16 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 18:14:53 GMT, Weijun Wang  wrote:

> Finalize the KDF API.

Changes requested by liach (Reviewer).

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:

> 80:         MODULE_IMPORTS,
> 81:         @JEP(number=478, title="Key Derivation Function API", status="Preview")
> 82:         KEY_DERIVATION,

Please keep this constant - we cannot remove this until our minimum boot JDK is 25.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2751196660
PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2033904746

From acobbs at openjdk.org  Tue Apr  8 19:51:36 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 8 Apr 2025 19:51:36 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available.
> 
> The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons.
> 
> Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Refactoring/cleanup for handling of ending positions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23669/files
  - new: https://git.openjdk.org/jdk/pull/23669/files/0f85a240..01270280

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23669&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23669&range=02-03

  Stats: 308 lines in 12 files changed: 62 ins; 135 del; 111 mod
  Patch: https://git.openjdk.org/jdk/pull/23669.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23669/head:pull/23669

PR: https://git.openjdk.org/jdk/pull/23669

From acobbs at openjdk.org  Tue Apr  8 19:55:14 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 8 Apr 2025 19:55:14 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <-zvNCuNkqA2ADhmF8j-cJcy1n0WdzNc1WtNEFXYkaSQ=.dfdfd9a0-03a2-4332-bd06-2693749da800@github.com>

On Tue, 8 Apr 2025 14:56:41 GMT, Jan Lahoda  wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing variable decl end position.
>
> The new calls to `storeEnd` seem to partly duplicate existing `to`/`toP` calls. That feels a bit unfortunate - as we may be adding new places that create AST node for declarations, and one sometimes forgets to do `to`/`toP` - and forgetting `storeEnd` might lead to weird problems.
> 
> I tried to re-write this part by putting the the set logic directly into the end pos tables here:
> https://github.com/archiecobbs/jdk/compare/JDK-8350212...lahodaj:jdk:JDK-8350212?expand=1
> 
> Notes:
> - I believe the fact that implictly declared classes don't have an end position was intentional at that time. I don't have an issue with changing that, just pointing it out.
> - for blocks, `endpos` is actually pointing at the start of the closing brace, not the end (I think, at least). So, I've renamed the field, but kept the semantics.
> 
> What do you think?

Description of the latest changes (these incorporate some of @lahodaj's suggestions as well):

General:
* Always store ending positions for `@SuppressWarnings`-bearing declarations, blocks, and switches.
* Always require a `EndPosTable` when using methods `TreeInfo.endPos()` and `TreeInfo.diagEndPos()`.

`JCTree`:
* Remove "one-off" ending position fields in specific `JCTree` classes, except for `JCBlock`
  and `JCSwitchExpression` which still need them; rename those two fields `bracePos`.

`JavacParser`
* Replace `EmptyEndPosTable` with `MinimalEndPosTable` which remembers the minimal required set.
* `EndPosTable` methods `to()` and `toP()` are unused; remove them and the now unneeded `parser` field.
* Make `storeEnd()` and `attach()` fluent methods and use that to cleanup a bit.
* Store ending position for implicit classes for consistency with other `JCClassDecl`'s.
* Fix module ending positions to be at the closing brace instead of EOF.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2787512884

From acobbs at openjdk.org  Tue Apr  8 20:07:24 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 8 Apr 2025 20:07:24 GMT
Subject: Integrated: 8353757: Log class should have a proper clear() method
In-Reply-To: 
References: 
Message-ID: 

On Fri, 4 Apr 2025 22:05:58 GMT, Archie Cobbs  wrote:

> This is a simple refactoring to add a method `Log.clear()`, move `ReusableLog.clear()`'s clearing operations into it and invoke `super.clear()` instead, and add two more fields that should be included in the clear operation but were not because they were added to `Log` after `ReusableLog.clear()` was added and were missed.
> 
> A natural question: Are there any other fields in `Log` that should be cleared in `Log.clear()`? The two I've added (`nsuppressederrors` and `nsuppressedwarns`) are the only two that weren't there when `ReusableLog` as added, so presumably not, but it's possible.

This pull request has now been integrated.

Changeset: 5b42c46b
Author:    Archie Cobbs 
URL:       https://git.openjdk.org/jdk/commit/5b42c46b48363acd00ee4a183edca9a48cdc16c8
Stats:     21 lines in 2 files changed: 14 ins; 2 del; 5 mod

8353757: Log class should have a proper clear() method

Reviewed-by: vromero, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/24460

From liach at openjdk.org  Tue Apr  8 20:33:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 20:33:33 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API [v2]
In-Reply-To: 
References: 
Message-ID: 

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

Chen Liang 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 six additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Other references to remove
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - FieldDescription.constantValue uses Integer for byte and short
 - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24212/files
  - new: https://git.openjdk.org/jdk/pull/24212/files/df57ca1e..e3d1a4ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24212&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24212&range=00-01

  Stats: 2874 lines in 118 files changed: 2267 ins; 175 del; 432 mod
  Patch: https://git.openjdk.org/jdk/pull/24212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24212/head:pull/24212

PR: https://git.openjdk.org/jdk/pull/24212

From liach at openjdk.org  Tue Apr  8 20:40:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 20:40:53 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK
Message-ID: 

With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.

Testing: built locally, running tier 1-3 tests

Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

-------------

Depends on: https://git.openjdk.org/jdk/pull/24212

Commit messages:
 - 8352748: Remove com.sun.tools.classfile from the JDK
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Other references to remove
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - FieldDescription.constantValue uses Integer for byte and short
 - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Changes: https://git.openjdk.org/jdk/pull/24528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352748
  Stats: 11072 lines in 74 files changed: 42 ins; 10705 del; 325 mod
  Patch: https://git.openjdk.org/jdk/pull/24528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24528/head:pull/24528

PR: https://git.openjdk.org/jdk/pull/24528

From acobbs at openjdk.org  Tue Apr  8 20:57:32 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 8 Apr 2025 20:57:32 GMT
Subject: RFR: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported
Message-ID: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>

This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.

Lint warnings that are subject to suppression via `@SuppressWarnings` must be deferred until attribution, because until then we can't determine whether they are suppressed or not.

Whether a lint warning is subject to suppression via `@SuppressWarnings` is a function of the associated `LintCategory`, not the warning itself. For example `LintCategory.OPTIONS` is not, so an occurrence of `@SuppressWarnings("options")` is meaningless and would be ignored.

This information is needed in the upcoming refactoring. We can facilitate that very simply by adding a boolean property to the `LintCategory` enum.

In addition, this permits a small optimization to be added to `Lint.suppressionsFrom()`.

-------------

Commit messages:
 - Add field LintCategory.annotationSuppression.

Changes: https://git.openjdk.org/jdk/pull/24529/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24529&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354071
  Stats: 35 lines in 1 file changed: 25 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24529.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24529/head:pull/24529

PR: https://git.openjdk.org/jdk/pull/24529

From weijun at openjdk.org  Tue Apr  8 21:03:17 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Apr 2025 21:03:17 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 19:35:33 GMT, Chen Liang  wrote:

>> Finalize the KDF API.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:
> 
>> 80:         MODULE_IMPORTS,
>> 81:         @JEP(number=478, title="Key Derivation Function API", status="Preview")
>> 82:         KEY_DERIVATION,
> 
> Please keep this constant - we cannot remove this until our minimum boot JDK is 25.

Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see no problem.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2034027369

From liach at openjdk.org  Tue Apr  8 21:06:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 21:06:23 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 21:00:41 GMT, Weijun Wang  wrote:

>> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:
>> 
>>> 80:         MODULE_IMPORTS,
>>> 81:         @JEP(number=478, title="Key Derivation Function API", status="Preview")
>>> 82:         KEY_DERIVATION,
>> 
>> Please keep this constant - we cannot remove this until our minimum boot JDK is 25.
>
> Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see no problem.

I think the dependency is in the CreateSymbols tool or something

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2034030628

From weijun at openjdk.org  Tue Apr  8 23:39:42 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 8 Apr 2025 23:39:42 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API [v2]
In-Reply-To: 
References: 
Message-ID: 

> Finalize the KDF API.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  add enum back

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/4ff3b95b..66706a50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520

PR: https://git.openjdk.org/jdk/pull/24520

From acobbs at openjdk.org  Wed Apr  9 01:27:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 01:27:52 GMT
Subject: RFR: 8354090: Refactor import warning suppression in Check.java
Message-ID: 

This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.

In JDK 9 and later, there is a special exception to the normal rules for deprecation and preview warnings, which is that these warnings are automatically suppressed for import statements. This is because an import statement is just a lexical shortcut, not an actual use of the symbol.

The current code in `Check.java` implements this by manipulating the current `Lint` instance directly, but this operation is incompatible upcoming changes to deferred lint handling. Instead, there can be an explicit flag for "import warning suppression" in `Check.java` to handle this. This will also make the code a bit clearer.

-------------

Commit messages:
 - Bump copyright.
 - Refactor handling of DEPRECATION_ON_IMPORT via new flag Check.importSuppression.

Changes: https://git.openjdk.org/jdk/pull/24532/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24532&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354090
  Stats: 33 lines in 3 files changed: 12 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24532/head:pull/24532

PR: https://git.openjdk.org/jdk/pull/24532

From acobbs at openjdk.org  Wed Apr  9 01:29:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 01:29:33 GMT
Subject: RFR: 8354090: Refactor import warning suppression in Check.java
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Apr 2025 01:20:50 GMT, Archie Cobbs  wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> In JDK 9 and later, there is a special exception to the normal rules for deprecation and preview warnings, which is that these warnings are automatically suppressed for import statements. This is because an import statement is just a lexical shortcut, not an actual use of the symbol.
> 
> The current code in `Check.java` implements this by manipulating the current `Lint` instance directly, but this operation is incompatible upcoming changes to deferred lint handling. Instead, there can be an explicit flag for "import warning suppression" in `Check.java` to handle this. This will also make the code a bit clearer.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3826:

> 3824:             sIsPreview = false;
> 3825:             previewSymbol = null;
> 3826:         }

We don't defer here because we want `warnPreviewAPI()` to use the current value of `importSuppression`, not some later value. But these warnings didn't really need to be deferred in the first place - because we can just use the current `Lint` instance, and in fact, that's what it was already doing. But a side effect of these changes is that the warnings checked in the `PreviewAutoSuppress.java` regression test get reordered.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24532#discussion_r2034296045

From alanb at openjdk.org  Wed Apr  9 06:16:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 06:16:45 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 8 Apr 2025 21:03:18 GMT, Chen Liang  wrote:

>> Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see no problem.
>
> I think the dependency is in the CreateSymbols tool or something

Yes, we've had issues with boot cycle builds at least, Jan has the details and I think the guidance the last time was to leave it in place to the next release.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2034519284

From mcimadamore at openjdk.org  Wed Apr  9 08:34:31 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 08:34:31 GMT
Subject: RFR: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported
In-Reply-To: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
References: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
Message-ID: 

On Tue, 8 Apr 2025 20:52:09 GMT, Archie Cobbs  wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> Lint warnings that are subject to suppression via `@SuppressWarnings` must be deferred until attribution, because until then we can't determine whether they are suppressed or not.
> 
> Whether a lint warning is subject to suppression via `@SuppressWarnings` is a function of the associated `LintCategory`, not the warning itself. For example `LintCategory.OPTIONS` is not, so an occurrence of `@SuppressWarnings("options")` is meaningless and would be ignored.
> 
> This information is needed in the upcoming refactoring. We can facilitate that very simply by adding a boolean property to the `LintCategory` enum.
> 
> In addition, this permits a small optimization to be added to `Lint.suppressionsFrom()`.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 377:

> 375:          * This category is not supported by {@code @SuppressWarnings}.
> 376:          */
> 377:         TEXT_BLOCKS("text-blocks", false),

For this I'm a bit unsure -- the warning here is not unsuppressible by design, but, rather because of a deficiency in how suppression works. So seeing a "bug" reified in a flag here seems odd. At the very least this one seems different from the others -- where effectively there's no place to even put the `SuppressWarning` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24529#discussion_r2034787042

From mcimadamore at openjdk.org  Wed Apr  9 08:41:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 08:41:29 GMT
Subject: RFR: 8354090: Refactor import warning suppression in Check.java
In-Reply-To: 
References: 
Message-ID: <32UthZ7hSa9TfDJ9rA6hZoSgtD7E5AnCQCUgRK5YH90=.b8123c81-3591-4737-b019-626530159d1f@github.com>

On Wed, 9 Apr 2025 01:20:50 GMT, Archie Cobbs  wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> In JDK 9 and later, there is a special exception to the normal rules for deprecation and preview warnings, which is that these warnings are automatically suppressed for import statements. This is because an import statement is just a lexical shortcut, not an actual use of the symbol.
> 
> The current code in `Check.java` implements this by manipulating the current `Lint` instance directly, but this operation is incompatible upcoming changes to deferred lint handling. Instead, there can be an explicit flag for "import warning suppression" in `Check.java` to handle this. This will also make the code a bit clearer.

Looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 239:

> 237:     boolean setImportSuppression(boolean newImportSuppression) {
> 238:         boolean prev = importSuppression;
> 239:         importSuppression = newImportSuppression;

This is fine. Another alternative that I'm mentioning for completeness would have been for `attribImportType` to set a flag on AttrContext (and then augment some of the methods in `Check` to accept an extra `env` parameter).

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24532#pullrequestreview-2752590983
PR Review Comment: https://git.openjdk.org/jdk/pull/24532#discussion_r2034796606

From mcimadamore at openjdk.org  Wed Apr  9 08:56:41 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 08:56:41 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 19:51:36 GMT, Archie Cobbs  wrote:

>> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
>> 
>> Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available.
>> 
>> The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons.
>> 
>> Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring/cleanup for handling of ending positions.

I'll leave this to @lahodaj . In my opinion the removal of the `endpos` field in `JCSwitch` adds more code than it removes -- because of that `TreeInfo.endPos` needs a new `EndPosTable` parameter, which means `Flow`/`Lower`/`TransPatterns` needs additional logic to set the end pos table. It's not a complex rewriting, but given that we kind of know we're going to put our hands in here again, I wonder if there could be some merit in being more minimal/pragmatic.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23669#pullrequestreview-2752637943

From liach at openjdk.org  Wed Apr  9 09:06:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 09:06:44 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang  wrote:

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

Tier 1-3 tests passed, only unrelated failure fixed by 8354088.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24528#issuecomment-2788873619

From alanb at openjdk.org  Wed Apr  9 10:24:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 10:24:37 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
Message-ID: <3Zk9YripITF8dslVfxe4NXy91mnMLLRjqJyDk48T6l4=.6644f577-685f-4c29-9db7-311f11b8e65a@github.com>

On Mon, 7 Apr 2025 21:07:36 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewrite bits about charset decoding, removing mention of "internal objects."

src/java.base/share/classes/java/lang/IO.java line 47:

> 45:  * Decoding may buffer additional bytes beyond those that have been decoded to characters
> 46:  * returned to the application. After the first call to one of the {@code readln} methods,
> 47:  * any subsequent use of {@code System.in} results in unspecified behavior.

I wonder if we should add a note about mixing API usage into System.in too. There are tutorials and books that show examples build on System.in that will add buffering on that input source.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035067290

From ihse at openjdk.org  Wed Apr  9 10:35:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:35:31 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang  wrote:

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

Build changes look trivially fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24528#pullrequestreview-2753004950

From alanb at openjdk.org  Wed Apr  9 10:39:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 10:39:43 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 7 Apr 2025 18:28:21 GMT, Stuart Marks  wrote:

>> Someone is bound to ask why the readln method throw but the println methods don't.
>
> The IOError was carried over from Console.readLine(), which throws IOError on error. Of course we're decoupled from Console now, but that was the original reason.
> 
> My guess is that Console methods throw IOError because (a) they didn't want to make everybody catch IOException, (b) they didn't want to maintain an internal error state like PrintStream, and (c) they wanted to throw a throwable whose type conveyed the meaning that it wasn't expected to be handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning still applies here.
> 
> UncheckedIOException wasn't added until JDK 1.8. Note also that UncheckedIOException has a cause of IOException, so it can't arise from some other throwable. This was used in the previous implementation, where IOError was thrown if Console was null. That doesn't apply anymore, but IOError is still somewhat more flexible than UncheckedIOException in this regard.
> 
> I think we need to say something, implicitly or explicitly, about error handling. Note that PrintStream has this internal error state so output is covered already. For input it seems like IOError is reasonable, but maybe there's a better choice.

The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause.

System.in.close() would a be wild thing to do, but a case where readln would throw IOError.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035089368

From ihse at openjdk.org  Wed Apr  9 10:41:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:41:45 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 20:33:33 GMT, Chen Liang  wrote:

>> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
>> 
>> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
>> 
>> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.
>
> Chen Liang 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Build changes look trivially fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24212#pullrequestreview-2753017837

From alanb at openjdk.org  Wed Apr  9 10:49:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 10:49:34 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 7 Apr 2025 21:07:36 GMT, Jan Lahoda  wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewrite bits about charset decoding, removing mention of "internal objects."

src/java.base/share/classes/java/lang/IO.java line 42:

> 40:  * {@code System.in} into characters. The charset used for decoding is specified by the
> 41:  * {@link System#getProperties stdin.encoding} property. If this property is not present,
> 42:  * or if the charset it names cannot be loaded, then UTF-8 is used instead.

stdout.encoding and stdin.encoding are specified (in System.getProperties) to lead to unspecified behavior if started with either property set to a value other than UTF-8. We should work through the issues of introducing stdin.encoding as soon as we can, esp. the redirect cases and whether there is use cases for setting any of these properties on the command line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035104215

From acobbs at openjdk.org  Wed Apr  9 13:53:34 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 13:53:34 GMT
Subject: RFR: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported
In-Reply-To: 
References: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 08:31:20 GMT, Maurizio Cimadamore  wrote:

>> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
>> 
>> Lint warnings that are subject to suppression via `@SuppressWarnings` must be deferred until attribution, because until then we can't determine whether they are suppressed or not.
>> 
>> Whether a lint warning is subject to suppression via `@SuppressWarnings` is a function of the associated `LintCategory`, not the warning itself. For example `LintCategory.OPTIONS` is not, so an occurrence of `@SuppressWarnings("options")` is meaningless and would be ignored.
>> 
>> This information is needed in the upcoming refactoring. We can facilitate that very simply by adding a boolean property to the `LintCategory` enum.
>> 
>> In addition, this permits a small optimization to be added to `Lint.suppressionsFrom()`.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 377:
> 
>> 375:          * This category is not supported by {@code @SuppressWarnings}.
>> 376:          */
>> 377:         TEXT_BLOCKS("text-blocks", false),
> 
> For this I'm a bit unsure -- the warning here is not unsuppressible by design, but, rather because of a deficiency in how suppression works. So seeing a "bug" reified in a flag here seems odd. At the very least this one seems different from the others -- where effectively there's no place to even put the `SuppressWarning` ?

The intent was for this field to represent what's actually (currently) true in the compiler - which is that `@SuppressWarnings("text-blocks")` is not supported - and then revert this part of the change when [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228) gets fixed. But we could also do that preemptively if you prefer - just let me know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24529#discussion_r2035425410

From vromero at openjdk.org  Wed Apr  9 14:08:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Apr 2025 14:08:55 GMT
Subject: RFR: 8322810: Lambda expressions can implement classes
Message-ID: 

Currently javac is accepting code like:


class Test {
    void m() {
        var r = (Test & Runnable) () -> System.out.println("Hello, World!");
    }
}


according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`

With this fix this code pattern will be rejected with a compiler error

TIA

-------------

Commit messages:
 - modifying comment
 - 8322810: Lambda expressions can implement classes

Changes: https://git.openjdk.org/jdk/pull/24548/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322810
  Stats: 40 lines in 5 files changed: 35 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24548/head:pull/24548

PR: https://git.openjdk.org/jdk/pull/24548

From duke at openjdk.org  Wed Apr  9 14:30:44 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Apr 2025 14:30:44 GMT
Subject: RFR: 8353840: JNativeScan should not throw error for missing
 system classes [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 13:51:59 GMT, Danish Nawab  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353840: remove unnecessary final

@danishnawab 
Your change (at version 1de3feca0a42ec1dfe4d8797fc362612277152a0) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2789930714

From jlahoda at openjdk.org  Wed Apr  9 14:32:43 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Apr 2025 14:32:43 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 20:33:33 GMT, Chen Liang  wrote:

>> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
>> 
>> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
>> 
>> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.
>
> Chen Liang 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

I skimmed through the `CreateSymbols` changes, used `test/langtools/tools/javac/sym/PrintCTSymContent.java` to print ct.sym content before and after, and let the tool that generates the `.sym.txt` to run for JDK 24. All seems fine to me. Thanks!

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24212#pullrequestreview-2753708018

From mcimadamore at openjdk.org  Wed Apr  9 14:55:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 14:55:29 GMT
Subject: RFR: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported
In-Reply-To: 
References: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
 
 
 
Message-ID: 

On Wed, 9 Apr 2025 14:52:11 GMT, Maurizio Cimadamore  wrote:

>> The intent was for this field to represent what's actually (currently) true in the compiler - which is that `@SuppressWarnings("text-blocks")` is not supported - and then revert this part of the change when [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228) gets fixed. But we could also do that preemptively if you prefer - just let me know.
>
>> The intent was for this field to represent what's actually (currently) true in the compiler - which is that `@SuppressWarnings("text-blocks")` is not supported - and then revert this part of the change when [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228) gets fixed. But we could also do that preemptively if you prefer - just let me know.
> 
> I'm fine with either -- I just wonder if this might suggest that we will start e.g. refusing/warn `@SuppressWarnings("XYZ")` where XYZ is declared as unsuppressible. But as long as we sequence things correctly, we should be ok either way.

Maybe just add a comment saying "for now" :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24529#discussion_r2035554004

From mcimadamore at openjdk.org  Wed Apr  9 14:55:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 14:55:29 GMT
Subject: RFR: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported
In-Reply-To: 
References: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
 
 
Message-ID: 

On Wed, 9 Apr 2025 13:51:17 GMT, Archie Cobbs  wrote:

> The intent was for this field to represent what's actually (currently) true in the compiler - which is that `@SuppressWarnings("text-blocks")` is not supported - and then revert this part of the change when [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228) gets fixed. But we could also do that preemptively if you prefer - just let me know.

I'm fine with either -- I just wonder if this might suggest that we will start e.g. refusing/warn `@SuppressWarnings("XYZ")` where XYZ is declared as unsuppressible. But as long as we sequence things correctly, we should be ok either way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24529#discussion_r2035553496

From liach at openjdk.org  Wed Apr  9 14:55:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 14:55:40 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 20:33:33 GMT, Chen Liang  wrote:

>> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
>> 
>> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
>> 
>> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.
>
> Chen Liang 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Thanks Nizar, Jan, and Magnus for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2790001750

From liach at openjdk.org  Wed Apr  9 14:55:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 14:55:41 GMT
Subject: Integrated: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API
In-Reply-To: 
References: 
Message-ID: <0TifGTZ6i79pWMlLNMk2NtrV0Zma57-jybekTj0f0QE=.91da1273-0927-4909-b1aa-facec1ece4ef@github.com>

On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang  wrote:

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

This pull request has now been integrated.

Changeset: 4dc9e589
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/4dc9e58906772bf8ee444cb1618aa43f66593d79
Stats:     1057 lines in 5 files changed: 42 ins; 696 del; 319 mod

8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Reviewed-by: ihse, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/24212

From acobbs at openjdk.org  Wed Apr  9 15:02:32 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 15:02:32 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 14:56:41 GMT, Jan Lahoda  wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing variable decl end position.
>
> The new calls to `storeEnd` seem to partly duplicate existing `to`/`toP` calls. That feels a bit unfortunate - as we may be adding new places that create AST node for declarations, and one sometimes forgets to do `to`/`toP` - and forgetting `storeEnd` might lead to weird problems.
> 
> I tried to re-write this part by putting the the set logic directly into the end pos tables here:
> https://github.com/archiecobbs/jdk/compare/JDK-8350212...lahodaj:jdk:JDK-8350212?expand=1
> 
> Notes:
> - I believe the fact that implictly declared classes don't have an end position was intentional at that time. I don't have an issue with changing that, just pointing it out.
> - for blocks, `endpos` is actually pointing at the start of the closing brace, not the end (I think, at least). So, I've renamed the field, but kept the semantics.
> 
> What do you think?

> I'll leave this to @lahodaj . In my opinion the removal of the `endpos` field in `JCSwitch` adds more code than it removes -- because of that `TreeInfo.endPos` needs a new `EndPosTable` parameter, which means `Flow`/`Lower`/`TransPatterns` needs additional logic to set the end pos table. It's not a complex rewriting, but given that we kind of know we're going to put our hands in here again, I wonder if there could be some merit in being more minimal/pragmatic.

Well the point of the latest refactoring was to try to remove the storage of duplicate end positions and move to a single unified way of accessing ending positions via `EndPosTable` (the `bracePos` fields are not duplicate, because they point to different positions).

Your suggestion now is to perhaps go back in the reverse direction. That's not totally crazy, but I feel like now I'm getting mixed messages.

FWIW my personal opinion is that the `EndPosTable` is readily accessible already, so it's OK to require it, and this makes the code more consistent without special exceptions. Of course it also comes with a small performance penalty - but then I remember [this](https://wiki.c2.com/?PrematureOptimization).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2790032282

From liach at openjdk.org  Wed Apr  9 15:04:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:04:24 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: 
References: 
Message-ID: 

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
 - 8352748: Remove com.sun.tools.classfile from the JDK
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Other references to remove
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - FieldDescription.constantValue uses Integer for byte and short
 - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

-------------

Changes: https://git.openjdk.org/jdk/pull/24528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24528&range=01
  Stats: 10015 lines in 70 files changed: 0 ins; 10009 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24528/head:pull/24528

PR: https://git.openjdk.org/jdk/pull/24528

From ihse at openjdk.org  Wed Apr  9 15:09:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 15:09:58 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
Message-ID: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu  wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:

> 20: # Peter Smolik
> 21: Cp1250 WINDOWS-1250 0x00FF
> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)

This does not seem to have been a correct conversion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2035582242

From liach at openjdk.org  Wed Apr  9 15:14:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:14:29 GMT
Subject: RFR: 8353840: JNativeScan should not abort for missing classes
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <5Ei6jXfX8xHlWEealxWf8Tlqaq47-yZ5Wv_Ofpg5G9U=.f0fa3a2f-1288-4382-a510-c6f8d5609260@github.com>

On Tue, 8 Apr 2025 13:51:59 GMT, Danish Nawab  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353840: remove unnecessary final

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24499#pullrequestreview-2753847531

From liach at openjdk.org  Wed Apr  9 15:14:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:14:30 GMT
Subject: RFR: 8353840: JNativeScan should not abort for missing classes
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: <00fbDY9dGX80hw-oX9eTKIV5vTn3cZy4s8iUAjZz6_I=.badcf9e9-154c-4c07-a827-cd396c4a76ea@github.com>

On Tue, 8 Apr 2025 14:25:11 GMT, Danish Nawab  wrote:

>> Changes look good, thanks!
>> 
>> Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.
>
>> Changes look good, thanks!
>> 
>> Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.
> 
> Great, thanks for your review! 
> I will wait until tomorrow to issue the `/integrate` (as instructed by openjdk[bot]). Since I am not an OpenJDK committer, I will request you to please sponsor it.

Hello @danishnawab, I have updated the issue title to "JNativeScan should not abort for missing classes" to be more accurate for the changes done. Can you update the PR title here too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2790067812

From acobbs at openjdk.org  Wed Apr  9 15:15:11 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 15:15:11 GMT
Subject: RFR: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported [v2]
In-Reply-To: 
References: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
 
 
 
 
Message-ID: 

On Wed, 9 Apr 2025 14:52:25 GMT, Maurizio Cimadamore  wrote:

>>> The intent was for this field to represent what's actually (currently) true in the compiler - which is that `@SuppressWarnings("text-blocks")` is not supported - and then revert this part of the change when [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228) gets fixed. But we could also do that preemptively if you prefer - just let me know.
>> 
>> I'm fine with either -- I just wonder if this might suggest that we will start e.g. refusing/warn `@SuppressWarnings("XYZ")` where XYZ is declared as unsuppressible. But as long as we sequence things correctly, we should be ok either way.
>
> Maybe just add a comment saying "for now" :-)

>  I just wonder if this might suggest that we will start e.g. refusing/warn `@SuppressWarnings("XYZ")` where XYZ is declared as unsuppressible.

Surely that would violate the spirit (if not the letter) of [?9.6.4.5](https://docs.oracle.com/javase/specs/jls/se24/html/jls-9.html#jls-9.6.4.5) which states "A Java compiler must ignore any such string that it does not recognize".

> Maybe just add a comment saying "for now" :-)

Good compromise idea :) Added in 5bb0b11431e.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24529#discussion_r2035591411

From acobbs at openjdk.org  Wed Apr  9 15:15:10 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 15:15:10 GMT
Subject: RFR: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported [v2]
In-Reply-To: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
References: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
Message-ID: 

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> Lint warnings that are subject to suppression via `@SuppressWarnings` must be deferred until attribution, because until then we can't determine whether they are suppressed or not.
> 
> Whether a lint warning is subject to suppression via `@SuppressWarnings` is a function of the associated `LintCategory`, not the warning itself. For example `LintCategory.OPTIONS` is not, so an occurrence of `@SuppressWarnings("options")` is meaningless and would be ignored.
> 
> This information is needed in the upcoming refactoring. We can facilitate that very simply by adding a boolean property to the `LintCategory` enum.
> 
> In addition, this permits a small optimization to be added to `Lint.suppressionsFrom()`.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add "not yet" comment to TEXT_BLOCKS.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24529/files
  - new: https://git.openjdk.org/jdk/pull/24529/files/f831a108..5bb0b114

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24529&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24529&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24529.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24529/head:pull/24529

PR: https://git.openjdk.org/jdk/pull/24529

From duke at openjdk.org  Wed Apr  9 15:17:26 2025
From: duke at openjdk.org (Danish Nawab)
Date: Wed, 9 Apr 2025 15:17:26 GMT
Subject: RFR: 8353840: JNativeScan should not abort for missing classes
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 8 Apr 2025 14:25:11 GMT, Danish Nawab  wrote:

>> Changes look good, thanks!
>> 
>> Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.
>
>> Changes look good, thanks!
>> 
>> Please note that we will have to wait 24 hours before integrating, in order to give other reviews time to look as well.
> 
> Great, thanks for your review! 
> I will wait until tomorrow to issue the `/integrate` (as instructed by openjdk[bot]). Since I am not an OpenJDK committer, I will request you to please sponsor it.

> Hello @danishnawab, I have updated the issue title to "JNativeScan should not abort for missing classes" to be more accurate for the changes done. Can you update the PR title here too?

@liach it's done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2790078272

From jlahoda at openjdk.org  Wed Apr  9 15:17:33 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Apr 2025 15:17:33 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: 
References: 
 
Message-ID: <8fGvLxgB44Zln3uK7Htt3LWMvCkiTYqpsGKNTDDJ7Do=.19e52043-d624-44b3-a901-85869fe9498c@github.com>

On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang  wrote:

>> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
>> 
>> Testing: built locally, running tier 1-3 tests
>> 
>> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - 8352748: Remove com.sun.tools.classfile from the JDK
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Looks good to me. I won't increase the reviewer count, but please wait a few days to give others chance to comment if they choose to.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24528#pullrequestreview-2753858690

From duke at openjdk.org  Wed Apr  9 15:28:38 2025
From: duke at openjdk.org (Danish Nawab)
Date: Wed, 9 Apr 2025 15:28:38 GMT
Subject: Integrated: 8353840: JNativeScan should not abort for missing classes
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab  wrote:

> ## Description
> 
> https://bugs.openjdk.org/browse/JDK-8353840 
> 
> ### Existing behavior
> Log the error message and terminate in case of missing system class
> 
> 
> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
> 
> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
> Exit code: 1
> 
> 
> ### New behavior
> Still log the error message about the missing system class, but continue the analysis
> 
> 
> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
> 
>   
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
> Exit code: 0
> 
> 
> ## Design choices
> 
> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
> 
> ### Alternatives considered
> 
> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
> 
> ### stdout vs stderr 
> 
> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.
> 
> ## Testing
> 
> The existing test `TestMissingSystemClass#testSingleJarClassPath` has ...

This pull request has now been integrated.

Changeset: 5f2a604b
Author:    Danish Nawab 
Committer: Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/5f2a604b633c0cd24f897f828a7c928c3d2b651c
Stats:     54 lines in 5 files changed: 25 ins; 2 del; 27 mod

8353840: JNativeScan should not abort for missing classes

Reviewed-by: jvernee, liach

-------------

PR: https://git.openjdk.org/jdk/pull/24499

From liach at openjdk.org  Wed Apr  9 15:28:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:28:37 GMT
Subject: RFR: 8353840: JNativeScan should not abort for missing classes
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <60i3YYy1zyJAWbMQ9ddazxVQn92FazdkDBqlQuT66Uk=.eaa161d8-e21d-4998-962c-dab86d0f311e@github.com>

On Tue, 8 Apr 2025 13:51:59 GMT, Danish Nawab  wrote:

>> ## Description
>> 
>> https://bugs.openjdk.org/browse/JDK-8353840 
>> 
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>> 
>> 
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
>> 
>> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
>> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
>> Exit code: 1
>> 
>> 
>> ### New behavior
>> Still log the error message about the missing system class, but continue the analysis
>> 
>> 
>> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
>> 
>>   
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::()void: System class can not be found: sun.misc.SharedSecrets
>> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::()void: System class can not be found: sun.misc.SharedSecrets
>> Exit code: 0
>> 
>> 
>> ## Design choices
>> 
>> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
>> 
>> ### Alternatives considered
>> 
>> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
>> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
>> 
>> ### stdout vs stderr 
>> 
>> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed....
>
> Danish Nawab has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353840: remove unnecessary final

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24499#issuecomment-2790105523

From vromero at openjdk.org  Wed Apr  9 15:43:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Apr 2025 15:43:42 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang  wrote:

>> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
>> 
>> Testing: built locally, running tier 1-3 tests
>> 
>> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - 8352748: Remove com.sun.tools.classfile from the JDK
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24528#pullrequestreview-2753941212

From acobbs at openjdk.org  Wed Apr  9 15:50:48 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 15:50:48 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
Message-ID: 

This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 

There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.

First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.

Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.

Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

-------------

Commit messages:
 - Small cleanups relating to Log.DiagnosticHandler.

Changes: https://git.openjdk.org/jdk/pull/24553/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24553&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354216
  Stats: 86 lines in 11 files changed: 8 ins; 26 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/24553.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24553/head:pull/24553

PR: https://git.openjdk.org/jdk/pull/24553

From smarks at openjdk.org  Wed Apr  9 16:57:40 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 9 Apr 2025 16:57:40 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 9 Apr 2025 10:46:40 GMT, Alan Bateman  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rewrite bits about charset decoding, removing mention of "internal objects."
>
> src/java.base/share/classes/java/lang/IO.java line 42:
> 
>> 40:  * {@code System.in} into characters. The charset used for decoding is specified by the
>> 41:  * {@link System#getProperties stdin.encoding} property. If this property is not present,
>> 42:  * or if the charset it names cannot be loaded, then UTF-8 is used instead.
> 
> stdout.encoding and stderr.encoding are specified (in System.getProperties) to lead to unspecified behavior if started with either property set to a value other than UTF-8. We should work through the issues of introducing stdin.encoding as soon as we can, esp. the redirect cases and whether there is use cases for setting any of these properties on the command line.

Yes, believe it or not, I am still studying this...

> src/java.base/share/classes/java/lang/IO.java line 47:
> 
>> 45:  * Decoding may buffer additional bytes beyond those that have been decoded to characters
>> 46:  * returned to the application. After the first call to one of the {@code readln} methods,
>> 47:  * any subsequent use of {@code System.in} results in unspecified behavior.
> 
> I wonder if we should add a note about mixing API usage into System.in too. There are tutorials and books that show examples build on System.in that will add buffering on that input source.

Might be a good idea. I'll handle this separately. I don't want it to refer to a Preview API. I'll probably just use Scanner and InputStreamReader as examples.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035772247
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035773250

From smarks at openjdk.org  Wed Apr  9 17:05:38 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 9 Apr 2025 17:05:38 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 9 Apr 2025 10:36:53 GMT, Alan Bateman  wrote:

>> The IOError was carried over from Console.readLine(), which throws IOError on error. Of course we're decoupled from Console now, but that was the original reason.
>> 
>> My guess is that Console methods throw IOError because (a) they didn't want to make everybody catch IOException, (b) they didn't want to maintain an internal error state like PrintStream, and (c) they wanted to throw a throwable whose type conveyed the meaning that it wasn't expected to be handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning still applies here.
>> 
>> UncheckedIOException wasn't added until JDK 1.8. Note also that UncheckedIOException has a cause of IOException, so it can't arise from some other throwable. This was used in the previous implementation, where IOError was thrown if Console was null. That doesn't apply anymore, but IOError is still somewhat more flexible than UncheckedIOException in this regard.
>> 
>> I think we need to say something, implicitly or explicitly, about error handling. Note that PrintStream has this internal error state so output is covered already. For input it seems like IOError is reasonable, but maybe there's a better choice.
>
> The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause.
> 
> System.in.close() would a be wild thing to do, but a case where readln would throw IOError.

Ah. Does the specification here need to state the policy around malformed input and unmappable characters? (Or, maybe in the class specification.)

People have ended up in cases where System.in is closed. It can occur when combining use of Scanner to read from System.in and applying the anything-that-you-open-must-be-closed rule, e.g.,

    try (Scanner sc = new Scanner(System.in)) {
        String s = sc.nextLine();
    }

which is a mistake, but it takes a long time to explain....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035784546

From mcimadamore at openjdk.org  Wed Apr  9 17:11:36 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 17:11:36 GMT
Subject: RFR: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported [v2]
In-Reply-To: 
References: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 15:15:10 GMT, Archie Cobbs  wrote:

>> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
>> 
>> Lint warnings that are subject to suppression via `@SuppressWarnings` must be deferred until attribution, because until then we can't determine whether they are suppressed or not.
>> 
>> Whether a lint warning is subject to suppression via `@SuppressWarnings` is a function of the associated `LintCategory`, not the warning itself. For example `LintCategory.OPTIONS` is not, so an occurrence of `@SuppressWarnings("options")` is meaningless and would be ignored.
>> 
>> This information is needed in the upcoming refactoring. We can facilitate that very simply by adding a boolean property to the `LintCategory` enum.
>> 
>> In addition, this permits a small optimization to be added to `Lint.suppressionsFrom()`.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "not yet" comment to TEXT_BLOCKS.

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24529#pullrequestreview-2754179462

From mcimadamore at openjdk.org  Wed Apr  9 17:15:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 17:15:49 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 8 Apr 2025 14:56:41 GMT, Jan Lahoda  wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing variable decl end position.
>
> The new calls to `storeEnd` seem to partly duplicate existing `to`/`toP` calls. That feels a bit unfortunate - as we may be adding new places that create AST node for declarations, and one sometimes forgets to do `to`/`toP` - and forgetting `storeEnd` might lead to weird problems.
> 
> I tried to re-write this part by putting the the set logic directly into the end pos tables here:
> https://github.com/archiecobbs/jdk/compare/JDK-8350212...lahodaj:jdk:JDK-8350212?expand=1
> 
> Notes:
> - I believe the fact that implictly declared classes don't have an end position was intentional at that time. I don't have an issue with changing that, just pointing it out.
> - for blocks, `endpos` is actually pointing at the start of the closing brace, not the end (I think, at least). So, I've renamed the field, but kept the semantics.
> 
> What do you think?

> > I'll leave this to @lahodaj . In my opinion the removal of the `endpos` field in `JCSwitch` adds more code than it removes -- because of that `TreeInfo.endPos` needs a new `EndPosTable` parameter, which means `Flow`/`Lower`/`TransPatterns` needs additional logic to set the end pos table. It's not a complex rewriting, but given that we kind of know we're going to put our hands in here again, I wonder if there could be some merit in being more minimal/pragmatic.
> 
> Well the point of the latest refactoring was to try to remove the storage of duplicate end positions and move to a single unified way of accessing ending positions via `EndPosTable` (the `bracePos` fields are not duplicate, because they point to different positions).
> 
> Your suggestion now is to perhaps go back in the reverse direction. That's not totally crazy, but I feel like now I'm getting mixed messages.
> 
> FWIW my personal opinion is that the `EndPosTable` is readily accessible already, so it's OK to require it, and this makes the code more consistent without special exceptions. Of course it also comes with a small performance penalty - but then I remember [this](https://wiki.c2.com/?PrematureOptimization).

I suppose what I'm saying is that we don't really care about Switch/SwitchExpression/Block. They have their own way to deal with positions (which javac's backend depends on). Fine.

What we care about in this PR is that we have valid end position for all the places where a `@SuppressWarnings` annotation can go. I see this as rather orthogonal from cleaning up all the other spurious pos-like fields in the JCTree hierarchy.

Of course, eventually, we'd like to have a consistent strategy for modelling _all_ end positions -- but it seems to me that it shouldn't be the goal of this PR to get there. Which would suggest that, subjectively, we're better off by leaving existing code be. But again, I defer any final judgment on the matter to @lahodaj

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2790425115

From mcimadamore at openjdk.org  Wed Apr  9 17:20:32 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 17:20:32 GMT
Subject: RFR: 8322810: Lambda expressions can implement classes
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Apr 2025 14:03:03 GMT, Vicente Romero  wrote:

> Currently javac is accepting code like:
> 
> 
> class Test {
>     void m() {
>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>     }
> }
> 
> 
> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
> 
> With this fix this code pattern will be rejected with a compiler error
> 
> TIA

I'm surprised this slipped through the cracks for so long! It seems like that other cases were already failing (e.g. `String & I`) so I wonder what's the difference between those and the new example in the test case...

test/langtools/tools/javac/diags/examples/NotAnInterfaceComponent.java line 29:

> 27: 
> 28: class NotAnInterfaceComponent {
> 29:     Object o = (String & Runnable) ()-> { };

How was this rejected before? The generated compiler keys look strange...

test/langtools/tools/javac/lambda/ClassInIntersectionTypeTest.java line 8:

> 6:  */
> 7: 
> 8: public class ClassInIntersectionTypeTest {

Maybe add a test with an annotation target?

-------------

PR Review: https://git.openjdk.org/jdk/pull/24548#pullrequestreview-2754202633
PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2035802436
PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2035804466

From mcimadamore at openjdk.org  Wed Apr  9 17:29:45 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 17:29:45 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Apr 2025 15:45:23 GMT, Archie Cobbs  wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
> 
> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
> 
> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
> 
> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
> 
> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 184:

> 182:         /** Report all deferred diagnostics in the specified order. */
> 183:         public void reportDeferredDiagnostics(Comparator order) {
> 184:             deferred.sort(order);

So, here there would seem to be a difference in behavior, in that `sort` has a permanent side-effect on `deferred`. But I think this is fine, because at the end of this method we end up setting `deferred = null` anyway, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24553#discussion_r2035817640

From acobbs at openjdk.org  Wed Apr  9 17:40:47 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 17:40:47 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 17:26:21 GMT, Maurizio Cimadamore  wrote:

>> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
>> 
>> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
>> 
>> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
>> 
>> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
>> 
>> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 184:
> 
>> 182:         /** Report all deferred diagnostics in the specified order. */
>> 183:         public void reportDeferredDiagnostics(Comparator order) {
>> 184:             deferred.sort(order);
> 
> So, here there would seem to be a difference in behavior, in that `sort` has a permanent side-effect on `deferred`. But I think this is fine, because at the end of this method we end up setting `deferred = null` anyway, right?

Yes, that's my thought too - we are indeed changing the list, but who cares because we're about to discard it. Of course the discarding is done indirectly by `reportDeferredDiagnostics()`, not by this method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24553#discussion_r2035834713

From alanb at openjdk.org  Wed Apr  9 17:55:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 17:55:47 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 2 Apr 2025 16:59:16 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - avoiding hardcoded constants.

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 415:

> 413:                 if (major >= 54
> 414:                     && mods.contains(Requires.Modifier.STATIC)) {
> 415:                     String flagName = "ACC_STATIC_PHASE";

A minor comment on the style here, do you mind combin L413+414 as it will make it easier to read. The change is okay of course.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2035855402

From weijun at openjdk.org  Wed Apr  9 18:15:03 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Apr 2025 18:15:03 GMT
Subject: RFR: 8353888: Implement Key Derivation Function API [v3]
In-Reply-To: 
References: 
Message-ID: 

> Finalize the KDF API.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  update @since tags as required by JEP 12

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/66706a50..a55c5069

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=01-02

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520

PR: https://git.openjdk.org/jdk/pull/24520

From vromero at openjdk.org  Wed Apr  9 19:59:30 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Apr 2025 19:59:30 GMT
Subject: RFR: 8322810: Lambda expressions can implement classes
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 17:15:52 GMT, Maurizio Cimadamore  wrote:

>> Currently javac is accepting code like:
>> 
>> 
>> class Test {
>>     void m() {
>>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>>     }
>> }
>> 
>> 
>> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
>> 
>> With this fix this code pattern will be rejected with a compiler error
>> 
>> TIA
>
> test/langtools/tools/javac/diags/examples/NotAnInterfaceComponent.java line 29:
> 
>> 27: 
>> 28: class NotAnInterfaceComponent {
>> 29:     Object o = (String & Runnable) ()-> { };
> 
> How was this rejected before? The generated compiler keys look strange...

it was rejected because javac was trying to determine the function descriptor associated with the supposed functional interface that could be derived from the intersection of `String & Runnable` a this is impossible then it was failing. This check is at `DescriptorCache::findDescriptorInternal`. But if we have an empty class as in the test case that shows the bug that only inherits from `j.l.Object` but doesn't defines any other method, then javac was only seeing the method defined in the interface and thus a function descriptor was "found". See that the filter `DescriptorFilter` used by `DescriptorCache::findDescriptorInternal` all methods already defined in `j.l.Object`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2036052458

From jlu at openjdk.org  Wed Apr  9 21:28:41 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Apr 2025 21:28:41 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
Message-ID: 

On Wed, 9 Apr 2025 15:06:32 GMT, Magnus Ihse Bursie  wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Convert the merged master changes to UTF-8
>>  - Merge master and fix conflicts
>>  - Close streams when finished loading into props
>>  - Adjust CF test to read in with UTF-8 to fix failing test
>>  - Reconvert CS.properties to UTF-8
>>  - Revert all changes to CurrencySymbols.properties
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
> 
>> 20: # Peter Smolik
>> 21: Cp1250 WINDOWS-1250 0x00FF
>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
> 
> This does not seem to have been a correct conversion.

Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)

Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036165417

From liach at openjdk.org  Wed Apr  9 22:59:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 22:59:27 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang  wrote:

>> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
>> 
>> Testing: built locally, running tier 1-3 tests
>> 
>> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - 8352748: Remove com.sun.tools.classfile from the JDK
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Tier 1-3 tests all pass. Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24528#issuecomment-2791008239

From liach at openjdk.org  Wed Apr  9 23:02:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 23:02:34 GMT
Subject: Integrated: 8352748: Remove com.sun.tools.classfile from the JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang  wrote:

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

This pull request has now been integrated.

Changeset: 5c438c5e
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/5c438c5e6b636a7992cbd737de0735070e480061
Stats:     10015 lines in 70 files changed: 0 ins; 10009 del; 6 mod

8352748: Remove com.sun.tools.classfile from the JDK

Reviewed-by: ihse, jlahoda, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/24528

From jlahoda at openjdk.org  Thu Apr 10 01:03:01 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 01:03:01 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
Message-ID: 

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Add clause about handling of malformed/unmappable bytes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/33e280df..05cc336e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438

PR: https://git.openjdk.org/jdk/pull/24438

From smarks at openjdk.org  Thu Apr 10 01:06:43 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 10 Apr 2025 01:06:43 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <2WoKJPTnP6NRxytTHtqJoi_8b-gAT1vd3YgO2swg_9U=.69c3746e-97cc-485e-8742-b92c1fbc4367@github.com>

On Wed, 9 Apr 2025 17:02:52 GMT, Stuart Marks  wrote:

>> The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause.
>> 
>> System.in.close() would a be wild thing to do, but a case where readln would throw IOError.
>
> Ah. Does the specification here need to state the policy around malformed input and unmappable characters? (Or, maybe in the class specification.)
> 
> People have ended up in cases where System.in is closed. It can occur when combining use of Scanner to read from System.in and applying the anything-that-you-open-must-be-closed rule, e.g.,
> 
>     try (Scanner sc = new Scanner(System.in)) {
>         String s = sc.nextLine();
>     }
> 
> which is a mistake, but it takes a long time to explain....

I added a clause to the class specification that covers malformed/unmappable byte sequences.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2036340667

From vromero at openjdk.org  Thu Apr 10 01:28:18 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Apr 2025 01:28:18 GMT
Subject: RFR: 8322810: Lambda expressions can implement classes [v2]
In-Reply-To: 
References: 
Message-ID: 

> Currently javac is accepting code like:
> 
> 
> class Test {
>     void m() {
>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>     }
> }
> 
> 
> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
> 
> With this fix this code pattern will be rejected with a compiler error
> 
> TIA

Vicente Romero 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-8322810
 - modifying comment
 - 8322810: Lambda expressions can implement classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24548/files
  - new: https://git.openjdk.org/jdk/pull/24548/files/3e8bdc16..16a0ad4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=00-01

  Stats: 3639 lines in 120 files changed: 1307 ins; 1473 del; 859 mod
  Patch: https://git.openjdk.org/jdk/pull/24548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24548/head:pull/24548

PR: https://git.openjdk.org/jdk/pull/24548

From vromero at openjdk.org  Thu Apr 10 01:55:43 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Apr 2025 01:55:43 GMT
Subject: RFR: 8322810: Lambda expressions can implement classes [v3]
In-Reply-To: 
References: 
Message-ID: 

> Currently javac is accepting code like:
> 
> 
> class Test {
>     void m() {
>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>     }
> }
> 
> 
> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
> 
> With this fix this code pattern will be rejected with a compiler error
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24548/files
  - new: https://git.openjdk.org/jdk/pull/24548/files/16a0ad4d..8e7a65e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=01-02

  Stats: 8 lines in 3 files changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24548/head:pull/24548

PR: https://git.openjdk.org/jdk/pull/24548

From vromero at openjdk.org  Thu Apr 10 03:00:24 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Apr 2025 03:00:24 GMT
Subject: RFR: 8322810: Lambda expressions can implement classes [v4]
In-Reply-To: 
References: 
Message-ID: 

> Currently javac is accepting code like:
> 
> 
> class Test {
>     void m() {
>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>     }
> }
> 
> 
> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
> 
> With this fix this code pattern will be rejected with a compiler error
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  allow annotations as functional interfaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24548/files
  - new: https://git.openjdk.org/jdk/pull/24548/files/8e7a65e6..2e641029

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=02-03

  Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24548/head:pull/24548

PR: https://git.openjdk.org/jdk/pull/24548

From vromero at openjdk.org  Thu Apr 10 03:04:33 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Apr 2025 03:04:33 GMT
Subject: RFR: 8322810: Lambda expressions can implement classes [v4]
In-Reply-To: 
References: 
 
Message-ID: <4YM9yRuBB1b8J1XNmBDR8S3ShL-cp0eM7Eb3p5n4vLQ=.28a19d3c-b7ab-48f2-b6ee-0ce30fb308b0@github.com>

On Thu, 10 Apr 2025 03:00:24 GMT, Vicente Romero  wrote:

>> Currently javac is accepting code like:
>> 
>> 
>> class Test {
>>     void m() {
>>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>>     }
>> }
>> 
>> 
>> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
>> 
>> With this fix this code pattern will be rejected with a compiler error
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   allow annotations as functional interfaces

strongly related to this change: javac is issuing an error implying that annotations can't be functional interfaces. But annotations inherit from `java.lang.annotation.Annotation` which is a rightful functional interface, I wonder if we should annotate it as such. So I have included a small change to allow for this. I can split it in a separate one but it will be weird allowing annotations in intersection types as lambda targets but not if used as an independent type

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24548#issuecomment-2791426879

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 21:26:15 GMT, Justin Lu  wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
>> 
>>> 20: # Peter Smolik
>>> 21: Cp1250 WINDOWS-1250 0x00FF
>>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
>> 
>> This does not seem to have been a correct conversion.
>
> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
> 
> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036695622

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 
 
Message-ID: 

On Thu, 10 Apr 2025 07:31:37 GMT, Magnus Ihse Bursie  wrote:

>> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
>> 
>> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.
>
> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036696723

From eirbjo at openjdk.org  Thu Apr 10 08:10:42 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:10:42 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 
 
 
Message-ID: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>

On Thu, 10 Apr 2025 07:32:18 GMT, Magnus Ihse Bursie  wrote:

>> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.
>
> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

Some observations: 

1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?

2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.

3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`

4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:


byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
String decoded = new String(origBytes, StandardCharsets.UTF_8);
byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
String hex = HexFormat.of().formatHex(encoded);
assertEquals("efbfbd", hex);
``` 

Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036767319

From ihse at openjdk.org  Thu Apr 10 08:38:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:38:38 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 
 
 
 <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
Message-ID: 

On Thu, 10 Apr 2025 08:08:02 GMT, Eirik Bj?rsn?s  wrote:

>> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.
>
> Some observations: 
> 
> 1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?
> 
> 2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.
> 
> 3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`
> 
> 4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:
> 
> 
> byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
> String decoded = new String(origBytes, StandardCharsets.UTF_8);
> byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
> String hex = HexFormat.of().formatHex(encoded);
> assertEquals("efbfbd", hex);
> ``` 
> 
> Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

> This PR seems to have been abondoned, so perhaps this discussion belongs in https://github.com/openjdk/jdk/pull/15694 ?

Oh, I didn't notice this was supplanted by another PR. It might be better to continue there, yes. Even if closed PRs seldom are the best places to conduct discussions, I think it might be a good idea to scrutinize all files modified by this script.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036820765

From ihse at openjdk.org  Thu Apr 10 08:41:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:41:45 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu  wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Continuing the discussion that was started at a predecessor to this PR, https://github.com/openjdk/jdk/pull/12726#discussion_r2035582242. At least one incorrect conversion has been found in this PR. It might be worthwhile to double- and triple-check all the other conversions as well.

As part of https://bugs.openjdk.org/browse/JDK-8301971 I am trying various ways of detecting files without UTF-8 encoding, but it is still a bit of hit and miss, since there are no surefire way of telling which encoding a file has, only heuristics. So finding and following up potential sources of error is important.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791991649
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791997157

From eirbjo at openjdk.org  Thu Apr 10 08:48:37 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:48:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: 
References: 
 
Message-ID: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu  wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

FWIW, I checked out the revision of the commit previous to this change and found the following:


% git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
% find src -name "*.properties" | xargs file | grep -v ASCII
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
  ISO-8859 text
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
  Unicode text, UTF-8 text, with very long lines (322)


Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792014164

From ihse at openjdk.org  Thu Apr 10 09:45:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 09:45:56 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu  wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Thanks for checking!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792170460

From mcimadamore at openjdk.org  Thu Apr 10 13:48:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 13:48:52 GMT
Subject: RFR: 8322810: Lambda expressions can implement classes [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 9 Apr 2025 19:54:07 GMT, Vicente Romero  wrote:

>> test/langtools/tools/javac/diags/examples/NotAnInterfaceComponent.java line 29:
>> 
>>> 27: 
>>> 28: class NotAnInterfaceComponent {
>>> 29:     Object o = (String & Runnable) ()-> { };
>> 
>> How was this rejected before? The generated compiler keys look strange...
>
> it was rejected because javac was trying to determine the function descriptor associated with the supposed functional interface that could be derived from the intersection of `String & Runnable` a this is impossible then it was failing. This check is at `DescriptorCache::findDescriptorInternal`. But if we have an empty class as in the test case that shows the bug that only inherits from `j.l.Object` but doesn't defines any other method, then javac was only seeing the method defined in the interface and thus a function descriptor was "found". See that the filter `DescriptorFilter` used by `DescriptorCache::findDescriptorInternal` all methods already defined in `j.l.Object`

I see - I did some debugging, and the issue with `String` is that there's more abstracts methods like `describeConstable` -- which then trigger a compilation error. I agree that it's better to validate the intersection type upfront.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2037454671

From mcimadamore at openjdk.org  Thu Apr 10 13:53:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 13:53:35 GMT
Subject: RFR: 8322810: Lambda expressions can implement classes [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 03:00:24 GMT, Vicente Romero  wrote:

>> Currently javac is accepting code like:
>> 
>> 
>> class Test {
>>     void m() {
>>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>>     }
>> }
>> 
>> 
>> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
>> 
>> With this fix this code pattern will be rejected with a compiler error
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   allow annotations as functional interfaces

Re annotations, I'm not sure.

The javadoc for `@FunctionalInterface` says:


 * 
If a type is annotated with this annotation type, compilers are
 * required to generate an error message unless:
 *
 * 
    
 * 
  •  The type is an interface type and not an annotation type, enum, or class.
 * 
  •  The annotated type satisfies the requirements of a functional interface.
 * 

 ```

So, annotations seem to be excluded there. I can't find something in the JLS though -- but it strikes me as an oversight. We fixed this here

https://bugs.openjdk.org/browse/JDK-8005299

After it was reported that one could create new annotation instances using lambda expressions. While this might be ok, I don't recall we made a deliberate decision to support this, which is why we disabled support for annotations. It seems that the JLS never got the memo.

I'd suggest to fix the issue in front of us, and maybe start a separate discussion on what is the fate of annotations and functional interfaces (to be fixed in another PR).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24548#issuecomment-2793252187

From mcimadamore at openjdk.org  Thu Apr 10 14:09:45 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 14:09:45 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: 
References: 
Message-ID: <4h5UCyj1741PhAs78B3mslLLBTeR-I-1tiqF0jY8FhA=.6f1ab892-1893-498b-ba4a-21d5228f5e65@github.com>

On Wed, 9 Apr 2025 15:45:23 GMT, Archie Cobbs  wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
> 
> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
> 
> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
> 
> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
> 
> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

Looks good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24553#pullrequestreview-2756989330

From mcimadamore at openjdk.org  Thu Apr 10 14:09:46 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 14:09:46 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 9 Apr 2025 17:38:10 GMT, Archie Cobbs  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 184:
>> 
>>> 182:         /** Report all deferred diagnostics in the specified order. */
>>> 183:         public void reportDeferredDiagnostics(Comparator order) {
>>> 184:             deferred.sort(order);
>> 
>> So, here there would seem to be a difference in behavior, in that `sort` has a permanent side-effect on `deferred`. But I think this is fine, because at the end of this method we end up setting `deferred = null` anyway, right?
>
> Yes, that's my thought too - we are indeed changing the list, but who cares because we're about to discard it. Of course the discarding is done indirectly by `reportDeferredDiagnostics()`, not by this method.

As usual -- maybe add comments to capture this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24553#discussion_r2037512331

From acobbs at openjdk.org  Thu Apr 10 14:31:10 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 14:31:10 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
> 
> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
> 
> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
> 
> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
> 
> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add comment per review suggestion.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24553/files
  - new: https://git.openjdk.org/jdk/pull/24553/files/2e68d7a3..dc3b98c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24553&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24553&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24553.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24553/head:pull/24553

PR: https://git.openjdk.org/jdk/pull/24553

From acobbs at openjdk.org  Thu Apr 10 14:31:10 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 14:31:10 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 14:06:13 GMT, Maurizio Cimadamore  wrote:

>> Yes, that's my thought too - we are indeed changing the list, but who cares because we're about to discard it. Of course the discarding is done indirectly by `reportDeferredDiagnostics()`, not by this method.
>
> As usual -- maybe add comments to capture this

Done in dc3b98c2685 - thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24553#discussion_r2037557820

From acobbs at openjdk.org  Thu Apr 10 14:49:36 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 14:49:36 GMT
Subject: Integrated: 8354090: Refactor import warning suppression in Check.java
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Apr 2025 01:20:50 GMT, Archie Cobbs  wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> In JDK 9 and later, there is a special exception to the normal rules for deprecation and preview warnings, which is that these warnings are automatically suppressed for import statements. This is because an import statement is just a lexical shortcut, not an actual use of the symbol.
> 
> The current code in `Check.java` implements this by manipulating the current `Lint` instance directly, but this operation is incompatible upcoming changes to deferred lint handling. Instead, there can be an explicit flag for "import warning suppression" in `Check.java` to handle this. This will also make the code a bit clearer.

This pull request has now been integrated.

Changeset: e50af6db
Author:    Archie Cobbs 
URL:       https://git.openjdk.org/jdk/commit/e50af6db099145149d704026e91fcc7bb188fc1b
Stats:     33 lines in 3 files changed: 12 ins; 10 del; 11 mod

8354090: Refactor import warning suppression in Check.java

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/24532

From mcimadamore at openjdk.org  Thu Apr 10 15:00:44 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:00:44 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 14:31:10 GMT, Archie Cobbs  wrote:

>> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
>> 
>> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
>> 
>> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
>> 
>> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
>> 
>> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment per review suggestion.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24553#pullrequestreview-2757189892

From cushon at openjdk.org  Thu Apr 10 15:19:40 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 10 Apr 2025 15:19:40 GMT
Subject: RFR: 8347291: Exhaustive switch over a generic sealed abstract
 class [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 6 Apr 2025 04:52:12 GMT, Liam Miller-Cushon  wrote:

>> This change avoids javac incorrectly reporting switches like the example in [JDK-8347291](https://bugs.openjdk.org/browse/JDK-8347291) as exhaustive.
>> 
>> As Jan noted in the bug it seems like the inference behaviour here may not be correct. If it was able to infer a type without crashing that would also avoid the bug.
>> 
>> However with the current inference behaviour, it's safer to assume that if inference crashes the subtype may need to be handled by the switch, instead of assuming that it doesn't.
>
> Liam Miller-Cushon 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 four additional commits since the last revision:
> 
>  - Handle error types in InferenceUnitTest
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - 8347291: Exhaustive switch over a generic sealed abstract class

> Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Any thoughts on this? To me false positives in exhaustiveness checking seem a lot worse than false negatives, and the principled fix to inference to avoid the crash seems like it's going to be more challenging. I think in the short term there's a argument for making this change, so in the rare cases where this comes up the switches need an explicit `default:` instead of getting an unexpected MatchException.

But if this is too hacky, and there's a preference for leaving this alone until there's time to fix the inference crash, that's fine and I can drop the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23286#issuecomment-2794194020

From mcimadamore at openjdk.org  Thu Apr 10 15:23:30 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:23:30 GMT
Subject: RFR: 8352731: Compiler workaround to forcibly set
 "-Xlint:-options" can be removed
In-Reply-To: 
References: 
Message-ID: <_34AokoD9LuAIHfGfb5P3CZ8EHlB0QjzSo65AmCwAOA=.7ae694ab-4d8e-4b8d-bf40-8d9e5c19307d@github.com>

On Sat, 29 Mar 2025 04:18:36 GMT, Archie Cobbs  wrote:

> Back in 2011, in order to prevent repeated warnings about bootclasspath not being set ([JDK-7022337](https://bugs.openjdk.org/browse/JDK-7022337)), code was added to `JavaCompiler.java` to forcibly set the `-Xlint:-options` flag after compiler startup:
> 
>         // forcibly set the equivalent of -Xlint:-options, so that no further
>         // warnings about command line options are generated from this point on
>         options.put(XLINT_CUSTOM.primaryName + "-" + LintCategory.OPTIONS.option, "true");
>         options.remove(XLINT_CUSTOM.primaryName + LintCategory.OPTIONS.option);
> 
> This workaround complicates logic relating to warnings in the `"options"` category and, due to improvements to the compiler design since then, it's no longer needed to actually fix the problem. So it can be removed.
> 
> As a separate cleanup, the field `optionsCheckingInitiallyDisabled` in `JavaCompiler.java` is no longer used and so it can also be removed.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24309#pullrequestreview-2757263801

From acobbs at openjdk.org  Thu Apr 10 15:28:47 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 15:28:47 GMT
Subject: RFR: 8354090: Refactor import warning suppression in Check.java
In-Reply-To: 
References: 
Message-ID: <9JvkcmpM4JGsldyQI7FSWqKbrGWc0T5cqcXRYhX6Qpg=.f31d16d8-9902-4023-b051-4bbce1092aa3@github.com>

On Wed, 9 Apr 2025 01:20:50 GMT, Archie Cobbs  wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> In JDK 9 and later, there is a special exception to the normal rules for deprecation and preview warnings, which is that these warnings are automatically suppressed for import statements. This is because an import statement is just a lexical shortcut, not an actual use of the symbol.
> 
> The current code in `Check.java` implements this by manipulating the current `Lint` instance directly, but this operation is incompatible upcoming changes to deferred lint handling. Instead, there can be an explicit flag for "import warning suppression" in `Check.java` to handle this. This will also make the code a bit clearer.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24532#issuecomment-2794233673

From mcimadamore at openjdk.org  Thu Apr 10 15:36:34 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:36:34 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v3]
In-Reply-To: <09nss6nEIUcdPdrnrpYVYKaQLIHumCz5AqFfuD0F0fw=.03a95547-bb07-4464-a326-828cc2007e7a@github.com>
References: 
 <09nss6nEIUcdPdrnrpYVYKaQLIHumCz5AqFfuD0F0fw=.03a95547-bb07-4464-a326-828cc2007e7a@github.com>
Message-ID: 

On Tue, 25 Mar 2025 16:42:06 GMT, Archie Cobbs  wrote:

>> This PR relates to the `-Xlint:none` flag. Currently, it not only disables all lint categories as one would expect, but it also disables all non-mandatory warnings, period. In other words, `-Xlint:none` has `-nowarn` as a hidden side-effect. So for example, trying to do `-Xlint:none,serial` to enable only the `serial` lint category is futile: the category will be enabled but the warnings won't ever appear. This PR removes that hidden side-effect, and also clarifies some of the help output.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct regression test expected output.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 171:

> 169:     Append to the bootstrap class path
> 170: javac.opt.Xlint=\
> 171:     Enable recommended lint warning categories

I think the use of "mandatory warning" above is good. However, I find the use of `lint warning` a bit too "implementation-related". I believe I liked the old text better, even if it was more vague.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2037690711

From mcimadamore at openjdk.org  Thu Apr 10 15:36:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:36:35 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v3]
In-Reply-To: 
References: 
 <09nss6nEIUcdPdrnrpYVYKaQLIHumCz5AqFfuD0F0fw=.03a95547-bb07-4464-a326-828cc2007e7a@github.com>
 
Message-ID: 

On Thu, 10 Apr 2025 15:30:31 GMT, Maurizio Cimadamore  wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct regression test expected output.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 171:
> 
>> 169:     Append to the bootstrap class path
>> 170: javac.opt.Xlint=\
>> 171:     Enable recommended lint warning categories
> 
> I think the use of "mandatory warning" above is good. However, I find the use of `lint warning` a bit too "implementation-related". I believe I liked the old text better, even if it was more vague.

Related, as part of this PR it might be needed to do a pass on the man pages, to make sure they are in sync -- I see for instance this:

       -nowarn
              Disables warning messages. This option operates the same as the -Xlint:none option.

Which would no longer be valid after this change. E.g.


javac -Xlint:none -Xlint:serial

is not the same as:

javac -nowarn -Xlint:serial

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2037694361

From mcimadamore at openjdk.org  Thu Apr 10 15:36:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:36:35 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v3]
In-Reply-To: 
References: 
 <09nss6nEIUcdPdrnrpYVYKaQLIHumCz5AqFfuD0F0fw=.03a95547-bb07-4464-a326-828cc2007e7a@github.com>
 
 
Message-ID: 

On Thu, 10 Apr 2025 15:32:39 GMT, Maurizio Cimadamore  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 171:
>> 
>>> 169:     Append to the bootstrap class path
>>> 170: javac.opt.Xlint=\
>>> 171:     Enable recommended lint warning categories
>> 
>> I think the use of "mandatory warning" above is good. However, I find the use of `lint warning` a bit too "implementation-related". I believe I liked the old text better, even if it was more vague.
>
> Related, as part of this PR it might be needed to do a pass on the man pages, to make sure they are in sync -- I see for instance this:
> 
>        -nowarn
>               Disables warning messages. This option operates the same as the -Xlint:none option.
> 
> Which would no longer be valid after this change. E.g.
> 
> 
> javac -Xlint:none -Xlint:serial
> 
> is not the same as:
> 
> javac -nowarn -Xlint:serial

I also wonder if the combo `nowarn` + (non-empty lint set) should result in an option warning (as the lint directive will be skipped) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2037696269

From jlahoda at openjdk.org  Thu Apr 10 16:32:32 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 16:32:32 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Apr 2025 19:51:36 GMT, Archie Cobbs  wrote:

>> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
>> 
>> Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available.
>> 
>> The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons.
>> 
>> Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring/cleanup for handling of ending positions.

In the sketch I was doing a few days back, I was peeking at forcing some kind of `EndPosTable` argument to `TreeInfo.endPos`, but I shied away as it seemed to complicate things. Here I see it is not as bad as I thought, but still it spreads a bit.

I see the value in avoiding special field and code path for the AST nodes for which the end pos is mandatory, in addition to the optional EndPosTable.

I think I would still slightly prefer the specialized fields, esp. if the impact on mostly unrelated outside code (like TransPatterns and Gen) could be eliminated. I would like to investigate if we can drop the EndPosTable altogether, although that is unlikely to happen before JDK 25 RPD1 (maybe 2). But, there is, of course, a possibility that the removal of EndPosTable won't happen, at which point we would have the duplication.

But, I can live with a patch long the lines here adding EndPosTable to `TreeInfo.endPos` if needed. Should we drop the EndPosTable as some point, we can drop the new EndPosTable argument. If not, we would preserve it. It is not what I would do, but I don't think either of the solutions is clearly wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2794448022

From acobbs at openjdk.org  Thu Apr 10 16:33:09 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 16:33:09 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR relates to the `-Xlint:none` flag. Currently, it not only disables all lint categories as one would expect, but it also disables all non-mandatory warnings, period. In other words, `-Xlint:none` has `-nowarn` as a hidden side-effect. So for example, trying to do `-Xlint:none,serial` to enable only the `serial` lint category is futile: the category will be enabled but the warnings won't ever appear. This PR removes that hidden side-effect, and also clarifies some of the help output.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Tweak wording changes and sync to man page per review suggestions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24227/files
  - new: https://git.openjdk.org/jdk/pull/24227/files/b6beb828..ffede9b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24227&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24227&range=02-03

  Stats: 10 lines in 2 files changed: 0 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24227/head:pull/24227

PR: https://git.openjdk.org/jdk/pull/24227

From acobbs at openjdk.org  Thu Apr 10 16:33:09 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 16:33:09 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v3]
In-Reply-To: 
References: 
 <09nss6nEIUcdPdrnrpYVYKaQLIHumCz5AqFfuD0F0fw=.03a95547-bb07-4464-a326-828cc2007e7a@github.com>
 
 
 
Message-ID: <0AVImtdOwaxDGPNGzOmt4YXiBQ13t-QC5gYW6_Ss2zc=.e06c4eed-7d2c-4023-8418-b3a39c675603@github.com>

On Thu, 10 Apr 2025 15:33:45 GMT, Maurizio Cimadamore  wrote:

>> Related, as part of this PR it might be needed to do a pass on the man pages, to make sure they are in sync -- I see for instance this:
>> 
>>        -nowarn
>>               Disables warning messages. This option operates the same as the -Xlint:none option.
>> 
>> Which would no longer be valid after this change. E.g.
>> 
>> 
>> javac -Xlint:none -Xlint:serial
>> 
>> is not the same as:
>> 
>> javac -nowarn -Xlint:serial
>
> I also wonder if the combo `nowarn` + (non-empty lint set) should result in an option warning (as the lint directive will be skipped) ?

I agree with your verbiage comments and also thanks for the reminder about the man page.

Both issues should be addressed in ffede9b0508.

>  I also wonder if the combo nowarn + (non-empty lint set) should result in an option warning (as the lint directive will be skipped) ?

I don't think so. For example, it's probably common for people to throw a temporary `-nowarn` into their build process while they work on something. You don't want to have to then _also_ temporarily find and remove the `-Xlint` flags that are normally there (and then remember later to also un-do that).

Put more simply, there's something fishy about having the simple addition of a `-nowarn` flag cause a new warning to appear :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2037815253

From jlahoda at openjdk.org  Thu Apr 10 16:43:35 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 16:43:35 GMT
Subject: RFR: 8347291: Exhaustive switch over a generic sealed abstract
 class [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 6 Apr 2025 04:52:12 GMT, Liam Miller-Cushon  wrote:

>> This change avoids javac incorrectly reporting switches like the example in [JDK-8347291](https://bugs.openjdk.org/browse/JDK-8347291) as exhaustive.
>> 
>> As Jan noted in the bug it seems like the inference behaviour here may not be correct. If it was able to infer a type without crashing that would also avoid the bug.
>> 
>> However with the current inference behaviour, it's safer to assume that if inference crashes the subtype may need to be handled by the switch, instead of assuming that it doesn't.
>
> Liam Miller-Cushon 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 four additional commits since the last revision:
> 
>  - Handle error types in InferenceUnitTest
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - 8347291: Exhaustive switch over a generic sealed abstract class

IIRC, I was looking into this when this came up. I think when I was debugging, there seemed to be incorrectly sorted bounds sent to intersection type, which then broke the rest of the inference machinery. I've had this:
https://github.com/lahodaj/jdk/commit/108e5afa2bca60c5ae9b1270c23865aa615bfe52

But I think, at that time, the idea was to take a better look at the (pattern) inference as a whole.

@mcimadamore - any insights? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23286#issuecomment-2794485669

From acobbs at openjdk.org  Thu Apr 10 17:10:43 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 17:10:43 GMT
Subject: RFR: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported [v2]
In-Reply-To: 
References: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
 
Message-ID: 

On Wed, 9 Apr 2025 15:15:10 GMT, Archie Cobbs  wrote:

>> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
>> 
>> Lint warnings that are subject to suppression via `@SuppressWarnings` must be deferred until attribution, because until then we can't determine whether they are suppressed or not.
>> 
>> Whether a lint warning is subject to suppression via `@SuppressWarnings` is a function of the associated `LintCategory`, not the warning itself. For example `LintCategory.OPTIONS` is not, so an occurrence of `@SuppressWarnings("options")` is meaningless and would be ignored.
>> 
>> This information is needed in the upcoming refactoring. We can facilitate that very simply by adding a boolean property to the `LintCategory` enum.
>> 
>> In addition, this permits a small optimization to be added to `Lint.suppressionsFrom()`.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "not yet" comment to TEXT_BLOCKS.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24529#issuecomment-2794570207

From acobbs at openjdk.org  Thu Apr 10 17:10:44 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 17:10:44 GMT
Subject: Integrated: 8354071: Add LintCategory property indicating whether
 @SuppressWarnings is supported
In-Reply-To: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
References: <7uJk5w2hn380R4vmxeiP4ml9r5WB7YSD8GsSf5j6nsE=.9bdb0403-f144-4924-a6d6-6ee4fe9e2e52@github.com>
Message-ID: 

On Tue, 8 Apr 2025 20:52:09 GMT, Archie Cobbs  wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> Lint warnings that are subject to suppression via `@SuppressWarnings` must be deferred until attribution, because until then we can't determine whether they are suppressed or not.
> 
> Whether a lint warning is subject to suppression via `@SuppressWarnings` is a function of the associated `LintCategory`, not the warning itself. For example `LintCategory.OPTIONS` is not, so an occurrence of `@SuppressWarnings("options")` is meaningless and would be ignored.
> 
> This information is needed in the upcoming refactoring. We can facilitate that very simply by adding a boolean property to the `LintCategory` enum.
> 
> In addition, this permits a small optimization to be added to `Lint.suppressionsFrom()`.

This pull request has now been integrated.

Changeset: 799e5b33
Author:    Archie Cobbs 
URL:       https://git.openjdk.org/jdk/commit/799e5b33a11d252109636dd15d22ed3b6280aad4
Stats:     35 lines in 1 file changed: 25 ins; 0 del; 10 mod

8354071: Add LintCategory property indicating whether @SuppressWarnings is supported

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/24529

From vromero at openjdk.org  Thu Apr 10 17:51:25 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Apr 2025 17:51:25 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v5]
In-Reply-To: 
References: 
Message-ID: 

> Currently javac is accepting code like:
> 
> 
> class Test {
>     void m() {
>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>     }
> }
> 
> 
> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
> 
> With this fix this code pattern will be rejected with a compiler error
> 
> TIA

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - addressing review comments
 - improving error message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24548/files
  - new: https://git.openjdk.org/jdk/pull/24548/files/2e641029..2dcaa548

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=03-04

  Stats: 39 lines in 5 files changed: 21 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/24548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24548/head:pull/24548

PR: https://git.openjdk.org/jdk/pull/24548

From liach at openjdk.org  Thu Apr 10 18:01:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Apr 2025 18:01:57 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v57]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
 
Message-ID: <17CDLKZYKCAtHgc4vB-Y9o1k266gkM4Sy7ZrmUfsjvU=.9328b2a1-36bd-45c8-beab-3b984fb65762@github.com>

On Sun, 6 Apr 2025 10:50:50 GMT, Luca Kellermann  wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
>> 
>>  - Merge branch 'master' into primitive-patterns
>>  - Update summary in ExactnessConversionsSupportTest
>>  - Address review by Jan
>>  - Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
>>  - Small fix in Javadoc
>>  - Tidy up Javadoc of Lower.visitTypeTest
>>  - Tidy up Javadoc of IllegalArgumentException in typeSwitch
>>  - Improve readability in SwitchBootstraps
>>  - Update year
>>  - Cleanup redundant clone
>>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 676:
> 
>> 674:         }
>> 675:         else if (selectorType.equals(targetType) ||
>> 676:                 ((selectorType.equals(byte.class) && !targetType.equals(char.class)) ||
> 
> Suggestion:
> 
>                 ((selectorType.equals(byte.class) && targetType.isPrimitve() && !targetType.equals(boolean.class) && !targetType.equals(char.class)) ||
> 
> Otherwise, `SwitchBootstraps.typeSwitch` produces wrong results for `byte`:
> 
> var l = MethodHandles.lookup();
> var shortType = MethodType.methodType(int.class, short.class, int.class);
> var byteType = MethodType.methodType(int.class, byte.class, int.class);
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(l, "", shortType, String.class);
> CallSite byteSwitch = SwitchBootstraps.typeSwitch(l, "", byteType, String.class);
> 
> int shortIndex = (int) shortSwitch.getTarget().invokeExact((short) 1, 0);
> int byteIndex = (int) byteSwitch.getTarget().invokeExact((byte) 1, 0);
> 
> System.out.println(shortIndex == 1); // true
> System.out.println(byteIndex == 1); // false
> System.out.println(byteIndex); // 0
> 
> This would cause this code to misbehave (if it would compile, which it doesn't):
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> So it isn't really a problem with `javac` but could cause problems for other users of `SwitchBootstraps`.

A JBS issue has been created at https://bugs.openjdk.org/browse/JDK-8354323

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r2037974588

From jlahoda at openjdk.org  Thu Apr 10 18:04:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 18:04:54 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v5]
In-Reply-To: 
References: 
Message-ID: 

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback: cleanup formatting in ModuleInfo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/d66703c1..029e0dd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801

PR: https://git.openjdk.org/jdk/pull/23801

From jlahoda at openjdk.org  Thu Apr 10 18:04:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 18:04:54 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 9 Apr 2025 17:52:26 GMT, Alan Bateman  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback - avoiding hardcoded constants.
>
> src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 415:
> 
>> 413:                 if (major >= 54
>> 414:                     && mods.contains(Requires.Modifier.STATIC)) {
>> 415:                     String flagName = "ACC_STATIC_PHASE";
> 
> A minor comment on the style here, do you mind combin L413+414 as it will make it easier to read. The change is okay of course.

I did this:
https://github.com/openjdk/jdk/pull/23801/commits/029e0dd59c7160f4fe043dd7191860b067ca787c
Please let me know if something more/different is needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2037978491

From mcimadamore at openjdk.org  Thu Apr 10 18:25:32 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 18:25:32 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v3]
In-Reply-To: <0AVImtdOwaxDGPNGzOmt4YXiBQ13t-QC5gYW6_Ss2zc=.e06c4eed-7d2c-4023-8418-b3a39c675603@github.com>
References: 
 <09nss6nEIUcdPdrnrpYVYKaQLIHumCz5AqFfuD0F0fw=.03a95547-bb07-4464-a326-828cc2007e7a@github.com>
 
 
 
 <0AVImtdOwaxDGPNGzOmt4YXiBQ13t-QC5gYW6_Ss2zc=.e06c4eed-7d2c-4023-8418-b3a39c675603@github.com>
Message-ID: 

On Thu, 10 Apr 2025 16:29:57 GMT, Archie Cobbs  wrote:

> Put more simply, there's something fishy about having the simple addition of a `-nowarn` flag cause a new warning to appear :)

That is true :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2038007820

From alanb at openjdk.org  Thu Apr 10 18:30:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Apr 2025 18:30:36 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 18:04:54 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback: cleanup formatting in ModuleInfo.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2757854063

From mcimadamore at openjdk.org  Thu Apr 10 18:33:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 18:33:29 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 16:33:09 GMT, Archie Cobbs  wrote:

>> This PR relates to the `-Xlint:none` flag. Currently, it not only disables all lint categories as one would expect, but it also disables all non-mandatory warnings, period. In other words, `-Xlint:none` has `-nowarn` as a hidden side-effect. So for example, trying to do `-Xlint:none,serial` to enable only the `serial` lint category is futile: the category will be enabled but the warnings won't ever appear. This PR removes that hidden side-effect, and also clarifies some of the help output.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak wording changes and sync to man page per review suggestions.

src/jdk.compiler/share/man/javac.md line 564:

> 562: 
> 563: `-Xlint:`\[`-`\]*key*(`,`\[`-`\]*key*)\*
> 564: :   Specifies warning categories to enable or disable, separated by comma.

This text uses `categories` and `key` in a very loose way -- they seem to refer to the same concept, yet none seems to be defined.


Enables or disables selected warning categories. Each warning category is identified by a key. Some keys allow multiple categories to be enabled or disabled in bulk. Keys are separated by a comma. Precede a key by a hyphen (-) to disable the corresponding warning category.

Supported keys are:
...


What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2038023951

From vromero at openjdk.org  Thu Apr 10 18:37:12 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Apr 2025 18:37:12 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v6]
In-Reply-To: 
References: 
Message-ID: 

> Currently javac is accepting code like:
> 
> 
> class Test {
>     void m() {
>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>     }
> }
> 
> 
> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
> 
> With this fix this code pattern will be rejected with a compiler error
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  minor error in condition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24548/files
  - new: https://git.openjdk.org/jdk/pull/24548/files/2dcaa548..c3ba9234

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24548/head:pull/24548

PR: https://git.openjdk.org/jdk/pull/24548

From jlu at openjdk.org  Thu Apr 10 18:47:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Apr 2025 18:47:53 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
References: 
 
 <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
Message-ID: <9aQcWun5KNgHgELVwkc3478_RtqfhRL1Cxvyn2Yl0Nw=.07ee596f-e738-4796-8d27-14621ed8860c@github.com>

On Thu, 10 Apr 2025 08:44:28 GMT, Eirik Bj?rsn?s  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace InputStreamReader with BufferedReader
>
> FWIW, I checked out the revision of the commit previous to this change and found the following:
> 
> 
> % git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
> % find src -name "*.properties" | xargs file | grep -v ASCII
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
>   ISO-8859 text
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
>   Unicode text, UTF-8 text, with very long lines (322)
> 
> 
> Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

This conversion was performed under the assumption of ASCII set and Unicode escape sequences, which is the format we expect for the translation process for .properties files. That file should have been omitted from this change. Thank you @eirbjo and @magicus for the analysis and checking!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2794828598

From acobbs at openjdk.org  Thu Apr 10 19:30:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 19:30:38 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 18:30:50 GMT, Maurizio Cimadamore  wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak wording changes and sync to man page per review suggestions.
>
> src/jdk.compiler/share/man/javac.md line 564:
> 
>> 562: 
>> 563: `-Xlint:`\[`-`\]*key*(`,`\[`-`\]*key*)\*
>> 564: :   Specifies warning categories to enable or disable, separated by comma.
> 
> This text uses `categories` and `key` in a very loose way -- they seem to refer to the same concept, yet none seems to be defined.
> 
> 
> Enables or disables selected warning categories. Each warning category is identified by a key. Some keys allow multiple categories to be enabled or disabled in bulk. Keys are separated by a comma. Precede a key by a hyphen (-) to disable the corresponding warning category.
> 
> Supported keys are:
> ...
> 
> 
> What do you think?

Yes more words are helpful. I think we also need to say that `all` and `none` can't be preceded by a hyphen (I just learned this not long ago :)

What do you think about this?

`-Xlint:`[`-`]*key*(`,`[`-`]*key*)*
:   Enables and/or disables selected warning categories. Categories are identified by one or more
    keys separated by commas. Keys preceded by a hyphen (`-`) disable the corresponding category;
    hyphens are not supported by the special keys `all` and `none`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2038154547

From acobbs at openjdk.org  Thu Apr 10 20:36:37 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 20:36:37 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 14:31:10 GMT, Archie Cobbs  wrote:

>> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
>> 
>> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
>> 
>> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
>> 
>> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
>> 
>> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment per review suggestion.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24553#issuecomment-2795096193

From acobbs at openjdk.org  Thu Apr 10 20:36:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 20:36:38 GMT
Subject: Integrated: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Apr 2025 15:45:23 GMT, Archie Cobbs  wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
> 
> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
> 
> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
> 
> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
> 
> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

This pull request has now been integrated.

Changeset: 4890b74c
Author:    Archie Cobbs 
URL:       https://git.openjdk.org/jdk/commit/4890b74c048a1472b87687294c316ecfb324e4ba
Stats:     85 lines in 11 files changed: 8 ins; 26 del; 51 mod

8354216: Small cleanups relating to Log.DiagnosticHandler

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/24553

From acobbs at openjdk.org  Thu Apr 10 20:48:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 20:48:27 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 16:30:03 GMT, Jan Lahoda  wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactoring/cleanup for handling of ending positions.
>
> In the sketch I was doing a few days back, I was peeking at forcing some kind of `EndPosTable` argument to `TreeInfo.endPos`, but I shied away as it seemed to complicate things. Here I see it is not as bad as I thought, but still it spreads a bit.
> 
> I see the value in avoiding special field and code path for the AST nodes for which the end pos is mandatory, in addition to the optional EndPosTable.
> 
> I think I would still slightly prefer the specialized fields, esp. if the impact on mostly unrelated outside code (like TransPatterns and Gen) could be eliminated. I would like to investigate if we can drop the EndPosTable altogether, although that is unlikely to happen before JDK 25 RPD1 (maybe 2). But, there is, of course, a possibility that the removal of EndPosTable won't happen, at which point we would have the duplication.
> 
> But, I can live with a patch long the lines here adding EndPosTable to `TreeInfo.endPos` if needed. Should we drop the EndPosTable as some point, we can drop the new EndPosTable argument. If not, we would preserve it. It is not what I would do, but I don't think either of the solutions is clearly wrong.

@lahodaj, thanks for your thoughts.

I agree it's not ideal either way. The thing that kindof pushes it in the `EndPosTable` direction for me is this: As long as we have `DiagnosticListener`'s and `-Xjcov`, we have a (sometimes) requirement to track the ending positions of _every_ node. So as long as we are required to have code that does that, why not just use it? Then we have only one mechanism for doing something, instead of two.

Practically speaking: @mcimadamore are you OK to proceed with the current approach?

In any case, it's not a tragedy if we change our minds in the future - removing `EndPosTable` or switching back to the previous approach is easy to do (and I'm happy to volunteer if needed).

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2795122929

From mcimadamore at openjdk.org  Thu Apr 10 21:01:40 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 21:01:40 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 9 Apr 2025 17:12:53 GMT, Maurizio Cimadamore  wrote:

>> The new calls to `storeEnd` seem to partly duplicate existing `to`/`toP` calls. That feels a bit unfortunate - as we may be adding new places that create AST node for declarations, and one sometimes forgets to do `to`/`toP` - and forgetting `storeEnd` might lead to weird problems.
>> 
>> I tried to re-write this part by putting the the set logic directly into the end pos tables here:
>> https://github.com/archiecobbs/jdk/compare/JDK-8350212...lahodaj:jdk:JDK-8350212?expand=1
>> 
>> Notes:
>> - I believe the fact that implictly declared classes don't have an end position was intentional at that time. I don't have an issue with changing that, just pointing it out.
>> - for blocks, `endpos` is actually pointing at the start of the closing brace, not the end (I think, at least). So, I've renamed the field, but kept the semantics.
>> 
>> What do you think?
>
>> > I'll leave this to @lahodaj . In my opinion the removal of the `endpos` field in `JCSwitch` adds more code than it removes -- because of that `TreeInfo.endPos` needs a new `EndPosTable` parameter, which means `Flow`/`Lower`/`TransPatterns` needs additional logic to set the end pos table. It's not a complex rewriting, but given that we kind of know we're going to put our hands in here again, I wonder if there could be some merit in being more minimal/pragmatic.
>> 
>> Well the point of the latest refactoring was to try to remove the storage of duplicate end positions and move to a single unified way of accessing ending positions via `EndPosTable` (the `bracePos` fields are not duplicate, because they point to different positions).
>> 
>> Your suggestion now is to perhaps go back in the reverse direction. That's not totally crazy, but I feel like now I'm getting mixed messages.
>> 
>> FWIW my personal opinion is that the `EndPosTable` is readily accessible already, so it's OK to require it, and this makes the code more consistent without special exceptions. Of course it also comes with a small performance penalty - but then I remember [this](https://wiki.c2.com/?PrematureOptimization).
> 
> I suppose what I'm saying is that we don't really care about Switch/SwitchExpression/Block. They have their own way to deal with positions (which javac's backend depends on). Fine.
> 
> What we care about in this PR is that we have valid end position for all the places where a `@SuppressWarnings` annotation can go. I see this as rather orthogonal from cleaning up all the other spurious pos-like fields in the JCTree hierarchy.
> 
> Of course, eventually, we'd like to have a consistent strategy for modelling _all_ end positions -- but it seems to me that it shouldn't be the goal of this PR to get there. Which would suggest that, subjectively, we're better off by leaving existing code be. But again, I defer any final judgment on the matter to @lahodaj

> Practically speaking: @mcimadamore are you OK to proceed with the current approach?

I'm ok. I was mildly surprised to see that the patch touched more than I was expecting (e.g. I did not expect we would touch _existing_ position fields, like the ones in switches). I have no strong preference one way or another -- no matter what we do we'd still have two ways to do very similar things -- and, for that reason, I guess my instinct was to go for something more minimal, given we know we're not done here. But I'm fine either way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2795154672

From mcimadamore at openjdk.org  Thu Apr 10 21:06:40 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 21:06:40 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 19:27:21 GMT, Archie Cobbs  wrote:

>> src/jdk.compiler/share/man/javac.md line 564:
>> 
>>> 562: 
>>> 563: `-Xlint:`\[`-`\]*key*(`,`\[`-`\]*key*)\*
>>> 564: :   Specifies warning categories to enable or disable, separated by comma.
>> 
>> This text uses `categories` and `key` in a very loose way -- they seem to refer to the same concept, yet none seems to be defined.
>> 
>> 
>> Enables or disables selected warning categories. Each warning category is identified by a key. Some keys allow multiple categories to be enabled or disabled in bulk. Keys are separated by a comma. Precede a key by a hyphen (-) to disable the corresponding warning category.
>> 
>> Supported keys are:
>> ...
>> 
>> 
>> What do you think?
>
> Yes more words are helpful. I think we also need to say that `all` and `none` can't be preceded by a hyphen (I just learned this not long ago :)
> 
> What do you think about this?
> 
> `-Xlint:`[`-`]*key*(`,`[`-`]*key*)*
> :   Enables and/or disables selected warning categories. Categories are identified by one or more
>     keys separated by commas. Keys preceded by a hyphen (`-`) disable the corresponding category;
>     hyphens are not supported by the special keys `all` and `none`.

It's good --- but I guess I liked to say that a key was either a warning category (serial) or something to enable/disable things in bulk (all/none). This is now missing in the new text.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2038336190

From mcimadamore at openjdk.org  Thu Apr 10 21:13:38 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 21:13:38 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Apr 2025 18:37:12 GMT, Vicente Romero  wrote:

>> Currently javac is accepting code like:
>> 
>> 
>> class Test {
>>     void m() {
>>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>>     }
>> }
>> 
>> 
>> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
>> 
>> With this fix this code pattern will be rejected with a compiler error
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor error in condition

test/langtools/tools/javac/lambda/ClassInIntersectionTypeTest.java line 32:

> 30:     static Class myAnnoType() { return null; }
> 31:     @interface Anno {}
> 32:     Anno a = (Anno & Serializable) ()-> null; // annotations not allowed

Actually, I wonder -- the annotation should not be allowed in any position right? Not just in the first type? E.g. since an annotation is an interface, you can also have:

`Runnable & Anno1 & Anno2`

Do we detect those?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2038343478

From acobbs at openjdk.org  Thu Apr 10 21:40:31 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 21:40:31 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 21:03:33 GMT, Maurizio Cimadamore  wrote:

>> Yes more words are helpful. I think we also need to say that `all` and `none` can't be preceded by a hyphen (I just learned this not long ago :)
>> 
>> What do you think about this?
>> 
>> `-Xlint:`[`-`]*key*(`,`[`-`]*key*)*
>> :   Enables and/or disables selected warning categories. Categories are identified by one or more
>>     keys separated by commas. Keys preceded by a hyphen (`-`) disable the corresponding category;
>>     hyphens are not supported by the special keys `all` and `none`.
>
> It's good --- but I guess I liked to say that a key was either a warning category (serial) or something to enable/disable things in bulk (all/none). This is now missing in the new text.

Hmm how about this:

`-Xlint:`[`-`]*key*(`,`[`-`]*key*)*
:   Enables and/or disables warning categories using the one or more of the keys described
    below separated by commas. The keys `all` and `none` enable or disable all categories
    (respectively); other keys enable the corresponding category, or disable it if preceded
    by a hyphen (`-`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2038377021

From vromero at openjdk.org  Fri Apr 11 00:25:28 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 00:25:28 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 10 Apr 2025 21:10:32 GMT, Maurizio Cimadamore  wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor error in condition
>
> test/langtools/tools/javac/lambda/ClassInIntersectionTypeTest.java line 32:
> 
>> 30:     static Class myAnnoType() { return null; }
>> 31:     @interface Anno {}
>> 32:     Anno a = (Anno & Serializable) ()-> null; // annotations not allowed
> 
> Actually, I wonder -- the annotation should not be allowed in any position right? Not just in the first type? E.g. since an annotation is an interface, you can also have:
> 
> `Runnable & Anno1 & Anno2`
> 
> Do we detect those?

I will add a test

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2038616643

From vromero at openjdk.org  Fri Apr 11 00:43:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 00:43:02 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
Message-ID: 

> Currently javac is accepting code like:
> 
> 
> class Test {
>     void m() {
>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>     }
> }
> 
> 
> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
> 
> With this fix this code pattern will be rejected with a compiler error
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  additional tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24548/files
  - new: https://git.openjdk.org/jdk/pull/24548/files/c3ba9234..7c633986

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=05-06

  Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24548/head:pull/24548

PR: https://git.openjdk.org/jdk/pull/24548

From vromero at openjdk.org  Fri Apr 11 01:15:44 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 01:15:44 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 00:43:02 GMT, Vicente Romero  wrote:

>> Currently javac is accepting code like:
>> 
>> 
>> class Test {
>>     void m() {
>>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>>     }
>> }
>> 
>> 
>> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
>> 
>> With this fix this code pattern will be rejected with a compiler error
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional tests

please review the CSR too, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24548#issuecomment-2795577480

From vromero at openjdk.org  Fri Apr 11 01:15:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 01:15:45 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v6]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 11 Apr 2025 00:22:19 GMT, Vicente Romero  wrote:

>> test/langtools/tools/javac/lambda/ClassInIntersectionTypeTest.java line 32:
>> 
>>> 30:     static Class myAnnoType() { return null; }
>>> 31:     @interface Anno {}
>>> 32:     Anno a = (Anno & Serializable) ()-> null; // annotations not allowed
>> 
>> Actually, I wonder -- the annotation should not be allowed in any position right? Not just in the first type? E.g. since an annotation is an interface, you can also have:
>> 
>> `Runnable & Anno1 & Anno2`
>> 
>> Do we detect those?
>
> I will add a test

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2038650611

From mcimadamore at openjdk.org  Fri Apr 11 08:12:32 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 08:12:32 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v4]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 10 Apr 2025 21:37:32 GMT, Archie Cobbs  wrote:

>> It's good --- but I guess I liked to say that a key was either a warning category (serial) or something to enable/disable things in bulk (all/none). This is now missing in the new text.
>
> Hmm how about this:
> 
> `-Xlint:`[`-`]*key*(`,`[`-`]*key*)*
> :   Enables and/or disables warning categories using the one or more of the keys described
>     below separated by commas. The keys `all` and `none` enable or disable all categories
>     (respectively); other keys enable the corresponding category, or disable it if preceded
>     by a hyphen (`-`).

I think this looks good -- defo better than current the text it replaces.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2039032424

From mcimadamore at openjdk.org  Fri Apr 11 08:13:40 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 08:13:40 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 00:43:02 GMT, Vicente Romero  wrote:

>> Currently javac is accepting code like:
>> 
>> 
>> class Test {
>>     void m() {
>>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>>     }
>> }
>> 
>> 
>> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
>> 
>> With this fix this code pattern will be rejected with a compiler error
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional tests

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24548#pullrequestreview-2759509755

From mcimadamore at openjdk.org  Fri Apr 11 08:32:31 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 08:32:31 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
 
Message-ID: <7rmgCZKEvb2J4oAWlyswZuHHrgKV9xLihslnVu5pACM=.507f1a66-6eb5-42d6-9283-e6c244a87a33@github.com>

On Fri, 11 Apr 2025 08:10:45 GMT, Maurizio Cimadamore  wrote:

> Looks good!

Apologies -- after approving I went to double check the code once again, and noticed something new -- I've left a comment on a possible sharper way to fix this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24548#issuecomment-2796212639

From mcimadamore at openjdk.org  Fri Apr 11 08:32:33 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 08:32:33 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 00:43:02 GMT, Vicente Romero  wrote:

>> Currently javac is accepting code like:
>> 
>> 
>> class Test {
>>     void m() {
>>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>>     }
>> }
>> 
>> 
>> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
>> 
>> With this fix this code pattern will be rejected with a compiler error
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional tests

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 3346:

> 3344:                             }
> 3345:                         }
> 3346:                         if (bound.tsym != syms.objectType.tsym && (!bound.isInterface() || (bound.tsym.flags() & ANNOTATION) != 0)) {

One question: we currently check this condition in `Types.findDescriptorInternal`. That method has this check:


if (!origin.isInterface() || (origin.flags() & ANNOTATION) != 0 || origin.isSealed()) {
                //t must be an interface
                throw failure("not.a.functional.intf", origin);
            }


Where this goes wrong (I think) is that if `origin` is an intersection type, this check fails, because it doesn't recursively check all the components of the intersection. But that would be easy to fix -- e.g. by having a special guard for intersection types.

Digging deeper, the real issue seems to be in how we compute a notional type for the intersection type. The JLS says this (4.9):

> If Ck is Object, a notional interface is induced; otherwise, a notional class is induced with direct superclass type Ck. This class or interface has direct superinterface types T1', ..., Tn' and is declared in the package in which the intersection type appears.

This means that the notional type we create in `Attr.targetChecker` should NOT blindly do this:


                notionalIntf.tsym.flags_field |= INTERFACE;


Instead, it should set the `INTERFACE` flag only if the class component of the intersection is `Object` (as the JLS says).

Once we do this, I'm confident that the existing checks in `Types` will rule out the bad intersection in this issue: because now it would be a class, not an interface -- so the existing check will kick in, and declare it not a suitable functional interface.

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2039066742

From mcimadamore at openjdk.org  Fri Apr 11 09:43:33 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 09:43:33 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 11 Apr 2025 08:29:22 GMT, Maurizio Cimadamore  wrote:

> Instead, it should set the `INTERFACE` flag only if the class component of the intersection is `Object` (as the JLS says).

Note: in principle one might claim that it should be `types.makeIntersectionType` to do this -- but there are complications, in that the method that creates the intersection type is not allowed to to call `flags()` as this method is also called from `ClassReader` at a very delicate time. There's a boolean `allInterfaces` flag that is used there, which we could use to set the optional `INTERFACE` flag on the intersection, but this relies on the assumption that `allInterfaces` is only set if the first bound is an interface (e.g. this tells the code if an extra `Object` supertype has to be injected into the intersection) -- which is not exactly what you want.

What we might do is to say that if `allInterfaces` is set, OR if the `firstExplicitBound` is `syms.objectType` then we treat this as `INTERFACE`. But if this is too difficult to do in general, then it's ok to keep the `Attr` code manually setting the `INTERFACE` flag depending on the bound (as there's no completion to worry about there).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2039190216

From jlahoda at openjdk.org  Fri Apr 11 11:20:30 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 11 Apr 2025 11:20:30 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v6]
In-Reply-To: 
References: 
Message-ID: 

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

Jan Lahoda 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 12 additional commits since the last revision:

 - Adjusting ToolProviderTest to the updated persistence handling.
 - Merge branch 'master' into JDK-8344708
 - Reflecting review feedback: cleanup formatting in ModuleInfo.
 - Reflecting review feedback - avoiding hardcoded constants.
 - Fixing test.
 - Cleanup, fixing tests.
 - Adjusting JShell defaults.
 - Fixing tests.
 - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
 - Cleanup.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/124c1cf4...4c14c3b0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/029e0dd5..4c14c3b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=04-05

  Stats: 213792 lines in 4489 files changed: 97109 ins; 91547 del; 25136 mod
  Patch: https://git.openjdk.org/jdk/pull/23801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801

PR: https://git.openjdk.org/jdk/pull/23801

From acobbs at openjdk.org  Fri Apr 11 13:17:11 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 13:17:11 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v5]
In-Reply-To: 
References: 
Message-ID: <31uo_OrOG4ZKIjvgogxyxodCOUDNX1IUTlACyN_JdkM=.80ce0af7-5cb7-4d2a-8196-786d035fd589@github.com>

> This PR relates to the `-Xlint:none` flag. Currently, it not only disables all lint categories as one would expect, but it also disables all non-mandatory warnings, period. In other words, `-Xlint:none` has `-nowarn` as a hidden side-effect. So for example, trying to do `-Xlint:none,serial` to enable only the `serial` lint category is futile: the category will be enabled but the warnings won't ever appear. This PR removes that hidden side-effect, and also clarifies some of the help output.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Man page wording improvements per review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24227/files
  - new: https://git.openjdk.org/jdk/pull/24227/files/ffede9b0..41ee595d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24227&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24227&range=03-04

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24227/head:pull/24227

PR: https://git.openjdk.org/jdk/pull/24227

From acobbs at openjdk.org  Fri Apr 11 13:29:28 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 13:29:28 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <18CAzYtvsSXvKzGrOaVTOxtIYiG41DkuGzLUrmf83nw=.e54dba3e-9553-44ae-827e-e4d2b90bd2ee@github.com>

On Fri, 11 Apr 2025 08:10:02 GMT, Maurizio Cimadamore  wrote:

>> Hmm how about this:
>> 
>> `-Xlint:`[`-`]*key*(`,`[`-`]*key*)*
>> :   Enables and/or disables warning categories using the one or more of the keys described
>>     below separated by commas. The keys `all` and `none` enable or disable all categories
>>     (respectively); other keys enable the corresponding category, or disable it if preceded
>>     by a hyphen (`-`).
>
> I think this looks good -- defo better than current the text it replaces.

Great, thanks for the suggestions. Updated in 41ee595d8a1.

I will also update the CSR, please take a look at that too if you have time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2039565204

From acobbs at openjdk.org  Fri Apr 11 13:32:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 13:32:38 GMT
Subject: RFR: 8352731: Compiler workaround to forcibly set
 "-Xlint:-options" can be removed
In-Reply-To: 
References: 
Message-ID: <7feDffQlGKwjrB-v0Hq8jh1X1Ps43U3aaFR5NFbQ50o=.e8dd7658-172e-482b-a34e-54d9b016ada1@github.com>

On Sat, 29 Mar 2025 04:18:36 GMT, Archie Cobbs  wrote:

> Back in 2011, in order to prevent repeated warnings about bootclasspath not being set ([JDK-7022337](https://bugs.openjdk.org/browse/JDK-7022337)), code was added to `JavaCompiler.java` to forcibly set the `-Xlint:-options` flag after compiler startup:
> 
>         // forcibly set the equivalent of -Xlint:-options, so that no further
>         // warnings about command line options are generated from this point on
>         options.put(XLINT_CUSTOM.primaryName + "-" + LintCategory.OPTIONS.option, "true");
>         options.remove(XLINT_CUSTOM.primaryName + LintCategory.OPTIONS.option);
> 
> This workaround complicates logic relating to warnings in the `"options"` category and, due to improvements to the compiler design since then, it's no longer needed to actually fix the problem. So it can be removed.
> 
> As a separate cleanup, the field `optionsCheckingInitiallyDisabled` in `JavaCompiler.java` is no longer used and so it can also be removed.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24309#issuecomment-2796919555

From acobbs at openjdk.org  Fri Apr 11 13:32:39 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 13:32:39 GMT
Subject: Integrated: 8352731: Compiler workaround to forcibly set
 "-Xlint:-options" can be removed
In-Reply-To: 
References: 
Message-ID: <_o94AK9xJ-SIlx8Nnhkz0sR6SpbZp4uTv3gqQuouKpA=.5d7eb70a-8533-4a52-9a61-3944244c184a@github.com>

On Sat, 29 Mar 2025 04:18:36 GMT, Archie Cobbs  wrote:

> Back in 2011, in order to prevent repeated warnings about bootclasspath not being set ([JDK-7022337](https://bugs.openjdk.org/browse/JDK-7022337)), code was added to `JavaCompiler.java` to forcibly set the `-Xlint:-options` flag after compiler startup:
> 
>         // forcibly set the equivalent of -Xlint:-options, so that no further
>         // warnings about command line options are generated from this point on
>         options.put(XLINT_CUSTOM.primaryName + "-" + LintCategory.OPTIONS.option, "true");
>         options.remove(XLINT_CUSTOM.primaryName + LintCategory.OPTIONS.option);
> 
> This workaround complicates logic relating to warnings in the `"options"` category and, due to improvements to the compiler design since then, it's no longer needed to actually fix the problem. So it can be removed.
> 
> As a separate cleanup, the field `optionsCheckingInitiallyDisabled` in `JavaCompiler.java` is no longer used and so it can also be removed.

This pull request has now been integrated.

Changeset: e604bb9e
Author:    Archie Cobbs 
URL:       https://git.openjdk.org/jdk/commit/e604bb9e9412310d6d63da0b0f475f9da54ff244
Stats:     15 lines in 1 file changed: 0 ins; 15 del; 0 mod

8352731: Compiler workaround to forcibly set "-Xlint:-options" can be removed

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/24309

From vromero at openjdk.org  Fri Apr 11 14:03:41 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 14:03:41 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 11 Apr 2025 09:40:21 GMT, Maurizio Cimadamore  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 3346:
>> 
>>> 3344:                             }
>>> 3345:                         }
>>> 3346:                         if (bound.tsym != syms.objectType.tsym && (!bound.isInterface() || (bound.tsym.flags() & ANNOTATION) != 0)) {
>> 
>> One question: we currently check this condition in `Types.findDescriptorInternal`. That method has this check:
>> 
>> 
>> if (!origin.isInterface() || (origin.flags() & ANNOTATION) != 0 || origin.isSealed()) {
>>                 //t must be an interface
>>                 throw failure("not.a.functional.intf", origin);
>>             }
>> 
>> 
>> Where this goes wrong (I think) is that if `origin` is an intersection type, this check fails, because it doesn't recursively check all the components of the intersection. But that would be easy to fix -- e.g. by having a special guard for intersection types.
>> 
>> Digging deeper, the real issue seems to be in how we compute a notional type for the intersection type. The JLS says this (4.9):
>> 
>>> If Ck is Object, a notional interface is induced; otherwise, a notional class is induced with direct superclass type Ck. This class or interface has direct superinterface types T1', ..., Tn' and is declared in the package in which the intersection type appears.
>> 
>> This means that the notional type we create in `Attr.targetChecker` should NOT blindly do this:
>> 
>> 
>>                 notionalIntf.tsym.flags_field |= INTERFACE;
>> 
>> 
>> Instead, it should set the `INTERFACE` flag only if the class component of the intersection is `Object` (as the JLS says).
>> 
>> Once we do this, I'm confident that the existing checks in `Types` will rule out the bad intersection in this issue: because now it would be a class, not an interface -- so the existing check will kick in, and declare it not a suitable functional interface.
>> 
>> What do you think?
>
>> Instead, it should set the `INTERFACE` flag only if the class component of the intersection is `Object` (as the JLS says).
> 
> Note: in principle one might claim that it should be `types.makeIntersectionType` to do this -- but there are complications, in that the method that creates the intersection type is not allowed to to call `flags()` as this method is also called from `ClassReader` at a very delicate time. There's a boolean `allInterfaces` flag that is used there, which we could use to set the optional `INTERFACE` flag on the intersection, but this relies on the assumption that `allInterfaces` is only set if the first bound is an interface (e.g. this tells the code if an extra `Object` supertype has to be injected into the intersection) -- which is not exactly what you want.
> 
> What we might do is to say that if `allInterfaces` is set, OR if the `firstExplicitBound` is `syms.objectType` then we treat this as `INTERFACE`. But if this is too difficult to do in general, then it's ok to keep the `Attr` code manually setting the `INTERFACE` flag depending on the bound (as there's no completion to worry about there).

we could do that but I would prefer failing asap, as in `makeNotionalInterface` instead of waiting on `Types.findDescriptorInternal` to do the right thing, semantically we will get to the same point, what you are proposing seems to me like another way to get there but honestly I don't see the gain

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2039620789

From vromero at openjdk.org  Fri Apr 11 14:54:32 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 14:54:32 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 11 Apr 2025 14:00:12 GMT, Vicente Romero  wrote:

>>> Instead, it should set the `INTERFACE` flag only if the class component of the intersection is `Object` (as the JLS says).
>> 
>> Note: in principle one might claim that it should be `types.makeIntersectionType` to do this -- but there are complications, in that the method that creates the intersection type is not allowed to to call `flags()` as this method is also called from `ClassReader` at a very delicate time. There's a boolean `allInterfaces` flag that is used there, which we could use to set the optional `INTERFACE` flag on the intersection, but this relies on the assumption that `allInterfaces` is only set if the first bound is an interface (e.g. this tells the code if an extra `Object` supertype has to be injected into the intersection) -- which is not exactly what you want.
>> 
>> What we might do is to say that if `allInterfaces` is set, OR if the `firstExplicitBound` is `syms.objectType` then we treat this as `INTERFACE`. But if this is too difficult to do in general, then it's ok to keep the `Attr` code manually setting the `INTERFACE` flag depending on the bound (as there's no completion to worry about there).
>
> we could do that but I would prefer failing asap, as in `makeNotionalInterface` instead of waiting on `Types.findDescriptorInternal` to do the right thing, semantically we will get to the same point, what you are proposing seems to me like another way to get there but honestly I don't see the gain

also what would we do if one of the components is an annotation? technically the intersection is still an interface, we could set then the ANNOTATION flag but it seems like a forced move

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2039707277

From mcimadamore at openjdk.org  Fri Apr 11 15:13:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 15:13:29 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v5]
In-Reply-To: <31uo_OrOG4ZKIjvgogxyxodCOUDNX1IUTlACyN_JdkM=.80ce0af7-5cb7-4d2a-8196-786d035fd589@github.com>
References: 
 <31uo_OrOG4ZKIjvgogxyxodCOUDNX1IUTlACyN_JdkM=.80ce0af7-5cb7-4d2a-8196-786d035fd589@github.com>
Message-ID: 

On Fri, 11 Apr 2025 13:17:11 GMT, Archie Cobbs  wrote:

>> This PR relates to the `-Xlint:none` flag. Currently, it not only disables all lint categories as one would expect, but it also disables all non-mandatory warnings, period. In other words, `-Xlint:none` has `-nowarn` as a hidden side-effect. So for example, trying to do `-Xlint:none,serial` to enable only the `serial` lint category is futile: the category will be enabled but the warnings won't ever appear. This PR removes that hidden side-effect, and also clarifies some of the help output.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Man page wording improvements per review comments.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24227#pullrequestreview-2760666020

From mcimadamore at openjdk.org  Fri Apr 11 15:13:30 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 15:13:30 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v4]
In-Reply-To: <18CAzYtvsSXvKzGrOaVTOxtIYiG41DkuGzLUrmf83nw=.e54dba3e-9553-44ae-827e-e4d2b90bd2ee@github.com>
References: 
 
 
 
 
 
 
 <18CAzYtvsSXvKzGrOaVTOxtIYiG41DkuGzLUrmf83nw=.e54dba3e-9553-44ae-827e-e4d2b90bd2ee@github.com>
Message-ID: 

On Fri, 11 Apr 2025 13:26:49 GMT, Archie Cobbs  wrote:

>> I think this looks good -- defo better than current the text it replaces.
>
> Great, thanks for the suggestions. Updated in 41ee595d8a1.
> 
> I will also update the CSR, please take a look at that too if you have time.

> Great, thanks for the suggestions. Updated in [41ee595](https://github.com/openjdk/jdk/commit/41ee595d8a1213a097256899ac3fa10e2a1ad4ae).
> 
> I will also update the CSR, please take a look at that too if you have time.

I've reviewed the CSR -- thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24227#discussion_r2039740548

From mcimadamore at openjdk.org  Fri Apr 11 15:17:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 15:17:29 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Fri, 11 Apr 2025 14:51:30 GMT, Vicente Romero  wrote:

>> we could do that but I would prefer failing asap, as in `makeNotionalInterface` instead of waiting on `Types.findDescriptorInternal` to do the right thing, semantically we will get to the same point, what you are proposing seems to me like another way to get there but honestly I don't see the gain
>
> also what would we do if one of the components is an annotation? technically the intersection is still an interface, we could set then the ANNOTATION flag but it seems like a forced move. Still I agree that, for correctness, we should set the INTERFACE flag at: `makeNotionalInterface` only when applicable

If you want to go with the current code, that's fine by me. It just seemed a bit weird to have the same check in two different places. But we can also clean up in a follow up PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2039744219

From mcimadamore at openjdk.org  Fri Apr 11 15:17:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 15:17:29 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <_8KvYnj3sRM1RWQhXHnDPvSA2Zi_WViNZ7zFzu32qyQ=.523a20c5-eca1-4840-95a5-2088c419c2c4@github.com>

On Fri, 11 Apr 2025 15:13:50 GMT, Maurizio Cimadamore  wrote:

> If you want to go with the current code, that's fine by me. It just seemed a bit weird to have the same check in two different places. But we can also clean up in a follow up PR.

Consider my approval valid :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2039744911

From vromero at openjdk.org  Fri Apr 11 15:19:31 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 15:19:31 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 11:20:30 GMT, Jan Lahoda  wrote:

>> This is a patch to finalize the module imports feature. Please see:
>> https://bugs.openjdk.org/browse/JDK-8344700
>
> Jan Lahoda 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 12 additional commits since the last revision:
> 
>  - Adjusting ToolProviderTest to the updated persistence handling.
>  - Merge branch 'master' into JDK-8344708
>  - Reflecting review feedback: cleanup formatting in ModuleInfo.
>  - Reflecting review feedback - avoiding hardcoded constants.
>  - Fixing test.
>  - Cleanup, fixing tests.
>  - Adjusting JShell defaults.
>  - Fixing tests.
>  - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.
>  - Cleanup.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/950110ae...4c14c3b0

lg

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2760679225

From acobbs at openjdk.org  Fri Apr 11 15:23:25 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 15:23:25 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v5]
In-Reply-To: <31uo_OrOG4ZKIjvgogxyxodCOUDNX1IUTlACyN_JdkM=.80ce0af7-5cb7-4d2a-8196-786d035fd589@github.com>
References: 
 <31uo_OrOG4ZKIjvgogxyxodCOUDNX1IUTlACyN_JdkM=.80ce0af7-5cb7-4d2a-8196-786d035fd589@github.com>
Message-ID: <4BeSb4UGbs1HZZ8tpU6LpFuAYHHmmYFt679WyRPZI0w=.91472776-ae52-4e09-8a51-5540f407fd2c@github.com>

On Fri, 11 Apr 2025 13:17:11 GMT, Archie Cobbs  wrote:

>> This PR relates to the `-Xlint:none` flag. Currently, it not only disables all lint categories as one would expect, but it also disables all non-mandatory warnings, period. In other words, `-Xlint:none` has `-nowarn` as a hidden side-effect. So for example, trying to do `-Xlint:none,serial` to enable only the `serial` lint category is futile: the category will be enabled but the warnings won't ever appear. This PR removes that hidden side-effect, and also clarifies some of the help output.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Man page wording improvements per review comments.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24227#issuecomment-2797216279

From vromero at openjdk.org  Fri Apr 11 15:40:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 15:40:39 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: <_8KvYnj3sRM1RWQhXHnDPvSA2Zi_WViNZ7zFzu32qyQ=.523a20c5-eca1-4840-95a5-2088c419c2c4@github.com>
References: 
 
 
 
 
 
 
 <_8KvYnj3sRM1RWQhXHnDPvSA2Zi_WViNZ7zFzu32qyQ=.523a20c5-eca1-4840-95a5-2088c419c2c4@github.com>
Message-ID: 

On Fri, 11 Apr 2025 15:14:19 GMT, Maurizio Cimadamore  wrote:

> If you want to go with the current code, that's fine by me. It just seemed a bit weird to have the same check in two different places. But we can also clean up in a follow up PR.

I think we will need a component by component check anyways in order to produce more precise error messages, either where it is now or where you are suggesting it to be, just dealing with a flag seems cleaner but won't be as precise I think

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2039801529

From mcimadamore at openjdk.org  Fri Apr 11 15:47:27 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 15:47:27 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
 
 
 
 
 
 <_8KvYnj3sRM1RWQhXHnDPvSA2Zi_WViNZ7zFzu32qyQ=.523a20c5-eca1-4840-95a5-2088c419c2c4@github.com>
 
Message-ID: 

On Fri, 11 Apr 2025 15:38:12 GMT, Vicente Romero  wrote:

> > If you want to go with the current code, that's fine by me. It just seemed a bit weird to have the same check in two different places. But we can also clean up in a follow up PR.
> 
> I think we will need a component by component check anyways in order to produce more precise error messages, either where it is now or where you are suggesting it to be, just dealing with a flag seems cleaner but won't be as precise I think

Yes, but maybe after we revisit (e.g. if we allow annotations), then we can cleanup (later) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24548#discussion_r2039822641

From vromero at openjdk.org  Fri Apr 11 15:52:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 15:52:55 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v8]
In-Reply-To: 
References: 
Message-ID: 

> Currently javac is accepting code like:
> 
> 
> class Test {
>     void m() {
>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>     }
> }
> 
> 
> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
> 
> With this fix this code pattern will be rejected with a compiler error
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  fixing bug in test, variables with same name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24548/files
  - new: https://git.openjdk.org/jdk/pull/24548/files/7c633986..427fa6dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24548&range=06-07

  Stats: 14 lines in 2 files changed: 0 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24548/head:pull/24548

PR: https://git.openjdk.org/jdk/pull/24548

From vromero at openjdk.org  Fri Apr 11 15:55:37 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 15:55:37 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 00:43:02 GMT, Vicente Romero  wrote:

>> Currently javac is accepting code like:
>> 
>> 
>> class Test {
>>     void m() {
>>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>>     }
>> }
>> 
>> 
>> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
>> 
>> With this fix this code pattern will be rejected with a compiler error
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional tests

I had a minor bug in the test, duplicated variable names, so I will need another approval plus a review of the CSR to fast-track it. Thanks for all the comments!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24548#issuecomment-2797318079

From mcimadamore at openjdk.org  Fri Apr 11 15:59:31 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Apr 2025 15:59:31 GMT
Subject: RFR: 8322810: Lambda expression types can't be classes [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 11 Apr 2025 15:52:55 GMT, Vicente Romero  wrote:

>> Currently javac is accepting code like:
>> 
>> 
>> class Test {
>>     void m() {
>>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>>     }
>> }
>> 
>> 
>> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
>> 
>> With this fix this code pattern will be rejected with a compiler error
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing bug in test, variables with same name

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24548#pullrequestreview-2760823724

From acobbs at openjdk.org  Fri Apr 11 20:01:34 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 20:01:34 GMT
Subject: RFR: 8354447: Missing test for retroactive
 @SuppressWarnings("dangling-doc-comments") behavior
Message-ID: 

This PR adds a regression test for the "retroactive" behavior of `@SuppressWarnings("dangling-doc-comments")`, that is,  the warning suppression applies to comments preceding the declaration that the annotation annotates, even though those comments are not within the lexical scope of that declaration. Previously there was no test for this behavior.

-------------

Commit messages:
 - Add test for retroactive @SuppressWarnings("dangling-doc-comments") behavior.

Changes: https://git.openjdk.org/jdk/pull/24600/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24600&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354447
  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24600/head:pull/24600

PR: https://git.openjdk.org/jdk/pull/24600

From acobbs at openjdk.org  Fri Apr 11 20:40:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 20:40:33 GMT
Subject: RFR: 8350514: Refactor MandatoryWarningHandler to support dynamic
 verbosity
In-Reply-To: <1F8PWZXfI4GP2YUyuO5C_49j5LV2GM_vBm3vs7Z6PA0=.e530aaf5-3842-4d84-923e-7e86d348688a@github.com>
References: <1F8PWZXfI4GP2YUyuO5C_49j5LV2GM_vBm3vs7Z6PA0=.e530aaf5-3842-4d84-923e-7e86d348688a@github.com>
Message-ID: 

On Fri, 21 Feb 2025 20:42:10 GMT, Archie Cobbs  wrote:

> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> The `MandatoryWarningHandler` is used by the `preview`, `deprecation`, `removal`, and `unchecked` mandatory warnings. The constructor takes a boolean `verbose` flag which is documented to "Specify whether or not detailed messages about individual instances should be given, or whether an aggregate message should be generated at the end of the compilation."
> 
> The problem is that this flag doesn't really make sense for warnings that are suppressible via `@SuppressWarnings`: for such warnings, what we actually want to do is trigger the aggregate message at the end of compilation if and only if there were any warnings that were not suppressed by `@SuppressWarnings` but _were_ suppressed because the corresponding lint category was not enabled, either because it wasn't enabled by default, or due to an explicit `-Xlint:-foo` flag.
> 
> Currently, we get that same net result, because `preview` is not suppressible via `@SuppressWarnings`, and for the other three categories there is logic around the calls to `MandatoryWarningHandler.report()` to ensure the right thing happens.
> 
> It would be simpler and more straightforward for the users of `MandatoryWarningHandler` to just pass along the currently applicable `Lint` instance and let `MandatoryWarningHandler` keep track of whether to generate the aggregate message at the end of the compilation.

Closing this PR. It's being made obsolete by #24584.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23730#issuecomment-2797967060

From acobbs at openjdk.org  Fri Apr 11 20:40:34 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 20:40:34 GMT
Subject: Withdrawn: 8350514: Refactor MandatoryWarningHandler to support
 dynamic verbosity
In-Reply-To: <1F8PWZXfI4GP2YUyuO5C_49j5LV2GM_vBm3vs7Z6PA0=.e530aaf5-3842-4d84-923e-7e86d348688a@github.com>
References: <1F8PWZXfI4GP2YUyuO5C_49j5LV2GM_vBm3vs7Z6PA0=.e530aaf5-3842-4d84-923e-7e86d348688a@github.com>
Message-ID: 

On Fri, 21 Feb 2025 20:42:10 GMT, Archie Cobbs  wrote:

> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> The `MandatoryWarningHandler` is used by the `preview`, `deprecation`, `removal`, and `unchecked` mandatory warnings. The constructor takes a boolean `verbose` flag which is documented to "Specify whether or not detailed messages about individual instances should be given, or whether an aggregate message should be generated at the end of the compilation."
> 
> The problem is that this flag doesn't really make sense for warnings that are suppressible via `@SuppressWarnings`: for such warnings, what we actually want to do is trigger the aggregate message at the end of compilation if and only if there were any warnings that were not suppressed by `@SuppressWarnings` but _were_ suppressed because the corresponding lint category was not enabled, either because it wasn't enabled by default, or due to an explicit `-Xlint:-foo` flag.
> 
> Currently, we get that same net result, because `preview` is not suppressible via `@SuppressWarnings`, and for the other three categories there is logic around the calls to `MandatoryWarningHandler.report()` to ensure the right thing happens.
> 
> It would be simpler and more straightforward for the users of `MandatoryWarningHandler` to just pass along the currently applicable `Lint` instance and let `MandatoryWarningHandler` keep track of whether to generate the aggregate message at the end of the compilation.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23730

From acobbs at openjdk.org  Fri Apr 11 21:43:40 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 21:43:40 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features [v17]
In-Reply-To: 
References: 
 
Message-ID: <6qH41hWwffhBf0--QExBUvUb__Hl7pB7MsZ3A9Y3JE0=.878e59c7-8b32-4588-8daa-11a9bec81cb5@github.com>

On Fri, 28 Feb 2025 23:02:31 GMT, Archie Cobbs  wrote:

>> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.
>> 
>> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's:
>> * #23167
>> * #23281
>> * #23400
>> * #23730
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix inconsistent bracket styling.

Closing this PR. It's being made obsolete by #24584.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2798058330

From acobbs at openjdk.org  Fri Apr 11 21:43:41 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Apr 2025 21:43:41 GMT
Subject: Withdrawn: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features
In-Reply-To: 
References: 
Message-ID: 

On Wed, 22 Jan 2025 16:15:40 GMT, Archie Cobbs  wrote:

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.
> 
> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's:
> * #23167
> * #23281
> * #23400
> * #23730

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23237

From nbenalla at openjdk.org  Mon Apr 14 12:53:26 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 14 Apr 2025 12:53:26 GMT
Subject: RFR: 8346785: Potential infinite loop in JavadocTokenizer.ensures
Message-ID: 

Please review this patch to fix a potential infinite loop in `JavadocTokenizer.ensure` when `map.length` and `size + need` approach Interger.MAX_VALUE.

While I couldn't reproduce the issue even with large inputs (~1.9GB java file where almost the entire file is one javadoc comment), the fix is about correctness and prevention of UB in extreme cases.

TIA

-------------

Commit messages:
 - fix JdT.ensure

Changes: https://git.openjdk.org/jdk/pull/24620/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24620&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346785
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24620/head:pull/24620

PR: https://git.openjdk.org/jdk/pull/24620

From jlahoda at openjdk.org  Mon Apr 14 12:53:45 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Apr 2025 12:53:45 GMT
Subject: RFR: 8353565: Javac throws "inconsistent stack types at join point"
 exception
Message-ID: 

Consider code like:

public class T {
    private Object computeTypeAtMergePoint1(int i) {
        return (Object) switch (i) {
            case 0 -> switch (i) {
                case 0 -> { yield new A(); }
                default -> { yield new B(); }
            };
            default -> switch (i) {
                case 0 -> { yield new C(); }
                default -> { yield new D(); }
            };
        };
    }
    enum E {A, B}
    interface I1 {}
    class A implements I1 {}
    class B implements I1 {}
    interface I2 {}
    class C implements I2 {}
    class D implements I2 {}

}


Compiling this leads to a crash:

$ .../jdk-24/bin/javac  /tmp/T.java 
An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError: inconsistent stack types at join point
        at jdk.compiler/com.sun.tools.javac.jvm.Code$State.error(Code.java:1824)
        at jdk.compiler/com.sun.tools.javac.jvm.Code$State.join(Code.java:1814)
        at jdk.compiler/com.sun.tools.javac.jvm.Code.resolve(Code.java:1525)
        at jdk.compiler/com.sun.tools.javac.jvm.Code.resolvePending(Code.java:1556)
        at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop(Code.java:382)
        at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:511)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1905)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1773)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:609)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:660)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.internalVisitBlock(Gen.java:1121)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1085)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1137)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:949)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:912)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:961)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2494)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:771)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1710)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1678)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:978)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
printing javac parameters to: /tmp/javac.20250414_101233.args


The reason is that all of the yields "jump" to the same point in the bytecode, and javac is unable to compute the top-of-stack type for that point. javac expects that there's subtyping relation for the types on the join point.

In a little bit more detail:
- the `(Object)` cast is important, as that makes the switch expressions standalone expressions, whose types are inferred from the content, not from the target type
-if we had only:

    private Object computeTypeAtMergePoint1(int i) {
        return (Object) switch (i) {
            case 0 -> { yield new A(); }
            default -> { yield new D(); }
        };
    }


then this would compile, as the type of the switch expression would be `Object`, and inside `visitYield`, we use `forceStackTop` to change the top-stack type to the type of the switch expression. This works on one level, but does not work well for nested level switch expressions - while the outer switch expression in the original example has type `Object`, the nested ones have `I1` and `I2`, respectively, and the nested `yield` statements set `I1` or `I2` as the stack-top type. And neither of `I1` or `I2` is a subtype of the other, leading to the failure.

The proposal here is to use `Types.lub` to compute the common supertype of the types that join. The subtyping checks are kept, to help with some corner cases, in particular with `null`/`BOT` type handling. And also to limit potential performance impact.

I also think the `forceStackTop` is more a workaround that permitted the use of simply subtyping rather than `lub` at the join points. And it only works for one level of nesting for switch expressions. The proposal here is to drop the `forceStackTop` for both switch expressions and conditional expressions, so that if there are some cases where the new code would not work, we would find out faster/easier. But I can keep the `forceStackTop` calls in that is preferred.

(In any case, there's one call to `forceStackTop` in `Gen.visitAssign`. That one seems legitimate to me, so that one is kept.)

-------------

Commit messages:
 - 8353565: Javac throws "inconsistent stack types at join point" exception

Changes: https://git.openjdk.org/jdk/pull/24617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24617&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353565
  Stats: 122 lines in 3 files changed: 112 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24617/head:pull/24617

PR: https://git.openjdk.org/jdk/pull/24617

From liach at openjdk.org  Mon Apr 14 19:13:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Apr 2025 19:13:43 GMT
Subject: RFR: 8346785: Potential infinite loop in JavadocTokenizer.ensures
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 10:59:48 GMT, Nizar Benalla  wrote:

> Please review this patch to fix a potential infinite loop in `JavadocTokenizer.ensure` when `map.length` and `size + need` approach Interger.MAX_VALUE.
> 
> While I couldn't reproduce the issue even with large inputs (~1.9GB java file where almost the entire file is one javadoc comment), the fix is about correctness and prevention of UB in extreme cases.
> 
> TIA

Consider if `grow == 0`, the while loop still stalls infinitely. I think the best solution is, after `grow <<= 1;`, add a check in the loop like `if (grow <= 0) throw new IndexOutOfBoundsException();` and keeping everything else as-is.

-------------

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24620#pullrequestreview-2765418753

From vromero at openjdk.org  Mon Apr 14 19:57:41 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 14 Apr 2025 19:57:41 GMT
Subject: RFR: 8353565: Javac throws
 "inconsistent stack types at join point" exception
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 08:34:47 GMT, Jan Lahoda  wrote:

> Consider code like:
> 
> public class T {
>     private Object computeTypeAtMergePoint1(int i) {
>         return (Object) switch (i) {
>             case 0 -> switch (i) {
>                 case 0 -> { yield new A(); }
>                 default -> { yield new B(); }
>             };
>             default -> switch (i) {
>                 case 0 -> { yield new C(); }
>                 default -> { yield new D(); }
>             };
>         };
>     }
>     enum E {A, B}
>     interface I1 {}
>     class A implements I1 {}
>     class B implements I1 {}
>     interface I2 {}
>     class C implements I2 {}
>     class D implements I2 {}
> 
> }
> 
> 
> Compiling this leads to a crash:
> 
> $ .../jdk-24/bin/javac  /tmp/T.java 
> An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError: inconsistent stack types at join point
>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.error(Code.java:1824)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.join(Code.java:1814)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolve(Code.java:1525)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolvePending(Code.java:1556)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop(Code.java:382)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:511)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1905)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1773)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:609)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:660)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.internalVisitBlock(Gen.java:1121)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1085)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1137)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(G...

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24617#pullrequestreview-2765514829

From liach at openjdk.org  Mon Apr 14 23:37:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Apr 2025 23:37:45 GMT
Subject: RFR: 8353565: Javac throws
 "inconsistent stack types at join point" exception
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Apr 2025 08:34:47 GMT, Jan Lahoda  wrote:

> Consider code like:
> 
> public class T {
>     private Object computeTypeAtMergePoint1(int i) {
>         return (Object) switch (i) {
>             case 0 -> switch (i) {
>                 case 0 -> { yield new A(); }
>                 default -> { yield new B(); }
>             };
>             default -> switch (i) {
>                 case 0 -> { yield new C(); }
>                 default -> { yield new D(); }
>             };
>         };
>     }
>     enum E {A, B}
>     interface I1 {}
>     class A implements I1 {}
>     class B implements I1 {}
>     interface I2 {}
>     class C implements I2 {}
>     class D implements I2 {}
> 
> }
> 
> 
> Compiling this leads to a crash:
> 
> $ .../jdk-24/bin/javac  /tmp/T.java 
> An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError: inconsistent stack types at join point
>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.error(Code.java:1824)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.join(Code.java:1814)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolve(Code.java:1525)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolvePending(Code.java:1556)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop(Code.java:382)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:511)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1905)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1773)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:609)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:660)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.internalVisitBlock(Gen.java:1121)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1085)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1137)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(G...

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java line 1814:

> 1812:                     types.isSubtype(t, tother) ? tother :
> 1813:                     types.isSubtype(tother, t) ? t :
> 1814:                     commonSuperClass(t, tother);

Are the `isSubtype()` or `t==tother` checks above still necessary? Like do those fast paths not exist in `types::lub`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24617#discussion_r2043164594

From liach at openjdk.org  Mon Apr 14 23:37:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Apr 2025 23:37:45 GMT
Subject: RFR: 8353565: Javac throws
 "inconsistent stack types at join point" exception
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Apr 2025 23:31:09 GMT, Chen Liang  wrote:

>> Consider code like:
>> 
>> public class T {
>>     private Object computeTypeAtMergePoint1(int i) {
>>         return (Object) switch (i) {
>>             case 0 -> switch (i) {
>>                 case 0 -> { yield new A(); }
>>                 default -> { yield new B(); }
>>             };
>>             default -> switch (i) {
>>                 case 0 -> { yield new C(); }
>>                 default -> { yield new D(); }
>>             };
>>         };
>>     }
>>     enum E {A, B}
>>     interface I1 {}
>>     class A implements I1 {}
>>     class B implements I1 {}
>>     interface I2 {}
>>     class C implements I2 {}
>>     class D implements I2 {}
>> 
>> }
>> 
>> 
>> Compiling this leads to a crash:
>> 
>> $ .../jdk-24/bin/javac  /tmp/T.java 
>> An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
>> java.lang.AssertionError: inconsistent stack types at join point
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.error(Code.java:1824)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.join(Code.java:1814)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolve(Code.java:1525)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolvePending(Code.java:1556)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop(Code.java:382)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:511)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1905)
>>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1773)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:609)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:660)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.internalVisitBlock(Gen.java:1121)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1085)
>>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1137)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>>         at jdk.compiler/com.sun.tools.jav...
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java line 1814:
> 
>> 1812:                     types.isSubtype(t, tother) ? tother :
>> 1813:                     types.isSubtype(tother, t) ? t :
>> 1814:                     commonSuperClass(t, tother);
> 
> Are the `isSubtype()` or `t==tother` checks above still necessary? Like do those fast paths not exist in `types::lub`?

Just checked, lub is a varargs call and is slow. However, I think the fast path merge logic `t==tother? ... ` should be in `commonSuperClass`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24617#discussion_r2043166910

From vromero at openjdk.org  Tue Apr 15 14:15:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 15 Apr 2025 14:15:50 GMT
Subject: RFR: 8346785: Potential infinite loop in JavadocTokenizer.ensures
In-Reply-To: 
References: 
Message-ID: <_rNiXjHMipmL0oEl3i4ZzsYHdXDj40Y45uGN6asFxhU=.2aac1d09-0295-4bb1-ac98-26094af6e509@github.com>

On Mon, 14 Apr 2025 10:59:48 GMT, Nizar Benalla  wrote:

> Please review this patch to fix a potential infinite loop in `JavadocTokenizer.ensure` when `map.length` and `size + need` approach Interger.MAX_VALUE.
> 
> While I couldn't reproduce the issue even with large inputs (~1.9GB java file where almost the entire file is one javadoc comment), the fix is about correctness and prevention of UB in extreme cases.
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java line 309:

> 307: 
> 308:             while (need > grow && grow <= Integer.MAX_VALUE/2) {
> 309:                 grow <<= 1;

I wonder why `map` is not an `ArrayList` which already have a grow strategy. If this is because of performance issues I think that stop growing the array as soon as `grow > Integer.MAX_VALUE / 2` is a bit premature as there is still plenty of room for a less aggressive growing strategy

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24620#discussion_r2044679939

From jlahoda at openjdk.org  Tue Apr 15 15:16:41 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Apr 2025 15:16:41 GMT
Subject: RFR: 8322706: AnnotationTypeMismatchException in javac with annotation
 processing
Message-ID: 

Annotations are processed in a sequence of queues. But, it may happen this:
- while running verification in `validateQ`, an annotation type is completed (when a default attribute value is an annotation, whose type has not been completed yet)
- if this annotation type has attributes with default values, there will be temporary proxies created for the default values, and conversion of these default values to real values will be scheduled into `q`. `Annotate.flush()` will be called, but because flush is already running it will be ignored.
- until there are more unrelated calls to `Annotate.flush()`, the temporary proxies will linger. If someone will try to use the default values for the attributes, they will get the proxies instead of the real values, leading to trouble.

The proposal herein is to clear the queues in rounds as long as there are entries in the queues. An alternative might be to use a `PriorityQueue`, although that brings some complexity.

-------------

Commit messages:
 - 8322706: AnnotationTypeMismatchException in javac with annotation processing

Changes: https://git.openjdk.org/jdk/pull/24666/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24666&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322706
  Stats: 168 lines in 2 files changed: 157 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24666.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24666/head:pull/24666

PR: https://git.openjdk.org/jdk/pull/24666

From jlahoda at openjdk.org  Tue Apr 15 17:45:28 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Apr 2025 17:45:28 GMT
Subject: RFR: 8353565: Javac throws
 "inconsistent stack types at join point" exception [v2]
In-Reply-To: 
References: 
Message-ID: 

> Consider code like:
> 
> public class T {
>     private Object computeTypeAtMergePoint1(int i) {
>         return (Object) switch (i) {
>             case 0 -> switch (i) {
>                 case 0 -> { yield new A(); }
>                 default -> { yield new B(); }
>             };
>             default -> switch (i) {
>                 case 0 -> { yield new C(); }
>                 default -> { yield new D(); }
>             };
>         };
>     }
>     enum E {A, B}
>     interface I1 {}
>     class A implements I1 {}
>     class B implements I1 {}
>     interface I2 {}
>     class C implements I2 {}
>     class D implements I2 {}
> 
> }
> 
> 
> Compiling this leads to a crash:
> 
> $ .../jdk-24/bin/javac  /tmp/T.java 
> An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError: inconsistent stack types at join point
>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.error(Code.java:1824)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.join(Code.java:1814)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolve(Code.java:1525)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolvePending(Code.java:1556)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop(Code.java:382)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:511)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1905)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1773)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:609)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:660)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.internalVisitBlock(Gen.java:1121)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1085)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1137)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(G...

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback - moving subtyping checks to commonSuperClass.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24617/files
  - new: https://git.openjdk.org/jdk/pull/24617/files/7539bea8..bb08b490

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24617&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24617&range=00-01

  Stats: 19 lines in 1 file changed: 8 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24617/head:pull/24617

PR: https://git.openjdk.org/jdk/pull/24617

From jlahoda at openjdk.org  Tue Apr 15 17:45:28 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Apr 2025 17:45:28 GMT
Subject: RFR: 8353565: Javac throws
 "inconsistent stack types at join point" exception [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <8rC0r7NOeM2eo1WHzwJhFyOO-YnEMVeIf_8JadNc2xA=.a0ce4b23-5d15-4a22-acc9-b3e3c111c192@github.com>

On Mon, 14 Apr 2025 23:34:26 GMT, Chen Liang  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java line 1814:
>> 
>>> 1812:                     types.isSubtype(t, tother) ? tother :
>>> 1813:                     types.isSubtype(tother, t) ? t :
>>> 1814:                     commonSuperClass(t, tother);
>> 
>> Are the `isSubtype()` or `t==tother` checks above still necessary? Like do those fast paths not exist in `types::lub`?
>
> Just checked, lub is a varargs call and is slow. However, I think the fast path merge logic `t==tother? ... ` should be in `commonSuperClass`.

The `isSubtype` serve two purposes - they handle `null`/`BOT` type (which, I think, `lub` normally does not handle), and they are cheaper to run.

I've moved them into `commonSuperClass`, as suggested, here:
https://github.com/openjdk/jdk/pull/24617/commits/bb08b490108556553e55b0361f57c99b91a3f89c

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24617#discussion_r2045154006

From vromero at openjdk.org  Tue Apr 15 20:18:43 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 15 Apr 2025 20:18:43 GMT
Subject: RFR: 8353565: Javac throws
 "inconsistent stack types at join point" exception [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 15 Apr 2025 17:45:28 GMT, Jan Lahoda  wrote:

>> Consider code like:
>> 
>> public class T {
>>     private Object computeTypeAtMergePoint1(int i) {
>>         return (Object) switch (i) {
>>             case 0 -> switch (i) {
>>                 case 0 -> { yield new A(); }
>>                 default -> { yield new B(); }
>>             };
>>             default -> switch (i) {
>>                 case 0 -> { yield new C(); }
>>                 default -> { yield new D(); }
>>             };
>>         };
>>     }
>>     enum E {A, B}
>>     interface I1 {}
>>     class A implements I1 {}
>>     class B implements I1 {}
>>     interface I2 {}
>>     class C implements I2 {}
>>     class D implements I2 {}
>> 
>> }
>> 
>> 
>> Compiling this leads to a crash:
>> 
>> $ .../jdk-24/bin/javac  /tmp/T.java 
>> An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
>> java.lang.AssertionError: inconsistent stack types at join point
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.error(Code.java:1824)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.join(Code.java:1814)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolve(Code.java:1525)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolvePending(Code.java:1556)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop(Code.java:382)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:511)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1905)
>>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1773)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:609)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:660)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.internalVisitBlock(Gen.java:1121)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1085)
>>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1137)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>>         at jdk.compiler/com.sun.tools.jav...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - moving subtyping checks to commonSuperClass.

lg

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24617#pullrequestreview-2769693685

From liach at openjdk.org  Tue Apr 15 20:26:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Apr 2025 20:26:50 GMT
Subject: RFR: 8353565: Javac throws
 "inconsistent stack types at join point" exception [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 15 Apr 2025 17:45:28 GMT, Jan Lahoda  wrote:

>> Consider code like:
>> 
>> public class T {
>>     private Object computeTypeAtMergePoint1(int i) {
>>         return (Object) switch (i) {
>>             case 0 -> switch (i) {
>>                 case 0 -> { yield new A(); }
>>                 default -> { yield new B(); }
>>             };
>>             default -> switch (i) {
>>                 case 0 -> { yield new C(); }
>>                 default -> { yield new D(); }
>>             };
>>         };
>>     }
>>     enum E {A, B}
>>     interface I1 {}
>>     class A implements I1 {}
>>     class B implements I1 {}
>>     interface I2 {}
>>     class C implements I2 {}
>>     class D implements I2 {}
>> 
>> }
>> 
>> 
>> Compiling this leads to a crash:
>> 
>> $ .../jdk-24/bin/javac  /tmp/T.java 
>> An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
>> java.lang.AssertionError: inconsistent stack types at join point
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.error(Code.java:1824)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.join(Code.java:1814)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolve(Code.java:1525)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolvePending(Code.java:1556)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop(Code.java:382)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:511)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1905)
>>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1773)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:609)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:660)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.internalVisitBlock(Gen.java:1121)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1085)
>>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1137)
>>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>>         at jdk.compiler/com.sun.tools.jav...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - moving subtyping checks to commonSuperClass.

Thanks for updating per my review!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24617#pullrequestreview-2769715398

From vromero at openjdk.org  Tue Apr 15 20:27:46 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 15 Apr 2025 20:27:46 GMT
Subject: RFR: 8322706: AnnotationTypeMismatchException in javac with
 annotation processing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Apr 2025 15:11:04 GMT, Jan Lahoda  wrote:

> Annotations are processed in a sequence of queues. But, it may happen this:
> - while running verification in `validateQ`, an annotation type is completed (when a default attribute value is an annotation, whose type has not been completed yet)
> - if this annotation type has attributes with default values, there will be temporary proxies created for the default values, and conversion of these default values to real values will be scheduled into `q`. `Annotate.flush()` will be called, but because flush is already running it will be ignored.
> - until there are more unrelated calls to `Annotate.flush()`, the temporary proxies will linger. If someone will try to use the default values for the attributes, they will get the proxies instead of the real values, leading to trouble.
> 
> The proposal herein is to clear the queues in rounds as long as there are entries in the queues. An alternative might be to use a `PriorityQueue`, although that brings some complexity.

looks sensible

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24666#pullrequestreview-2769716998

From jlahoda at openjdk.org  Wed Apr 16 11:47:00 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Apr 2025 11:47:00 GMT
Subject: Integrated: 8322706: AnnotationTypeMismatchException in javac with
 annotation processing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Apr 2025 15:11:04 GMT, Jan Lahoda  wrote:

> Annotations are processed in a sequence of queues. But, it may happen this:
> - while running verification in `validateQ`, an annotation type is completed (when a default attribute value is an annotation, whose type has not been completed yet)
> - if this annotation type has attributes with default values, there will be temporary proxies created for the default values, and conversion of these default values to real values will be scheduled into `q`. `Annotate.flush()` will be called, but because flush is already running it will be ignored.
> - until there are more unrelated calls to `Annotate.flush()`, the temporary proxies will linger. If someone will try to use the default values for the attributes, they will get the proxies instead of the real values, leading to trouble.
> 
> The proposal herein is to clear the queues in rounds as long as there are entries in the queues. An alternative might be to use a `PriorityQueue`, although that brings some complexity.

This pull request has now been integrated.

Changeset: 1ad869f8
Author:    Jan Lahoda 
URL:       https://git.openjdk.org/jdk/commit/1ad869f8440cb274e474abd9f89f88db11101071
Stats:     168 lines in 2 files changed: 157 ins; 0 del; 11 mod

8322706: AnnotationTypeMismatchException in javac with annotation processing

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/24666

From ihse at openjdk.org  Thu Apr 17 14:48:23 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Apr 2025 14:48:23 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters
Message-ID: 

As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.

99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 

I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.

There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.

-------------

Commit messages:
 - 8354968: Replace unicode sequences in comment text with UTF-8 characters

Changes: https://git.openjdk.org/jdk/pull/24727/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354968
  Stats: 158 lines in 153 files changed: 0 ins; 2 del; 156 mod
  Patch: https://git.openjdk.org/jdk/pull/24727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24727/head:pull/24727

PR: https://git.openjdk.org/jdk/pull/24727

From chen.l.liang at oracle.com  Fri Apr 18 22:55:31 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 18 Apr 2025 22:55:31 +0000
Subject: Preview features and class file formats
Message-ID: 

Hi Alex and others,
I am currently enhancing java.lang.reflect.AccessFlag to be able to handle access flags introduced by preview features of the runtime Java SE; for example, project valhalla recognizes ACC_IDENTITY and ACC_STRICT_INIT when running with preview features enabled.

In AccessFlag, there are two APIs: locations() and locations(ClassFileFormatVersion). Currently, both are affected by the enabling of preview features: when preview features are enabled, for both new flags, both locations() and locations(ClassFileFormatVersion.RELEASE_25) (where RELEASE_25 is ClassFileFormatVersion.current()) return their supported locations as preview features; otherwise, they report they support no location. However, I felt that was wrong: when preview features are enabled, applications should still be able to obtain right reflective information applicable to 69.0 class files.

I have been looking at java.lang.reflect.ClassFileFormatVersion, and it seems the versions here never represent class file versions that depend on preview features of specific versions of the Java SE platform. My logical conclusion was that for these flags, locations(ClassFileFormatVersion.RELEASE_25) should report they support no location even when preview features are enabled; ClassFileFormatVersion.RELEASE_25 represents the class file format 69.0, which does not support the new flags, instead of 69.65535. In addition, it does not make sense for locations(ClassFileFormatVersion.RELEASE_25) to differ for a preview-enabled Java SE runtime 25 and any Java SE runtime of a future Java SE release, whether or not preview features are enabled.

Are my understandings of class file format versions and treatment of those APIs correct?

Regards,
Chen Liang


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alex.buckley at oracle.com  Sat Apr 19 00:28:03 2025
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 18 Apr 2025 17:28:03 -0700
Subject: Preview features and class file formats
In-Reply-To: 
References: 
Message-ID: 

On 4/18/2025 3:55 PM, Chen Liang wrote:
> In AccessFlag, there are two APIs: locations() and 
> locations(ClassFileFormatVersion). Currently, both are affected by
> the enabling of preview features: when preview features are enabled,
> for both new flags, both locations() and 
> locations(ClassFileFormatVersion.RELEASE_25) return their supported
> locations as preview features; otherwise, they report they support
> no location. However, I felt that was wrong: when preview features
> are enabled, applications should still be able to obtain right
> reflective information applicable to 69.0 class files.
I wasn't familiar with AccessFlag and ClassFileFormatVersion, but I see 
they were introduced in Java 20 with the intent of accurately modeling 
class file versions and artifacts.

It strikes me as an oversight that for ClassFileFormatVersion, "this 
enum only models the major version". This major-only design decision 
prevents an enum constant RELEASE_25_PREVIEW that models 69.65535. Such 
an enum constant would completely answer the question of what 
locations(ClassFileFormatVersion) should return.

If all we have is RELEASE_25, then I agree with you that uniformly 
returning "no location" is the right answer -- even if preview features 
are enabled. Having reflective APIs vary their answer based on whether 
preview features are enabled is possible but inessential.

As you say, having locations(RELEASE_25) return <> on 
JDK 25 _when preview features are enabled_ is inconsistent with the 
future. Roll forward to JDK 33, enable preview features, and call 
locations(RELEASE_25) again: the preview features are different than in 
25, so it doesn't make sense to still answer <>. Even if 
it did make sense, we don't want a future JDK (33) to have to remember 
the semantics of preview features from a prior JDK (25).


JEP 12 contemplates "reflective preview APIs" that expose in-preview 
aspects of classes, fields, etc, without requiring preview features to 
be enabled; the expectation is that reflective preview APIs are upgraded 
to permanent APIs later. Examples were Class::isRecord in Java 14 and 
ImportTree::isModule in Java 24. You could in theory introduce a 
reflective preview API like `supportsIdentityFlag()` on 
java.lang.reflect.Field (just an illustration) ... but the nature of the 
reflection that you want to offer for the preview feature ("Is the 
STRICT_INIT flag allowed here?") is _already_ exposed by AccessFlag, a 
permanent API, so it would be redundant to introduce a reflective 
preview API.

Alex