From jzaugg at gmail.com  Sun Mar  2 13:43:14 2025
From: jzaugg at gmail.com (Jason Zaugg)
Date: Sun, 2 Mar 2025 23:43:14 +1000
Subject: Passing ziptime-info=false to ZipFileSystemProvider (along with other
 classpath performance ideas)
Message-ID: <CAG3_yeU4Z7Go37Tqqs+_r9PBq-Th7T0oqUOsLo603zWT-cmKKA@mail.gmail.com>

I've been analysing the performance of javac in a relatively large codebase
and found classpath scanning to be the dominant factor. There are large
numbers of compilation tasks, most with long classpaths including large
JARs.

I've been using the wall-time profiling mode of async-profiler to analyse
where time is being spent.

I've been able improve build times (most dramatically on Windows, 750s
reduced to 350s) by modifying javac to:

1. pass ziptime-info=false to the env Map of jarFsProvider.newFileSystem,
which means the classpath scan in the constructor of ArchiveContainer need
only read the ZIP central directory, rather then reading per-entry Extended
Time metadata.
2. Extend cache lifetime for FSInfo.getJarClassPath
3. share ZipFileSystem instances across compilation tasks in a build
session (multiple JavacTasks). The (custom) build tool knows which JARs are
immutable.

I don't see any supported way to make this change via the public compiler
APIs, so I'm currently using a bytecode transform to patch the
implementation [1].

Change 1 is self contained and low risk -- would this be worth a patch?
Other calls to newFilesystem, e.g in inferModuleName, should also be
changed to for consistency.

Change 2 would not be needed if I could share a CacheFSInfo instance across
a number of compilation tasks, but I don't see a way to do this via the
public APIs. Am I missing something here?

Change 3 doesn't seem to belong in javac, but perhaps could be accommodated
with an extension point akin to StandardFileManager.setPathFactory. Two
options:

// option a), a wrapper around ZipFileSystemProvider can defer javac's
close() calls
void setJarFsProvider(FileSystemProvider provider)

// option b)
void setJarFileSystemFactory(JarFileSystemFactory factory)
interface JarFileSystemFactory {
   FileSystem newFileSystem(FileSystemProvider provider, Path path,
Map<String, String> env)
   void close(FileSystem fileSystem)
}

I reviewed the Java integration in other build tools to see if this problem
has been tackled elsewhere. Bazel and Gradle do use the non-public compiler
API but don't appear to add this sort of caching.

Regards,

Jason Zaugg


[1] https://github.com/retronym/jarcache
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250302/f8fc594b/attachment-0001.htm>

From hannesw at openjdk.org  Mon Mar  3 16:48:38 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 3 Mar 2025 16:48:38 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted text
Message-ID: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>

Please review an enhancement to make `DocCommentParser` normalize whitespace inside `<pre>` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `<pre>` tags.

This fixes the incidental one-space indentation in the vast majority of JDK code samples using `<pre>` alone or in combination with `<code>` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `<blockquote>`). 

The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `<pre>` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 

If the exact number of leading whitespace in `<pre>` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 

Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `<pre><code>\n` open tags. Browsers will [ignore a newline immediately following a `<pre>` tag][1], but not if there is a `<code>` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `<code>\n` at the beginning of `<pre>` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.

[1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

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

Commit messages:
 - Make sure whitespace normalization is only applied to block content
 - Only normalize inside <pre> tags, add tests
 - 8346118: Improve whitespace normalization in preformatted text

Changes: https://git.openjdk.org/jdk/pull/23868/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23868&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346118
  Stats: 334 lines in 11 files changed: 258 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/23868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23868/head:pull/23868

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

From darcy at openjdk.org  Tue Mar  4 03:06:57 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Mar 2025 03:06:57 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v12]
In-Reply-To: <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
Message-ID: <W8BPBHtpkYLbekVYCqKGsSeApyGK60RNxTllOXVrtps=.c6f70097-023c-4576-adca-24af472b29d3@github.com>

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
>  - Remove a few more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update @LastModified tags.
>  - Revert changes under src/java.desktop (to be moved into a separate PR).
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

The changes in java.base look fine.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2655808338

From darcy at openjdk.org  Tue Mar  4 03:51:58 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Mar 2025 03:51:58 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v2]
In-Reply-To: <VYKBD8I4cuuoEYhdtcEfCo6L_-DMGKCKSdXVKYZtTyU=.d3cfa7e6-ef3f-4e05-abb4-99d133308d91@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <VYKBD8I4cuuoEYhdtcEfCo6L_-DMGKCKSdXVKYZtTyU=.d3cfa7e6-ef3f-4e05-abb4-99d133308d91@github.com>
Message-ID: <RfPuVogOZlNBKvqkh1J2ik2bLNC-yT-3XIh3uqKo8cc=.00cccfcc-ec2f-4a58-b21c-d7dda3184b1d@github.com>

On Thu, 23 Jan 2025 13:56:35 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
>> 
>> TIA.
>
> Nizar Benalla 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 seven additional commits since the last revision:
> 
>  - whitespace
>  - Update according to review comments.
>  - Merge remote-tracking branch 'upstream/master' into elements-api-note
>  - Respond to feedback around the wording.
>  - Respond to feedback. Using Jan's comment to not imply particular requirement on the implementation.
>  - (C) 2025
>  - Initial commit obtained from a cherry pick/squash of a now superseded PR.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 784:

> 782:      * return types, and method modifiers specified in JLS {@jls 8.4.8.1} and {@jls 8.4.8.3},
> 783:      * although implementations of this method are allowed to implement these additional checks.
> 784:      *

I don't think the current wording conveys enough context for the reader. I suggest a structure like:

apiNote
This method must examines X, Y, and Z in determining whether one method overrides another. In addition, an implementation may have a stricter checking including  at properties A, B, and C as described in JLS ..."

HTH

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1978563468

From joe.darcy at oracle.com  Tue Mar  4 06:16:20 2025
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 3 Mar 2025 22:16:20 -0800
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
Message-ID: <c75c8be6-ebe7-42f1-bb87-f3804ef71f48@oracle.com>

PS Belated comments when catching up on email...

On 11/9/2024 2:50 PM, Archie Cobbs wrote:
> *Overview*
>
> This is a proposal to add the ability for the compiler to detect and 
> report unnecessary warning suppressions.
>
> An "unnecessary warning suppression" is when one of the following happens:
>
>   * There is a @SuppressWarnings("foo")annotation, but if it hadn't
>     been there, no foo warning would have been generated within the
>     annotation's scope
>   * The compiler is passed -Xlint:-foo, but if it hadn't been, no foo
>     warning wouldhave been generated during the entire compilation
>

Another consideration is being able to successfully compile a code base 
under multiple javac versions. A particular important instance of this 
is boot strapping the JDK :-)

Cases that have occurred in the past that would make such a discipline 
challenging include:

* Correctness fixes to the warning computation
* Expanding (or narrowing) the scope of what the warning looks for (e.g. 
the serial warning)

So perhaps "messages" about "unnecessary warning suppression" should be 
relayed somewhat outside of the existing warnings mechanism.

Cheers,

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250303/3976d9c8/attachment-0001.htm>

From jlahoda at openjdk.org  Tue Mar  4 11:31:46 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 4 Mar 2025 11:31:46 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations
Message-ID: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>

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

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

Commit messages:
 - Cleanup.
 - Cleanup.
 - Finalizing module imports.

Changes: https://git.openjdk.org/jdk/pull/23801/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344708
  Stats: 113 lines in 15 files changed: 9 ins; 71 del; 33 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 asemenyuk at openjdk.org  Tue Mar  4 15:33:18 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Mar 2025 15:33:18 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v12]
In-Reply-To: <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
Message-ID: <U_4rxRfTLxWD5hsA5ijRVf2WtFs9OZIaRgipndWaYF0=.cfdcaed5-bca2-4709-bd8f-73d2a0bf8e10@github.com>

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
>  - Remove a few more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update @LastModified tags.
>  - Revert changes under src/java.desktop (to be moved into a separate PR).
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

jpackage looks good

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

Marked as reviewed by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2658012030

From hannesw at openjdk.org  Tue Mar  4 15:33:16 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 4 Mar 2025 15:33:16 GMT
Subject: RFR: 8350007: Add usage message to the javadoc executable [v3]
In-Reply-To: <aPc5o3JwcIT36U76Kld8QVmbYn48y31mqSPA5W4SVZM=.28efc778-9f95-4729-9789-ca884494625f@github.com>
References: <dV9fCg-17wNUsIr6T02OwoIHg1vFAjZINje5CYhT6hY=.2198af40-1da1-48aa-ae43-b9cb26f25d60@github.com>
 <RiN6eY394H2GHlN5EGwBLHY7YkU0ldGxy9metmzGKXw=.8193eeee-9802-4d46-8ab9-06ec372b6d71@github.com>
 <YU3Igwg3JIqDERADTzTuq2MxXOwbB20kSqwbE8PKcfY=.d9d0ff36-6f22-4ecb-84a4-6492d8b1679a@github.com>
 <H2H47ZzNMqq1v8YRP5Zo8J1_GQs8YtBbypWzYl1B_wo=.ac6a0feb-a66c-49e4-bfb1-2c9200f0fd73@github.com>
 <aPc5o3JwcIT36U76Kld8QVmbYn48y31mqSPA5W4SVZM=.28efc778-9f95-4729-9789-ca884494625f@github.com>
Message-ID: <J23FkKD85POsXIxtVD-5jRUd8cX4xHsIrBucHMqJI1E=.f1bb4549-6c57-47eb-a644-baa4aed3d6ba@github.com>

On Wed, 26 Feb 2025 20:16:36 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> `jpackage` and `jar` return 0 if there are no args. `javap` returns `2`/`EXIT_CMDERR` so it's not very consistent.
>> 
>> This is the behavior when returning `CMDERR`
>> 
>> 
>> nizar-mac! $ javadoc 
>> error: Usage:
>>       javadoc [options] [packagenames] [sourcefiles] [@files]
>>   For more details on available options, use --help or --help-extra
>> 1 error
>> 
>> 
>> I'm not sure we want to emit an error? Returning 0 or 1 might better.
>> But I can understand why we would want to keep those things the same.
>
> For the record, I discussed this offline with a couple of people.
> Since the user didn't ask for the help message, this is indeed be an invalid run and returning a non-zero value might  be the right thing to do.

I see, you can't return an error without generating the `error: ` prefix and the `1 error` line. That's a pity, as the `error: Usage:` line makes no sense, because the usage message is not an error message. An acceptable solution could be to print the usage method, and then throw the original error message, which produces:


Usage:
    javadoc [options] [packagenames] [sourcefiles] [@files]
For more details on available options, use --help or --help-extra
error: No modules, packages or classes specified.
1 error

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23618#discussion_r1979693905

From acobbs at openjdk.org  Tue Mar  4 15:50:57 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 4 Mar 2025 15:50:57 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v12]
In-Reply-To: <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
Message-ID: <usXIhWpm-DANq2l3PeiNZIXORXwrePyQTgwrxrclAAc=.59105abf-ecbd-481a-a9ea-ed8a39bfeeec@github.com>

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
>  - Remove a few more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update @LastModified tags.
>  - Revert changes under src/java.desktop (to be moved into a separate PR).
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2698092830

From vromero at openjdk.org  Tue Mar  4 19:23:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 4 Mar 2025 19:23:54 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <hPt0ZKToYxJsVA6S67vaM-HGGTFGkcXUZq9vV0u63aQ=.ccd34233-7e47-416c-802e-c58e9334acca@github.com>

On Wed, 26 Feb 2025 13:50:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

looks sensible

test/langtools/tools/javac/modules/EdgeCases.java line 1190:

> 1188: 
> 1189:         List<String> expected = List.of(
> 1190:                 "Test.java:2:8: compiler.err.feature.not.supported.in.source.plural: (compiler.misc.feature.module.imports), 24, 25",

isn't there a similar test above?

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2658747032
PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r1980096065

From attila.kelemen85 at gmail.com  Tue Mar  4 19:51:56 2025
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Tue, 4 Mar 2025 20:51:56 +0100
Subject: JEP 300 - casting with declaration-site variance
Message-ID: <CAKDaPBcnkpmq-zBdcaQJ_F_a1O-t0ugs=GGg1PswrfYDPvh9yw@mail.gmail.com>

Hi,

I have read JEP 300, and it seems it is not defining what it intends to do
with casting these adjusted types to a subtype. For example consider the
following method:

```
<T> void method1(Iterable<T> itr) {
  if (itr instanceof List) {
    var list = (List<T>) itr;
    list.add(null);
  }
}
```

The cast in the above example is safe (it doesn't emit any unsafe cast
warning). However, if `Iterable` becomes covariant at the declaration site,
then the above code is now unsafe.

What is the plan of the JEP with such casting? Will it make the above cast
unsafe? If so, then there will be no way to safely cast from `Iterable<T>`
to `List<T>`. Admittedly, I can't recall any code I have ever seen where
this would be a problem (and so I wouldn't worry about it too much), but it
would be nice if the JEP would explicitly address this question.

In Kotlin, they allow such unsafe casts without a warning (in fact, you
don't even need a cast in Kotlin for it). For example, the following code
compiles without warning in Kotlin:

```
fun evilMethod(list: List<Any>) {
  if (list is MutableList) {
    list.add("hello")
  }
}

fun naiveMethod() {
  val list = mutableListOf<Int>()
  evilMethod(list)
  println(list.sum())
}
```

Of course, calling `naiveMethod` fails with an exception when trying to
call `sum`. (Note: `List` in Kotlin is a "read-only" variant of Java's
List, and MutableList is the equivalent of Java's List interface).

I personally don't like the behavior of Kotlin, and would rather choose
that only `Iterable<T>` to `List<? extends T>` is safe from here onwards.

Attila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250304/9ef9fafd/attachment.htm>

From joe.darcy at oracle.com  Tue Mar  4 21:14:57 2025
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 4 Mar 2025 13:14:57 -0800
Subject: State of JEP 119
In-Reply-To: <k3yS3fJLlT4y2QXDxQKvNA2huWu__XxzZ49vfb5yrtYbPReWGX-5lbb_3GNLUGvmmldzQHjNDc51wsWe5lhF0uVTyRYbx8u0SNa-vHlvZoM=@protonmail.com>
References: <k3yS3fJLlT4y2QXDxQKvNA2huWu__XxzZ49vfb5yrtYbPReWGX-5lbb_3GNLUGvmmldzQHjNDc51wsWe5lhF0uVTyRYbx8u0SNa-vHlvZoM=@protonmail.com>
Message-ID: <b1c4df8b-22d4-44cd-937f-639ebf4e9a1e@oracle.com>

Catching up on email, that prototype / proof of concept code was the 
final result of JEP 119.

It was removed from the JDK after a change in policy on hosting such code.

HTH,

-Joe

On 12/18/2024 3:06 AM, Determann wrote:
> Hi all,
>
> I'm trying to build an API for any kind of meta-programming in Java.
> An implementation of javax.lang.model backed by reflection might simplify that.
>
> https://openjdk.org/jeps/119
> The JEP is marked as Closed/Delivered with Release 8.
> I only found prototypes, the last one for JDK 9.
> https://hg.openjdk.org/jdk9/jdk9/langtools/file/82d0e10df078/src/sample/share/language/model/CoreReflectionFactory.java
>
> What did I miss?
>
> Lukas



From attila.kelemen85 at gmail.com  Wed Mar  5 12:34:22 2025
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Wed, 5 Mar 2025 13:34:22 +0100
Subject: JEP 300 - casting with declaration-site variance
In-Reply-To: <CAKDaPBcnkpmq-zBdcaQJ_F_a1O-t0ugs=GGg1PswrfYDPvh9yw@mail.gmail.com>
References: <CAKDaPBcnkpmq-zBdcaQJ_F_a1O-t0ugs=GGg1PswrfYDPvh9yw@mail.gmail.com>
Message-ID: <CAKDaPBfH-nSw3_4imndCwXB2zvtByTTZ9Gfsq4gLBpmYs9DrMQ@mail.gmail.com>

Actually, I have realized that there are realistic methods that would fall
into this problem. In fact, with pattern matching, it is also a question
how the JEP will plan to retain source compatibility, because a method
might this could realistically exist:

```
<T> boolean contains(Iterable<T> itr, T element) {
  return itr instanceof Collection<T> c
    ? c.contains(element)
    : iterableContains(itr, element); // impl of iterableContains omitted
}
```

One could argue that the implementor should have used `? extends T` here,
but (as even the JEP admits) people are often lazy (or just lack knowledge)
and will not write `? extends`.

If it was on me, I would allow the above unsafe construct in the JEP, but
would issue some kind of unsafe cast warning.


Attila Kelemen <attila.kelemen85 at gmail.com> ezt ?rta (id?pont: 2025. m?rc.
4., K, 20:51):

> Hi,
>
> I have read JEP 300, and it seems it is not defining what it intends to do
> with casting these adjusted types to a subtype. For example consider the
> following method:
>
> ```
> <T> void method1(Iterable<T> itr) {
>   if (itr instanceof List) {
>     var list = (List<T>) itr;
>     list.add(null);
>   }
> }
> ```
>
> The cast in the above example is safe (it doesn't emit any unsafe cast
> warning). However, if `Iterable` becomes covariant at the declaration site,
> then the above code is now unsafe.
>
> What is the plan of the JEP with such casting? Will it make the above cast
> unsafe? If so, then there will be no way to safely cast from `Iterable<T>`
> to `List<T>`. Admittedly, I can't recall any code I have ever seen where
> this would be a problem (and so I wouldn't worry about it too much), but it
> would be nice if the JEP would explicitly address this question.
>
> In Kotlin, they allow such unsafe casts without a warning (in fact, you
> don't even need a cast in Kotlin for it). For example, the following code
> compiles without warning in Kotlin:
>
> ```
> fun evilMethod(list: List<Any>) {
>   if (list is MutableList) {
>     list.add("hello")
>   }
> }
>
> fun naiveMethod() {
>   val list = mutableListOf<Int>()
>   evilMethod(list)
>   println(list.sum())
> }
> ```
>
> Of course, calling `naiveMethod` fails with an exception when trying to
> call `sum`. (Note: `List` in Kotlin is a "read-only" variant of Java's
> List, and MutableList is the equivalent of Java's List interface).
>
> I personally don't like the behavior of Kotlin, and would rather choose
> that only `Iterable<T>` to `List<? extends T>` is safe from here onwards.
>
> Attila
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250305/19d1ce69/attachment.htm>

From liach at openjdk.org  Wed Mar  5 15:08:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 15:08:32 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner class
 with null outer class
Message-ID: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>

The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.

However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.

This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.

The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.

---------
### Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue
- [ ] Change requires CSR request [JDK-8351274](https://bugs.openjdk.org/browse/JDK-8351274) to be approved



### Reviewing
<details><summary>Using <code>git</code></summary>

Checkout this PR locally: \
`$ git fetch https://git.openjdk.org/jdk.git pull/23875/head:pull/23875` \
`$ git checkout pull/23875`

Update a local copy of the PR: \
`$ git checkout pull/23875` \
`$ git pull https://git.openjdk.org/jdk.git pull/23875/head`

</details>
<details><summary>Using Skara CLI tools</summary>

Checkout this PR locally: \
`$ git pr checkout 23875`

View PR using the GUI difftool: \
`$ git pr show -t 23875`

</details>
<details><summary>Using diff file</summary>

Download this PR as a diff file: \
<a href="https://git.openjdk.org/jdk/pull/23875.diff">https://git.openjdk.org/jdk/pull/23875.diff</a>

</details>

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

Commit messages:
 - 8164714: Constructor.newInstance creates instance of inner class with null outer class

Changes: https://git.openjdk.org/jdk/pull/23875/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23875&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8164714
  Stats: 105 lines in 4 files changed: 85 ins; 3 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/23875.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23875/head:pull/23875

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

From liach at openjdk.org  Wed Mar  5 15:12:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 15:12:28 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v2]
In-Reply-To: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
Message-ID: <rjQqe2gsOBXptah4Kb_a0hWYD0P-PbMX8FBJLShr7Bw=.a89cf4a1-75b9-41cd-81d7-ef2e275afcd9@github.com>

> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
> 
> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
> 
> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
> 
> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change requires CSR request [JDK-8351274](https://bugs.openjdk.org/browse/JDK-8351274) to be approved
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23875/head:pull/23875` \
> `$ git checkout pull/23875`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23875` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23875/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 23875`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23875`
> 
> ...

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix javap test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23875/files
  - new: https://git.openjdk.org/jdk/pull/23875/files/3ba5e715..3778a3ce

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

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

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

From liach at openjdk.org  Wed Mar  5 15:14:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 15:14:20 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v10]
In-Reply-To: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
Message-ID: <yatp27I090GzJLGMIFrbF9o55VB47s717V6aqCnyLco=.7dc669bb-d90f-49b8-bfc8-70190da39620@github.com>

> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
> 
> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
> 
> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
> 
> Here are some actions:
> 1. Add section for hierarchy overview for both Type and AnnotatedType
> 2. Specify the underlying type for different AnnotatedType subinterfaces
> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
> 5. Minor improvements to `ParameterizedType::getRawType`
> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
> 
> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html
> 
> Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Links

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/c237c2ad..712d3ec5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=08-09

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

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

From ecaspole at openjdk.org  Wed Mar  5 15:21:39 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 5 Mar 2025 15:21:39 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH fails
 with -ea
Message-ID: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>

The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

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

Commit messages:
 - 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem benchmark fails with -ea

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

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

From liach at openjdk.org  Wed Mar  5 16:42:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 16:42:02 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v3]
In-Reply-To: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
Message-ID: <-1FFbwdd5-iKZm3sg_bu1BVj-g-jo5XHq4dykt9Spyk=.5d5979b8-3b14-45d2-b4cb-2280713020c5@github.com>

> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
> 
> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
> 
> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
> 
> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change requires CSR request [JDK-8351274](https://bugs.openjdk.org/browse/JDK-8351274) to be approved
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23875/head:pull/23875` \
> `$ git checkout pull/23875`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23875` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23875/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 23875`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23875`
> 
> ...

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 three additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
 - Fix javap test
 - 8164714: Constructor.newInstance creates instance of inner class with null outer class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23875/files
  - new: https://git.openjdk.org/jdk/pull/23875/files/3778a3ce..9251340a

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

  Stats: 7549 lines in 150 files changed: 4891 ins; 1304 del; 1354 mod
  Patch: https://git.openjdk.org/jdk/pull/23875.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23875/head:pull/23875

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

From liach at openjdk.org  Wed Mar  5 16:43:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 16:43:54 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea
In-Reply-To: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
References: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
Message-ID: <wN83mg8DRHAdFa1qY4KnKktVgC_SXiTFYqu6dK41Fh0=.ed2a71b2-fb19-463c-b660-b09074af350d@github.com>

On Wed, 5 Mar 2025 15:16:03 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

These benchmarks are malformed indeed; the blackhole is never used.

@ericcaspole Do you mean hotspot-compiler for the label instead of javac?

Also might need to add an 2025 copyright header for this file.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23917#pullrequestreview-2661738797
PR Comment: https://git.openjdk.org/jdk/pull/23917#issuecomment-2701485115
PR Comment: https://git.openjdk.org/jdk/pull/23917#issuecomment-2701489585

From acobbs at openjdk.org  Wed Mar  5 17:36:13 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 5 Mar 2025 17:36:13 GMT
Subject: Integrated: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs)
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <icYlXrDtiwdWI9MZiwebjTsB4KdwFL1dUxcwmGAJzaU=.fecd1705-787d-4be0-b2a3-081e6a81236e@github.com>

On Sat, 2 Nov 2024 15:40:30 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

This pull request has now been integrated.

Changeset: 661bd5bf
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/661bd5bfe883a7449c6949c9f4bd6b5d82d20e10
Stats:     211 lines in 93 files changed: 0 ins; 90 del; 121 mod

8343478: Remove unnecessary @SuppressWarnings annotations (core-libs)

Reviewed-by: darcy, asemenyuk, joehw

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

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

From jjg at openjdk.org  Wed Mar  5 18:09:53 2025
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 5 Mar 2025 18:09:53 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text
In-Reply-To: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
References: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
Message-ID: <ytiC5aoARrCzdFLE1X3jpB4mTEDRrZwcC2Vs6mNnZwo=.f8783235-5734-4fd0-8bc2-4f2b2da0e91b@github.com>

On Mon, 3 Mar 2025 16:41:18 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `<pre>` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `<pre>` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `<pre>` alone or in combination with `<code>` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `<blockquote>`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `<pre>` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `<pre>` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `<pre><code>\n` open tags. Browsers will [ignore a newline immediately following a `<pre>` tag][1], but not if there is a `<code>` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `<code>\n` at the beginning of `<pre>` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

As you indicated, there are two problems being addressed here, which might indicate the need for two separate patches. These issues are:

1. The leading 1-space problem.
2. The trailing newline-after-<pre> problem

For the first, it is unduly hard work to fix this just for `<pre>` blocks. I still think that an overall better long-term solution would be to apply a conceptual `stripIndent` to the entire doc comment. This would bring traditional comments into line with the new Markdown comments, and can be done in just a few lines in `DocCommentParser`, and doing it there in DCP means you need not update `Elements.getDocComment`. If nothing else, I would suggest doing the experiment and comparing the generated docs, to verify there are no unexpected side effects. If there are any significant unexpected side effects, then your approach might deserve a second look. You could also make this a JDK-version-specific change if you wanted: meaning the new behavior does not apply to older JDK versions, although that is not a policy we have adhered to in the past.

For the second, I just feel that is a step too far, using JavaScript to clean up what some might consider to be bad input. Authors should either write HTML according to the HTML (and CSS?) specs, so that `javadoc` is just a "pass-through" layer, or authors should use a suitable construct, like `{@snippet...}`, that is "pleasing" to look at in source form while still generating the desired output.

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

PR Comment: https://git.openjdk.org/jdk/pull/23868#issuecomment-2701699839

From vromero at openjdk.org  Wed Mar  5 18:36:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 5 Mar 2025 18:36:54 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v2]
In-Reply-To: <rjQqe2gsOBXptah4Kb_a0hWYD0P-PbMX8FBJLShr7Bw=.a89cf4a1-75b9-41cd-81d7-ef2e275afcd9@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <rjQqe2gsOBXptah4Kb_a0hWYD0P-PbMX8FBJLShr7Bw=.a89cf4a1-75b9-41cd-81d7-ef2e275afcd9@github.com>
Message-ID: <9UnH5j5gAYh1vZrvysnTSc8hfSbKwGmdjMB2Iq12rAs=.09281753-af6d-4ee3-a26e-7ac77b1d07d9@github.com>

On Wed, 5 Mar 2025 15:12:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
>> 
>> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
>> 
>> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
>> 
>> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix javap test

test/langtools/tools/javap/AnnoTest.java line 5:

> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 4:  *
> 5:  * This code is free software; you can redistribute it and/or modify it

why changing this test?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1981705165

From vromero at openjdk.org  Wed Mar  5 18:36:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 5 Mar 2025 18:36:56 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v3]
In-Reply-To: <-1FFbwdd5-iKZm3sg_bu1BVj-g-jo5XHq4dykt9Spyk=.5d5979b8-3b14-45d2-b4cb-2280713020c5@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <-1FFbwdd5-iKZm3sg_bu1BVj-g-jo5XHq4dykt9Spyk=.5d5979b8-3b14-45d2-b4cb-2280713020c5@github.com>
Message-ID: <8-mB_ewKkeLOS_WmUO2cv7FWvY-kA8KFul_q7kGYXiU=.750bb90c-79ae-415b-916d-550ac0f978a2@github.com>

On Wed, 5 Mar 2025 16:42:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
>> 
>> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
>> 
>> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
>> 
>> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Fix javap test
>  - 8164714: Constructor.newInstance creates instance of inner class with null outer class

test/langtools/tools/javap/classfile/T6887895.java line 60:

> 58:                 "java/lang/String",
> 59:                 "T6887895",
> 60:                 "T6887895$Test"

not sure why this test is changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1981950531

From liach at openjdk.org  Wed Mar  5 18:56:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 18:56:00 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v3]
In-Reply-To: <8-mB_ewKkeLOS_WmUO2cv7FWvY-kA8KFul_q7kGYXiU=.750bb90c-79ae-415b-916d-550ac0f978a2@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <-1FFbwdd5-iKZm3sg_bu1BVj-g-jo5XHq4dykt9Spyk=.5d5979b8-3b14-45d2-b4cb-2280713020c5@github.com>
 <8-mB_ewKkeLOS_WmUO2cv7FWvY-kA8KFul_q7kGYXiU=.750bb90c-79ae-415b-916d-550ac0f978a2@github.com>
Message-ID: <JRVtI21wDMxkbIEunrQ4reKkznJfG24taiYAK3DtZnY=.5e7e873d-46e0-4fcd-ad9a-daf2c99493cc@github.com>

On Wed, 5 Mar 2025 18:31:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>>  - Fix javap test
>>  - 8164714: Constructor.newInstance creates instance of inner class with null outer class
>
> test/langtools/tools/javap/classfile/T6887895.java line 60:
> 
>> 58:                 "java/lang/String",
>> 59:                 "T6887895",
>> 60:                 "T6887895$Test"
> 
> not sure why this test is changed

Now Objects is used for requireNonNull

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1982023419

From liach at openjdk.org  Wed Mar  5 18:55:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 18:55:58 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v2]
In-Reply-To: <9UnH5j5gAYh1vZrvysnTSc8hfSbKwGmdjMB2Iq12rAs=.09281753-af6d-4ee3-a26e-7ac77b1d07d9@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <rjQqe2gsOBXptah4Kb_a0hWYD0P-PbMX8FBJLShr7Bw=.a89cf4a1-75b9-41cd-81d7-ef2e275afcd9@github.com>
 <9UnH5j5gAYh1vZrvysnTSc8hfSbKwGmdjMB2Iq12rAs=.09281753-af6d-4ee3-a26e-7ac77b1d07d9@github.com>
Message-ID: <l50ZsoWz03v_ZR3xsID29V63ttrXwrpre_60ZsQixUY=.2210bd68-9603-4d6f-830f-882b6fe17e09@github.com>

On Wed, 5 Mar 2025 15:54:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix javap test
>
> test/langtools/tools/javap/AnnoTest.java line 5:
> 
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> 4:  *
>> 5:  * This code is free software; you can redistribute it and/or modify it
> 
> why changing this test?

CP differences when Objects.requireNonNull is emitted

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1982021933

From vromero at openjdk.org  Wed Mar  5 20:21:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 5 Mar 2025 20:21:02 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v2]
In-Reply-To: <l50ZsoWz03v_ZR3xsID29V63ttrXwrpre_60ZsQixUY=.2210bd68-9603-4d6f-830f-882b6fe17e09@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <rjQqe2gsOBXptah4Kb_a0hWYD0P-PbMX8FBJLShr7Bw=.a89cf4a1-75b9-41cd-81d7-ef2e275afcd9@github.com>
 <9UnH5j5gAYh1vZrvysnTSc8hfSbKwGmdjMB2Iq12rAs=.09281753-af6d-4ee3-a26e-7ac77b1d07d9@github.com>
 <l50ZsoWz03v_ZR3xsID29V63ttrXwrpre_60ZsQixUY=.2210bd68-9603-4d6f-830f-882b6fe17e09@github.com>
Message-ID: <Q0hLvYduIpPrlQay_b5p0-TpSrmdxrK0M4lpy5x_3vU=.d11fb7de-8558-4223-b8a3-5248e6036fb5@github.com>

On Wed, 5 Mar 2025 18:52:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javap/AnnoTest.java line 5:
>> 
>>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> 4:  *
>>> 5:  * This code is free software; you can redistribute it and/or modify it
>> 
>> why changing this test?
>
> CP differences when Objects.requireNonNull is emitted

then we should add the bug id to the test

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1982130256

From vromero at openjdk.org  Wed Mar  5 20:21:03 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 5 Mar 2025 20:21:03 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v3]
In-Reply-To: <JRVtI21wDMxkbIEunrQ4reKkznJfG24taiYAK3DtZnY=.5e7e873d-46e0-4fcd-ad9a-daf2c99493cc@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <-1FFbwdd5-iKZm3sg_bu1BVj-g-jo5XHq4dykt9Spyk=.5d5979b8-3b14-45d2-b4cb-2280713020c5@github.com>
 <8-mB_ewKkeLOS_WmUO2cv7FWvY-kA8KFul_q7kGYXiU=.750bb90c-79ae-415b-916d-550ac0f978a2@github.com>
 <JRVtI21wDMxkbIEunrQ4reKkznJfG24taiYAK3DtZnY=.5e7e873d-46e0-4fcd-ad9a-daf2c99493cc@github.com>
Message-ID: <oCbsGTYGN5oASevcLv-i5jXVs_Jhy4dH237v4cgaT5Y=.e2260af8-c77b-4b1e-8b5d-234b7567837f@github.com>

On Wed, 5 Mar 2025 18:53:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javap/classfile/T6887895.java line 60:
>> 
>>> 58:                 "java/lang/String",
>>> 59:                 "T6887895",
>>> 60:                 "T6887895$Test"
>> 
>> not sure why this test is changed
>
> Now Objects is used for requireNonNull

we should then add the bug id to the test

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1982130662

From hannesw at openjdk.org  Wed Mar  5 20:48:57 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 Mar 2025 20:48:57 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text
In-Reply-To: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
References: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
Message-ID: <us5X438kN5v90INayXaRbxewu5dy8VUOstKdxJyYa8U=.ff7fa06e-bf19-4bc7-888d-25b406df60e5@github.com>

On Mon, 3 Mar 2025 16:41:18 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `<pre>` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `<pre>` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `<pre>` alone or in combination with `<code>` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `<blockquote>`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `<pre>` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `<pre>` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `<pre><code>\n` open tags. Browsers will [ignore a newline immediately following a `<pre>` tag][1], but not if there is a `<code>` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `<code>\n` at the beginning of `<pre>` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

Thanks for reviewing this, Jon. I agree there are two issues that maybe shold be handled separately. 

Regarding the first issue, stripping leading space in `DocCommentParser`, I did in fact start out processing the whole doc comment. I was pretty far into fixing tests when I realized that this approach breaks our ability to get a diagnostic position from a string extracted from the comment. The source postion mapping is generated in `JavadocScanner`, and it would be quite complex to keep track of whitespace removed after the fact and correctly translate to a source position. 

The test that made me realize this problem was [TestDocTreeDiags.java], which tests reporting positions inside strings extracted from the comment (added in [JDK-8268420]) , but with wholesale whitespace removal also start positions are affected. I should have mentioned this in the PR description, but it was already long enough as it was.

[TestDocTreeDiags.java]: https://github.com/openjdk/jdk/blob/master/test/langtools/jdk/javadoc/doclet/testDocTreeDiags/TestDocTreeDiags.java
[JDK-8268420]: https://bugs.openjdk.org/browse/JDK-8268420

This is why I reverted to the proposed minimalistic solution, limiting space removal to text and `{@code}`/`{@literal}` tags within `<pre>` elements. These are all doctrees that are passed though without further processing, so it is highly unlikely that anybody would ever want to report a source position inside of them. The begin postions will be correct since we're parsing the unchanged doc comment, but positions inside the string after the first line break would report a wrong position. This is why I filed [a CSR to amend the spec for above mentioned method][CSR] with a note about this. 

[CSR]: https://bugs.openjdk.org/browse/JDK-8350428

Regarding the second issue, I agree the JavaScript solution is not ideal. But it's a small price to pay in order to get readable and good looking documentation. We have close to 1000 instances of `<pre>{@code}` in JDK source code alone, and they will never get fixed and continue to haunt our otherwise great documentation. The same problem affects most Java libraries out there. You see I'm quite passionate about this, but I agree to move it to a separate issue if you think that's the best way to handle this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23868#issuecomment-2702033467

From darcy at openjdk.org  Thu Mar  6 00:31:54 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Mar 2025 00:31:54 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea
In-Reply-To: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
References: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
Message-ID: <CrPrnus-MjJp1ngxFQGXFOPP4d-5_OxC1O-O6l4OSHQ=.2d604de5-a6b2-47ef-b610-13fd1f11591c@github.com>

On Wed, 5 Mar 2025 15:16:03 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23917#pullrequestreview-2662793406

From hannesw at openjdk.org  Thu Mar  6 05:18:26 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 6 Mar 2025 05:18:26 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text [v2]
In-Reply-To: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
References: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
Message-ID: <LYiVL3onbfc3beZkP2PyJqqysTzqQng1At6f3gNoTb4=.dc92b07d-b6e1-445e-b26a-eca897bd9f48@github.com>

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `<pre>` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `<pre>` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `<pre>` alone or in combination with `<code>` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `<blockquote>`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `<pre>` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `<pre>` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `<pre><code>\n` open tags. Browsers will [ignore a newline immediately following a `<pre>` tag][1], but not if there is a `<code>` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `<code>\n` at the beginning of `<pre>` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

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

  Remove script for normalizing leading space in pre/code based on review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23868/files
  - new: https://git.openjdk.org/jdk/pull/23868/files/13638f80..d2128b3a

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

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

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

From hannesw at openjdk.org  Thu Mar  6 05:31:52 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 6 Mar 2025 05:31:52 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text [v2]
In-Reply-To: <LYiVL3onbfc3beZkP2PyJqqysTzqQng1At6f3gNoTb4=.dc92b07d-b6e1-445e-b26a-eca897bd9f48@github.com>
References: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
 <LYiVL3onbfc3beZkP2PyJqqysTzqQng1At6f3gNoTb4=.dc92b07d-b6e1-445e-b26a-eca897bd9f48@github.com>
Message-ID: <RB6nVg-TnIJnBSM27dVYhhV-cu-de_fjlAqxIZSSZhw=.5d807de3-b5ca-447e-8c8e-8e0aa775da97@github.com>

On Thu, 6 Mar 2025 05:18:26 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `<pre>` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `<pre>` tags.
>> 
>> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `<pre>` alone or in combination with `<code>` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `<blockquote>`). 
>> 
>> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `<pre>` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
>> 
>> If the exact number of leading whitespace in `<pre>` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
>> 
>> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `<pre><code>\n` open tags. Browsers will [ignore a newline immediately following a `<pre>` tag][1], but not if there is a `<code>` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `<code>\n` at the beginning of `<pre>` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
>> 
>> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove script for normalizing leading space in pre/code based on review feedback

I removed the script to strip leading whitespace based on your feedback. 

Regarding the added complexity this patch adds to `DocCommentParser` (which I dislike as you do): I think we could reconsider exclusion of multiline inline content. The test examples I came up with are very contrived (multiline `title` attribute and `{@index}` tag inside `<pre>`, both of which would not mind removal of redundant space after line breaks). I initially tried using a `{@snippet}` tag inside `<pre>` which is also completely unrealistic, but `{@snippet}` is not even affected as it does its own parsing.

Without that exclusion, the patch is mostly just two simple methods, and all the added complexity to `content` and other existing methods is gone.

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

PR Comment: https://git.openjdk.org/jdk/pull/23868#issuecomment-2702853308

From duke at openjdk.org  Thu Mar  6 15:43:21 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 6 Mar 2025 15:43:21 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v4]
In-Reply-To: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
Message-ID: <Wj7pRjftl2j8Lh_2PmUMtlrClm0Gn6ybXASF-uPNWgM=.14d2ac87-d7a0-4a00-9e24-5e1d5ba7f776@github.com>

> 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:

  Adding a test for the annotation processing Filer.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23699/files
  - new: https://git.openjdk.org/jdk/pull/23699/files/8b913484..2fbb486e

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

  Stats: 193 lines in 2 files changed: 191 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 magnus.ihse.bursie at oracle.com  Thu Mar  6 15:45:26 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 16:45:26 +0100
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <c75c8be6-ebe7-42f1-bb87-f3804ef71f48@oracle.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
 <c75c8be6-ebe7-42f1-bb87-f3804ef71f48@oracle.com>
Message-ID: <99c2297d-9c66-4c88-8146-cf4c654a017d@oracle.com>

On 2025-03-04 07:16, Joseph D. Darcy wrote:

> Another consideration is being able to successfully compile a code 
> base under multiple javac versions. A particular important instance of 
> this is boot strapping the JDK :-)
>
> Cases that have occurred in the past that would make such a discipline 
> challenging include:
>
> * Correctness fixes to the warning computation
> * Expanding (or narrowing) the scope of what the warning looks for 
> (e.g. the serial warning)
>
> So perhaps "messages" about "unnecessary warning suppression" should 
> be relayed somewhat outside of the existing warnings mechanism.
>
I concur. Earlier versions of gcc complained if you wanted to disable a 
warning like -Wno-new-fancy-warning, making it a complete mess to get 
things to compile cleanly for different versions. Later versions changed 
this into a policy where command line arguments like 
-Wno-dont-recognize-this-warning are just silently ignored -- unless 
another warning is triggered on that file, in which case gcc *also* 
emits a warning about an unknown warning. I think this is a reasonably 
pragmatic approach.

But having warning suppression that does not make sense for a given 
compiler is not necessary a problem, and if it should be flagged, it 
should be something you opt into, and possibly, as Joe suggests, somehow 
lie outside normal warnings.

/Magnus


From archie.cobbs at gmail.com  Thu Mar  6 16:12:50 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 6 Mar 2025 10:12:50 -0600
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <99c2297d-9c66-4c88-8146-cf4c654a017d@oracle.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
 <c75c8be6-ebe7-42f1-bb87-f3804ef71f48@oracle.com>
 <99c2297d-9c66-4c88-8146-cf4c654a017d@oracle.com>
Message-ID: <CANSoFxvznLHEjUBCm4FgSK8rrYswCsB=fvBpc7jj8ki4GZ+CBw@mail.gmail.com>

On Thu, Mar 6, 2025 at 9:45?AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> But having warning suppression that does not make sense for a given
> compiler is not necessary a problem, and if it should be flagged, it
> should be something you opt into, and possibly, as Joe suggests, somehow
> lie outside normal warnings.


I did think about this question of interactions between -Werror, -Xlint:all,
and different compiler versions with respect to these new warning
categories. In particular, thinking through the scenarios is why the
-Xlint:suppression flag is ignored unless the -Xlint:options flag is also
enabled (see below).

Here are my thoughts... please check my logic:

   - In the case of @SuppressWarnings annotations:
      - What if a compiler doesn't recognize
      @SuppressWarnings("suppression")?
         - No problem - it's already the case that unrecognized keys are
         ignored
      - What if two compiler versions handle some warning "foo"
      differently, so that one warns where one doesn't?
         - In this case @SuppressWarnings("foo") will be unnecessary in one
         case but not the other
            - In the latter you'd then get a "suppression" warning if
            enabled and the compiler supports it
         - But this happens all the time - i.e., a new warning is
         introduced or an existing warning's behavior changes
         - The usual answer is to add @SuppressWarnings("foo") to suppress
         the warning in the compiler version where it occurs
         - Similarly, the answer here is to add
         @SuppressWarnings("suppression") to suppress the warning in the
         compiler version where it occurs
      - In the case of -Xlint:suppression-option flags:
      - It's always safe to add -Xlint:-suppression-option to a build to
      restore the current behavior IF every compiler version knows that flag
      - If some compiler version doesn't know -Xlint:-suppression-option
      then -Xlint:-options also works
      - So there's always a way to disable suppression warnings, regardless
      of whether the compiler knows about "suppression-option"
      - Using -Xlint:-options  is only a temporary measure until all
      compiler versions support "suppression-option

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250306/09ab4573/attachment-0001.htm>

From hannesw at openjdk.org  Thu Mar  6 16:42:42 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 6 Mar 2025 16:42:42 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text [v3]
In-Reply-To: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
References: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
Message-ID: <bA344QY2QtBR5YdGkCCRqW3PMl8_iT5x59hfk8SzI28=.97b22bfb-8817-4f61-9238-2ab3e9c4c290@github.com>

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `<pre>` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `<pre>` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `<pre>` alone or in combination with `<code>` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `<blockquote>`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `<pre>` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `<pre>` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `<pre><code>\n` open tags. Browsers will [ignore a newline immediately following a `<pre>` tag][1], but not if there is a `<code>` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `<code>\n` at the beginning of `<pre>` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

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

  Switch to post-processing approach that fixes both problems
  
  This implements a visitor-based post-processing method in
  DocCommentParser that is able to fix both kinds of whitespace
  common in traditional doc comments. Tests have to be adapted
  to the additional normalization step. A few more tests should
  be added on the javadoc side.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23868/files
  - new: https://git.openjdk.org/jdk/pull/23868/files/d2128b3a..8a9036d6

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

  Stats: 304 lines in 4 files changed: 200 ins; 63 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/23868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23868/head:pull/23868

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

From hannesw at openjdk.org  Thu Mar  6 16:54:13 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 6 Mar 2025 16:54:13 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text [v4]
In-Reply-To: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
References: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
Message-ID: <FkV3_9PYJ9-3DIjOM1tLbeA9_6IxIzmYkAakXsvLulA=.2bba9cb0-a474-4716-96c9-a0b41b3a3b40@github.com>

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `<pre>` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `<pre>` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `<pre>` alone or in combination with `<code>` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `<blockquote>`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `<pre>` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `<pre>` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `<pre><code>\n` open tags. Browsers will [ignore a newline immediately following a `<pre>` tag][1], but not if there is a `<code>` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `<code>\n` at the beginning of `<pre>` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

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

  Fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23868/files
  - new: https://git.openjdk.org/jdk/pull/23868/files/8a9036d6..69464173

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

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

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

From darcy at openjdk.org  Thu Mar  6 17:07:58 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Mar 2025 17:07:58 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v4]
In-Reply-To: <Wj7pRjftl2j8Lh_2PmUMtlrClm0Gn6ybXASF-uPNWgM=.14d2ac87-d7a0-4a00-9e24-5e1d5ba7f776@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
 <Wj7pRjftl2j8Lh_2PmUMtlrClm0Gn6ybXASF-uPNWgM=.14d2ac87-d7a0-4a00-9e24-5e1d5ba7f776@github.com>
Message-ID: <IuDv4Sz_g1KNiVYhw1-rCOepYmiGyjO3vcYj2i5ejCo=.b1ad53ff-e8ac-4c83-9498-d50a36f415d6@github.com>

On Thu, 6 Mar 2025 15:43:21 GMT, David Beaumont <duke at openjdk.org> 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:
> 
>   Adding a test for the annotation processing Filer.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 921:

> 919:                 // Use the sibling to determine the output location where possible, unless
> 920:                 // it is in a JAR/ZIP file (we don't attempt to write class files back into
> 921:                 // archives). See JDK-8338675.

Per usual JDK coding conventions, we don't put bug numbers into source code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1983745971

From darcy at openjdk.org  Thu Mar  6 17:13:54 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Mar 2025 17:13:54 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v4]
In-Reply-To: <Wj7pRjftl2j8Lh_2PmUMtlrClm0Gn6ybXASF-uPNWgM=.14d2ac87-d7a0-4a00-9e24-5e1d5ba7f776@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
 <Wj7pRjftl2j8Lh_2PmUMtlrClm0Gn6ybXASF-uPNWgM=.14d2ac87-d7a0-4a00-9e24-5e1d5ba7f776@github.com>
Message-ID: <VjmB-DLb2Zs3ONXzHCc0zp_jJdKgLa1d1SA8DGNzLhM=.a583067e-bec9-48ee-8cbb-f5c60bf7020b@github.com>

On Thu, 6 Mar 2025 15:43:21 GMT, David Beaumont <duke at openjdk.org> 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:
> 
>   Adding a test for the annotation processing Filer.

test/langtools/tools/javac/modules/AnnotationFilerTest.java line 122:

> 120: 
> 121:     @SupportedAnnotationTypes("*")
> 122:     static class TestAnnotationProcessor extends AbstractProcessor {

Please see the test library file

langtools/toosl/javac/lib/JavacTestingAbstractProcessor.java

and consider extending that class instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1983754190

From ecaspole at openjdk.org  Thu Mar  6 19:51:46 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 6 Mar 2025 19:51:46 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea [v2]
In-Reply-To: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
References: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
Message-ID: <eq-WHe8KPISy6JkT_G66tjqdPYT89pFmFD5gQZ5C69o=.deef5eef-97b5-426a-8b09-919397fe6a7d@github.com>

> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:

  Fix header and remove unused Blackhole

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23917/files
  - new: https://git.openjdk.org/jdk/pull/23917/files/8c882666..649957dc

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

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

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

From ecaspole at openjdk.org  Thu Mar  6 19:51:47 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 6 Mar 2025 19:51:47 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea
In-Reply-To: <wN83mg8DRHAdFa1qY4KnKktVgC_SXiTFYqu6dK41Fh0=.ed2a71b2-fb19-463c-b660-b09074af350d@github.com>
References: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
 <wN83mg8DRHAdFa1qY4KnKktVgC_SXiTFYqu6dK41Fh0=.ed2a71b2-fb19-463c-b660-b09074af350d@github.com>
Message-ID: <rb97caTBTluudtS0BH9XF-eqna2UWHyyg3rLdIFAya8=.6b1c68ee-786e-4c64-8f9b-b2fbe64c5819@github.com>

On Wed, 5 Mar 2025 16:40:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.
>
> Also might need to add an 2025 copyright header for this file.

Thanks @liach I removed the unused Blackhole and updated the copyright header.

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

PR Comment: https://git.openjdk.org/jdk/pull/23917#issuecomment-2704796397

From ecaspole at openjdk.org  Fri Mar  7 15:31:08 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Fri, 7 Mar 2025 15:31:08 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea [v2]
In-Reply-To: <eq-WHe8KPISy6JkT_G66tjqdPYT89pFmFD5gQZ5C69o=.deef5eef-97b5-426a-8b09-919397fe6a7d@github.com>
References: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
 <eq-WHe8KPISy6JkT_G66tjqdPYT89pFmFD5gQZ5C69o=.deef5eef-97b5-426a-8b09-919397fe6a7d@github.com>
Message-ID: <-WCvmCD8w4Mdjm8IIjlkf2tFkUCZSJFSuZerS1YDCaM=.f7b06be3-cbcf-46fa-b40a-94cdf3b9488a@github.com>

On Thu, 6 Mar 2025 19:51:46 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix header and remove unused Blackhole

If these last cleanups are OK could I get one last Reviewer rubber stamp? TIA

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

PR Comment: https://git.openjdk.org/jdk/pull/23917#issuecomment-2706738246

From cushon at openjdk.org  Fri Mar  7 17:30:10 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 7 Mar 2025 17:30:10 GMT
Subject: RFR: 8351431: Type annotations on new class creation expressions can't
 be retrieved
Message-ID: <Rc-rH-PpJIO5iWTLv1QBoyiT2ebsAVN1se68PcZ-P54=.3354e93e-8235-4a37-907d-76bfa22fd1a2@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.

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

Commit messages:
 - 8351431: Type annotations on new class creation expressions can't be retrieved

Changes: https://git.openjdk.org/jdk/pull/23946/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23946&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351431
  Stats: 160 lines in 3 files changed: 153 ins; 1 del; 6 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 liach at openjdk.org  Fri Mar  7 20:39:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Mar 2025 20:39:54 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea [v2]
In-Reply-To: <eq-WHe8KPISy6JkT_G66tjqdPYT89pFmFD5gQZ5C69o=.deef5eef-97b5-426a-8b09-919397fe6a7d@github.com>
References: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
 <eq-WHe8KPISy6JkT_G66tjqdPYT89pFmFD5gQZ5C69o=.deef5eef-97b5-426a-8b09-919397fe6a7d@github.com>
Message-ID: <n3yBJu88qEvo0YbCg1luvKkxP75LIGR8GINkX77dE0Q=.c7bd270f-0e32-4a27-8c26-7ca565da2095@github.com>

On Thu, 6 Mar 2025 19:51:46 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix header and remove unused Blackhole

Indeed, these tests uses a static non-final field as the sink of work, which should be equivalent to using a blackhole. We can remove this unused blackhole safely.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23917#pullrequestreview-2668307561

From ecaspole at openjdk.org  Fri Mar  7 21:32:57 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Fri, 7 Mar 2025 21:32:57 GMT
Subject: Integrated: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea
In-Reply-To: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
References: <A2dw-Aihltap1LSxfCzBHRt-ALdvF4-i4pfpxlLda2c=.59e89f01-382e-4406-a694-72da6ed1e562@github.com>
Message-ID: <os9yoG6fUy59j6PXaHVrjVYQSL2IdeJlNYPIuD2eWUA=.8dbf3029-8c22-4ab4-b64e-3dc0a5f4f398@github.com>

On Wed, 5 Mar 2025 15:16:03 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

This pull request has now been integrated.

Changeset: 76e0f30b
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/76e0f30b15efda86cbb974bbc764ac3fb3f0f054
Stats:     157 lines in 1 file changed: 1 ins; 154 del; 2 mod

8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH fails with -ea

Reviewed-by: liach, darcy

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

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

From nbenalla at openjdk.org  Mon Mar 10 12:58:17 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 10 Mar 2025 12:58:17 GMT
Subject: RFR: 8350007: Add usage message to the javadoc executable [v5]
In-Reply-To: <dV9fCg-17wNUsIr6T02OwoIHg1vFAjZINje5CYhT6hY=.2198af40-1da1-48aa-ae43-b9cb26f25d60@github.com>
References: <dV9fCg-17wNUsIr6T02OwoIHg1vFAjZINje5CYhT6hY=.2198af40-1da1-48aa-ae43-b9cb26f25d60@github.com>
Message-ID: <x4u41-qCyk4PDa8EFGP4uWrUqSCayUYvEzjMUoI83c8=.ebf153c9-c6c5-4ddb-a8f6-83324d928623@github.com>

> This patch adds a new message when you run the `javadoc` executable with any arguments.
> Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved.
> 
> Before change:
> 
> W $ ./javadoc
> error: No modules, packages or classes specified.
> 1 error
> 
> 
> After change:
> 
> W $ ./javadoc
> Usage:
>     javadoc [options] [packagenames] [sourcefiles] [@files]
> For additional help on usage:           javadoc --help

Nizar Benalla 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 eight additional commits since the last revision:

 - review feedback: improve error message
 - Merge branch 'master' into javadoc-usage-message
 - update test
 - keep the same return value and write to STDERR
 - respond to feedback
 - Merge branch 'master' into javadoc-usage-message
 - update test with new usage message
 - improve javadoc executable message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23618/files
  - new: https://git.openjdk.org/jdk/pull/23618/files/d67e033b..1814c4b0

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

  Stats: 39103 lines in 1148 files changed: 17535 ins; 15983 del; 5585 mod
  Patch: https://git.openjdk.org/jdk/pull/23618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23618/head:pull/23618

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

From nbenalla at openjdk.org  Mon Mar 10 13:02:02 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 10 Mar 2025 13:02:02 GMT
Subject: RFR: 8350007: Add usage message to the javadoc executable [v5]
In-Reply-To: <x4u41-qCyk4PDa8EFGP4uWrUqSCayUYvEzjMUoI83c8=.ebf153c9-c6c5-4ddb-a8f6-83324d928623@github.com>
References: <dV9fCg-17wNUsIr6T02OwoIHg1vFAjZINje5CYhT6hY=.2198af40-1da1-48aa-ae43-b9cb26f25d60@github.com>
 <x4u41-qCyk4PDa8EFGP4uWrUqSCayUYvEzjMUoI83c8=.ebf153c9-c6c5-4ddb-a8f6-83324d928623@github.com>
Message-ID: <cNsOlaVvcnOgNihlgp6_M9qd6gOtLeuKnjupAbWk_Ec=.cd82ff86-3993-4529-95d5-2e15cbc8fee9@github.com>

On Mon, 10 Mar 2025 12:58:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This patch adds a new message when you run the `javadoc` executable with any arguments.
>> Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved.
>> 
>> Before change:
>> 
>> W $ ./javadoc
>> error: No modules, packages or classes specified.
>> 1 error
>> 
>> 
>> After change:
>> 
>> W $ ./javadoc
>> Usage:
>>     javadoc [options] [packagenames] [sourcefiles] [@files]
>> For additional help on usage:           javadoc --help
>
> Nizar Benalla 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 eight additional commits since the last revision:
> 
>  - review feedback: improve error message
>  - Merge branch 'master' into javadoc-usage-message
>  - update test
>  - keep the same return value and write to STDERR
>  - respond to feedback
>  - Merge branch 'master' into javadoc-usage-message
>  - update test with new usage message
>  - improve javadoc executable message

nizar-mac! $ javadoc
Usage:
    javadoc [options] [packagenames] [sourcefiles] [@files]
For more details on available options, use --help or --help-extra
error: No modules, packages or classes specified.
1 error

flushing is necessary to print out the usage message consistently before the error

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

PR Comment: https://git.openjdk.org/jdk/pull/23618#issuecomment-2710516531

From hannesw at openjdk.org  Mon Mar 10 15:57:02 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 10 Mar 2025 15:57:02 GMT
Subject: RFR: 8350007: Add usage message to the javadoc executable [v5]
In-Reply-To: <x4u41-qCyk4PDa8EFGP4uWrUqSCayUYvEzjMUoI83c8=.ebf153c9-c6c5-4ddb-a8f6-83324d928623@github.com>
References: <dV9fCg-17wNUsIr6T02OwoIHg1vFAjZINje5CYhT6hY=.2198af40-1da1-48aa-ae43-b9cb26f25d60@github.com>
 <x4u41-qCyk4PDa8EFGP4uWrUqSCayUYvEzjMUoI83c8=.ebf153c9-c6c5-4ddb-a8f6-83324d928623@github.com>
Message-ID: <68udoUXFr-Y1eYrZTyyQJWWBkX4X29qrACYWEud3Uqg=.1e5fcb20-42ab-46ed-859d-1c9ac8d230d7@github.com>

On Mon, 10 Mar 2025 12:58:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This patch adds a new message when you run the `javadoc` executable with any arguments.
>> Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved.
>> 
>> Before change:
>> 
>> W $ ./javadoc
>> error: No modules, packages or classes specified.
>> 1 error
>> 
>> 
>> After change:
>> 
>> W $ ./javadoc
>> Usage:
>>     javadoc [options] [packagenames] [sourcefiles] [@files]
>> For additional help on usage:           javadoc --help
>
> Nizar Benalla 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 eight additional commits since the last revision:
> 
>  - review feedback: improve error message
>  - Merge branch 'master' into javadoc-usage-message
>  - update test
>  - keep the same return value and write to STDERR
>  - respond to feedback
>  - Merge branch 'master' into javadoc-usage-message
>  - update test with new usage message
>  - improve javadoc executable message

Nice!

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23618#pullrequestreview-2671482448

From nbenalla at openjdk.org  Mon Mar 10 16:18:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 10 Mar 2025 16:18:59 GMT
Subject: Integrated: 8350007: Add usage message to the javadoc executable
In-Reply-To: <dV9fCg-17wNUsIr6T02OwoIHg1vFAjZINje5CYhT6hY=.2198af40-1da1-48aa-ae43-b9cb26f25d60@github.com>
References: <dV9fCg-17wNUsIr6T02OwoIHg1vFAjZINje5CYhT6hY=.2198af40-1da1-48aa-ae43-b9cb26f25d60@github.com>
Message-ID: <JanELLbfcPrLhfv7W10fiG1mZy8p_PaTd0lDSMoIGHs=.a84a6d42-7810-4bbf-a769-7a8ea157e183@github.com>

On Thu, 13 Feb 2025 16:41:54 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This patch adds a new message when you run the `javadoc` executable with any arguments.
> Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved.
> 
> Before change:
> 
> W $ ./javadoc
> error: No modules, packages or classes specified.
> 1 error
> 
> 
> After change:
> 
> W $ ./javadoc
> Usage:
>     javadoc [options] [packagenames] [sourcefiles] [@files]
> For additional help on usage:           javadoc --help

This pull request has now been integrated.

Changeset: 6b84bdef
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b84bdef3b203e62cebd77705ef5b3e081302c28
Stats:     11 lines in 3 files changed: 6 ins; 1 del; 4 mod

8350007: Add usage message to the javadoc executable

Reviewed-by: hannesw

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

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

From nbenalla at openjdk.org  Mon Mar 10 16:18:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 10 Mar 2025 16:18:59 GMT
Subject: RFR: 8350007: Add usage message to the javadoc executable [v5]
In-Reply-To: <x4u41-qCyk4PDa8EFGP4uWrUqSCayUYvEzjMUoI83c8=.ebf153c9-c6c5-4ddb-a8f6-83324d928623@github.com>
References: <dV9fCg-17wNUsIr6T02OwoIHg1vFAjZINje5CYhT6hY=.2198af40-1da1-48aa-ae43-b9cb26f25d60@github.com>
 <x4u41-qCyk4PDa8EFGP4uWrUqSCayUYvEzjMUoI83c8=.ebf153c9-c6c5-4ddb-a8f6-83324d928623@github.com>
Message-ID: <mPGb6yGRmtbKZUsjaUvcBN-P2awqNGTQFsptF1Lx5iw=.96fba8c3-d0a5-4ae3-afcd-a753d4c92466@github.com>

On Mon, 10 Mar 2025 12:58:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This patch adds a new message when you run the `javadoc` executable with any arguments.
>> Currently, unlike most other tools, running `javadoc` without any arguments does not show you how to use the tool or point you to use the `--help` option, this can be improved.
>> 
>> Before change:
>> 
>> W $ ./javadoc
>> error: No modules, packages or classes specified.
>> 1 error
>> 
>> 
>> After change:
>> 
>> W $ ./javadoc
>> Usage:
>>     javadoc [options] [packagenames] [sourcefiles] [@files]
>> For additional help on usage:           javadoc --help
>
> Nizar Benalla 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 eight additional commits since the last revision:
> 
>  - review feedback: improve error message
>  - Merge branch 'master' into javadoc-usage-message
>  - update test
>  - keep the same return value and write to STDERR
>  - respond to feedback
>  - Merge branch 'master' into javadoc-usage-message
>  - update test with new usage message
>  - improve javadoc executable message

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23618#issuecomment-2711122330

From vromero at openjdk.org  Mon Mar 10 16:47:00 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 10 Mar 2025 16:47:00 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v3]
In-Reply-To: <-1FFbwdd5-iKZm3sg_bu1BVj-g-jo5XHq4dykt9Spyk=.5d5979b8-3b14-45d2-b4cb-2280713020c5@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <-1FFbwdd5-iKZm3sg_bu1BVj-g-jo5XHq4dykt9Spyk=.5d5979b8-3b14-45d2-b4cb-2280713020c5@github.com>
Message-ID: <yWoedN3FTdzRonEc6GfXqfZ24tLjnq5VUMamkIK0wl0=.8d0d93d0-4a21-47d1-828b-c1dcac3babf1@github.com>

On Wed, 5 Mar 2025 16:42:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
>> 
>> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
>> 
>> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
>> 
>> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Fix javap test
>  - 8164714: Constructor.newInstance creates instance of inner class with null outer class

looks sensible

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 1797:

> 1795:     }
> 1796: 
> 1797:     /** Return tree simulating null checking outer this and assigning. */

probably this comment should state that the assignment is generated or not depending on the value of argument `stores`

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23875#pullrequestreview-2671613345
PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1987661446

From liach at openjdk.org  Mon Mar 10 17:08:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Mar 2025 17:08:55 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v2]
In-Reply-To: <Q0hLvYduIpPrlQay_b5p0-TpSrmdxrK0M4lpy5x_3vU=.d11fb7de-8558-4223-b8a3-5248e6036fb5@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <rjQqe2gsOBXptah4Kb_a0hWYD0P-PbMX8FBJLShr7Bw=.a89cf4a1-75b9-41cd-81d7-ef2e275afcd9@github.com>
 <9UnH5j5gAYh1vZrvysnTSc8hfSbKwGmdjMB2Iq12rAs=.09281753-af6d-4ee3-a26e-7ac77b1d07d9@github.com>
 <l50ZsoWz03v_ZR3xsID29V63ttrXwrpre_60ZsQixUY=.2210bd68-9603-4d6f-830f-882b6fe17e09@github.com>
 <Q0hLvYduIpPrlQay_b5p0-TpSrmdxrK0M4lpy5x_3vU=.d11fb7de-8558-4223-b8a3-5248e6036fb5@github.com>
Message-ID: <eiIC9fLOghRpJf8PLmbwlhrfvCu1Ei7OyA-bgZVAyI4=.f790a63d-833c-4a4e-a41f-b9eba838acf4@github.com>

On Wed, 5 Mar 2025 20:17:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> CP differences when Objects.requireNonNull is emitted
>
> then we should add the bug id to the test

I noted https://bugs.openjdk.org/browse/JDK-8292275 also changed many tests that this patch has changed but did not add the bug id. Is the bug id only to indicate which bug's regression is a test testing against?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1987700753

From shade at openjdk.org  Mon Mar 10 18:28:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 18:28:55 GMT
Subject: RFR: 8351556: Optimize Location.isModuleOrientedLocation
In-Reply-To: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
Message-ID: <EFb-ng4mfNbzG0rZWz8Ar1fGZ7Xs10YFkXS9dVadAhY=.25f34eaf-48d6-46a9-a520-f5f4b7b046ab@github.com>

On Mon, 10 Mar 2025 18:22:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
> 
> This improvement naturally spills over to `Location.locationFor`.
> 
> Things we do:
>  1. Avoid `putIfAbsent` on fast-path.
>  2. Lazily cache `Pattern` and reuse for all related paths.
>  3. Capture output/module flags ahead of time, instead of recomputing them.
>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
> 
> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
> 
> Additional testing:
>  - [x] New regression test still works
>  - [x] New benchmark shows improvements
>  - [x] Linux x86_64 server fastdebug, `langtools_all`

5950X benchmark run:


Benchmark             Mode  Cnt   Score   Error  Units

# Before
LocationFor.custom    avgt    9    9.372 ? 0.069  ns/op
LocationFor.standard  avgt    9  163.774 ? 1.459  ns/op

# After
LocationFor.custom    avgt    9    1.982 ? 0.036  ns/op
LocationFor.standard  avgt    9   38.854 ? 0.276  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/23973#issuecomment-2711459225

From shade at openjdk.org  Mon Mar 10 18:28:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 18:28:55 GMT
Subject: RFR: 8351556: Optimize Location.isModuleOrientedLocation
Message-ID: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>

Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.

This improvement naturally spills over to `Location.locationFor`.

Things we do:
 1. Avoid `putIfAbsent` on fast-path.
 2. Lazily cache `Pattern` and reuse for all related paths.
 3. Capture output/module flags ahead of time, instead of recomputing them.
 4. (for interpreter/startup benefit) Use direct class type instead of interface.

There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.

Additional testing:
 - [x] New regression test still works
 - [x] New benchmark shows improvements
 - [x] Linux x86_64 server fastdebug, `langtools_all`

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/23973/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23973&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351556
  Stats: 194 lines in 4 files changed: 178 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23973/head:pull/23973

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

From shade at openjdk.org  Mon Mar 10 18:34:34 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 18:34:34 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v2]
In-Reply-To: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
Message-ID: <dwFrMCjM-VQxfjv8snbDj-5jY9Y5J2q-aZgNxah-qzg=.de50640a-e2da-46e8-9ccb-a729773da7b9@github.com>

> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
> 
> This improvement naturally spills over to `Location.locationFor`.
> 
> Things we do:
>  1. Avoid `putIfAbsent` on fast-path.
>  2. Lazily cache `Pattern` and reuse for all related paths.
>  3. Capture output/module flags ahead of time, instead of recomputing them.
>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
> 
> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
> 
> Additional testing:
>  - [x] New regression test still works
>  - [x] New benchmark shows improvements
>  - [ ] Linux x86_64 server fastdebug, `langtools_all`

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Also direct properties test
 - Touchups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23973/files
  - new: https://git.openjdk.org/jdk/pull/23973/files/08490e19..d58d2769

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

  Stats: 64 lines in 2 files changed: 59 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23973/head:pull/23973

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

From duke at openjdk.org  Mon Mar 10 19:18:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 10 Mar 2025 19:18:12 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v4]
In-Reply-To: <IuDv4Sz_g1KNiVYhw1-rCOepYmiGyjO3vcYj2i5ejCo=.b1ad53ff-e8ac-4c83-9498-d50a36f415d6@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
 <Wj7pRjftl2j8Lh_2PmUMtlrClm0Gn6ybXASF-uPNWgM=.14d2ac87-d7a0-4a00-9e24-5e1d5ba7f776@github.com>
 <IuDv4Sz_g1KNiVYhw1-rCOepYmiGyjO3vcYj2i5ejCo=.b1ad53ff-e8ac-4c83-9498-d50a36f415d6@github.com>
Message-ID: <MLa7J5aHPdc4nIjFL5K73yolgEWnHcS2Zu1Cn8ZaMXg=.37a22e36-cf86-46e6-bdec-d5f1b9eee724@github.com>

On Thu, 6 Mar 2025 17:05:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a test for the annotation processing Filer.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 921:
> 
>> 919:                 // Use the sibling to determine the output location where possible, unless
>> 920:                 // it is in a JAR/ZIP file (we don't attempt to write class files back into
>> 921:                 // archives). See JDK-8338675.
> 
> Per usual JDK coding conventions, we don't put bug numbers into source code.

I wasn't aware of this. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r1987879314

From liach at openjdk.org  Mon Mar 10 19:34:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Mar 2025 19:34:53 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v2]
In-Reply-To: <dwFrMCjM-VQxfjv8snbDj-5jY9Y5J2q-aZgNxah-qzg=.de50640a-e2da-46e8-9ccb-a729773da7b9@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <dwFrMCjM-VQxfjv8snbDj-5jY9Y5J2q-aZgNxah-qzg=.de50640a-e2da-46e8-9ccb-a729773da7b9@github.com>
Message-ID: <36aV2A4XBxf85H37Spvvu4mTfDxJFGXnaojiaYgTWb4=.abab13d5-3e56-456c-a954-7898800dab5f@github.com>

On Mon, 10 Mar 2025 18:34:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
>> 
>> This improvement naturally spills over to `Location.locationFor`.
>> 
>> Things we do:
>>  1. Avoid `putIfAbsent` on fast-path.
>>  2. Lazily cache `Pattern` and reuse for all related paths.
>>  3. Capture output/module flags ahead of time, instead of recomputing them.
>>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
>> 
>> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
>> 
>> Additional testing:
>>  - [x] New regression test still works
>>  - [x] New benchmark shows improvements
>>  - [x] Linux x86_64 server fastdebug/release, `langtools_all`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Also direct properties test
>  - Touchups

src/java.compiler/share/classes/javax/tools/StandardLocation.java line 119:

> 117:     private static final ConcurrentHashMap<String, Location> LOCATIONS = new ConcurrentHashMap<>();
> 118: 
> 119:     private static class LazyPatternHolder {

Should we keep this as a local class in `computeIsModuleOrientedLocation` as it is only used in that method??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23973#discussion_r1987900168

From liach at openjdk.org  Mon Mar 10 19:34:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Mar 2025 19:34:53 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v2]
In-Reply-To: <36aV2A4XBxf85H37Spvvu4mTfDxJFGXnaojiaYgTWb4=.abab13d5-3e56-456c-a954-7898800dab5f@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <dwFrMCjM-VQxfjv8snbDj-5jY9Y5J2q-aZgNxah-qzg=.de50640a-e2da-46e8-9ccb-a729773da7b9@github.com>
 <36aV2A4XBxf85H37Spvvu4mTfDxJFGXnaojiaYgTWb4=.abab13d5-3e56-456c-a954-7898800dab5f@github.com>
Message-ID: <3CfNL52qlL0SayJmcw0A8OuleljEVN2elty9Xx0avPo=.6c737e4b-32af-4770-8f2f-b1ae460035fa@github.com>

On Mon, 10 Mar 2025 19:30:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Also direct properties test
>>  - Touchups
>
> src/java.compiler/share/classes/javax/tools/StandardLocation.java line 119:
> 
>> 117:     private static final ConcurrentHashMap<String, Location> LOCATIONS = new ConcurrentHashMap<>();
>> 118: 
>> 119:     private static class LazyPatternHolder {
> 
> Should we keep this as a local class in `computeIsModuleOrientedLocation` as it is only used in that method??

Even better, we can move this static utility `computeIsModuleOrientedLocation` into the `new Location` anonymous class and convert it to a local class; that way we define one fewer class as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23973#discussion_r1987903069

From liach at openjdk.org  Mon Mar 10 19:39:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Mar 2025 19:39:00 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v2]
In-Reply-To: <dwFrMCjM-VQxfjv8snbDj-5jY9Y5J2q-aZgNxah-qzg=.de50640a-e2da-46e8-9ccb-a729773da7b9@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <dwFrMCjM-VQxfjv8snbDj-5jY9Y5J2q-aZgNxah-qzg=.de50640a-e2da-46e8-9ccb-a729773da7b9@github.com>
Message-ID: <kJkN8JPMjbfFXZq_t08dN_pkwFfVdBdoN0TZ-KbM0ic=.cba3847d-3d68-45ea-b27b-390dabe00d7f@github.com>

On Mon, 10 Mar 2025 18:34:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
>> 
>> This improvement naturally spills over to `Location.locationFor`.
>> 
>> Things we do:
>>  1. Avoid `putIfAbsent` on fast-path.
>>  2. Lazily cache `Pattern` and reuse for all related paths.
>>  3. Capture output/module flags ahead of time, instead of recomputing them.
>>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
>> 
>> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
>> 
>> Additional testing:
>>  - [x] New regression test still works
>>  - [x] New benchmark shows improvements
>>  - [x] Linux x86_64 server fastdebug/release, `langtools_all`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Also direct properties test
>  - Touchups

src/java.compiler/share/classes/javax/tools/StandardLocation.java line 166:

> 164:             boolean isOutputLocation = name.endsWith("_OUTPUT");
> 165:             boolean isModuleOrientedLocation = computeIsModuleOrientedLocation(name);
> 166:             newLoc = new Location() {

So something like:

record CustomLocation(String name, boolean isOutputLocation, boolean isModuleOrientedLocation) implements Location {
    static final Pattern MODULE_WORD_PATTERN = Pattern.compile("\\bMODULE\\b");
    static boolean computeIsModuleOrientedLocation(String name) {
        return MODULE_WORD_PATTERN.matcher(name).matches();
    }
    @Override public String getName() { return name; }
}
boolean isOutputLocation = name.endsWith("_OUTPUT");
boolean isModuleOrientedLocation = CustomLocation.computeIsModuleOrientedLocation(name);
return new CustomLocation(name, isOutputLocation, isModuleOrientedLocation);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23973#discussion_r1987907251

From shade at openjdk.org  Mon Mar 10 19:49:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 19:49:54 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v2]
In-Reply-To: <3CfNL52qlL0SayJmcw0A8OuleljEVN2elty9Xx0avPo=.6c737e4b-32af-4770-8f2f-b1ae460035fa@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <dwFrMCjM-VQxfjv8snbDj-5jY9Y5J2q-aZgNxah-qzg=.de50640a-e2da-46e8-9ccb-a729773da7b9@github.com>
 <36aV2A4XBxf85H37Spvvu4mTfDxJFGXnaojiaYgTWb4=.abab13d5-3e56-456c-a954-7898800dab5f@github.com>
 <3CfNL52qlL0SayJmcw0A8OuleljEVN2elty9Xx0avPo=.6c737e4b-32af-4770-8f2f-b1ae460035fa@github.com>
Message-ID: <tQzW0iCu1Ew5Z5l85B5OEMe7TRxkBLu-iSeEpFbArRE=.880fa91b-011b-482e-8d30-720154db2945@github.com>

On Mon, 10 Mar 2025 19:32:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/tools/StandardLocation.java line 119:
>> 
>>> 117:     private static final ConcurrentHashMap<String, Location> LOCATIONS = new ConcurrentHashMap<>();
>>> 118: 
>>> 119:     private static class LazyPatternHolder {
>> 
>> Should we keep this as a local class in `computeIsModuleOrientedLocation` as it is only used in that method??
>
> Even better, we can move this static utility `computeIsModuleOrientedLocation` into the `new Location` anonymous class and convert it to a local class; that way we define one fewer class as well.

Problem is, I need to reach the compiled `Pattern` from `JavaFileManager.Location.isModuleOrientedLocation`. So I need to make sure there is no extra leakage within the package. A single package-private static method is the smallest hole I can drill. I can take a closer look tomorrow, but it feels more reliable this way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23973#discussion_r1987922265

From shade at openjdk.org  Tue Mar 11 09:22:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Mar 2025 09:22:44 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v3]
In-Reply-To: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
Message-ID: <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>

> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
> 
> This improvement naturally spills over to `Location.locationFor`.
> 
> Things we do:
>  1. Avoid `putIfAbsent` on fast-path.
>  2. Lazily cache `Pattern` and reuse for all related paths.
>  3. Capture output/module flags ahead of time, instead of recomputing them.
>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
> 
> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
> 
> Additional testing:
>  - [x] New regression test still works
>  - [x] New benchmark shows improvements
>  - [x] Linux x86_64 server fastdebug/release, `langtools_all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Tidy up comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23973/files
  - new: https://git.openjdk.org/jdk/pull/23973/files/d58d2769..6a219ace

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

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

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

From shade at openjdk.org  Tue Mar 11 09:22:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Mar 2025 09:22:44 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v2]
In-Reply-To: <tQzW0iCu1Ew5Z5l85B5OEMe7TRxkBLu-iSeEpFbArRE=.880fa91b-011b-482e-8d30-720154db2945@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <dwFrMCjM-VQxfjv8snbDj-5jY9Y5J2q-aZgNxah-qzg=.de50640a-e2da-46e8-9ccb-a729773da7b9@github.com>
 <36aV2A4XBxf85H37Spvvu4mTfDxJFGXnaojiaYgTWb4=.abab13d5-3e56-456c-a954-7898800dab5f@github.com>
 <3CfNL52qlL0SayJmcw0A8OuleljEVN2elty9Xx0avPo=.6c737e4b-32af-4770-8f2f-b1ae460035fa@github.com>
 <tQzW0iCu1Ew5Z5l85B5OEMe7TRxkBLu-iSeEpFbArRE=.880fa91b-011b-482e-8d30-720154db2945@github.com>
Message-ID: <43uR3a4dVqMvcEMcTCkDr-2hbIreJ-YZavwQ97dUzv0=.07b573fe-2922-49b2-af5e-f708ac5e6252@github.com>

On Mon, 10 Mar 2025 19:47:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Even better, we can move this static utility `computeIsModuleOrientedLocation` into the `new Location` anonymous class and convert it to a local class; that way we define one fewer class as well.
>
> Problem is, I need to reach the compiled `Pattern` from `JavaFileManager.Location.isModuleOrientedLocation`. So I need to make sure there is no extra leakage within the package. A single package-private static method is the smallest hole I can drill. I can take a closer look tomorrow, but it feels more reliable this way.

Yeah, it does not work, really. My attempts in creating a separate class/record for location, attempts to access it from `JavaFileManager`, munging build system to compile the interim javac correctly -- all this uglifies the patch. So I would like to go with the current version. I tidied up some comments, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23973#discussion_r1988770939

From shade at openjdk.org  Tue Mar 11 09:22:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Mar 2025 09:22:44 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v2]
In-Reply-To: <kJkN8JPMjbfFXZq_t08dN_pkwFfVdBdoN0TZ-KbM0ic=.cba3847d-3d68-45ea-b27b-390dabe00d7f@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <dwFrMCjM-VQxfjv8snbDj-5jY9Y5J2q-aZgNxah-qzg=.de50640a-e2da-46e8-9ccb-a729773da7b9@github.com>
 <kJkN8JPMjbfFXZq_t08dN_pkwFfVdBdoN0TZ-KbM0ic=.cba3847d-3d68-45ea-b27b-390dabe00d7f@github.com>
Message-ID: <U_qZOTc1Ie5Nadx2xGYFFHw68p2GTfvr2DAnRLNXEEM=.2a8d34de-6dc4-40a3-918d-efe87c25e87c@github.com>

On Mon, 10 Mar 2025 19:36:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Also direct properties test
>>  - Touchups
>
> src/java.compiler/share/classes/javax/tools/StandardLocation.java line 166:
> 
>> 164:             boolean isOutputLocation = name.endsWith("_OUTPUT");
>> 165:             boolean isModuleOrientedLocation = computeIsModuleOrientedLocation(name);
>> 166:             newLoc = new Location() {
> 
> So something like:
> 
> record CustomLocation(String name, boolean isOutputLocation, boolean isModuleOrientedLocation) implements Location {
>     static final Pattern MODULE_WORD_PATTERN = Pattern.compile("\\bMODULE\\b");
>     static boolean computeIsModuleOrientedLocation(String name) {
>         return MODULE_WORD_PATTERN.matcher(name).matches();
>     }
>     @Override public String getName() { return name; }
> }
> boolean isOutputLocation = name.endsWith("_OUTPUT");
> boolean isModuleOrientedLocation = CustomLocation.computeIsModuleOrientedLocation(name);
> return new CustomLocation(name, isOutputLocation, isModuleOrientedLocation);

See https://github.com/openjdk/jdk/pull/23973/files#r1988770939

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23973#discussion_r1988771741

From rriggs at openjdk.org  Tue Mar 11 19:27:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Mar 2025 19:27:58 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v2]
In-Reply-To: <eiIC9fLOghRpJf8PLmbwlhrfvCu1Ei7OyA-bgZVAyI4=.f790a63d-833c-4a4e-a41f-b9eba838acf4@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <rjQqe2gsOBXptah4Kb_a0hWYD0P-PbMX8FBJLShr7Bw=.a89cf4a1-75b9-41cd-81d7-ef2e275afcd9@github.com>
 <9UnH5j5gAYh1vZrvysnTSc8hfSbKwGmdjMB2Iq12rAs=.09281753-af6d-4ee3-a26e-7ac77b1d07d9@github.com>
 <l50ZsoWz03v_ZR3xsID29V63ttrXwrpre_60ZsQixUY=.2210bd68-9603-4d6f-830f-882b6fe17e09@github.com>
 <Q0hLvYduIpPrlQay_b5p0-TpSrmdxrK0M4lpy5x_3vU=.d11fb7de-8558-4223-b8a3-5248e6036fb5@github.com>
 <eiIC9fLOghRpJf8PLmbwlhrfvCu1Ei7OyA-bgZVAyI4=.f790a63d-833c-4a4e-a41f-b9eba838acf4@github.com>
Message-ID: <UY1VvhPpKF_GhGBScW3YIYAYCKes9eoFZkwV4F9vvvk=.be2e79f8-ba08-4997-b77d-ba225336fae0@github.com>

On Mon, 10 Mar 2025 17:06:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> then we should add the bug id to the test
>
> I noted https://bugs.openjdk.org/browse/JDK-8292275 also changed many tests that this patch has changed but did not add the bug id. Is the bug id only to indicate which bug's regression is a test testing against?

Jtreg supports the -bug:<bugid> option to run matching tests.

Adding the bugid is an aid in verifying bugs. If it was missed being added earlier it can be added now.  But it is unlikely it will be missed by anyone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1989991176

From liach at openjdk.org  Tue Mar 11 19:39:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Mar 2025 19:39:03 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v2]
In-Reply-To: <UY1VvhPpKF_GhGBScW3YIYAYCKes9eoFZkwV4F9vvvk=.be2e79f8-ba08-4997-b77d-ba225336fae0@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <rjQqe2gsOBXptah4Kb_a0hWYD0P-PbMX8FBJLShr7Bw=.a89cf4a1-75b9-41cd-81d7-ef2e275afcd9@github.com>
 <9UnH5j5gAYh1vZrvysnTSc8hfSbKwGmdjMB2Iq12rAs=.09281753-af6d-4ee3-a26e-7ac77b1d07d9@github.com>
 <l50ZsoWz03v_ZR3xsID29V63ttrXwrpre_60ZsQixUY=.2210bd68-9603-4d6f-830f-882b6fe17e09@github.com>
 <Q0hLvYduIpPrlQay_b5p0-TpSrmdxrK0M4lpy5x_3vU=.d11fb7de-8558-4223-b8a3-5248e6036fb5@github.com>
 <eiIC9fLOghRpJf8PLmbwlhrfvCu1Ei7OyA-bgZVAyI4=.f790a63d-833c-4a4e-a41f-b9eba838acf4@github.com>
 <UY1VvhPpKF_GhGBScW3YIYAYCKes9eoFZkwV4F9vvvk=.be2e79f8-ba08-4997-b77d-ba225336fae0@github.com>
Message-ID: <qZ6FOqIs6F2aUYdpCpURSZ8iGcwRw-SYN6JiIdc6cZE=.d31bf619-31b1-4ebe-a3ae-e18345bceb1c@github.com>

On Tue, 11 Mar 2025 19:25:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I noted https://bugs.openjdk.org/browse/JDK-8292275 also changed many tests that this patch has changed but did not add the bug id. Is the bug id only to indicate which bug's regression is a test testing against?
>
> Jtreg supports the -bug:<bugid> option to run matching tests.
> 
> Adding the bugid is an aid in verifying bugs. If it was missed being added earlier it can be added now.  But it is unlikely it will be missed by anyone.

I don't think this test is associated to the inner class feature - it is just that the outputs this test is testing against is too closely tied to irrelevant implementation details.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r1990006389

From liach at openjdk.org  Wed Mar 12 04:37:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Mar 2025 04:37:52 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v3]
In-Reply-To: <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>
Message-ID: <Heeci_MkO80nah1en41CDQwTHR9h9hP_W14t2CyeuPQ=.7cb8961d-a7a4-4982-8ca6-74437d60604c@github.com>

On Tue, 11 Mar 2025 09:22:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
>> 
>> This improvement naturally spills over to `Location.locationFor`.
>> 
>> Things we do:
>>  1. Avoid `putIfAbsent` on fast-path.
>>  2. Lazily cache `Pattern` and reuse for all related paths.
>>  3. Capture output/module flags ahead of time, instead of recomputing them.
>>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
>> 
>> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
>> 
>> Additional testing:
>>  - [x] New regression test still works
>>  - [x] New benchmark shows improvements
>>  - [x] Linux x86_64 server fastdebug/release, `langtools_all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tidy up comments

Since this is about Leyden: can Leyden perform as well if this holder class is replaced with a basic `StableValue` as from #23972 and lock initialization on the SV object?

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

PR Comment: https://git.openjdk.org/jdk/pull/23973#issuecomment-2716420171

From shade at openjdk.org  Wed Mar 12 09:52:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Mar 2025 09:52:54 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v3]
In-Reply-To: <Heeci_MkO80nah1en41CDQwTHR9h9hP_W14t2CyeuPQ=.7cb8961d-a7a4-4982-8ca6-74437d60604c@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>
 <Heeci_MkO80nah1en41CDQwTHR9h9hP_W14t2CyeuPQ=.7cb8961d-a7a4-4982-8ca6-74437d60604c@github.com>
Message-ID: <0t2qkfh21klMqlx5S7QMyuEfFDa9khXZypsDFS5BSCk=.77a6063e-67e5-40a9-a47b-eb41098a8442@github.com>

On Wed, 12 Mar 2025 04:34:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> Since this is about Leyden: can Leyden perform as well if this holder class is replaced with a basic `StableValue` as from #23972 and lock initialization on the SV object?

This is javac API code, it get already awkward with interim javac build. I don't think we should be doing preview features in this code. So, no `StableValue`-s for here yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/23973#issuecomment-2717288728

From liach at openjdk.org  Wed Mar 12 14:20:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Mar 2025 14:20:54 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v3]
In-Reply-To: <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>
Message-ID: <Uv26NLyHLkqQpn5gIYwzmRdNX7wveo6K14qGhAl8SdY=.ff5836dc-94c5-4c24-9f82-0e734b017623@github.com>

On Tue, 11 Mar 2025 09:22:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
>> 
>> This improvement naturally spills over to `Location.locationFor`.
>> 
>> Things we do:
>>  1. Avoid `putIfAbsent` on fast-path.
>>  2. Lazily cache `Pattern` and reuse for all related paths.
>>  3. Capture output/module flags ahead of time, instead of recomputing them.
>>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
>> 
>> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
>> 
>> Additional testing:
>>  - [x] New regression test still works
>>  - [x] New benchmark shows improvements
>>  - [x] Linux x86_64 server fastdebug/release, `langtools_all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tidy up comments

Looks good to me performance-wise; please wait for another javac engineer to review.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23973#pullrequestreview-2678691307

From cushon at openjdk.org  Wed Mar 12 22:18:24 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 12 Mar 2025 22:18:24 GMT
Subject: RFR: 8347291: Exhaustive switch over a generic sealed abstract class
Message-ID: <TMMDmgmn3wLFjSti-hVkk5FDM6nqW1P3r51LZ7iVXDU=.305ed575-f9d6-4815-b28a-23513d79627f@github.com>

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.

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

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8347291
 - 8347291: Exhaustive switch over a generic sealed abstract class

Changes: https://git.openjdk.org/jdk/pull/23286/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23286&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347291
  Stats: 34 lines in 4 files changed: 30 ins; 0 del; 4 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 jlahoda at openjdk.org  Wed Mar 12 22:18:24 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 12 Mar 2025 22:18:24 GMT
Subject: RFR: 8347291: Exhaustive switch over a generic sealed abstract
 class
In-Reply-To: <TMMDmgmn3wLFjSti-hVkk5FDM6nqW1P3r51LZ7iVXDU=.305ed575-f9d6-4815-b28a-23513d79627f@github.com>
References: <TMMDmgmn3wLFjSti-hVkk5FDM6nqW1P3r51LZ7iVXDU=.305ed575-f9d6-4815-b28a-23513d79627f@github.com>
Message-ID: <lmD8d7xBdUgR-E2sEXszKwvdC5yLN5dHegcNblzNwfw=.046b2249-bfc6-4ff5-b59d-31ae8030808f@github.com>

On Fri, 24 Jan 2025 01:08:56 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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.

FWIW: there was this attempt:
https://github.com/lahodaj/jdk/commit/108e5afa2bca60c5ae9b1270c23865aa615bfe52
but it requires more discussion on what exactly should the inference do.

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

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

From cushon at openjdk.org  Wed Mar 12 22:18:24 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 12 Mar 2025 22:18:24 GMT
Subject: RFR: 8347291: Exhaustive switch over a generic sealed abstract
 class
In-Reply-To: <TMMDmgmn3wLFjSti-hVkk5FDM6nqW1P3r51LZ7iVXDU=.305ed575-f9d6-4815-b28a-23513d79627f@github.com>
References: <TMMDmgmn3wLFjSti-hVkk5FDM6nqW1P3r51LZ7iVXDU=.305ed575-f9d6-4815-b28a-23513d79627f@github.com>
Message-ID: <GkRbYt7VIK5PZ_2-EgWpqALeSwzXeVmTTrjiRM3A4yI=.135a512b-07a8-4afb-a5de-6b7746f60c7b@github.com>

On Fri, 24 Jan 2025 01:08:56 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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.

I think this is worth considering - the code is already handling an `InferenceException` and working around it in a way that leads to a `MatchException` at runtime. Until it's possible to improve the underlying inference behaviour to not fail, it seems safer to treat types where inference fails conservatively.

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

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

From liach at openjdk.org  Thu Mar 13 11:20:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Mar 2025 11:20:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <5Em3jYkKNERI9WrgRe9zfbEVLK8Gca46V4nL98N2Xmw=.54f09707-856e-4b26-9a03-0ebd17a40b6b@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

FYI we don't usually drop the benchmark scores in the PR description; we usually leave them in comments to indicate which revision the bench results apply to.

src/hotspot/share/ci/ciField.cpp line 255:

> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
> 254:   return signature == vmSymbols::java_lang_StableValue_signature() ||
> 255:          signature == vmSymbols::java_lang_StableValue_array_signature();

This is dubious - a user can declare a `final StableValue[] array;` and modify the array elements, which is totally compliant to the language and the VM rules. Don't know what this serves.

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2711648215
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1987920134

From pminborg at openjdk.org  Thu Mar 13 11:20:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <YdmKW_G534BGnExnfGYDPcdcIqzOxVoOUuk9EA7kj44=.de5507e3-017e-494f-b074-f1f64b8b7e73@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Here are the current benchmarks for Mac M1:


Benchmark                                     Mode  Cnt  Score   Error  Units
StableFunctionBenchmark.function              avgt   10  4.071 ? 0.252  ns/op
StableFunctionBenchmark.stable                avgt   10  4.107 ? 0.065  ns/op
StableFunctionBenchmark.staticIntFunction     avgt   10  2.688 ? 1.647  ns/op
StableFunctionBenchmark.staticStable          avgt   10  1.708 ? 0.278  ns/op
StableIntFunctionBenchmark.intFunction        avgt   10  1.528 ? 0.040  ns/op
StableIntFunctionBenchmark.stable             avgt   10  1.515 ? 0.019  ns/op
StableIntFunctionBenchmark.staticIntFunction  avgt   10  1.047 ? 0.023  ns/op
StableIntFunctionBenchmark.staticStable       avgt   10  1.056 ? 0.045  ns/op
StableSupplierBenchmark.stable                avgt   10  1.411 ? 0.127  ns/op
StableSupplierBenchmark.supplier              avgt   10  1.676 ? 0.055  ns/op
StableValueBenchmark.atomic                   avgt   10  1.404 ? 0.061  ns/op
StableValueBenchmark.dcl                      avgt   10  1.398 ? 0.037  ns/op
StableValueBenchmark.refSupplier              avgt   10  0.498 ? 0.077  ns/op
StableValueBenchmark.stable                   avgt   10  1.406 ? 0.053  ns/op
StableValueBenchmark.stableNull               avgt   10  1.279 ? 0.062  ns/op
StableValueBenchmark.staticAtomic             avgt   10  1.228 ? 0.060  ns/op
StableValueBenchmark.staticDcl                avgt   10  0.342 ? 0.005  ns/op
StableValueBenchmark.staticHolder             avgt   10  0.342 ? 0.006  ns/op
StableValueBenchmark.staticStable             avgt   10  0.348 ? 0.015  ns/op

``

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2713007259

From pminborg at openjdk.org  Thu Mar 13 11:20:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
Message-ID: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>

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 pminborg at openjdk.org  Thu Mar 13 11:20:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <5Em3jYkKNERI9WrgRe9zfbEVLK8Gca46V4nL98N2Xmw=.54f09707-856e-4b26-9a03-0ebd17a40b6b@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <5Em3jYkKNERI9WrgRe9zfbEVLK8Gca46V4nL98N2Xmw=.54f09707-856e-4b26-9a03-0ebd17a40b6b@github.com>
Message-ID: <UnSr3Bl34SyAZFo4VYHbgz99Oxc5ThMtyNSTfWbz09A=.91708fea-c78d-4dfb-b61a-3fb844584539@github.com>

On Mon, 10 Mar 2025 19:45:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/hotspot/share/ci/ciField.cpp line 255:
> 
>> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
>> 254:   return signature == vmSymbols::java_lang_StableValue_signature() ||
>> 255:          signature == vmSymbols::java_lang_StableValue_array_signature();
> 
> This is dubious - a user can declare a `final StableValue[] array;` and modify the array elements, which is totally compliant to the language and the VM rules. Don't know what this serves.

Fair comment. We should at least remove the array signature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988609781

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/java.base/share/classes/java/lang/StableValue.java line 79:

> 77:  *            logger.trySet(Logger.create(Component.class));
> 78:  *        }
> 79:  *         return logger.orThrow();

Suggestion:

 *         return logger.orElseThrow();

src/java.base/share/classes/java/lang/StableValue.java line 127:

> 125:  * evaluated only once, even when {@code logger.orElseSet()} is invoked concurrently.
> 126:  * This property is crucial as evaluation of the supplier may have side effects,
> 127:  * e.g., the call above to {@code Logger.getLogger()} may result in storage resources

Suggestion:

 * e.g., the call above to {@code Logger.create()} may result in storage resources

src/java.base/share/classes/java/lang/StableValue.java line 344:

> 342:  * {@linkplain java.lang.ref##reachability reachable} stable values will hold their set
> 343:  * content perpetually.
> 344:  * <p>

Should the original functions / mappers (for stable functions and collections) also stay reachable? Kotlin's [`Lazy`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-lazy/) [nulls out](https://github.com/JetBrains/kotlin/blob/c6f337283d59fcede75954eebaa589ad1b479aea/libraries/stdlib/jvm/src/kotlin/util/LazyJVM.kt#L70-L89) the initializer function when it's no longer needed.

src/java.base/share/classes/java/lang/StableValue.java line 423:

> 421:      * {@snippet lang=java:
> 422:      * if (stable.isSet()) {
> 423:      *     return stable.get();

Suggestion:

     *     return stable.orElseThrow();

src/java.base/share/classes/java/lang/StableValue.java line 547:

> 545:                                           IntFunction<? extends R> original) {
> 546:         if (size < 0) {
> 547:             throw new IllegalArgumentException();

This exceptions isn't documented, same for `StableValue.list()`

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 112:

> 110:         final Class<E> enumType = (Class<E>)inputs.iterator().next().getClass();
> 111:         return (Function<T, R>) new StableEnumFunction<E, R>(enumType, min, StableValueFactories.array(size), (Function<E, R>) original);
> 112:     }

If `inputs` contains the enumuration constants with ordinals 0 and 2, wouldn't this code wrongly cause the enumeration constant with ordinal 1 to be an allowed input?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 141:

> 139:                 ? "(this StableValue)"
> 140:                 : "StableValue" + renderWrapped(t);
> 141:     }

Are deeper cycles of concern? I was thinking of this:

var a = StableValue.of();
var b = StableValue.of();
a.trySet(b);
b.trySet(a);
System.out.println(a);


This would solve deeper cycles for `StableValueImpl`:

@Override
public String toString() {
    final StringBuilder sb = new StringBuilder("StableValue");
    int depth = 0;
    Object t = value;
    while (t instanceof StableValueImpl<?> s) {
        if (s == this) {
            t = "(this StableValue)";
            break;
        }
        sb.append("[StableValue");
        depth++;
        t = s.value;
    }
    sb.append(renderWrapped(t));
    while (depth-- > 0) sb.append(']');
    return sb.toString();
}

This might also apply to stable functions and collections, I haven't thought it through for them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989143787
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989165612
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989265489
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989377859
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989504117
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988064795
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988092230

From liach at openjdk.org  Thu Mar 13 11:20:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
Message-ID: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>

On Tue, 11 Mar 2025 13:22:20 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/java.base/share/classes/java/lang/StableValue.java line 344:
> 
>> 342:  * {@linkplain java.lang.ref##reachability reachable} stable values will hold their set
>> 343:  * content perpetually.
>> 344:  * <p>
> 
> Should the original functions / mappers (for stable functions and collections) also stay reachable? Kotlin's [`Lazy`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-lazy/) [nulls out](https://github.com/JetBrains/kotlin/blob/c6f337283d59fcede75954eebaa589ad1b479aea/libraries/stdlib/jvm/src/kotlin/util/LazyJVM.kt#L70-L89) the initializer function when it's no longer needed.

The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

> src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 112:
> 
>> 110:         final Class<E> enumType = (Class<E>)inputs.iterator().next().getClass();
>> 111:         return (Function<T, R>) new StableEnumFunction<E, R>(enumType, min, StableValueFactories.array(size), (Function<E, R>) original);
>> 112:     }
> 
> If `inputs` contains the enumuration constants with ordinals 0 and 2, wouldn't this code wrongly cause the enumeration constant with ordinal 1 to be an allowed input?

Indeed, a bit set predicate can be used to check input validity if it is necessary - I think for enums, using a `StableFunction.ofEnum` dedicated API might be better just because `StableValue` can access `Class.getEnumConstantsShared` easily.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 141:
> 
>> 139:                 ? "(this StableValue)"
>> 140:                 : "StableValue" + renderWrapped(t);
>> 141:     }
> 
> Are deeper cycles of concern? I was thinking of this:
> 
> var a = StableValue.of();
> var b = StableValue.of();
> a.trySet(b);
> b.trySet(a);
> System.out.println(a);
> 
> 
> This would solve deeper cycles for `StableValueImpl`:
> 
> @Override
> public String toString() {
>     final StringBuilder sb = new StringBuilder("StableValue");
>     int depth = 0;
>     Object t = value;
>     while (t instanceof StableValueImpl<?> s) {
>         if (s == this) {
>             t = "(this StableValue)";
>             break;
>         }
>         sb.append("[StableValue");
>         depth++;
>         t = s.value;
>     }
>     sb.append(renderWrapped(t));
>     while (depth-- > 0) sb.append(']');
>     return sb.toString();
> }
> 
> This might also apply to stable functions and collections, I haven't thought it through for them.

I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989965200
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988159371
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988154881

From pminborg at openjdk.org  Thu Mar 13 11:20:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
Message-ID: <lX1y9g2OirKBvEmg8OerZiPCwbJ65JMDAENvsg2DtNI=.a97af05c-4e13-4568-97b5-f16054aec252@github.com>

On Tue, 11 Mar 2025 19:04:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StableValue.java line 344:
>> 
>>> 342:  * {@linkplain java.lang.ref##reachability reachable} stable values will hold their set
>>> 343:  * content perpetually.
>>> 344:  * <p>
>> 
>> Should the original functions / mappers (for stable functions and collections) also stay reachable? Kotlin's [`Lazy`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-lazy/) [nulls out](https://github.com/JetBrains/kotlin/blob/c6f337283d59fcede75954eebaa589ad1b479aea/libraries/stdlib/jvm/src/kotlin/util/LazyJVM.kt#L70-L89) the initializer function when it's no longer needed.
>
> The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 141:
>> 
>>> 139:                 ? "(this StableValue)"
>>> 140:                 : "StableValue" + renderWrapped(t);
>>> 141:     }
>> 
>> Are deeper cycles of concern? I was thinking of this:
>> 
>> var a = StableValue.of();
>> var b = StableValue.of();
>> a.trySet(b);
>> b.trySet(a);
>> System.out.println(a);
>> 
>> 
>> This would solve deeper cycles for `StableValueImpl`:
>> 
>> @Override
>> public String toString() {
>>     final StringBuilder sb = new StringBuilder("StableValue");
>>     int depth = 0;
>>     Object t = value;
>>     while (t instanceof StableValueImpl<?> s) {
>>         if (s == this) {
>>             t = "(this StableValue)";
>>             break;
>>         }
>>         sb.append("[StableValue");
>>         depth++;
>>         t = s.value;
>>     }
>>     sb.append(renderWrapped(t));
>>     while (depth-- > 0) sb.append(']');
>>     return sb.toString();
>> }
>> 
>> This might also apply to stable functions and collections, I haven't thought it through for them.
>
> I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.

The `toString()` function for stable value is inspired by `Optional` and some of the collections.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990919074
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988637468

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <lX1y9g2OirKBvEmg8OerZiPCwbJ65JMDAENvsg2DtNI=.a97af05c-4e13-4568-97b5-f16054aec252@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 <lX1y9g2OirKBvEmg8OerZiPCwbJ65JMDAENvsg2DtNI=.a97af05c-4e13-4568-97b5-f16054aec252@github.com>
Message-ID: <D7JiLG5pqp76lszELgo44SdKEVIWNv6uKz7HOBGPGEs=.c92b0e2d-cfa6-4b2f-9158-d3dfd9817da2@github.com>

On Wed, 12 Mar 2025 08:16:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)
>
> This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.

> (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

You mean [this](https://github.com/openjdk/jdk/blob/a05717d8da8f804003cfb8d6d25b8a5b6cecd473/src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java#L117-L120) is missing `Objects.requireNonNull(supplier);`, right?

>> I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.
>
> The `toString()` function for stable value is inspired by `Optional` and some of the collections.

`Optional` doesn't have the issue of containing itself.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991649915
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989329168

From pminborg at openjdk.org  Thu Mar 13 11:20:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <D7JiLG5pqp76lszELgo44SdKEVIWNv6uKz7HOBGPGEs=.c92b0e2d-cfa6-4b2f-9158-d3dfd9817da2@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 <lX1y9g2OirKBvEmg8OerZiPCwbJ65JMDAENvsg2DtNI=.a97af05c-4e13-4568-97b5-f16054aec252@github.com>
 <D7JiLG5pqp76lszELgo44SdKEVIWNv6uKz7HOBGPGEs=.c92b0e2d-cfa6-4b2f-9158-d3dfd9817da2@github.com>
Message-ID: <9eaXze3gUOvuO_dJhn31evFsyUO6zw9z9Dneexn8WKw=.7bd9d254-d8ea-44a5-a57d-a98173ba536f@github.com>

On Wed, 12 Mar 2025 14:38:28 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.
>
>> (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)
> 
> You mean [this](https://github.com/openjdk/jdk/blob/a05717d8da8f804003cfb8d6d25b8a5b6cecd473/src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java#L117-L120) is missing `Objects.requireNonNull(supplier);`, right?

Fixed `Objects.requireNonNull()` now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993279982

From pminborg at openjdk.org  Thu Mar 13 11:20:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
Message-ID: <Z1MMhJOj7XznWixu8qHnDxlAtewOII15a3g4TnDpqD4=.d955fc88-a97e-4b61-b804-33842f00f56d@github.com>

On Tue, 11 Mar 2025 01:20:16 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 772:
> 
>> 770: 
>> 771:     @jdk.internal.ValueBased
>> 772:     static final class StableList<E> extends AbstractImmutableList<E> {
> 
> Is there significant reuse gained by putting StableList in ImmutableCollection? The back-and-forth between here and SV through SharedSecrets is a little awkward.

This allows reuse of `AbstractImmutableList` with list iterators, sub lists and more.

> src/java.base/share/classes/java/util/ImmutableCollections.java line 1462:
> 
>> 1460: 
>> 1461:     static final class StableMap<K, V>
>> 1462:             extends AbstractImmutableMap<K, V> {
> 
> Same question about whether StableMap needs to go here. Though there?s more stuff going on for maps than lists here.

Same argument as for `StableList`. This allows reuse of several classes including `AbstractImmutableMap`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988605709
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988607732

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/java.base/share/classes/java/util/ImmutableCollections.java line 772:

> 770: 
> 771:     @jdk.internal.ValueBased
> 772:     static final class StableList<E> extends AbstractImmutableList<E> {

Is there significant reuse gained by putting StableList in ImmutableCollection? The back-and-forth between here and SV through SharedSecrets is a little awkward.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1462:

> 1460: 
> 1461:     static final class StableMap<K, V>
> 1462:             extends AbstractImmutableMap<K, V> {

Same question about whether StableMap needs to go here. Though there?s more stuff going on for maps than lists here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988220230
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988222063

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <Z1MMhJOj7XznWixu8qHnDxlAtewOII15a3g4TnDpqD4=.d955fc88-a97e-4b61-b804-33842f00f56d@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
 <Z1MMhJOj7XznWixu8qHnDxlAtewOII15a3g4TnDpqD4=.d955fc88-a97e-4b61-b804-33842f00f56d@github.com>
Message-ID: <P7AJ5yflgcyJezMdv10XlK0zDDPk6atKzqOookzHjrc=.78583938-7d09-46b5-b72b-4667b9c87f0e@github.com>

On Tue, 11 Mar 2025 07:48:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 772:
>> 
>>> 770: 
>>> 771:     @jdk.internal.ValueBased
>>> 772:     static final class StableList<E> extends AbstractImmutableList<E> {
>> 
>> Is there significant reuse gained by putting StableList in ImmutableCollection? The back-and-forth between here and SV through SharedSecrets is a little awkward.
>
> This allows reuse of `AbstractImmutableList` with list iterators, sub lists and more.

Using the regular AbstractList as a base would also get you implementations of those.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989875430

From qamai at openjdk.org  Thu Mar 13 11:20:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/java.base/share/classes/java/util/ImmutableCollections.java line 777:

> 775:         private final IntFunction<? extends E> mapper;
> 776:         @Stable
> 777:         private final StableValueImpl<E>[] backing;

You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:

> 63:     //
> 64:     @Stable
> 65:     private volatile Object value;

Can we use `acquire`/`release` semantics instead of `volatile`?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 128:

> 126:             final T newValue = supplier.get();
> 127:             // The mutex is reentrant so we need to check if the value was actually set.
> 128:             return wrapAndCas(newValue) ? newValue : orElseThrow();

Reentrancy into here seems really buggy, I would endorse disallowing it instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 159:

> 157:     private boolean wrapAndCas(Object value) {
> 158:         // This upholds the invariant, a `@Stable` field is written to at most once
> 159:         return UNSAFE.compareAndSetReference(this, UNDERLYING_DATA_OFFSET, null, wrap(value));

There is no need for a cas here as all setters have to hold the lock. We should have a dedicated private `set` that asserts `Thread.holdsLock(this)`.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 168:

> 166:     // Wraps `null` values into a sentinel value
> 167:     @ForceInline
> 168:     private static <T> T wrap(T t) {

Suggestion:

    private static <T> Object wrap(T t) {

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 181:

> 179:     @SuppressWarnings("unchecked")
> 180:     @ForceInline
> 181:     private static <T> T nullSentinel() {

Suggestion:

    private static Object nullSentinel() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988608920
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988612784
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993081551
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988616943
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993110162
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993111723

From liach at openjdk.org  Thu Mar 13 11:20:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <P7AJ5yflgcyJezMdv10XlK0zDDPk6atKzqOookzHjrc=.78583938-7d09-46b5-b72b-4667b9c87f0e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
 <Z1MMhJOj7XznWixu8qHnDxlAtewOII15a3g4TnDpqD4=.d955fc88-a97e-4b61-b804-33842f00f56d@github.com>
 <P7AJ5yflgcyJezMdv10XlK0zDDPk6atKzqOookzHjrc=.78583938-7d09-46b5-b72b-4667b9c87f0e@github.com>
Message-ID: <C-64owYhIlPvE7u-6OH5P3D0y0CMLyG5xsJG4HshJDI=.36160812-660e-485e-a61f-12ebdd3b5ee4@github.com>

On Tue, 11 Mar 2025 18:08:47 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This allows reuse of `AbstractImmutableList` with list iterators, sub lists and more.
>
> Using the regular AbstractList as a base would also get you implementations of those.

`AbstractList` has non-final fields, which makes it not suitable for `@ValueBased`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989947965

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
Message-ID: <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>

On Tue, 11 Mar 2025 07:50:38 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 777:
> 
>> 775:         private final IntFunction<? extends E> mapper;
>> 776:         @Stable
>> 777:         private final StableValueImpl<E>[] backing;
> 
> You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.

Can you please elaborate a bit more on your proposal @merykitty?

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:
> 
>> 63:     //
>> 64:     @Stable
>> 65:     private volatile Object value;
> 
> Can we use `acquire`/`release` semantics instead of `volatile`?

Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 128:
> 
>> 126:             final T newValue = supplier.get();
>> 127:             // The mutex is reentrant so we need to check if the value was actually set.
>> 128:             return wrapAndCas(newValue) ? newValue : orElseThrow();
> 
> Reentrancy into here seems really buggy, I would endorse disallowing it instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`

StableValueImpl was carefully designed to minimize memory footprint. Adding a lock would inflate memory usage substantially.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 159:
> 
>> 157:     private boolean wrapAndCas(Object value) {
>> 158:         // This upholds the invariant, a `@Stable` field is written to at most once
>> 159:         return UNSAFE.compareAndSetReference(this, UNDERLYING_DATA_OFFSET, null, wrap(value));
> 
> There is no need for a cas here as all setters have to hold the lock. We should have a dedicated private `set` that asserts `Thread.holdsLock(this)`.

This is more of a belt and suspenders solution. It is true that it is redundant. A set volatile would suffice here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989016337
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988630199
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993142117
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988634451

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
Message-ID: <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>

On Tue, 11 Mar 2025 16:15:10 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Can you please elaborate a bit more on your proposal @merykitty?
>
> If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:
> 
>     ReentrantLock[] locks;
> 
>     T get(int idx) {
>         Object x = backing[idx];
>         if (x == null) {
>             return compute(idx);
>         }
>         return unwrap(x);
>     }
> 
>     T compute(int idx) {
>         ReentrantLock lock = locks[idx];
>         lock.lock();
>         try {
>             Object x = backing[idx];
>             if (x != null) {
>                 return unwrap(x);
>             }
>             T obj = ...;
>             backing[idx] = wrap(obj);
>             return obj;
>         } finally {
>             lock.unlock();
>         }
>     }

What would be the difference between `@Stable StableValueImpl<E>[] backing` and `@Stable Object[] backing`?

>> Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.
>
> You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.

Yeah. Maybe that could strike a balance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990908235
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991599680

From qamai at openjdk.org  Thu Mar 13 11:20:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
Message-ID: <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>

On Tue, 11 Mar 2025 11:19:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 777:
>> 
>>> 775:         private final IntFunction<? extends E> mapper;
>>> 776:         @Stable
>>> 777:         private final StableValueImpl<E>[] backing;
>> 
>> You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.
>
> Can you please elaborate a bit more on your proposal @merykitty?

If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:

    ReentrantLock[] locks;

    T get(int idx) {
        Object x = backing[idx];
        if (x == null) {
            return compute(idx);
        }
        return unwrap(x);
    }

    T compute(int idx) {
        ReentrantLock lock = locks[idx];
        lock.lock();
        try {
            Object x = backing[idx];
            if (x != null) {
                return unwrap(x);
            }
            T obj = ...;
            backing[idx] = wrap(obj);
            return obj;
        } finally {
            lock.unlock();
        }
    }

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:
>> 
>>> 63:     //
>>> 64:     @Stable
>>> 65:     private volatile Object value;
>> 
>> Can we use `acquire`/`release` semantics instead of `volatile`?
>
> Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.

You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989664004
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990989622

From mcimadamore at openjdk.org  Thu Mar 13 11:20:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
 <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
Message-ID: <YLjzElq0n2eivme-qW8tDzUWpFwKaxpzVEI6Gme65Eg=.d390c02b-7de4-4bcb-8681-2abf4b9f69de@github.com>

On Wed, 12 Mar 2025 08:09:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:
>> 
>>     ReentrantLock[] locks;
>> 
>>     T get(int idx) {
>>         Object x = backing[idx];
>>         if (x == null) {
>>             return compute(idx);
>>         }
>>         return unwrap(x);
>>     }
>> 
>>     T compute(int idx) {
>>         ReentrantLock lock = locks[idx];
>>         lock.lock();
>>         try {
>>             Object x = backing[idx];
>>             if (x != null) {
>>                 return unwrap(x);
>>             }
>>             T obj = ...;
>>             backing[idx] = wrap(obj);
>>             return obj;
>>         } finally {
>>             lock.unlock();
>>         }
>>     }
>
> What would be the difference between `@Stable StableValueImpl<E>[] backing` and `@Stable Object[] backing`?

It's true that the storage can be flatter here -- that said, this can also be done as a later refactoring. One advantage of doing things the way @minborg did it here, is that it's fairly easy to prove that the code below is correct -- which makes the initial review easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991505367

From qamai at openjdk.org  Thu Mar 13 11:20:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
 <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
Message-ID: <7hEWpE3GTKhCa15FRQBf6_tzHUsr9mbzv6zh1HeZlXY=.1800d27a-33d9-41de-b8bd-31fd82a3661b@github.com>

On Wed, 12 Mar 2025 08:09:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:
>> 
>>     ReentrantLock[] locks;
>> 
>>     T get(int idx) {
>>         Object x = backing[idx];
>>         if (x == null) {
>>             return compute(idx);
>>         }
>>         return unwrap(x);
>>     }
>> 
>>     T compute(int idx) {
>>         ReentrantLock lock = locks[idx];
>>         lock.lock();
>>         try {
>>             Object x = backing[idx];
>>             if (x != null) {
>>                 return unwrap(x);
>>             }
>>             T obj = ...;
>>             backing[idx] = wrap(obj);
>>             return obj;
>>         } finally {
>>             lock.unlock();
>>         }
>>     }
>
> What would be the difference between `@Stable StableValueImpl<E>[] backing` and `@Stable Object[] backing`?

For an `Object[]`, you only need to load the object from the array and it is probably what you need. For a `StableValueImpl[]`, you need to load the `StableValueImpl` from the array, and load the value from that `StableValueImpl`, which is 2 levels of indirections.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990993459

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <YLjzElq0n2eivme-qW8tDzUWpFwKaxpzVEI6Gme65Eg=.d390c02b-7de4-4bcb-8681-2abf4b9f69de@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
 <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
 <YLjzElq0n2eivme-qW8tDzUWpFwKaxpzVEI6Gme65Eg=.d390c02b-7de4-4bcb-8681-2abf4b9f69de@github.com>
Message-ID: <8eLNHYCb3NOjDPJhbTd2sT_MxAhlPjI9fC4mr0sSWOU=.51260d3f-6585-4fbb-a367-43f26bc225fb@github.com>

On Wed, 12 Mar 2025 13:28:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> What would be the difference between `@Stable StableValueImpl<E>[] backing` and `@Stable Object[] backing`?
>
> It's true that the storage can be flatter here -- that said, this can also be done as a later refactoring. One advantage of doing things the way @minborg did it here, is that it's fairly easy to prove that the code below is correct -- which makes the initial review easier.

Ahh. Now I see what you mean. This is something we did in a handful of prototypes we explored. While it is true that there will be one indirection less, the complexity of the code is going to grow. Also, if the element is constant folded, it does not matter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991597981

From duke at openjdk.org  Thu Mar 13 11:20:14 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
Message-ID: <NPJHGuhm_d-L0aMPmujJxYemfzscgWOAyRM2Kl65lLw=.264a6d1f-a4d2-4d03-b3a5-f8036af7db55@github.com>

On Mon, 10 Mar 2025 23:42:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 112:
>> 
>>> 110:         final Class<E> enumType = (Class<E>)inputs.iterator().next().getClass();
>>> 111:         return (Function<T, R>) new StableEnumFunction<E, R>(enumType, min, StableValueFactories.array(size), (Function<E, R>) original);
>>> 112:     }
>> 
>> If `inputs` contains the enumuration constants with ordinals 0 and 2, wouldn't this code wrongly cause the enumeration constant with ordinal 1 to be an allowed input?
>
> Indeed, a bit set predicate can be used to check input validity if it is necessary - I think for enums, using a `StableFunction.ofEnum` dedicated API might be better just because `StableValue` can access `Class.getEnumConstantsShared` easily.

What if instead you had a `@Stable` array of Object of the appropriate size, and populated each cell with a StableValue if the corresponding index was in the set, otherwise used a sentinel value. Then on the lookup, if it was the sentinel you throw, else you use the the SV.

Also there is an awful lot of similarity between the enum function and the int function. Could one possibly be implemented using the other?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988195668

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <NPJHGuhm_d-L0aMPmujJxYemfzscgWOAyRM2Kl65lLw=.264a6d1f-a4d2-4d03-b3a5-f8036af7db55@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 <NPJHGuhm_d-L0aMPmujJxYemfzscgWOAyRM2Kl65lLw=.264a6d1f-a4d2-4d03-b3a5-f8036af7db55@github.com>
Message-ID: <lbdSyXIBqMh038sXLg6ZGf9XoFea69rZwrQ2acYLTSk=.578d74b0-6971-492a-b9dc-099632ca48b7@github.com>

On Tue, 11 Mar 2025 00:40:31 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Indeed, a bit set predicate can be used to check input validity if it is necessary - I think for enums, using a `StableFunction.ofEnum` dedicated API might be better just because `StableValue` can access `Class.getEnumConstantsShared` easily.
>
> What if instead you had a `@Stable` array of Object of the appropriate size, and populated each cell with a StableValue if the corresponding index was in the set, otherwise used a sentinel value. Then on the lookup, if it was the sentinel you throw, else you use the the SV.
> 
> Also there is an awful lot of similarity between the enum function and the int function. Could one possibly be implemented using the other?

Thanks for spotting this glitch. I have fixed the issue and added a test for member sets with "holes".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988707099

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <lbdSyXIBqMh038sXLg6ZGf9XoFea69rZwrQ2acYLTSk=.578d74b0-6971-492a-b9dc-099632ca48b7@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 <NPJHGuhm_d-L0aMPmujJxYemfzscgWOAyRM2Kl65lLw=.264a6d1f-a4d2-4d03-b3a5-f8036af7db55@github.com>
 <lbdSyXIBqMh038sXLg6ZGf9XoFea69rZwrQ2acYLTSk=.578d74b0-6971-492a-b9dc-099632ca48b7@github.com>
Message-ID: <HMavQ4tdFEZyIM2fFY8dUMvxDLyiixVzGVg1BAbcphs=.d26839a0-dce0-4c76-81fe-33eed1d07ceb@github.com>

On Tue, 11 Mar 2025 08:44:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> What if instead you had a `@Stable` array of Object of the appropriate size, and populated each cell with a StableValue if the corresponding index was in the set, otherwise used a sentinel value. Then on the lookup, if it was the sentinel you throw, else you use the the SV.
>> 
>> Also there is an awful lot of similarity between the enum function and the int function. Could one possibly be implemented using the other?
>
> Thanks for spotting this glitch. I have fixed the issue and added a test for member sets with "holes".

It might be worth exploring using a stable int function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991590911

From alanb at openjdk.org  Thu Mar 13 11:20:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Mar 2025 11:20:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <zPzP-BI32XaB8BQ4qHALhdtQaIW7bVDDxAHK0_c-9J0=.3823d378-9373-4a62-a68d-94e696d92211@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/jdk.unsupported/share/classes/sun/misc/Unsafe.java line 983:

> 981: 
> 982:     @ForceInline
> 983:     private static void assertNotTrusted(Field f) {

I don't think this can be named assertXXX, needs to something like ensureNotTrusted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1987836045

From pminborg at openjdk.org  Thu Mar 13 11:20:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
 <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
Message-ID: <1O-QKtK9LBw8YzDDGzJxtBTwYBD3jnoKfXFJYiY1sp4=.dea93da7-bfcd-42ca-98c8-f8e0705bac07@github.com>

On Wed, 12 Mar 2025 14:14:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.
>
> Yeah. Maybe that could strike a balance.

On an M1 Mac:

Volatile:


StableValueBenchmark.stable        avgt   10  1.373 ? 0.057  ns/op
StableValueBenchmark.stableNull    avgt   10  1.245 ? 0.074  ns/op


Acquire:


StableValueBenchmark.stable        avgt   10  1.339 ? 0.044  ns/op
StableValueBenchmark.stableNull    avgt   10  1.241 ? 0.090  ns/op


We would have to examine the difference on other platforms as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993284760

From duke at openjdk.org  Thu Mar 13 12:03:11 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 13 Mar 2025 12:03:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
Message-ID: <IdsyS9iV8Ms2QYg30urSJWFLVx63qckCV7PqfAwh0-s=.c5769fcb-ce0f-4c8b-8d42-3d43d80a47e6@github.com>

On Thu, 13 Mar 2025 09:45:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 128:
>> 
>>> 126:             final T newValue = supplier.get();
>>> 127:             // The mutex is reentrant so we need to check if the value was actually set.
>>> 128:             return wrapAndCas(newValue) ? newValue : orElseThrow();
>> 
>> Reentrancy into here seems really buggy, I would endorse disallowing it instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`
>
> StableValueImpl was carefully designed to minimize memory footprint. Adding a lock would inflate memory usage substantially.

There is also `Thread.holdsLock()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993371561

From pminborg at openjdk.org  Thu Mar 13 12:45:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 12:45:50 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v2]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <LAcln0w51aj3S9Tj6lcd5H_Zs8Rd7pD54WhSjzgNb-g=.0950edbd-d11b-4434-ad72-a5e703090dc7@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework reenterant logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/09ca44e6..1cd1cdb2

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

  Stats: 67 lines in 4 files changed: 56 ins; 1 del; 10 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 pminborg at openjdk.org  Thu Mar 13 12:52:32 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 12:52:32 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v3]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <OmY4p5JvFpx8pHK-fjG-Xf5B2UvJRpoggxCNnia5_D0=.b3409736-09d5-4a29-801c-7d74a381ca82@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename method and fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/1cd1cdb2..8f6d6bc0

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

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 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 pminborg at openjdk.org  Thu Mar 13 13:01:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 13:01:58 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v4]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <qRT3MNT1BgbTD2FBNuUH6X7gkh66Os2RP_N3Z-64Hgk=.b244bdea-4633-4975-90e9-6749e2b5bb11@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/8f6d6bc0..c648ea2b

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

  Stats: 23 lines in 6 files changed: 1 ins; 0 del; 22 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 pminborg at openjdk.org  Thu Mar 13 13:52:24 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 13:52:24 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v5]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <INsmeBaaEFRgNdJj_qDqzMbV9cp2V-6gcQ1Ok6o0WgI=.f36bb583-8d1f-4a39-b6c9-bbf52f5b5031@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Clean up exception messages and fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/c648ea2b..2fe5b0f8

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

  Stats: 10 lines in 2 files changed: 3 ins; 0 del; 7 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 pminborg at openjdk.org  Thu Mar 13 15:22:43 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 15:22:43 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:

 - Merge branch 'master' into implement-jep502
 - Clean up exception messages and fix comments
 - Rename field
 - Rename method and fix comment
 - Rework reenterant logic
 - 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
 - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

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

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=05
  Stats: 4040 lines in 30 files changed: 4009 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  Thu Mar 13 15:39:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:39:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
Message-ID: <MQMqlH-62fZOR02IAAcmYmgKhPLDJL9AsfZWZ1vqxWI=.2cc182f2-051f-4f06-acef-90a27e85d37e@github.com>

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - 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
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/hotspot/share/ci/ciField.cpp line 254:

> 252: 
> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
> 254:   return signature == vmSymbols::java_lang_StableValue_signature();

Just a note that we will need to decide whether to keep this or not...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993795795

From mcimadamore at openjdk.org  Thu Mar 13 15:52:16 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:52:16 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
Message-ID: <XpnOo9OG0UgG7dNr98Jy8rda2NOSZvNYPA7UQX0FU7c=.cb486622-86f1-4366-91a2-8c1155590801@github.com>

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - 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
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/lang/StableValue.java line 45:

> 43: 
> 44: /**
> 45:  * A stable value is a shallowly immutable holder of deferred content.

Is this terminology a leftover from previous JEP iterations? The JEP now says: 
>  stable values, which are objects that hold immutable data.

src/java.base/share/classes/java/lang/StableValue.java line 283:

> 281:  * the {@code Foo} does not already exist.
> 282:  * <p>
> 283:  * Here is another example where a more complex dependency graph is created in which

I wonder if just leaving the fibonacci example would be enough here -- as that has a nice dependency graph

src/java.base/share/classes/java/lang/StableValue.java line 330:

> 328:  * thread safe and guarantee at-most-once-per-input invocation.
> 329:  *
> 330:  * <h2 id="miscellaneous">Miscellaneous</h2>

I'm dubious about a section called "misc" :-)

src/java.base/share/classes/java/lang/StableValue.java line 331:

> 329:  *
> 330:  * <h2 id="miscellaneous">Miscellaneous</h2>
> 331:  * Except for a StableValue's content itself, an {@linkplain #orElse(Object) orElse(other)}

missing `{@code}`

src/java.base/share/classes/java/lang/StableValue.java line 335:

> 333:  * parameters must be <em>non-null</em> or a {@link NullPointerException} will be thrown.
> 334:  * <p>
> 335:  * Stable functions and collections are not {@link Serializable} as this would require

Not sure this belongs here. Perhaps the comment on these functions not being serializable should be on their factories. And the point on security vulnerability seems specific and vague at the same time -- better remove it.

src/java.base/share/classes/java/lang/StableValue.java line 339:

> 337:  * which would introduce security vulnerabilities.
> 338:  * <p>
> 339:  * As objects can be set via stable values but never removed, this can be a source

It feels like this could probably be expanded upon -- also covering stable functions (and morphed into a new section)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993819611
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993803509
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993810862
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993805209
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993808888
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993812118

From mcimadamore at openjdk.org  Thu Mar 13 15:52:16 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:52:16 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <XpnOo9OG0UgG7dNr98Jy8rda2NOSZvNYPA7UQX0FU7c=.cb486622-86f1-4366-91a2-8c1155590801@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
 <XpnOo9OG0UgG7dNr98Jy8rda2NOSZvNYPA7UQX0FU7c=.cb486622-86f1-4366-91a2-8c1155590801@github.com>
Message-ID: <HzcTx_inUxv-RYn-J5KglOzZh01D31ILAKBnEb1ICVg=.59b687c8-0c33-43d3-ae3b-f43cb26ba165@github.com>

On Thu, 13 Mar 2025 15:48:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>> 
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - 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
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/java/lang/StableValue.java line 45:
> 
>> 43: 
>> 44: /**
>> 45:  * A stable value is a shallowly immutable holder of deferred content.
> 
> Is this terminology a leftover from previous JEP iterations? The JEP now says: 
>>  stable values, which are objects that hold immutable data.

Maybe: `A stable value in an holder for shallowly immutable content`.

> src/java.base/share/classes/java/lang/StableValue.java line 330:
> 
>> 328:  * thread safe and guarantee at-most-once-per-input invocation.
>> 329:  *
>> 330:  * <h2 id="miscellaneous">Miscellaneous</h2>
> 
> I'm dubious about a section called "misc" :-)

We can probably move out some of the contents (I left some suggestions) - then move the remaining into api notes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993822111
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993815323

From mcimadamore at openjdk.org  Thu Mar 13 15:57:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:57:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
Message-ID: <CDrakdC_bHXkOVoDnAh3cpNeXGrHC-n91RO2uJECLeo=.7b01d4a2-e6cd-44a1-8399-7cae080bc153@github.com>

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - 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
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/lang/StableValue.java line 497:

> 495: 
> 496:     /**
> 497:      * {@return a new unset stable supplier}

Should we say "unset" here?

src/java.base/share/classes/java/lang/StableValue.java line 526:

> 524: 
> 525:     /**
> 526:      * {@return a new unset stable int function}

Should we say "unset" here?

src/java.base/share/classes/java/lang/StableValue.java line 564:

> 562: 
> 563:     /**
> 564:      * {@return a new unset stable function}

Should we say "unset" here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993828637
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993829241
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993831680

From mcimadamore at openjdk.org  Thu Mar 13 15:57:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:57:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <CDrakdC_bHXkOVoDnAh3cpNeXGrHC-n91RO2uJECLeo=.7b01d4a2-e6cd-44a1-8399-7cae080bc153@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
 <CDrakdC_bHXkOVoDnAh3cpNeXGrHC-n91RO2uJECLeo=.7b01d4a2-e6cd-44a1-8399-7cae080bc153@github.com>
Message-ID: <wYWFD_7Kqfzt2lTHvWGqk866OmDFLTBOlHn_bBSmtcE=.22efb3e2-2a93-481c-bcd4-fa95fb87bc35@github.com>

On Thu, 13 Mar 2025 15:52:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>> 
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - 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
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/java/lang/StableValue.java line 497:
> 
>> 495: 
>> 496:     /**
>> 497:      * {@return a new unset stable supplier}
> 
> Should we say "unset" here?

E.g. we do not define the term "unset supplier" anywhere -- we just define what a stable supplier is -- IMHO that's enough. Also... whether unset or set, that's not really visible by the user?

> src/java.base/share/classes/java/lang/StableValue.java line 564:
> 
>> 562: 
>> 563:     /**
>> 564:      * {@return a new unset stable function}
> 
> Should we say "unset" here?

Same with all the other lazy XYZ factories

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993830847
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993832264

From mcimadamore at openjdk.org  Thu Mar 13 16:07:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 16:07:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
Message-ID: <a7bMFVUZX0bRNKG2fdBG0jE1utnwWWOt7k0ijZkMMyI=.f63c0067-7985-4a25-b3a7-7a372b1eafea@github.com>

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - 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
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 74:

> 72:     @Override
> 73:     public boolean trySet(T value) {
> 74:         if (wrappedContentAcquire() != null) {

IMHO, if our goal is to do:

Object content = this.content;
if (context != null) return content:
synchronized (...) {
    if (context != null) return content:
    this.context = ...
}


Then we might just use a volatile field and synchronized blocks. I don't see an immediate need for using acquire/release semantics -- especially when using a monitor. E.g. this should look more like a classic double checked locking idiom. (but with a stable field to make the first volatile read more efficient in case the field is already set)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993850760

From hannesw at openjdk.org  Thu Mar 13 18:19:02 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 13 Mar 2025 18:19:02 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text
In-Reply-To: <ytiC5aoARrCzdFLE1X3jpB4mTEDRrZwcC2Vs6mNnZwo=.f8783235-5734-4fd0-8bc2-4f2b2da0e91b@github.com>
References: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
 <ytiC5aoARrCzdFLE1X3jpB4mTEDRrZwcC2Vs6mNnZwo=.f8783235-5734-4fd0-8bc2-4f2b2da0e91b@github.com>
Message-ID: <qv65vfh6PcBFOgwCZWxAM11ojhfev2liz1PaxWZ660E=.9aee7b66-f244-4e96-bf4e-4b114c2aa617@github.com>

On Wed, 5 Mar 2025 18:07:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `<pre>` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `<pre>` tags.
>> 
>> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `<pre>` alone or in combination with `<code>` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `<blockquote>`). 
>> 
>> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `<pre>` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
>> 
>> If the exact number of leading whitespace in `<pre>` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
>> 
>> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `<pre><code>\n` open tags. Browsers will [ignore a newline immediately following a `<pre>` tag][1], but not if there is a `<code>` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `<code>\n` at the beginning of `<pre>` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
>> 
>> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element
>
> As you indicated, there are two problems being addressed here, which might indicate the need for two separate patches. These issues are:
> 
> 1. The leading 1-space problem.
> 2. The trailing newline-after-<pre> problem
> 
> For the first, it is unduly hard work to fix this just for `<pre>` blocks. I still think that an overall better long-term solution would be to apply a conceptual `stripIndent` to the entire doc comment. This would bring traditional comments into line with the new Markdown comments, and can be done in just a few lines in `DocCommentParser`, and doing it there in DCP means you need not update `Elements.getDocComment`. If nothing else, I would suggest doing the experiment and comparing the generated docs, to verify there are no unexpected side effects. If there are any significant unexpected side effects, then your approach might deserve a second look. You could also make this a JDK-version-specific change if you wanted: meaning the new behavior does not apply to older JDK versions, although that is not a policy we have adhered to in the past.
> 
> For the second, I just feel that is a step too far, using JavaScript to clean up what some might consider to be bad input. Authors should either write HTML according to the HTML (and CSS?) specs, so that `javadoc` is just a "pass-through" layer, or authors should use a suitable construct, like `{@snippet...}`, that is "pleasing" to look at in source form while still generating the desired output.

After discussion with @jonathan-gibbons we have agreed that the two issues in this PR should be handled separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/23868#issuecomment-2722311586

From hannesw at openjdk.org  Thu Mar 13 18:19:03 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 13 Mar 2025 18:19:03 GMT
Subject: Withdrawn: 8346118: Improve whitespace normalization in preformatted
 text
In-Reply-To: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
References: <ttHVSSUCm3Rgrc4902K8uC-WY9Jf0CmBXxP9DrNgUNs=.05ae2161-2a54-4019-b2a1-79e2c9352843@github.com>
Message-ID: <YikWRSACT4bffehINlc8u6-3j51IDIA0OAVNZze6qHQ=.749a79ed-dc49-4c50-84b5-f75005596c7e@github.com>

On Mon, 3 Mar 2025 16:41:18 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `<pre>` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `<pre>` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `<pre>` alone or in combination with `<code>` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `<blockquote>`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `<pre>` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `<pre>` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `<pre><code>\n` open tags. Browsers will [ignore a newline immediately following a `<pre>` tag][1], but not if there is a `<code>` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `<code>\n` at the beginning of `<pre>` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

This pull request has been closed without being integrated.

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

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

From jlahoda at openjdk.org  Thu Mar 13 19:22:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 13 Mar 2025 19:22:54 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v3]
In-Reply-To: <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>
Message-ID: <GH5dvLw_XsfedPjlzdhPyM-EENZOB_Ubm0pYR2hRowU=.073be3bb-15d6-4ddf-83a0-41d3cc274892@github.com>

On Tue, 11 Mar 2025 09:22:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
>> 
>> This improvement naturally spills over to `Location.locationFor`.
>> 
>> Things we do:
>>  1. Avoid `putIfAbsent` on fast-path.
>>  2. Lazily cache `Pattern` and reuse for all related paths.
>>  3. Capture output/module flags ahead of time, instead of recomputing them.
>>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
>> 
>> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
>> 
>> Additional testing:
>>  - [x] New regression test still works
>>  - [x] New benchmark shows improvements
>>  - [x] Linux x86_64 server fastdebug/release, `langtools_all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tidy up comments

Looks OK to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23973#pullrequestreview-2683142481

From shade at openjdk.org  Fri Mar 14 07:48:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 14 Mar 2025 07:48:59 GMT
Subject: RFR: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation [v3]
In-Reply-To: <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
 <VmUrdjuzjHsLMBMlOufWNyLLSmsdmjl3H3VZhRkOPDM=.8f1074f1-30e1-4f02-8966-4a1c60a496ff@github.com>
Message-ID: <rElQUVR0Jw9iCHOPRzbMOhF6XW-NLUpWgI6vTM3RaLs=.23edfba1-ace3-4a96-9935-22cca9545c36@github.com>

On Tue, 11 Mar 2025 09:22:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
>> 
>> This improvement naturally spills over to `Location.locationFor`.
>> 
>> Things we do:
>>  1. Avoid `putIfAbsent` on fast-path.
>>  2. Lazily cache `Pattern` and reuse for all related paths.
>>  3. Capture output/module flags ahead of time, instead of recomputing them.
>>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
>> 
>> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
>> 
>> Additional testing:
>>  - [x] New regression test still works
>>  - [x] New benchmark shows improvements
>>  - [x] Linux x86_64 server fastdebug/release, `langtools_all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tidy up comments

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/23973#issuecomment-2723885863

From shade at openjdk.org  Fri Mar 14 07:49:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 14 Mar 2025 07:49:00 GMT
Subject: Integrated: 8351556: Optimize
 Location.locationFor/isModuleOrientedLocation
In-Reply-To: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
References: <EIBPUCh5kj-nj2JfNqivOgNVhPHdl-iUWm02mmoDoUk=.ded230de-ed3f-4bcc-8cfa-254fc3f36fed@github.com>
Message-ID: <tbwygoHmR8r4h8tu9EuRGPYdYBnFTXdQyQkmDGpArIQ=.5f86bf78-b3d1-4485-8743-92b375800ef1@github.com>

On Mon, 10 Mar 2025 18:22:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
> 
> This improvement naturally spills over to `Location.locationFor`.
> 
> Things we do:
>  1. Avoid `putIfAbsent` on fast-path.
>  2. Lazily cache `Pattern` and reuse for all related paths.
>  3. Capture output/module flags ahead of time, instead of recomputing them.
>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
> 
> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
> 
> Additional testing:
>  - [x] New regression test still works
>  - [x] New benchmark shows improvements
>  - [x] Linux x86_64 server fastdebug/release, `langtools_all`

This pull request has now been integrated.

Changeset: e3c29c9e
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3c29c9e6cff7648952c0ba359b0763a0ea8da18
Stats:     248 lines in 5 files changed: 232 ins; 3 del; 13 mod

8351556: Optimize Location.locationFor/isModuleOrientedLocation

Reviewed-by: liach, jlahoda

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

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

From john.r.rose at oracle.com  Sun Mar 16 01:02:06 2025
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 15 Mar 2025 18:02:06 -0700
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
Message-ID: <48649453-7926-4353-8AD7-A62EFD5AAF84@oracle.com>

> Are deeper cycles of concern? I was thinking of this:

There are a couple of ways existing java.util code handles
self-cycles.  The deepToString method handles them at all
levels, so it is robust.  But it is tricky and expensive.
(Look at the variable named ?dejaVu?.)

If you grep for /"(this / in the java.util sources, you
will see several examples of a one-level exclusion of
self-references.  This is what the present PR emulates,
and I think it is just fine to follow those precedents.
It?s a 99% solution.  Omitting the self-check would be
a 90% solution, but the self-check is so simple that,
why not do it?  Adding a ?dejaVu? table is not simple;
don?t.

One thing I noticed, when doing that grep, is that
the type name is usually ?detuned?.  We should do that
as well in this patch.  For example, in Hashtable.java,
the string says ?(this Map)? not ?(this Hashtable)?.
The toString method tilts away from TMI. I think we
have a slight TMI problem in this patch, maybe, and
given the precedents I would expect ?(this Function)?
not ?(this StableEnumFunction)?, etc.

(TMI = Too Much Information.  See also Gafter on
the TMI temptation for language designers, which
applies to API design as well:
https://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html )

I see the PR?s unit tests look at this string.  My
humble take on it is, let?s dial back the TMI before
it?s too late.

(My sensitivity to TMI also informs other comments I
made on this PR.)

From john.r.rose at oracle.com  Sun Mar 16 03:19:38 2025
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 15 Mar 2025 20:19:38 -0700
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
Message-ID: <93E21D00-2C99-4278-A6BB-0578F32295F8@oracle.com>

On 13 Mar 2025, at 4:20, Per Minborg wrote:

> ?
>> Reentrancy into here seems really buggy, I would endorse disallowing it >> instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`
>
> StableValueImpl was carefully designed to minimize memory footprint. Adding a lock would inflate memory usage substantially.

+1 from me

A similar level of concern with footprint was in my mind in my
earlier comment, where I claimed that capturing /this/ in a lambda
is suboptimal.  The inefficiency is in object creation and footprint,
since an extra copy of /this/ must be tracked.

>
>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 159:
>>
>>> 157:     private boolean wrapAndCas(Object value) {
>>> 158:         // This upholds the invariant, a `@Stable` field is written to at most once
>>> 159:         return UNSAFE.compareAndSetReference(this, UNDERLYING_DATA_OFFSET, null, wrap(value));
>>
>> There is no need for a cas here as all setters have to hold the lock. We should have a dedicated private `set` that asserts `Thread.holdsLock(this)`.
>
> This is more of a belt and suspenders solution. It is true that it is redundant. A set volatile would suffice here.

There is a broad choice at the beginning of this design whether
to use a mutex (as <clinit> and ClassValue do) or use lock-free
CAS (as condy/indy do).  This API, which is more parallel to
the higher-level <clinit> and ClassValue, uses a mutex.

The choice connects to the rules about handling races.  Surely,
two threads can ask concurrently for a SV state, and both may
?suggest? a lambda to give it a value.  Now we come to a fork
in the road:  Do we select at most one lambda to run?  Or,
do we let both lambdas run and then pick a winner?  The first
requires a mutex.  The second is lock-free and uses CAS.

It?s a binary choice.  I don?t think we ever need the belt
and suspenders.  I agree that StableValue is like ClassValue
and not like condy, so it should not be playing with lock
free stuff.  (Or did I forget something??)

? John

From john.r.rose at oracle.com  Sun Mar 16 03:29:28 2025
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 15 Mar 2025 20:29:28 -0700
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <a7bMFVUZX0bRNKG2fdBG0jE1utnwWWOt7k0ijZkMMyI=.f63c0067-7985-4a25-b3a7-7a372b1eafea@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
 <a7bMFVUZX0bRNKG2fdBG0jE1utnwWWOt7k0ijZkMMyI=.f63c0067-7985-4a25-b3a7-7a372b1eafea@github.com>
Message-ID: <2AEBD2FF-0816-418A-B8A9-C936D942F4D3@oracle.com>

A @Stable field does not need to be volatile.
Avoiding volatile is one of the uses for @Stable.

That said, @Stable is not as foolproof as volatile.
It?s more dangerous, and cheaper.

You have to do a release store to a stable variable.

That?s what the VM does for you automatically for
a final, and a stable is like a delayed final.
But the VM does not give you the release store
automatically; you must do it manually.

That?s why @Stable is an internal feature, and
StableValue is the ?housebroken? version of it.
StableValue has to help the VM maintain the
appearance of a ?final? variable whose initialization
got delayed.  The wrapAndSet method does this job.

This might seem to contradict my previous assertion
that StableValue, being mutex based, must not
use lock-free idioms.  That comment applies
specifically to the update operation that takes
a lambda.  Other operations, such as reading
a SV, or hopefully poking a value at a SV can be,
and should be, composed of lock-free operations.
Why take a lock when it?s just a one-word read
or write?


On 13 Mar 2025, at 9:07, Maurizio Cimadamore wrote:

> On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:
>
>>> Implement JEP 502.
>>>
>>> The PR passes tier1-tier3 tests.
>>
>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>>
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - 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
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 74:
>
>> 72:     @Override
>> 73:     public boolean trySet(T value) {
>> 74:         if (wrappedContentAcquire() != null) {
>
> IMHO, if our goal is to do:
>
> Object content = this.content;
> if (context != null) return content:
> synchronized (...) {
>     if (context != null) return content:
>     this.context = ...
> }
>
>
> Then we might just use a volatile field and synchronized blocks. I don't see an immediate need for using acquire/release semantics --
> especially when using a monitor. E.g. this should look more like a classic double checked locking idiom. (but with a stable field to make the first volatile read more efficient in case the field is already set)
>
> -------------
>
> PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993850760

From jai.forums2013 at gmail.com  Sun Mar 16 09:40:33 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sun, 16 Mar 2025 15:10:33 +0530
Subject: Passing ziptime-info=false to ZipFileSystemProvider (along with
 other classpath performance ideas)
In-Reply-To: <CAG3_yeU4Z7Go37Tqqs+_r9PBq-Th7T0oqUOsLo603zWT-cmKKA@mail.gmail.com>
References: <CAG3_yeU4Z7Go37Tqqs+_r9PBq-Th7T0oqUOsLo603zWT-cmKKA@mail.gmail.com>
Message-ID: <50530d5a-b0e9-4027-b842-90963ca26efa@gmail.com>

Hello Jason,

On 02/03/25 7:13 pm, Jason Zaugg wrote:
> I've been analysing the performance of javac in a relatively large 
> codebase and found classpath scanning to be the dominant factor. There 
> are large numbers of compilation tasks, most with long classpaths 
> including large JARs.
>
> I've been using the wall-time profiling mode of async-profiler to 
> analyse where time is being spent.
>
> I've been able improve build times (most dramatically on Windows, 750s 
> reduced to 350s) by modifying javac to:
>
> 1. pass ziptime-info=false to the env Map of 
> jarFsProvider.newFileSystem, which means the classpath scan in the 
> constructor of ArchiveContainer need only read the ZIP central 
> directory, rather then reading per-entry Extended Time metadata.

I am not familiar with the compiler implementation code, but speaking in 
context of the ZipFileSystem, it appears that this (undocumented) 
"ziptime-info" property of the ZIP file system was indeed introduced to 
help improve the performance of the ZipFileSystem. Setting it to false 
implies that the lastAccessTime() and the creationTime() returned by the 
ZipFileAttributes may not be accurate for some entries, since settings 
this property to false skips reading the per entry creation and access 
time information for the entries. Would you happen to know if either of 
these two methods are used in the code path where you are proposing to 
add "ziptime-info=false"?

-Jaikiran


From jzaugg at gmail.com  Mon Mar 17 04:45:58 2025
From: jzaugg at gmail.com (Jason Zaugg)
Date: Mon, 17 Mar 2025 14:45:58 +1000
Subject: Passing ziptime-info=false to ZipFileSystemProvider (along with
 other classpath performance ideas)
In-Reply-To: <50530d5a-b0e9-4027-b842-90963ca26efa@gmail.com>
References: <CAG3_yeU4Z7Go37Tqqs+_r9PBq-Th7T0oqUOsLo603zWT-cmKKA@mail.gmail.com>
 <50530d5a-b0e9-4027-b842-90963ca26efa@gmail.com>
Message-ID: <CAG3_yeWsh3HqLsH+dtf95VHAeoDVLyXha+dcvVBW=NjMa-ZABA@mail.gmail.com>

On Sun, 16 Mar 2025 at 19:40, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:

> Hello Jason,
>
> On 02/03/25 7:13 pm, Jason Zaugg wrote:
> > I've been analysing the performance of javac in a relatively large
> > codebase and found classpath scanning to be the dominant factor. There
> > are large numbers of compilation tasks, most with long classpaths
> > including large JARs.
> >
> > I've been using the wall-time profiling mode of async-profiler to
> > analyse where time is being spent.
> >
> > I've been able improve build times (most dramatically on Windows, 750s
> > reduced to 350s) by modifying javac to:
> >
> > 1. pass ziptime-info=false to the env Map of
> > jarFsProvider.newFileSystem, which means the classpath scan in the
> > constructor of ArchiveContainer need only read the ZIP central
> > directory, rather then reading per-entry Extended Time metadata.
>
> I am not familiar with the compiler implementation code, but speaking in
> context of the ZipFileSystem, it appears that this (undocumented)
> "ziptime-info" property of the ZIP file system was indeed introduced to
> help improve the performance of the ZipFileSystem. Setting it to false
> implies that the lastAccessTime() and the creationTime() returned by the
> ZipFileAttributes may not be accurate for some entries, since settings
> this property to false skips reading the per entry creation and access
> time information for the entries. Would you happen to know if either of
> these two methods are used in the code path where you are proposing to
> add "ziptime-info=false"?
>
> -Jaikiran
>

I am not aware of any use of these attributes within javac, nor does it
seem likely that they would be used.

But the difference in the attributes could be observed by a client of
JavaFileManager that
unwraps the underlying Path from a JavaFileObject representing a JAR entry.

```
jshell> var compiler = javax.tools.ToolProvider.getSystemJavaCompiler();
compiler ==> com.sun.tools.javac.api.JavacTool at 4b9e255

jshell> var fileManager = compiler.getStandardFileManager(null, null, null)
fileManager ==> com.sun.tools.javac.file.JavacFileManager at 7f416310

jshell> var head =
fileManager.list(javax.tools.StandardLocation.CLASS_PATH, "",
Set.of(javax.tools.JavaFileObject.Kind.OTHER), true).iterator().next()
head ==> JarFileObject[/Users/jz/Library/Caches/Coursier/v ...
e/protobuf/wrappers.proto]

jshell> java.nio.file.Files.readAttributes(fileManager.asPath(head),
java.nio.file.attribute.BasicFileAttributes.class)
$11 ==>     name            : /google/protobuf/wrappers.proto
    creationTime    : Fri Feb 14 21:06:54 AEST 2020
    lastAccessTime  : Fri Feb 14 21:06:54 AEST 2020
    lastModifiedTime: Fri Feb 14 21:06:54 AEST 2020
...
```

A new option could be added to toggle between the existing and proposed
behaviour if this is a concern.

Regards,

Jason Zaugg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250317/ee1d9ec7/attachment.htm>

From alan.bateman at oracle.com  Mon Mar 17 08:07:51 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Mar 2025 08:07:51 +0000
Subject: Passing ziptime-info=false to ZipFileSystemProvider (along with
 other classpath performance ideas)
Message-ID: <c78e8027-e5af-4d12-905e-36253c187992@oracle.com>

On 16/03/2025 09:40, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:

> I am not familiar with the compiler implementation code, but speaking 
> in context of the ZipFileSystem, it appears that this (undocumented) 
> "ziptime-info" property of the ZIP file system was indeed introduced 
> to help improve the performance of the ZipFileSystem.

It came about in the context of early work to move javac to use zipfs 
[1]. I thought there had been follow on work in javac around this but it 
seems not. In file system terms, it's okay to have the equivalent of 
mount options to configure where time stamps come from or whether they 
are updated when accessed/modified. So we could surface it as documented 
property although maybe its name should be examined.

-Alan

[1] https://mail.openjdk.org/pipermail/core-libs-dev/2016-May/040742.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250317/3c6b6220/attachment.htm>

From hannesw at openjdk.org  Tue Mar 18 17:05:44 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 18 Mar 2025 17:05:44 GMT
Subject: RFR: 8352249: Remove incidental whitespace in traditional doc comments
Message-ID: <7U7VUjG-qIfM5AkHx7SaPnoh_rRBkxBl-et2TYzZ6VQ=.01406987-8cd8-4385-8945-92fb7b3f568d@github.com>

Please review a patch to remove incidental indentation from traditional doc comments. This adds a `stripIndent()` method to the `Tokens.Comment` interface and a new `JavadocTokenizer.StrippedComment` nested class that implements indentation stripping while maintaining a map of position offsets to the original comment. 

While the patch changes `javadoc` output by removing leading whitespace, the change is generally not visible in the browser except in `<pre>` elements, which is the point of this enhancement. 

The change affects most tree positions in the AST checker tests in javac/doctree, but mostly does not affect the structure of the parsed trees, with the exception of `BreakIterator` tests in `FirstSentenceTest.java`. 

`BreakIterator` does not recognize `.\n` immediately followed by a lower case letter as sentence break, while it recognizes the break if the letter is an upper-case letter *or* if there is a space between the line break and the letter. I find this rule a bit peculiar but AFAICT we can't influence the behavior of `BreakIterator`, so I have added tests that cover both lower and upper-case behavior.

The source position lookup in the stripped comment is implemented by creating a new `OffsetMap` that translates from the stripped to the original comment, then using the original comment's `OffsetMap` to translate the position to the source file. `OffsetMap` is relatively lightweight (usually 2 `int[]` elements per comment paragraph), so the added overhead is not too bad. 

Inspired by [JDK-8305688](https://bugs.openjdk.org/browse/JDK-8305688) I did various test builds with restricted jobs and memory settings, but didn't notice any change in processing or memory overhead to API docs builds.

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

Commit messages:
 - 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
 - Avoid losing the last of multiple trailing newlines in stripComment
 - Remove unnecessary variable
 - Don't rely on trailing newline
 - Strip indentation from traditional doc comments

Changes: https://git.openjdk.org/jdk/pull/24032/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24032&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352249
  Stats: 1386 lines in 63 files changed: 268 ins; 5 del; 1113 mod
  Patch: https://git.openjdk.org/jdk/pull/24032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24032/head:pull/24032

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

From hannesw at openjdk.org  Wed Mar 19 08:22:25 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 19 Mar 2025 08:22:25 GMT
Subject: RFR: 8352249: Remove incidental whitespace in traditional doc
 comments [v2]
In-Reply-To: <7U7VUjG-qIfM5AkHx7SaPnoh_rRBkxBl-et2TYzZ6VQ=.01406987-8cd8-4385-8945-92fb7b3f568d@github.com>
References: <7U7VUjG-qIfM5AkHx7SaPnoh_rRBkxBl-et2TYzZ6VQ=.01406987-8cd8-4385-8945-92fb7b3f568d@github.com>
Message-ID: <AErB5dwFRk0Ol1ah3S8TXKD7dA5BT8Na2yip9wNGAJQ=.46dc6987-0027-4201-abb3-ab4a812c549b@github.com>

> Please review a patch to remove incidental indentation from traditional doc comments. This adds a `stripIndent()` method to the `Tokens.Comment` interface and a new `JavadocTokenizer.StrippedComment` nested class that implements indentation stripping while maintaining a map of position offsets to the original comment. 
> 
> While the patch changes `javadoc` output by removing leading whitespace, the change is generally not visible in the browser except in `<pre>` elements, which is the point of this enhancement. 
> 
> The change affects most tree positions in the AST checker tests in javac/doctree, but mostly does not affect the structure of the parsed trees, with the exception of `BreakIterator` tests in `FirstSentenceTest.java`. 
> 
> `BreakIterator` does not recognize `.\n` immediately followed by a lower case letter as sentence break, while it recognizes the break if the letter is an upper-case letter *or* if there is a space between the line break and the letter. I find this rule a bit peculiar but AFAICT we can't influence the behavior of `BreakIterator`, so I have added tests that cover both lower and upper-case behavior.
> 
> The source position lookup in the stripped comment is implemented by creating a new `OffsetMap` that translates from the stripped to the original comment, then using the original comment's `OffsetMap` to translate the position to the source file. `OffsetMap` is relatively lightweight (usually 2 `int[]` elements per comment paragraph), so the added overhead is not too bad. 
> 
> Inspired by [JDK-8305688](https://bugs.openjdk.org/browse/JDK-8305688) I did various test builds with restricted jobs and memory settings, but didn't notice any change in processing or memory overhead to API docs builds.

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

  Whitespace normalization in PrettyCheck becomes simpler

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24032/files
  - new: https://git.openjdk.org/jdk/pull/24032/files/eb9a090c..1c21de77

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

  Stats: 55 lines in 3 files changed: 0 ins; 48 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24032/head:pull/24032

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

From hannesw at openjdk.org  Wed Mar 19 11:31:51 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 19 Mar 2025 11:31:51 GMT
Subject: RFR: 8352389: Remove incidental whitespace in pre/code content
Message-ID: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>

Please review a change to remove incidental whitespace commonly found at the beginning of `<pre><code>` or `<pre>{@code` tags. This patch is dependent on [JDK-8352249](https://bugs.openjdk.org/browse/JDK-8352249) and completes the removal of incidental whitespace in traditional doc comments. 

This is implemented by parsing content of `<pre>` elements into a separate list buffer in `DocCommentParser`, and filter the content for leading blank linkes when the element is closed. The decision to filter `<pre>` element contents only once the element is closed was made in order to be able to keep the logic in a single method without further complicating other parts of `DocCommentParser`.

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

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

Commit messages:
 - Improve test
 - Add comment
 - 8352389: Remove incidental whitespace in pre/code content

Changes: https://git.openjdk.org/jdk/pull/24112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352389
  Stats: 354 lines in 7 files changed: 342 ins; 3 del; 9 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 liach at openjdk.org  Wed Mar 19 18:12:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Mar 2025 18:12:31 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v4]
In-Reply-To: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
Message-ID: <PgSl0v7ghxIt65EgUMZyuzRRWbn0TdFO0hfTn_Imtxg=.598b806b-e63f-41e9-a8e9-eb2a7d9fa61e@github.com>

> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
> 
> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
> 
> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
> 
> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.

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 seven additional commits since the last revision:

 - Better docs
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
 - Emit null check by flag/release
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
 - Fix javap test
 - 8164714: Constructor.newInstance creates instance of inner class with null outer class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23875/files
  - new: https://git.openjdk.org/jdk/pull/23875/files/9251340a..6729faad

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

  Stats: 58626 lines in 1033 files changed: 29068 ins; 19026 del; 10532 mod
  Patch: https://git.openjdk.org/jdk/pull/23875.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23875/head:pull/23875

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

From vromero at openjdk.org  Wed Mar 19 18:51:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 19 Mar 2025 18:51:14 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v4]
In-Reply-To: <PgSl0v7ghxIt65EgUMZyuzRRWbn0TdFO0hfTn_Imtxg=.598b806b-e63f-41e9-a8e9-eb2a7d9fa61e@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <PgSl0v7ghxIt65EgUMZyuzRRWbn0TdFO0hfTn_Imtxg=.598b806b-e63f-41e9-a8e9-eb2a7d9fa61e@github.com>
Message-ID: <SIjb_nk3P2Tkb-ZGm8xWir2AzjpNDeqQYZWsx_5UoEs=.c87f1440-226b-436c-a86c-0bd37dc6332b@github.com>

On Wed, 19 Mar 2025 18:12:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
>> 
>> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
>> 
>> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
>> 
>> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
>
> 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 seven additional commits since the last revision:
> 
>  - Better docs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Emit null check by flag/release
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Fix javap test
>  - 8164714: Constructor.newInstance creates instance of inner class with null outer class

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23875#pullrequestreview-2699699130

From liach at openjdk.org  Wed Mar 19 23:33:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Mar 2025 23:33:13 GMT
Subject: RFR: 8352249: Remove incidental whitespace in traditional doc
 comments [v2]
In-Reply-To: <AErB5dwFRk0Ol1ah3S8TXKD7dA5BT8Na2yip9wNGAJQ=.46dc6987-0027-4201-abb3-ab4a812c549b@github.com>
References: <7U7VUjG-qIfM5AkHx7SaPnoh_rRBkxBl-et2TYzZ6VQ=.01406987-8cd8-4385-8945-92fb7b3f568d@github.com>
 <AErB5dwFRk0Ol1ah3S8TXKD7dA5BT8Na2yip9wNGAJQ=.46dc6987-0027-4201-abb3-ab4a812c549b@github.com>
Message-ID: <ZLaTVbyaHY4_fm7TRkDqi97IdWLx8DfQ1NiNPyv3mWw=.72eed97e-3a97-4972-8fb0-7baa19326d00@github.com>

On Wed, 19 Mar 2025 08:22:25 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a patch to remove incidental indentation from traditional doc comments, comparable to doing a `String.stripIndent()` on the comment contents but without special treatment of a last blank line. This adds a `stripIndent()` method to the `Tokens.Comment` interface and a new `JavadocTokenizer.StrippedComment` nested class that implements indentation stripping while maintaining a map of position offsets to the original comment. 
>> 
>> While the patch changes `javadoc` output by removing leading whitespace, the change is generally not visible in the browser except in `<pre>` elements, which is the point of this enhancement. 
>> 
>> The change affects most tree positions in the AST checker tests in javac/doctree, but mostly does not affect the structure of the parsed trees, with the exception of `BreakIterator` tests in `FirstSentenceTest.java`. 
>> 
>> `BreakIterator` does not recognize `.\n` immediately followed by a lower case letter as sentence break, while it recognizes the break if the letter is an upper-case letter *or* if there is a space between the line break and the letter. I find this rule a bit peculiar but AFAICT we can't influence the behavior of `BreakIterator`, so I have added tests that cover both lower and upper-case behavior.
>> 
>> The source position lookup in the stripped comment is implemented by creating a new `OffsetMap` that translates from the stripped to the original comment, then using the original comment's `OffsetMap` to translate the position to the source file. `OffsetMap` is relatively lightweight (usually 2 `int[]` elements per comment paragraph), so the added overhead is not too bad. 
>> 
>> Inspired by [JDK-8305688](https://bugs.openjdk.org/browse/JDK-8305688) I did various test builds with restricted jobs and memory settings, but didn't notice any change in processing or memory overhead to API docs builds.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace normalization in PrettyCheck becomes simpler

Looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24032#pullrequestreview-2700546175

From hannesw at openjdk.org  Thu Mar 20 06:02:12 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 20 Mar 2025 06:02:12 GMT
Subject: RFR: 8352249: Remove incidental whitespace in traditional doc
 comments [v2]
In-Reply-To: <AErB5dwFRk0Ol1ah3S8TXKD7dA5BT8Na2yip9wNGAJQ=.46dc6987-0027-4201-abb3-ab4a812c549b@github.com>
References: <7U7VUjG-qIfM5AkHx7SaPnoh_rRBkxBl-et2TYzZ6VQ=.01406987-8cd8-4385-8945-92fb7b3f568d@github.com>
 <AErB5dwFRk0Ol1ah3S8TXKD7dA5BT8Na2yip9wNGAJQ=.46dc6987-0027-4201-abb3-ab4a812c549b@github.com>
Message-ID: <-ORVCezfWrCYimEOORZHcheJusIrftPY9Mdt7xkGIWs=.54cd70b7-28f4-4fd0-a046-fa73a1d80efa@github.com>

On Wed, 19 Mar 2025 08:22:25 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a patch to remove incidental indentation from traditional doc comments, comparable to doing a `String.stripIndent()` on the comment contents but without special treatment of a last blank line. This adds a `stripIndent()` method to the `Tokens.Comment` interface and a new `JavadocTokenizer.StrippedComment` nested class that implements indentation stripping while maintaining a map of position offsets to the original comment. 
>> 
>> While the patch changes `javadoc` output by removing leading whitespace, the change is generally not visible in the browser except in `<pre>` elements, which is the point of this enhancement. 
>> 
>> The change affects most tree positions in the AST checker tests in javac/doctree, but mostly does not affect the structure of the parsed trees, with the exception of `BreakIterator` tests in `FirstSentenceTest.java`. 
>> 
>> `BreakIterator` does not recognize `.\n` immediately followed by a lower case letter as sentence break, while it recognizes the break if the letter is an upper-case letter *or* if there is a space between the line break and the letter. I find this rule a bit peculiar but AFAICT we can't influence the behavior of `BreakIterator`, so I have added tests that cover both lower and upper-case behavior.
>> 
>> The source position lookup in the stripped comment is implemented by creating a new `OffsetMap` that translates from the stripped to the original comment, then using the original comment's `OffsetMap` to translate the position to the source file. `OffsetMap` is relatively lightweight (usually 2 `int[]` elements per comment paragraph), so the added overhead is not too bad. 
>> 
>> Inspired by [JDK-8305688](https://bugs.openjdk.org/browse/JDK-8305688) I did various test builds with restricted jobs and memory settings, but didn't notice any change in processing or memory overhead to API docs builds.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace normalization in PrettyCheck becomes simpler

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24032#issuecomment-2739289037

From hannesw at openjdk.org  Thu Mar 20 06:02:13 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 20 Mar 2025 06:02:13 GMT
Subject: Integrated: 8352249: Remove incidental whitespace in traditional doc
 comments
In-Reply-To: <7U7VUjG-qIfM5AkHx7SaPnoh_rRBkxBl-et2TYzZ6VQ=.01406987-8cd8-4385-8945-92fb7b3f568d@github.com>
References: <7U7VUjG-qIfM5AkHx7SaPnoh_rRBkxBl-et2TYzZ6VQ=.01406987-8cd8-4385-8945-92fb7b3f568d@github.com>
Message-ID: <PL4DujhukqLsKk618AijOEnPRh6oma5Pm6ioSerYrjg=.9566f30a-8f81-43ae-9d24-ab572cb71a26@github.com>

On Thu, 13 Mar 2025 13:12:10 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to remove incidental indentation from traditional doc comments, comparable to doing a `String.stripIndent()` on the comment contents but without special treatment of a last blank line. This adds a `stripIndent()` method to the `Tokens.Comment` interface and a new `JavadocTokenizer.StrippedComment` nested class that implements indentation stripping while maintaining a map of position offsets to the original comment. 
> 
> While the patch changes `javadoc` output by removing leading whitespace, the change is generally not visible in the browser except in `<pre>` elements, which is the point of this enhancement. 
> 
> The change affects most tree positions in the AST checker tests in javac/doctree, but mostly does not affect the structure of the parsed trees, with the exception of `BreakIterator` tests in `FirstSentenceTest.java`. 
> 
> `BreakIterator` does not recognize `.\n` immediately followed by a lower case letter as sentence break, while it recognizes the break if the letter is an upper-case letter *or* if there is a space between the line break and the letter. I find this rule a bit peculiar but AFAICT we can't influence the behavior of `BreakIterator`, so I have added tests that cover both lower and upper-case behavior.
> 
> The source position lookup in the stripped comment is implemented by creating a new `OffsetMap` that translates from the stripped to the original comment, then using the original comment's `OffsetMap` to translate the position to the source file. `OffsetMap` is relatively lightweight (usually 2 `int[]` elements per comment paragraph), so the added overhead is not too bad. 
> 
> Inspired by [JDK-8305688](https://bugs.openjdk.org/browse/JDK-8305688) I did various test builds with restricted jobs and memory settings, but didn't notice any change in processing or memory overhead to API docs builds.

This pull request has now been integrated.

Changeset: a5d06a18
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5d06a18762c81eda5883c07b42621278b9209c9
Stats:     1438 lines in 64 files changed: 268 ins; 53 del; 1117 mod

8352249: Remove incidental whitespace in traditional doc comments

Reviewed-by: liach

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

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

From hannesw at openjdk.org  Thu Mar 20 06:07:47 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 20 Mar 2025 06:07:47 GMT
Subject: RFR: 8352389: Remove incidental whitespace in pre/code content
 [v2]
In-Reply-To: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
References: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
Message-ID: <-fUZ7sCv8Q02u6hd6m_jMJbDGHdn_4Ix4Z-hJlTYWkQ=.8166f84e-fd35-4950-9916-d017dceefdde@github.com>

> Please review a change to remove incidental whitespace commonly found at the beginning of `<pre><code>` or `<pre>{@code` tags. This patch is dependent on [JDK-8352249](https://bugs.openjdk.org/browse/JDK-8352249) and completes the removal of incidental whitespace in traditional doc comments. 
> 
> This is implemented by parsing content of `<pre>` elements into a separate list buffer in `DocCommentParser`, and filter the content for leading blank linkes when the element is closed. The decision to filter `<pre>` element contents only once the element is closed was made in order to be able to keep the logic in a single method without further complicating other parts of `DocCommentParser`.

Hannes Walln?fer 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24112/files
  - new: https://git.openjdk.org/jdk/pull/24112/files/e3ded45f..e3ded45f

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 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 hannesw at openjdk.org  Thu Mar 20 07:27:39 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 20 Mar 2025 07:27:39 GMT
Subject: RFR: 8352389: Remove incidental whitespace in pre/code content
 [v3]
In-Reply-To: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
References: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
Message-ID: <ubUk0MkY770qWlGfBRpNAsP94bO9zdy42MKaESSGvtw=.4b01189a-d21e-476f-8580-e5b4f9787ddd@github.com>

> Please review a change to remove incidental whitespace commonly found at the beginning of `<pre><code>` or `<pre>{@code` tags. This patch is dependent on [JDK-8352249](https://bugs.openjdk.org/browse/JDK-8352249) and completes the removal of incidental whitespace in traditional doc comments. 
> 
> This is implemented by parsing content of `<pre>` elements into a separate list buffer in `DocCommentParser`, and filter the content for leading blank linkes when the element is closed. The decision to filter `<pre>` element contents only once the element is closed was made in order to be able to keep the logic in a single method without further complicating other parts of `DocCommentParser`.

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

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

Changes: https://git.openjdk.org/jdk/pull/24112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24112&range=02
  Stats: 354 lines in 7 files changed: 342 ins; 3 del; 9 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 archie.cobbs at gmail.com  Thu Mar 20 20:16:03 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 20 Mar 2025 15:16:03 -0500
Subject: The meaning of -Xlint:none,serial
Message-ID: <CANSoFxuKuVDPE5qVZy-UkK7ZyhYybpy1yNzU90Pb9Uo80WiZLg@mail.gmail.com>

What is the intended meaning of a javac flag like -Xlint:none,serial (where
you might replace "serial" with any other non-mandatory lint category).

I always assumed that this means "Disable all lint categories, and then
enable the "serial" category". And in fact, that's how it works for
mandatory lint categories like "unchecked".

But for non-mandatory lint categories, what it actually means is "Disable
all lint categories, period." (which happens here
<https://github.com/openjdk/jdk/blob/56038fb5a156568cce2e80f5db18b10ad61c06e4/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java#L370>
and here
<https://github.com/openjdk/jdk/blob/56038fb5a156568cce2e80f5db18b10ad61c06e4/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java#L722>).


Is that intended? It seems surprising, and is asymmetrical with the meaning
of -Xlint:all,-serial, which means the converse "Enable all lint
categories, and then disable the "serial" category".

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250320/5a75733f/attachment.htm>

From hannesw at openjdk.org  Fri Mar 21 06:10:12 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 21 Mar 2025 06:10:12 GMT
Subject: RFR: 8352389: Remove incidental whitespace in pre/code content
 [v3]
In-Reply-To: <ubUk0MkY770qWlGfBRpNAsP94bO9zdy42MKaESSGvtw=.4b01189a-d21e-476f-8580-e5b4f9787ddd@github.com>
References: <_nIhYXPaNlvsFHzHejW-nHWfSubHnTRN2OqLqbyOj00=.e3f2b677-512f-413c-b26d-7996275a986d@github.com>
 <ubUk0MkY770qWlGfBRpNAsP94bO9zdy42MKaESSGvtw=.4b01189a-d21e-476f-8580-e5b4f9787ddd@github.com>
Message-ID: <IsnO0bAhxCPy5U7PXUhkCvpLceqIWvgymQAimJ27rcs=.ede22cc8-30b2-4407-8bee-9e973bdfee76@github.com>

On Thu, 20 Mar 2025 07:27:39 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to remove incidental whitespace commonly found at the beginning of combined `pre` and `code` tags. 
>> 
>> In a nutshell, using `<pre><code>\n` or `<pre>{@code\n` at the beginning of preformatted code adds an extra empty line at the beginning of the content, compared to just using `<pre>\n`. This is due to [HTML syntax rules](https://html.spec.whatwg.org/#the-pre-element:the-pre-element) and needlessly complicates use of these tags in doc comments. 
>> 
>> This change does the minimum necessary to remove the leading line break. What makes the task slightly more complicated is that we also have to remove any horizontal whitespace between `pre` and `code` tags as these would otherwise add indentation to the first line of actual pre content.
>> 
>> This is implemented by parsing content of `<pre>` elements into a separate list buffer in `DocCommentParser`, and filtering the content when we encounter the `</pre>` close tag. This approach allows us to keep the logic in a single `normalizePreContent` method instead of spreading it in various existing places of `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 in `<pre>{@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 `<pre>` and `{@literal` will cause the problem, so we err on the side of caution.
>
> 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

Note: Github shows 14 commits for this PR, but the first 10 belong to #24032, on which this PR depended and which has already been integrated. Only the last 4 commits actually belong to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24112#issuecomment-2742416198

From rafael.wth at gmail.com  Fri Mar 21 09:20:48 2025
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 21 Mar 2025 10:20:48 +0100
Subject: Bug in JDK25 with switch statements
Message-ID: <CA+DM0A=0gE7sXC1QxBrw0RNQvVz=v8OR3nZYGxQ+jBZJU5Q7LA@mail.gmail.com>

Hello,
my project Byte Buddy fails to build with recent JDK 25s. I am not sure if
this is a known bug, but I wanted to mention it:
https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617

The reason for the build failure is that this switch statement ends up in
the default branch:
https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239

This is happening for the char 'p' which is the last legal branch of the
switch. This does not yield an error on JDKs 5 to 24, so this must be
introduced recently.

Thanks, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/5cd02a53/attachment-0001.htm>

From forax at univ-mlv.fr  Fri Mar 21 09:54:16 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 21 Mar 2025 10:54:16 +0100 (CET)
Subject: Bug in JDK25 with switch statements
In-Reply-To: <CA+DM0A=0gE7sXC1QxBrw0RNQvVz=v8OR3nZYGxQ+jBZJU5Q7LA@mail.gmail.com>
References: <CA+DM0A=0gE7sXC1QxBrw0RNQvVz=v8OR3nZYGxQ+jBZJU5Q7LA@mail.gmail.com>
Message-ID: <1237973890.177927044.1742550856142.JavaMail.zimbra@univ-eiffel.fr>

Hello Raphael, 
It may be hard to reproduce, 
can you do a javap -c on the class/method so it will be easier to see if the generated bytecode is wrong of if it's a VM issue. 

regards, 
R?mi 

> From: "Rafael Winterhalter" <rafael.wth at gmail.com>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Friday, March 21, 2025 10:20:48 AM
> Subject: Bug in JDK25 with switch statements

> Hello,
> my project Byte Buddy fails to build with recent JDK 25s. I am not sure if this
> is a known bug, but I wanted to mention it: [
> https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617 |
> https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617 ]

> The reason for the build failure is that this switch statement ends up in the
> default branch: [
> https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239
> |
> https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239
> ]

> This is happening for the char 'p' which is the last legal branch of the switch.
> This does not yield an error on JDKs 5 to 24, so this must be introduced
> recently.

> Thanks, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/5748a94f/attachment.htm>

From rafael.wth at gmail.com  Fri Mar 21 10:14:23 2025
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 21 Mar 2025 11:14:23 +0100
Subject: Bug in JDK25 with switch statements
In-Reply-To: <1237973890.177927044.1742550856142.JavaMail.zimbra@univ-eiffel.fr>
References: <CA+DM0A=0gE7sXC1QxBrw0RNQvVz=v8OR3nZYGxQ+jBZJU5Q7LA@mail.gmail.com>
 <1237973890.177927044.1742550856142.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CA+DM0An-hZykqcZr4oUchDnsK+KwmYWVWKowjSsnkGM52jyV0w@mail.gmail.com>

The error is stable and can be reproduced by simply building the project.
But it seems to be an issue with javac indeed. The tableswitch statement is
compiled as follows.

       213: tableswitch   { // 100 to 116
                     100: 322
                     101: 296
                     102: 361
                     103: 335
                     104: 348
                     105: 309
                     106: 374
                     107: 374
                     108: 374
                     109: 374
                     110: 374
                     111: 374
                     112: 374
                     113: 374
                     114: 374
                     115: 374
                     116: 374
                 default: 374

The right branch for 'p' is included at offset 361, but 'p' is an integer
value of 109. The character 102 (f) is not included in the Java source.

I guess this is the wrong mailing list in this case. I will post this to
the javac list.

Thanks, Rafael

Am Fr., 21. M?rz 2025 um 10:54 Uhr schrieb Remi Forax <forax at univ-mlv.fr>:

> Hello Raphael,
> It may be hard to reproduce,
> can you do a javap -c on the class/method so it will be easier to see if
> the generated bytecode is wrong of if it's a VM issue.
>
> regards,
> R?mi
>
> ------------------------------
>
> *From: *"Rafael Winterhalter" <rafael.wth at gmail.com>
> *To: *"compiler-dev" <compiler-dev at openjdk.org>
> *Sent: *Friday, March 21, 2025 10:20:48 AM
> *Subject: *Bug in JDK25 with switch statements
>
> Hello,
> my project Byte Buddy fails to build with recent JDK 25s. I am not sure if
> this is a known bug, but I wanted to mention it:
> https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617
>
> The reason for the build failure is that this switch statement ends up in
> the default branch:
> https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239
>
> This is happening for the char 'p' which is the last legal branch of the
> switch. This does not yield an error on JDKs 5 to 24, so this must be
> introduced recently.
>
> Thanks, Rafael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/2c21e33b/attachment.htm>

From rafael.wth at gmail.com  Fri Mar 21 10:15:57 2025
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 21 Mar 2025 11:15:57 +0100
Subject: Bug in JDK25 with switch statements
In-Reply-To: <CA+DM0An-hZykqcZr4oUchDnsK+KwmYWVWKowjSsnkGM52jyV0w@mail.gmail.com>
References: <CA+DM0A=0gE7sXC1QxBrw0RNQvVz=v8OR3nZYGxQ+jBZJU5Q7LA@mail.gmail.com>
 <1237973890.177927044.1742550856142.JavaMail.zimbra@univ-eiffel.fr>
 <CA+DM0An-hZykqcZr4oUchDnsK+KwmYWVWKowjSsnkGM52jyV0w@mail.gmail.com>
Message-ID: <CA+DM0A=DRWWcwnMa9oOTSi+U2F5u-dDFpVC+UKmrz_sz=M0AKQ@mail.gmail.com>

(And of course, this is the right list, I originally thought to post this
to the HotSpot list, but this happens in interpreted mode, so I excluded
that.)

Am Fr., 21. M?rz 2025 um 11:14 Uhr schrieb Rafael Winterhalter <
rafael.wth at gmail.com>:

> The error is stable and can be reproduced by simply building the project.
> But it seems to be an issue with javac indeed. The tableswitch statement is
> compiled as follows.
>
>        213: tableswitch   { // 100 to 116
>                      100: 322
>                      101: 296
>                      102: 361
>                      103: 335
>                      104: 348
>                      105: 309
>                      106: 374
>                      107: 374
>                      108: 374
>                      109: 374
>                      110: 374
>                      111: 374
>                      112: 374
>                      113: 374
>                      114: 374
>                      115: 374
>                      116: 374
>                  default: 374
>
> The right branch for 'p' is included at offset 361, but 'p' is an integer
> value of 109. The character 102 (f) is not included in the Java source.
>
> I guess this is the wrong mailing list in this case. I will post this to
> the javac list.
>
> Thanks, Rafael
>
> Am Fr., 21. M?rz 2025 um 10:54 Uhr schrieb Remi Forax <forax at univ-mlv.fr>:
>
>> Hello Raphael,
>> It may be hard to reproduce,
>> can you do a javap -c on the class/method so it will be easier to see if
>> the generated bytecode is wrong of if it's a VM issue.
>>
>> regards,
>> R?mi
>>
>> ------------------------------
>>
>> *From: *"Rafael Winterhalter" <rafael.wth at gmail.com>
>> *To: *"compiler-dev" <compiler-dev at openjdk.org>
>> *Sent: *Friday, March 21, 2025 10:20:48 AM
>> *Subject: *Bug in JDK25 with switch statements
>>
>> Hello,
>> my project Byte Buddy fails to build with recent JDK 25s. I am not sure
>> if this is a known bug, but I wanted to mention it:
>> https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617
>>
>> The reason for the build failure is that this switch statement ends up in
>> the default branch:
>> https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239
>>
>> This is happening for the char 'p' which is the last legal branch of the
>> switch. This does not yield an error on JDKs 5 to 24, so this must be
>> introduced recently.
>>
>> Thanks, Rafael
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/0a3f049c/attachment-0001.htm>

From forax at univ-mlv.fr  Fri Mar 21 11:09:17 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 21 Mar 2025 12:09:17 +0100 (CET)
Subject: Bug in JDK25 with switch statements
In-Reply-To: <CA+DM0A=DRWWcwnMa9oOTSi+U2F5u-dDFpVC+UKmrz_sz=M0AKQ@mail.gmail.com>
References: <CA+DM0A=0gE7sXC1QxBrw0RNQvVz=v8OR3nZYGxQ+jBZJU5Q7LA@mail.gmail.com>
 <1237973890.177927044.1742550856142.JavaMail.zimbra@univ-eiffel.fr>
 <CA+DM0An-hZykqcZr4oUchDnsK+KwmYWVWKowjSsnkGM52jyV0w@mail.gmail.com>
 <CA+DM0A=DRWWcwnMa9oOTSi+U2F5u-dDFpVC+UKmrz_sz=M0AKQ@mail.gmail.com>
Message-ID: <962276951.178204924.1742555357445.JavaMail.zimbra@univ-eiffel.fr>

> From: "Rafael Winterhalter" <rafael.wth at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Friday, March 21, 2025 11:15:57 AM
> Subject: Re: Bug in JDK25 with switch statements

> (And of course, this is the right list, I originally thought to post this to the
> HotSpot list, but this happens in interpreted mode, so I excluded that.)

> Am Fr., 21. M?rz 2025 um 11:14 Uhr schrieb Rafael Winterhalter < [
> mailto:rafael.wth at gmail.com | rafael.wth at gmail.com ] >:

>> The error is stable and can be reproduced by simply building the project. But it
>> seems to be an issue with javac indeed. The tableswitch statement is compiled
>> as follows.

>> 213: tableswitch { // 100 to 116
>> 100: 322
>> 101: 296
>> 102: 361
>> 103: 335
>> 104: 348
>> 105: 309
>> 106: 374
>> 107: 374
>> 108: 374
>> 109: 374
>> 110: 374
>> 111: 374
>> 112: 374
>> 113: 374
>> 114: 374
>> 115: 374
>> 116: 374
>> default: 374

>> The right branch for 'p' is included at offset 361, but 'p' is an integer value
>> of 109. The character 102 (f) is not included in the Java source.

The table is constructed like if all the targets that correspond to a valid branches (one of the six) are all on top instead of being in front the right value (m, t, d, s, r, p). 

Sadly, i'm not able to reproduce the issue, the following code works for me :( 

static final char M_SYMBOL = 'm' ; 
static final char T_SYMBOL = 't' ; 
static final char D_SYMBOL = 'd' ; 
static final char S_SYMBOL = 's' ; 
static final char R_SYMBOL = 'r' ; 
static final char P_SYMBOL = 'p' ; 

public static void main ( String [] args ) { 
var text = "mtdsrp" ; 
for ( var i = 0 ; i < text .length(); i ++) { 
switch ( text .charAt( i )) { 
case M_SYMBOL : 
System . out .println( "m" ); 
break ; 
case T_SYMBOL : 
System . out .println( "t" ); 
break ; 
case D_SYMBOL : 
System . out .println( "d" ); 
break ; 
case S_SYMBOL : 
System . out .println( "s" ); 
break ; 
case R_SYMBOL : 
System . out .println( "r" ); 
break ; 
case P_SYMBOL : 
System . out .println( "p" ); 
break ; 
default : 
throw new IllegalStateException(); 
} 
} 
} 

>> I guess this is the wrong mailing list in this case. I will post this to the
>> javac list.

>> Thanks, Rafael

>> Am Fr., 21. M?rz 2025 um 10:54 Uhr schrieb Remi Forax < [
>> mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >:

>>> Hello Raphael,
>>> It may be hard to reproduce,
>>> can you do a javap -c on the class/method so it will be easier to see if the
>>> generated bytecode is wrong of if it's a VM issue.

>>> regards,
>>> R?mi

>>>> From: "Rafael Winterhalter" < [ mailto:rafael.wth at gmail.com |
>>>> rafael.wth at gmail.com ] >
>>>> To: "compiler-dev" < [ mailto:compiler-dev at openjdk.org |
>>>> compiler-dev at openjdk.org ] >
>>>> Sent: Friday, March 21, 2025 10:20:48 AM
>>>> Subject: Bug in JDK25 with switch statements

>>>> Hello,
>>>> my project Byte Buddy fails to build with recent JDK 25s. I am not sure if this
>>>> is a known bug, but I wanted to mention it: [
>>>> https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617 |
>>>> https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617 ]

>>>> The reason for the build failure is that this switch statement ends up in the
>>>> default branch: [
>>>> https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239
>>>> |
>>>> https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239
>>>> ]

>>>> This is happening for the char 'p' which is the last legal branch of the switch.
>>>> This does not yield an error on JDKs 5 to 24, so this must be introduced
>>>> recently.

>>>> Thanks, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/1d233772/attachment.htm>

From jan.lahoda at oracle.com  Fri Mar 21 11:40:44 2025
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 21 Mar 2025 12:40:44 +0100
Subject: Bug in JDK25 with switch statements
In-Reply-To: <CA+DM0A=DRWWcwnMa9oOTSi+U2F5u-dDFpVC+UKmrz_sz=M0AKQ@mail.gmail.com>
References: <CA+DM0A=0gE7sXC1QxBrw0RNQvVz=v8OR3nZYGxQ+jBZJU5Q7LA@mail.gmail.com>
 <1237973890.177927044.1742550856142.JavaMail.zimbra@univ-eiffel.fr>
 <CA+DM0An-hZykqcZr4oUchDnsK+KwmYWVWKowjSsnkGM52jyV0w@mail.gmail.com>
 <CA+DM0A=DRWWcwnMa9oOTSi+U2F5u-dDFpVC+UKmrz_sz=M0AKQ@mail.gmail.com>
Message-ID: <5ff0580c-6a68-4a64-a43d-edd0a39f9ea7@oracle.com>

Hello Rafael,


I peeked at this, and it seems to me that when javac writes the file, 
the table switch offsets seem sensible:

 ???????????????????? 100: 322
 ???????????????????? 101: 374
 ???????????????????? 102: 374
 ???????????????????? 103: 374
 ???????????????????? 104: 374
 ???????????????????? 105: 374
 ???????????????????? 106: 374
 ???????????????????? 107: 374
 ???????????????????? 108: 374
 ???????????????????? 109: 296
 ???????????????????? 110: 374
 ???????????????????? 111: 374
 ???????????????????? 112: 361
 ???????????????????? 113: 374
 ???????????????????? 114: 335
 ???????????????????? 115: 348
 ???????????????????? 116: 309
 ???????????????? default: 374

(I tweaked javac to make a copy of the generated classfile right after 
it is done with writing it to the disk.)

But when the build ends, the classfile does not look sensible anymore. 
Is there some classfile postprocessing going on? Could you please check 
if that's working correctly?


Thanks,

 ??? Jan


On 21. 03. 25 11:15, Rafael Winterhalter wrote:
> (And of course, this is the right list, I originally thought to post 
> this to the HotSpot list, but this happens in interpreted mode, so I 
> excluded that.)
>
> Am Fr., 21. M?rz 2025 um 11:14?Uhr schrieb Rafael Winterhalter 
> <rafael.wth at gmail.com>:
>
>     The error is stable and can be reproduced by simply building the
>     project. But it seems to be an issue with javac indeed. The
>     tableswitch statement is compiled as follows.
>
>     ? ? ?? 213: tableswitch ? { // 100 to 116
>     ? ? ? ? ? ? ? ? ? ? ?100: 322
>     ? ? ? ? ? ? ? ? ? ? ?101: 296
>     ? ? ? ? ? ? ? ? ? ? ?102: 361
>     ? ? ? ? ? ? ? ? ? ? ?103: 335
>     ? ? ? ? ? ? ? ? ? ? ?104: 348
>     ? ? ? ? ? ? ? ? ? ? ?105: 309
>     ? ? ? ? ? ? ? ? ? ? ?106: 374
>     ? ? ? ? ? ? ? ? ? ? ?107: 374
>     ? ? ? ? ? ? ? ? ? ? ?108: 374
>     ? ? ? ? ? ? ? ? ? ? ?109: 374
>     ? ? ? ? ? ? ? ? ? ? ?110: 374
>     ? ? ? ? ? ? ? ? ? ? ?111: 374
>     ? ? ? ? ? ? ? ? ? ? ?112: 374
>     ? ? ? ? ? ? ? ? ? ? ?113: 374
>     ? ? ? ? ? ? ? ? ? ? ?114: 374
>     ? ? ? ? ? ? ? ? ? ? ?115: 374
>     ? ? ? ? ? ? ? ? ? ? ?116: 374
>     ? ? ? ? ? ? ? ? ?default: 374
>
>     The right branch for 'p' is included at offset 361, but 'p' is an
>     integer value of 109. The character 102 (f) is not included in the
>     Java source.
>
>     I guess this is the wrong mailing list in this case. I will post
>     this to the javac list.
>
>     Thanks, Rafael
>
>     Am Fr., 21. M?rz 2025 um 10:54?Uhr schrieb Remi Forax
>     <forax at univ-mlv.fr>:
>
>         Hello Raphael,
>         It may be hard to reproduce,
>         can you do a javap -c on the class/method so it will be easier
>         to see if the generated bytecode is wrong of if it's a VM issue.
>
>         regards,
>         R?mi
>
>         ------------------------------------------------------------------------
>
>             *From: *"Rafael Winterhalter" <rafael.wth at gmail.com>
>             *To: *"compiler-dev" <compiler-dev at openjdk.org>
>             *Sent: *Friday, March 21, 2025 10:20:48 AM
>             *Subject: *Bug in JDK25 with switch statements
>
>             Hello,
>             my project Byte Buddy fails to build with recent JDK 25s.
>             I am not sure if this is a known bug, but I wanted to
>             mention it:
>             https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617
>
>             The reason for the build failure is that this switch
>             statement ends up in the default branch:
>             https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239
>
>             This is happening for the char 'p' which is the last legal
>             branch of the switch. This does not yield an error on JDKs
>             5 to 24, so this must be introduced recently.
>
>             Thanks, Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/0d61922e/attachment-0001.htm>

From rafael.wth at gmail.com  Fri Mar 21 12:01:26 2025
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 21 Mar 2025 13:01:26 +0100
Subject: Bug in JDK25 with switch statements
In-Reply-To: <5ff0580c-6a68-4a64-a43d-edd0a39f9ea7@oracle.com>
References: <CA+DM0A=0gE7sXC1QxBrw0RNQvVz=v8OR3nZYGxQ+jBZJU5Q7LA@mail.gmail.com>
 <1237973890.177927044.1742550856142.JavaMail.zimbra@univ-eiffel.fr>
 <CA+DM0An-hZykqcZr4oUchDnsK+KwmYWVWKowjSsnkGM52jyV0w@mail.gmail.com>
 <CA+DM0A=DRWWcwnMa9oOTSi+U2F5u-dDFpVC+UKmrz_sz=M0AKQ@mail.gmail.com>
 <5ff0580c-6a68-4a64-a43d-edd0a39f9ea7@oracle.com>
Message-ID: <CA+DM0AkDTVU5c0o-w4KtNA+fSPTix5We8oi66OG=aNwOGKef9g@mail.gmail.com>

Yes, of course. On Java 25 the post processing is using the Class File API
and not ASM, but the method should be passed "as is" as it is not
transformed. Yet, the code seems to break.

I will have a look why this is the case and if this is a result of my
integration or the API in itself.

Thanks for the pointer. Best regards, Rafael



Am Fr., 21. M?rz 2025 um 12:40 Uhr schrieb Jan Lahoda <jan.lahoda at oracle.com
>:

> Hello Rafael,
>
>
> I peeked at this, and it seems to me that when javac writes the file, the
> table switch offsets seem sensible:
>
>                      100: 322
>                      101: 374
>                      102: 374
>                      103: 374
>                      104: 374
>                      105: 374
>                      106: 374
>                      107: 374
>                      108: 374
>                      109: 296
>                      110: 374
>                      111: 374
>                      112: 361
>                      113: 374
>                      114: 335
>                      115: 348
>                      116: 309
>                  default: 374
>
> (I tweaked javac to make a copy of the generated classfile right after it
> is done with writing it to the disk.)
>
> But when the build ends, the classfile does not look sensible anymore. Is
> there some classfile postprocessing going on? Could you please check if
> that's working correctly?
>
>
> Thanks,
>
>     Jan
>
>
> On 21. 03. 25 11:15, Rafael Winterhalter wrote:
>
> (And of course, this is the right list, I originally thought to post this
> to the HotSpot list, but this happens in interpreted mode, so I excluded
> that.)
>
> Am Fr., 21. M?rz 2025 um 11:14 Uhr schrieb Rafael Winterhalter <
> rafael.wth at gmail.com>:
>
>> The error is stable and can be reproduced by simply building the project.
>> But it seems to be an issue with javac indeed. The tableswitch statement is
>> compiled as follows.
>>
>>        213: tableswitch   { // 100 to 116
>>                      100: 322
>>                      101: 296
>>                      102: 361
>>                      103: 335
>>                      104: 348
>>                      105: 309
>>                      106: 374
>>                      107: 374
>>                      108: 374
>>                      109: 374
>>                      110: 374
>>                      111: 374
>>                      112: 374
>>                      113: 374
>>                      114: 374
>>                      115: 374
>>                      116: 374
>>                  default: 374
>>
>> The right branch for 'p' is included at offset 361, but 'p' is an integer
>> value of 109. The character 102 (f) is not included in the Java source.
>>
>> I guess this is the wrong mailing list in this case. I will post this to
>> the javac list.
>>
>> Thanks, Rafael
>>
>> Am Fr., 21. M?rz 2025 um 10:54 Uhr schrieb Remi Forax <forax at univ-mlv.fr
>> >:
>>
>>> Hello Raphael,
>>> It may be hard to reproduce,
>>> can you do a javap -c on the class/method so it will be easier to see if
>>> the generated bytecode is wrong of if it's a VM issue.
>>>
>>> regards,
>>> R?mi
>>>
>>> ------------------------------
>>>
>>> *From: *"Rafael Winterhalter" <rafael.wth at gmail.com>
>>> *To: *"compiler-dev" <compiler-dev at openjdk.org>
>>> *Sent: *Friday, March 21, 2025 10:20:48 AM
>>> *Subject: *Bug in JDK25 with switch statements
>>>
>>> Hello,
>>> my project Byte Buddy fails to build with recent JDK 25s. I am not sure
>>> if this is a known bug, but I wanted to mention it:
>>> https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617
>>>
>>> The reason for the build failure is that this switch statement ends up
>>> in the default branch:
>>> https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239
>>>
>>> This is happening for the char 'p' which is the last legal branch of the
>>> switch. This does not yield an error on JDKs 5 to 24, so this must be
>>> introduced recently.
>>>
>>> Thanks, Rafael
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/e0411f42/attachment.htm>

From maurizio.cimadamore at oracle.com  Fri Mar 21 12:27:32 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 21 Mar 2025 12:27:32 +0000
Subject: The meaning of -Xlint:none,serial
In-Reply-To: <CANSoFxuKuVDPE5qVZy-UkK7ZyhYybpy1yNzU90Pb9Uo80WiZLg@mail.gmail.com>
References: <CANSoFxuKuVDPE5qVZy-UkK7ZyhYybpy1yNzU90Pb9Uo80WiZLg@mail.gmail.com>
Message-ID: <734f6b8a-901c-475f-bf3d-d53426a9e660@oracle.com>

I always assumed what you assumed :-)

E.g. _all_ is a special markers which selects all, _none_ one that 
selects nothing. From there you can remove (in the first case) or add 
(in the second case).

If it doesn't work like that, I'd say that's a bug.

Maurizio

On 20/03/2025 20:16, Archie Cobbs wrote:
> What is the intended meaning of a javac flag like -Xlint:none,serial 
> (where you might replace "serial" with any other non-mandatory lint 
> category).
>
> I always assumed that this means "Disable all lint categories, and 
> then enable the "serial" category". And in fact, that's how it works 
> for mandatory lint categories like "unchecked".
>
> But for non-mandatory lint categories, what it actually means is 
> "Disable all lint categories, period." (which happens here 
> <https://github.com/openjdk/jdk/blob/56038fb5a156568cce2e80f5db18b10ad61c06e4/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java#L370> 
> and here 
> <https://github.com/openjdk/jdk/blob/56038fb5a156568cce2e80f5db18b10ad61c06e4/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java#L722>). 
>
>
> Is that intended? It seems surprising, and is asymmetrical with the 
> meaning of -Xlint:all,-serial, which means the converse "Enable all 
> lint categories, and then disable the "serial" category".
>
> Thanks,
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/1b5a962f/attachment-0001.htm>

From mcimadamore at openjdk.org  Fri Mar 21 12:37:16 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Mar 2025 12:37:16 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v4]
In-Reply-To: <PgSl0v7ghxIt65EgUMZyuzRRWbn0TdFO0hfTn_Imtxg=.598b806b-e63f-41e9-a8e9-eb2a7d9fa61e@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <PgSl0v7ghxIt65EgUMZyuzRRWbn0TdFO0hfTn_Imtxg=.598b806b-e63f-41e9-a8e9-eb2a7d9fa61e@github.com>
Message-ID: <v66rZkHse9cPlhPzZmRohYeIfciikH7diXxhon3G8U8=.96dfb816-c8be-43c3-917a-68d04fca0208@github.com>

On Wed, 19 Mar 2025 18:12:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
>> 
>> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
>> 
>> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
>> 
>> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
>
> 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 seven additional commits since the last revision:
> 
>  - Better docs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Emit null check by flag/release
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Fix javap test
>  - 8164714: Constructor.newInstance creates instance of inner class with null outer class

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 1820:

> 1818:                     sourceExp).setType(lhs.erasure(types));
> 1819:         } else {
> 1820:             Assert.check(nullCheckOuterThis);

This code seems repeated twice. Perhaps you could first create the expression (which could be null checked or not) and then use that expression to store in the `this$0` field (if needed).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r2007491333

From mcimadamore at openjdk.org  Fri Mar 21 12:41:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Mar 2025 12:41:10 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v4]
In-Reply-To: <PgSl0v7ghxIt65EgUMZyuzRRWbn0TdFO0hfTn_Imtxg=.598b806b-e63f-41e9-a8e9-eb2a7d9fa61e@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <PgSl0v7ghxIt65EgUMZyuzRRWbn0TdFO0hfTn_Imtxg=.598b806b-e63f-41e9-a8e9-eb2a7d9fa61e@github.com>
Message-ID: <s6XLYqLQXXuWmz7U0dOKnsiFO2ytT88t5NoX2oS1l1Q=.7c0215ea-334c-40ab-a1c7-d9e4967d32bd@github.com>

On Wed, 19 Mar 2025 18:12:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
>> 
>> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
>> 
>> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
>> 
>> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
>
> 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 seven additional commits since the last revision:
> 
>  - Better docs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Emit null check by flag/release
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>  - Fix javap test
>  - 8164714: Constructor.newInstance creates instance of inner class with null outer class

The compiler changes look good - and I think more generally this looks like a good enforcement to do in the generated code (also in perspective, consider what's coming in Valhalla).

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

PR Comment: https://git.openjdk.org/jdk/pull/23875#issuecomment-2743247946

From archie.cobbs at gmail.com  Fri Mar 21 14:13:33 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 21 Mar 2025 09:13:33 -0500
Subject: The meaning of -Xlint:none,serial
In-Reply-To: <734f6b8a-901c-475f-bf3d-d53426a9e660@oracle.com>
References: <CANSoFxuKuVDPE5qVZy-UkK7ZyhYybpy1yNzU90Pb9Uo80WiZLg@mail.gmail.com>
 <734f6b8a-901c-475f-bf3d-d53426a9e660@oracle.com>
Message-ID: <CANSoFxv+bYx1JV=3e40kM473BE7+8SfhgZE9=jSE-cOKW9WyMA@mail.gmail.com>

Thanks for the confirmation. I've created JDK-8352612
<https://bugs.openjdk.org/browse/JDK-8352612> to track it.

-Archie

On Fri, Mar 21, 2025 at 7:27?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I always assumed what you assumed :-)
>
> E.g. _all_ is a special markers which selects all, _none_ one that selects
> nothing. From there you can remove (in the first case) or add (in the
> second case).
>
> If it doesn't work like that, I'd say that's a bug.
>
> Maurizio
> On 20/03/2025 20:16, Archie Cobbs wrote:
>
> What is the intended meaning of a javac flag like -Xlint:none,serial
> (where you might replace "serial" with any other non-mandatory lint
> category).
>
> I always assumed that this means "Disable all lint categories, and then
> enable the "serial" category". And in fact, that's how it works for
> mandatory lint categories like "unchecked".
>
> But for non-mandatory lint categories, what it actually means is "Disable
> all lint categories, period." (which happens here
> <https://github.com/openjdk/jdk/blob/56038fb5a156568cce2e80f5db18b10ad61c06e4/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java#L370>
> and here
> <https://github.com/openjdk/jdk/blob/56038fb5a156568cce2e80f5db18b10ad61c06e4/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java#L722>).
>
>
> Is that intended? It seems surprising, and is asymmetrical with the
> meaning of -Xlint:all,-serial, which means the converse "Enable all lint
> categories, and then disable the "serial" category".
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/61a6367b/attachment-0001.htm>

From jlahoda at openjdk.org  Fri Mar 21 14:15:18 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 21 Mar 2025 14:15:18 GMT
Subject: RFR: 8348928: Check for case label validity are misbehaving when
 binding patterns with unnamed bindings are present
Message-ID: <WqHraZlmaTd7IY4RkdgQxxZ72zA2sfUyft3GOEIw1jE=.1266a33a-b849-4a71-827c-9a0b1eac3cdc@github.com>

Consider code like:

public class Exp0 {
    public static void main(String... args) {
        Object o = "";
        record R(int i, String s) {}

        switch (o) {
            case Integer _, R(int i, String _) -> {}
            default -> {}
        }
    }
}


This compiles OK, but it should. The JLS says:
> It is a compile-time error for a case label to have more than one case pattern and declare any pattern variables (other than those declared by a guard associated with the case label).

Some similar cases leads to a javac crash:

$ cat Exp2.java 
public class Exp2 {
    public static void main(String... args) {
        Object o = "";
        record R(int i, String s) {}

        switch (o) {
            case Integer _:
            case R(int i, String _):
                System.err.println(i);
                break;
            default: break;
        }
    }
}

$ jdk-24/bin/javac Exp2.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
        at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
        at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
        at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.<init>(Items.java:392)
        at jdk.compiler/com.sun.tools.javac.jvm.Items.makeLocalItem(Items.java:133)
        at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitIdent(Gen.java:2350)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2711)
...
printing javac parameters to: /tmp/javac.20250321_150757.args


The root cause here is a bug when determining whether or not a given case label contains bindings - the "has-bindings" flag gets cleared when `_` is used. The "has-bindings" flags must remain set despite seeing unnamed binding variables.

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

Commit messages:
 - Adding test for case fall-through.
 - Adding newline
 - Adjusting test.
 - 8348928: Check for case label validity are misbehaving when binding patterns with unnamed bindings are present

Changes: https://git.openjdk.org/jdk/pull/24155/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24155&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348928
  Stats: 23 lines in 3 files changed: 20 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24155/head:pull/24155

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

From duke at openjdk.org  Fri Mar 21 15:11:42 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 21 Mar 2025 15:11:42 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v5]
In-Reply-To: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
Message-ID: <Y5D9FimEtmFOdBtr8BsTdk54hyPWC9-DosPVD2p_7IY=.412b4d47-b086-4c0f-9c6c-390b3cd87514@github.com>

> 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 two additional commits since the last revision:

 - Rewriting test and merging annotation tests based on feedback.
 - Updating from feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23699/files
  - new: https://git.openjdk.org/jdk/pull/23699/files/2fbb486e..2905c223

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

  Stats: 672 lines in 4 files changed: 280 ins; 391 del; 1 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 liach at openjdk.org  Fri Mar 21 20:45:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Mar 2025 20:45:26 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v5]
In-Reply-To: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
Message-ID: <2PZsCA5gssZj-sH1jpoufz_yLScKBFbVQq_JfN96WeM=.10b4ddd7-fdac-4c15-ab21-417c18de89ab@github.com>

> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
> 
> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
> 
> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
> 
> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Reduce code repetition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23875/files
  - new: https://git.openjdk.org/jdk/pull/23875/files/6729faad..d2e10cda

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

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

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

From liach at openjdk.org  Fri Mar 21 20:49:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Mar 2025 20:49:13 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v4]
In-Reply-To: <v66rZkHse9cPlhPzZmRohYeIfciikH7diXxhon3G8U8=.96dfb816-c8be-43c3-917a-68d04fca0208@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <PgSl0v7ghxIt65EgUMZyuzRRWbn0TdFO0hfTn_Imtxg=.598b806b-e63f-41e9-a8e9-eb2a7d9fa61e@github.com>
 <v66rZkHse9cPlhPzZmRohYeIfciikH7diXxhon3G8U8=.96dfb816-c8be-43c3-917a-68d04fca0208@github.com>
Message-ID: <XjZp_ks5QfpPEVvSP_sfPhSQ3Bx0-MRGN3dOVEQF4xY=.b22a7426-e5e9-4161-954f-f8f18e386d08@github.com>

On Fri, 21 Mar 2025 12:34:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Better docs
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>>  - Emit null check by flag/release
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/enclosing-this-null-check
>>  - Fix javap test
>>  - 8164714: Constructor.newInstance creates instance of inner class with null outer class
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 1820:
> 
>> 1818:                     sourceExp).setType(lhs.erasure(types));
>> 1819:         } else {
>> 1820:             Assert.check(nullCheckOuterThis);
> 
> This code seems repeated twice. Perhaps you could first create the expression (which could be null checked or not) and then use that expression to store in the `this$0` field (if needed).

Thanks for the comment. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23875#discussion_r2008310912

From jai.forums2013 at gmail.com  Sat Mar 22 10:06:22 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 22 Mar 2025 15:36:22 +0530
Subject: Passing ziptime-info=false to ZipFileSystemProvider (along with
 other classpath performance ideas)
In-Reply-To: <CAG3_yeWsh3HqLsH+dtf95VHAeoDVLyXha+dcvVBW=NjMa-ZABA@mail.gmail.com>
References: <CAG3_yeU4Z7Go37Tqqs+_r9PBq-Th7T0oqUOsLo603zWT-cmKKA@mail.gmail.com>
 <50530d5a-b0e9-4027-b842-90963ca26efa@gmail.com>
 <CAG3_yeWsh3HqLsH+dtf95VHAeoDVLyXha+dcvVBW=NjMa-ZABA@mail.gmail.com>
Message-ID: <b1c8d027-5de5-46b8-a562-a1178ad7e3b0@gmail.com>

Hello Jason,

For the proposal to set zipinfo-time=false when constructing the zipfs 
FileSystem in the compiler code, I've created 
https://bugs.openjdk.org/browse/JDK-8352642. Since you have already 
experimented with the changes, could you create a PR with just that 
change for review?

-Jaikiran

On 17/03/25 10:15 am, Jason Zaugg wrote:
> On Sun, 16 Mar 2025 at 19:40, Jaikiran Pai <jai.forums2013 at gmail.com> 
> wrote:
>
>     Hello Jason,
>
>     On 02/03/25 7:13 pm, Jason Zaugg wrote:
>     > I've been analysing the performance of javac in a relatively large
>     > codebase and found classpath scanning to be the dominant factor.
>     There
>     > are large numbers of compilation tasks, most with long classpaths
>     > including large JARs.
>     >
>     > I've been using the wall-time profiling mode of async-profiler to
>     > analyse where time is being spent.
>     >
>     > I've been able improve build times (most dramatically on
>     Windows, 750s
>     > reduced to 350s) by modifying javac to:
>     >
>     > 1. pass ziptime-info=false to the env Map of
>     > jarFsProvider.newFileSystem, which means the classpath scan in the
>     > constructor of ArchiveContainer need only read the ZIP central
>     > directory, rather then reading per-entry Extended Time metadata.
>
>     I am not familiar with the compiler implementation code, but
>     speaking in
>     context of the ZipFileSystem, it appears that this (undocumented)
>     "ziptime-info" property of the ZIP file system was indeed
>     introduced to
>     help improve the performance of the ZipFileSystem. Setting it to
>     false
>     implies that the lastAccessTime() and the creationTime() returned
>     by the
>     ZipFileAttributes may not be accurate for some entries, since
>     settings
>     this property to false skips reading the per entry creation and
>     access
>     time information for the entries. Would you happen to know if
>     either of
>     these two methods are used in the code path where you are
>     proposing to
>     add "ziptime-info=false"?
>
>     -Jaikiran
>
>
> I am not aware of any?use of these attributes within javac, nor does 
> it seem likely that they would be used.
>
> But the difference in?the attributes could be observed by a client of 
> JavaFileManager that
> unwraps the underlying Path from a JavaFileObject representing a JAR 
> entry.
>
> ```
> jshell> var compiler = javax.tools.ToolProvider.getSystemJavaCompiler();
> compiler ==> com.sun.tools.javac.api.JavacTool at 4b9e255
>
> jshell> var fileManager = compiler.getStandardFileManager(null, null, 
> null)
> fileManager ==> com.sun.tools.javac.file.JavacFileManager at 7f416310
>
> jshell> var head = 
> fileManager.list(javax.tools.StandardLocation.CLASS_PATH, "", 
> Set.of(javax.tools.JavaFileObject.Kind.OTHER), true).iterator().next()
> head ==> JarFileObject[/Users/jz/Library/Caches/Coursier/v ... 
> e/protobuf/wrappers.proto]
>
> jshell> java.nio.file.Files.readAttributes(fileManager.asPath(head), 
> java.nio.file.attribute.BasicFileAttributes.class)
> $11 ==> ? ? name ? ? ? ? ? ?: /google/protobuf/wrappers.proto
> ? ? creationTime ? ?: Fri Feb 14 21:06:54 AEST 2020
> ? ? lastAccessTime ?: Fri Feb 14 21:06:54 AEST 2020
> ? ? lastModifiedTime: Fri Feb 14 21:06:54 AEST 2020
> ...
> ```
>
> A new option could be added to toggle between the existing and 
> proposed behaviour if this is a concern.
>
> Regards,
>
> Jason Zaugg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250322/a9ade7d5/attachment.htm>

From jzaugg at openjdk.org  Sun Mar 23 12:45:38 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Sun, 23 Mar 2025 12:45:38 GMT
Subject: RFR: 8352642: Reduce cost of JAR directory scan in ArchiveContainer
Message-ID: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>

8352642: Reduce cost of JAR directory scan in ArchiveContainer

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

Commit messages:
 - 8352642: Reduce cost of JAR directory scan in ArchiveContainer

Changes: https://git.openjdk.org/jdk/pull/24176/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24176&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352642
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 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 jzaugg at openjdk.org  Sun Mar 23 12:45:38 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Sun, 23 Mar 2025 12:45:38 GMT
Subject: RFR: 8352642: Reduce cost of JAR directory scan in
 ArchiveContainer
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <zb6wSBmuGKWfsdhqSAxmtvlTNtle_B7GMf5jCqvjN_E=.74ec98b6-16e9-409a-9625-3b3b7d575c12@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Reduce cost of JAR directory scan in ArchiveContainer

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 564:

> 562:         public ArchiveContainer(Path archivePath) throws IOException, ProviderNotFoundException {
> 563:             this.archivePath = archivePath;
> 564:             if (multiReleaseValue != null && archivePath.toString().endsWith(".jar")) {

The else branch, which uses `FileSystems.newFileSystem(archivePath, (ClassLoader)null); rather than  `jarFsProvider.newFileSystem`,  is unchanged in the PR. 

AFAICT that would only be taken when a client using `JavacFileManager` directly, omitting the `fm.handleOption(Option.MULTIRELEASE, .. )` call, or in a custom scenario with non-JAR archivess.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2009104482

From jzaugg at gmail.com  Sun Mar 23 12:47:33 2025
From: jzaugg at gmail.com (Jason Zaugg)
Date: Sun, 23 Mar 2025 22:47:33 +1000
Subject: Passing ziptime-info=false to ZipFileSystemProvider (along with
 other classpath performance ideas)
In-Reply-To: <b1c8d027-5de5-46b8-a562-a1178ad7e3b0@gmail.com>
References: <CAG3_yeU4Z7Go37Tqqs+_r9PBq-Th7T0oqUOsLo603zWT-cmKKA@mail.gmail.com>
 <50530d5a-b0e9-4027-b842-90963ca26efa@gmail.com>
 <CAG3_yeWsh3HqLsH+dtf95VHAeoDVLyXha+dcvVBW=NjMa-ZABA@mail.gmail.com>
 <b1c8d027-5de5-46b8-a562-a1178ad7e3b0@gmail.com>
Message-ID: <CAG3_yeXxUntPb9KM8ObNQS5vNQQ4LHVgWporomPiM1w2AfGoGA@mail.gmail.com>

Submitted as https://github.com/openjdk/jdk/pull/24176

Jason Zaugg

On Sat, 22 Mar 2025 at 20:06, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:

> Hello Jason,
>
> For the proposal to set zipinfo-time=false when constructing the zipfs
> FileSystem in the compiler code, I've created
> https://bugs.openjdk.org/browse/JDK-8352642. Since you have already
> experimented with the changes, could you create a PR with just that change
> for review?
>
> -Jaikiran
> On 17/03/25 10:15 am, Jason Zaugg wrote:
>
> On Sun, 16 Mar 2025 at 19:40, Jaikiran Pai <jai.forums2013 at gmail.com>
> wrote:
>
>> Hello Jason,
>>
>> On 02/03/25 7:13 pm, Jason Zaugg wrote:
>> > I've been analysing the performance of javac in a relatively large
>> > codebase and found classpath scanning to be the dominant factor. There
>> > are large numbers of compilation tasks, most with long classpaths
>> > including large JARs.
>> >
>> > I've been using the wall-time profiling mode of async-profiler to
>> > analyse where time is being spent.
>> >
>> > I've been able improve build times (most dramatically on Windows, 750s
>> > reduced to 350s) by modifying javac to:
>> >
>> > 1. pass ziptime-info=false to the env Map of
>> > jarFsProvider.newFileSystem, which means the classpath scan in the
>> > constructor of ArchiveContainer need only read the ZIP central
>> > directory, rather then reading per-entry Extended Time metadata.
>>
>> I am not familiar with the compiler implementation code, but speaking in
>> context of the ZipFileSystem, it appears that this (undocumented)
>> "ziptime-info" property of the ZIP file system was indeed introduced to
>> help improve the performance of the ZipFileSystem. Setting it to false
>> implies that the lastAccessTime() and the creationTime() returned by the
>> ZipFileAttributes may not be accurate for some entries, since settings
>> this property to false skips reading the per entry creation and access
>> time information for the entries. Would you happen to know if either of
>> these two methods are used in the code path where you are proposing to
>> add "ziptime-info=false"?
>>
>> -Jaikiran
>>
>
> I am not aware of any use of these attributes within javac, nor does it
> seem likely that they would be used.
>
> But the difference in the attributes could be observed by a client of
> JavaFileManager that
> unwraps the underlying Path from a JavaFileObject representing a JAR entry.
>
> ```
> jshell> var compiler = javax.tools.ToolProvider.getSystemJavaCompiler();
> compiler ==> com.sun.tools.javac.api.JavacTool at 4b9e255
>
> jshell> var fileManager = compiler.getStandardFileManager(null, null, null)
> fileManager ==> com.sun.tools.javac.file.JavacFileManager at 7f416310
>
> jshell> var head =
> fileManager.list(javax.tools.StandardLocation.CLASS_PATH, "",
> Set.of(javax.tools.JavaFileObject.Kind.OTHER), true).iterator().next()
> head ==> JarFileObject[/Users/jz/Library/Caches/Coursier/v ...
> e/protobuf/wrappers.proto]
>
> jshell> java.nio.file.Files.readAttributes(fileManager.asPath(head),
> java.nio.file.attribute.BasicFileAttributes.class)
> $11 ==>     name            : /google/protobuf/wrappers.proto
>     creationTime    : Fri Feb 14 21:06:54 AEST 2020
>     lastAccessTime  : Fri Feb 14 21:06:54 AEST 2020
>     lastModifiedTime: Fri Feb 14 21:06:54 AEST 2020
> ...
> ```
>
> A new option could be added to toggle between the existing and proposed
> behaviour if this is a concern.
>
> Regards,
>
> Jason Zaugg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250323/f9324a08/attachment.htm>

From liach at openjdk.org  Mon Mar 24 01:39:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Mar 2025 01:39:14 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <PthJt6awV4YEdSCtkPl82h4qFMuXAlk8264RWpmcY-Q=.d3c6bae4-194b-441b-9f70-4b3f8475ef59@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Looks good. Indeed JavacTask sets Option.MULTIRELEASE explicitly. Might need another zip area contributor to comment on such usages, as there is no usage of this property in the jdk codebase besides one specific test.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24176#pullrequestreview-2708929404

From alanb at openjdk.org  Mon Mar 24 07:50:21 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Mar 2025 07:50:21 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <udF5aeNiU7RHwVreoFV-wqDqiU8xSV6dRnXluwj6b3E=.b3328f96-f508-4bee-b2d6-c0e61595a7ee@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

I think this is okay. I was chatting with Jai and Lance about the undocumented property and I think we've agreed there is merit to the semantics (or close to it) for what is there now, but give it a more suitable name. It could then be documented in the jdk.zipfs's module description.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2747185940

From asotona at openjdk.org  Mon Mar 24 08:24:12 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Mar 2025 08:24:12 GMT
Subject: RFR: 8348928: Check for case label validity are misbehaving when
 binding patterns with unnamed bindings are present
In-Reply-To: <WqHraZlmaTd7IY4RkdgQxxZ72zA2sfUyft3GOEIw1jE=.1266a33a-b849-4a71-827c-9a0b1eac3cdc@github.com>
References: <WqHraZlmaTd7IY4RkdgQxxZ72zA2sfUyft3GOEIw1jE=.1266a33a-b849-4a71-827c-9a0b1eac3cdc@github.com>
Message-ID: <hVRWTEvz5OjQYmsi2d-us1gGMJXgVVkuue_7i17jRCI=.8c065fc0-5170-4c13-be86-89c75954fc1c@github.com>

On Fri, 21 Mar 2025 14:11:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class Exp0 {
>     public static void main(String... args) {
>         Object o = "";
>         record R(int i, String s) {}
> 
>         switch (o) {
>             case Integer _, R(int i, String _) -> {}
>             default -> {}
>         }
>     }
> }
> 
> 
> This compiles OK, but it should. The JLS says:
>> It is a compile-time error for a case label to have more than one case pattern and declare any pattern variables (other than those declared by a guard associated with the case label).
> 
> Some similar cases leads to a javac crash:
> 
> $ cat Exp2.java 
> public class Exp2 {
>     public static void main(String... args) {
>         Object o = "";
>         record R(int i, String s) {}
> 
>         switch (o) {
>             case Integer _:
>             case R(int i, String _):
>                 System.err.println(i);
>                 break;
>             default: break;
>         }
>     }
> }
> 
> $ jdk-24/bin/javac Exp2.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
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.<init>(Items.java:392)
>         at jdk.compiler/com.sun.tools.javac.jvm.Items.makeLocalItem(Items.java:133)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitIdent(Gen.java:2350)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2711)
> ...
> printing javac parameters to: /tmp/javac.20250321_150757.args
> 
> 
> The root cause here is a bug when determining whether or not a given case label contains bindings - the "has-bindings" flag gets cleared when `_` is used. The "has-bindings" flags must remain set despite seeing unnamed binding variables.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24155#pullrequestreview-2709519731

From abimpoudis at openjdk.org  Mon Mar 24 08:51:19 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 24 Mar 2025 08:51:19 GMT
Subject: RFR: 8348928: Check for case label validity are misbehaving when
 binding patterns with unnamed bindings are present
In-Reply-To: <WqHraZlmaTd7IY4RkdgQxxZ72zA2sfUyft3GOEIw1jE=.1266a33a-b849-4a71-827c-9a0b1eac3cdc@github.com>
References: <WqHraZlmaTd7IY4RkdgQxxZ72zA2sfUyft3GOEIw1jE=.1266a33a-b849-4a71-827c-9a0b1eac3cdc@github.com>
Message-ID: <w3NhOuZ7lTiENMKkXIg4kdarpmj7Zg2cAR9nQupgveE=.89addf6e-e9ce-46d1-87af-994c331a3bed@github.com>

On Fri, 21 Mar 2025 14:11:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class Exp0 {
>     public static void main(String... args) {
>         Object o = "";
>         record R(int i, String s) {}
> 
>         switch (o) {
>             case Integer _, R(int i, String _) -> {}
>             default -> {}
>         }
>     }
> }
> 
> 
> This compiles OK, but it should. The JLS says:
>> It is a compile-time error for a case label to have more than one case pattern and declare any pattern variables (other than those declared by a guard associated with the case label).
> 
> Some similar cases leads to a javac crash:
> 
> $ cat Exp2.java 
> public class Exp2 {
>     public static void main(String... args) {
>         Object o = "";
>         record R(int i, String s) {}
> 
>         switch (o) {
>             case Integer _:
>             case R(int i, String _):
>                 System.err.println(i);
>                 break;
>             default: break;
>         }
>     }
> }
> 
> $ jdk-24/bin/javac Exp2.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
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.<init>(Items.java:392)
>         at jdk.compiler/com.sun.tools.javac.jvm.Items.makeLocalItem(Items.java:133)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitIdent(Gen.java:2350)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2711)
> ...
> printing javac parameters to: /tmp/javac.20250321_150757.args
> 
> 
> The root cause here is a bug when determining whether or not a given case label contains bindings - the "has-bindings" flag gets cleared when `_` is used. The "has-bindings" flags must remain set despite seeing unnamed binding variables.

Seems good.

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24155#pullrequestreview-2709587739

From duke at openjdk.org  Mon Mar 24 09:45:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 24 Mar 2025 09:45:57 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v6]
In-Reply-To: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
Message-ID: <R72aZbApmtNdt3RccJ8YB5ZuZ5B9XvGkU4ENdsQ0xrU=.d87d7761-45c1-477c-a758-e294c9cc71eb@github.com>

> 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:

  Adding sanity check that the test directory is empty (since we clean it between tests).

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23699/files
  - new: https://git.openjdk.org/jdk/pull/23699/files/2905c223..0a3613b6

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

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 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 duke at openjdk.org  Mon Mar 24 09:49:09 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 24 Mar 2025 09:49:09 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v7]
In-Reply-To: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
Message-ID: <_O-rObil9n_4DlTZebVgctZ_WQmqqCseQg7ovMk3XfQ=.fc00072d-8c29-454e-9909-4adb56657bc5@github.com>

> 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:

  Remove unused import.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23699/files
  - new: https://git.openjdk.org/jdk/pull/23699/files/0a3613b6..1341c7c7

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

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 jzaugg at openjdk.org  Mon Mar 24 12:31:26 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Mon, 24 Mar 2025 12:31:26 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <udF5aeNiU7RHwVreoFV-wqDqiU8xSV6dRnXluwj6b3E=.b3328f96-f508-4bee-b2d6-c0e61595a7ee@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <udF5aeNiU7RHwVreoFV-wqDqiU8xSV6dRnXluwj6b3E=.b3328f96-f508-4bee-b2d6-c0e61595a7ee@github.com>
Message-ID: <nEfdzsPFZfwbtjmRZ2cOtlvUnPDYuMnSWtTzSeTSQPw=.3bf9fa2d-5cd6-469d-b042-b73d722a6252@github.com>

On Mon, 24 Mar 2025 07:47:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> but give it a more suitable name

I'm assuming this would come in a followup change for the ZipFS maintainers, rather this in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2747962754

From jpai at openjdk.org  Mon Mar 24 13:17:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Mar 2025 13:17:07 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <nEfdzsPFZfwbtjmRZ2cOtlvUnPDYuMnSWtTzSeTSQPw=.3bf9fa2d-5cd6-469d-b042-b73d722a6252@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <udF5aeNiU7RHwVreoFV-wqDqiU8xSV6dRnXluwj6b3E=.b3328f96-f508-4bee-b2d6-c0e61595a7ee@github.com>
 <nEfdzsPFZfwbtjmRZ2cOtlvUnPDYuMnSWtTzSeTSQPw=.3bf9fa2d-5cd6-469d-b042-b73d722a6252@github.com>
Message-ID: <oZHUWA0nYbZFm48BAPUqhJGIAZ1PbF7wPajf66cUnNY=.3e6d3065-09be-4526-9973-731a4ad638da@github.com>

On Mon, 24 Mar 2025 12:28:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> > but give it a more suitable name
> 
> I'm assuming this would come in a followup change for the ZipFS maintainers, rather this in this PR.

Yes, that's correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2748097839

From liach at openjdk.org  Mon Mar 24 14:50:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Mar 2025 14:50:09 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <cD35kXgeQmX10Vstj-fEAiVEyTtHsuVfV3HYtmRmFwY=.4ba66676-c01e-404f-b89f-5b90f00bb940@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Can any zip area developer leave an approval?

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2748389320

From jpai at openjdk.org  Mon Mar 24 15:22:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Mar 2025 15:22:15 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <HU-USUomSIRCmGPE12vdl1B-GjoV71KqYAyBNOpi36Q=.15822777-6f72-4788-b8db-6c694341547c@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

I'm running some tests with this change. I'll approve it once that completes.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2748502690

From lancea at openjdk.org  Mon Mar 24 16:29:15 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 24 Mar 2025 16:29:15 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <48vInEvWJqvK1f9z34L842IFY77vJgF47CZLf2pDmho=.f81f681b-a92f-46de-ae17-f8e75a8e9b8a@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24176#pullrequestreview-2710990255

From jlahoda at openjdk.org  Mon Mar 24 19:23:11 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 24 Mar 2025 19:23:11 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <2PjV5qPpliR71q_2HQRBychDHCFCTM4Pbw4xZDAIb7M=.329d3adf-a82e-47d8-9bd8-aab1ca897c38@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Good catch, thanks! Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2749174291

From jlahoda at openjdk.org  Mon Mar 24 19:23:13 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 24 Mar 2025 19:23:13 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <zb6wSBmuGKWfsdhqSAxmtvlTNtle_B7GMf5jCqvjN_E=.74ec98b6-16e9-409a-9625-3b3b7d575c12@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <zb6wSBmuGKWfsdhqSAxmtvlTNtle_B7GMf5jCqvjN_E=.74ec98b6-16e9-409a-9625-3b3b7d575c12@github.com>
Message-ID: <cy3_CmUdLBnoMVz5aFTuaTAhYGx1bqYzfIO2ZtuJC2E=.9844695a-7d07-4ced-96e1-1c204e8b851c@github.com>

On Sun, 23 Mar 2025 12:41:51 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 564:
> 
>> 562:         public ArchiveContainer(Path archivePath) throws IOException, ProviderNotFoundException {
>> 563:             this.archivePath = archivePath;
>> 564:             if (multiReleaseValue != null && archivePath.toString().endsWith(".jar")) {
> 
> The else branch, which uses `FileSystems.newFileSystem(archivePath, (ClassLoader)null)` rather than  `jarFsProvider.newFileSystem`,  is unchanged in the PR. 
> 
> AFAICT that would only be taken when a client using `JavacFileManager` directly, omitting the `fm.handleOption(Option.MULTIRELEASE, .. )` call, or in a custom scenario with non-JAR archivess.

I wonder if there's some suspicion of a particular problem in the other branch, or other reason to not add the flag there as well. I would expect the default should be to add it to both branches, unless there's a fairly strong reason not to.

There are some more new jar FileSystems created in `Locations`, but those only typically read one file, so probably not that big deal w.r.t. this flag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2010793506

From liach at openjdk.org  Mon Mar 24 20:18:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Mar 2025 20:18:46 GMT
Subject: RFR: 8315447: Invalid Type Annotation attached to a method instead of
 a lambda
Message-ID: <A-sGoN3e5D7pWKnAZm3g8FNup4f_-AKQYaGSkDfgBe0=.5f2ae49c-52f2-4cb4-934e-6fa813866984@github.com>

In `LambdaToMethod`, when a type annotation is attributed to a lambda's synthetic method or the original method, the annotation's position is queried. However, for container annotations, their positions may not yet be up-to-date, and they are wrongly attributed to the outer method.

This bug was discovered because this wrong attribution can bring in an invalid BCI value referring to a lambda method code array that may be out-of-bounds for the outer method. CombinationTargetTest3 had to stay on the old internal proprietary classfile API due to this reason, as the ClassFile API throws an IAE for such a malformed type annotation attribute.

Please review this patch; this is a blocker for the removal of com.sun.tools.classfile from the JDK, which I wish to accomplish when the boot JDK is 24.

Testing: langtools/tools/javac and javap.

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

Commit messages:
 - 8315447: Invalid Type Annotation attached to a method instead of a lambda

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

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

From vromero at openjdk.org  Mon Mar 24 20:48:11 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 24 Mar 2025 20:48:11 GMT
Subject: RFR: 8315447: Invalid Type Annotation attached to a method instead
 of a lambda
In-Reply-To: <A-sGoN3e5D7pWKnAZm3g8FNup4f_-AKQYaGSkDfgBe0=.5f2ae49c-52f2-4cb4-934e-6fa813866984@github.com>
References: <A-sGoN3e5D7pWKnAZm3g8FNup4f_-AKQYaGSkDfgBe0=.5f2ae49c-52f2-4cb4-934e-6fa813866984@github.com>
Message-ID: <3_U5yOFt6fJGMvu5rixErJyeQinRaO8GaElfMNJJU_U=.0eebf384-e488-4963-949c-a3a5b61433d9@github.com>

On Mon, 24 Mar 2025 20:13:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> In `LambdaToMethod`, when a type annotation is attributed to a lambda's synthetic method or the original method, the annotation's position is queried. However, for container annotations, their positions may not yet be up-to-date, and they are wrongly attributed to the outer method.
> 
> This bug was discovered because this wrong attribution can bring in an invalid BCI value referring to a lambda method code array that may be out-of-bounds for the outer method. CombinationTargetTest3 had to stay on the old internal proprietary classfile API due to this reason, as the ClassFile API throws an IAE for such a malformed type annotation attribute.
> 
> Please review this patch; this is a blocker for the removal of com.sun.tools.classfile from the JDK, which I wish to accomplish when the boot JDK is 24.
> 
> Testing: langtools/tools/javac and javap.

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24206#pullrequestreview-2711640379

From liach at openjdk.org  Mon Mar 24 21:39:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Mar 2025 21:39:12 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <Tj4wk7N3NqPan2HiSykzi5RxoalHiKIFb-nDTK0WhE4=.96819023-9915-4b3f-a4bf-9656782fdc92@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

The tier 1-3 tests submitted by jaikiran all pass. This should be good to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2749457134

From jzaugg at openjdk.org  Mon Mar 24 22:36:07 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Mon, 24 Mar 2025 22:36:07 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <2PjV5qPpliR71q_2HQRBychDHCFCTM4Pbw4xZDAIb7M=.329d3adf-a82e-47d8-9bd8-aab1ca897c38@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <2PjV5qPpliR71q_2HQRBychDHCFCTM4Pbw4xZDAIb7M=.329d3adf-a82e-47d8-9bd8-aab1ca897c38@github.com>
Message-ID: <fjXxuXGIvezZ5aoE-a_ex4EQimfGGVQq2IqoWaie1IA=.39eaa16e-f074-4993-b10e-8d6175159951@github.com>

On Mon, 24 Mar 2025 19:20:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.

I tested this change [externally](https://github.com/retronym/jarcache/blob/ba7f5cdd5f7db976a6568855a0d517f52a1404bf/demo/src/test/scala/demo/JarCacheAgentTest.java#L75-L76) with [JFRUnit](https://github.com/moditect/jfrunit). 

If preferred, I could create a `jtreg` test along similar lines. It would use the JFR API directly to capture `jdk.FileRead` events. The test would construct a JAR that previously triggered one read per entry, and assert that after this change, only a single read is needed to initialize a compiler whose classpath includes that JAR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2749547902

From jzaugg at openjdk.org  Mon Mar 24 23:18:07 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Mon, 24 Mar 2025 23:18:07 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <cy3_CmUdLBnoMVz5aFTuaTAhYGx1bqYzfIO2ZtuJC2E=.9844695a-7d07-4ced-96e1-1c204e8b851c@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <zb6wSBmuGKWfsdhqSAxmtvlTNtle_B7GMf5jCqvjN_E=.74ec98b6-16e9-409a-9625-3b3b7d575c12@github.com>
 <cy3_CmUdLBnoMVz5aFTuaTAhYGx1bqYzfIO2ZtuJC2E=.9844695a-7d07-4ced-96e1-1c204e8b851c@github.com>
Message-ID: <PHN-08NaTVu0HKVEEepEdDmYNBifuaIhk09u20IzwEU=.011b8921-c6b2-4446-95aa-ab9f7e2ecacb@github.com>

On Mon, 24 Mar 2025 19:19:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There are some more new jar FileSystems created in Locations, but those only typically read one file, so probably not that big deal w.r.t. this flag.

Agreed. I initially changed those as well but when I realized they only read a single file I reverted.

> I wonder if there's some suspicion of a particular problem in the other branch, 

The `then` branch, which I've modified, was introduced in e652402ed239e171a6f87f5ef88e07d505ad3fe8 (JDK-8149757: Implement Multi-Release JAR aware JavacFileManager for javac). It became necessary to ensure exact usage of `ZipFileSystemProvider` to be able to pass in the `env` map with the `multiRelease` config.

I reviewed the discussion of that change. There was a mention of the introduction of this branch, but it didn't go as far to suggest removal of the `FileSystems.newFileSystem` call, it only justified the addition of the `jarFsProvider.newFileSystem` call.

https://mail.openjdk.org/pipermail/compiler-dev/2016-April/thread.html


> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
> FileSystems.newFileSystem(realPath, env);
> be enough? (Calling an SPI directly from an API client seems 
> suspicious to me.)

If I recall correctly, the NIO2 API design forced this one. The method 
you are referring to does not exist. There is only one that takes a URI, 
and that has very different semantics.  So we had to go with the method 
on the provider, hence the use of getJarFSProvider.


The tests introduced in e652402ed239e171a6f87f5ef88e07d505ad3fe8 don't appear to exercise the else branch.

It appears there are two ways to get there:
  1. Direct, programatic use of the a file manager in which the initialization sequence does not populate `multiReleaseValue`
  2. Use of javac with a `.zip` as a classpath entry (I had to check, but this does work.) Side question -- what is the expected behaviour with a classpath entry with a non-lowercase extension, `.JAR`? It is allowed by `javac` but would not respect the `multi-release` setting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2011047234

From liach at openjdk.org  Tue Mar 25 00:08:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Mar 2025 00:08:07 GMT
Subject: RFR: 8315447: Invalid Type Annotation attached to a method instead
 of a lambda
In-Reply-To: <A-sGoN3e5D7pWKnAZm3g8FNup4f_-AKQYaGSkDfgBe0=.5f2ae49c-52f2-4cb4-934e-6fa813866984@github.com>
References: <A-sGoN3e5D7pWKnAZm3g8FNup4f_-AKQYaGSkDfgBe0=.5f2ae49c-52f2-4cb4-934e-6fa813866984@github.com>
Message-ID: <oTS4RnWrA4xxPJm_qQqOIAb-y4_GALmz9CwX5q5BQpc=.c38fa3fe-ab8d-47b1-8ce7-3ea3bcd771df@github.com>

On Mon, 24 Mar 2025 20:13:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> In `LambdaToMethod`, when a type annotation is attributed to a lambda's synthetic method or the original method, the annotation's position is queried. However, for container annotations, their positions may not yet be up-to-date, and they are wrongly attributed to the outer method.
> 
> This bug was discovered because this wrong attribution can bring in an invalid BCI value referring to a lambda method code array that may be out-of-bounds for the outer method. CombinationTargetTest3 had to stay on the old internal proprietary classfile API due to this reason, as the ClassFile API throws an IAE for such a malformed type annotation attribute.
> 
> Please review this patch; this is a blocker for the removal of com.sun.tools.classfile from the JDK, which I wish to accomplish when the boot JDK is 24.
> 
> Testing: langtools/tools/javac and javap.

Tier 1-3 tests pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/24206#issuecomment-2749689320

From jpai at openjdk.org  Tue Mar 25 01:36:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Mar 2025 01:36:13 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <zLKLsTis00UZQLCqO2lucryXJ5qt4jMXWkIFWdrz-BY=.2c89afde-c31c-47e9-91b8-91340ef3c837@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Hello Jason, I was crafting some JAR files to compose a large classpath and running some compilation tests on a Windows system to see if there's a observable difference with this change. But I see that you have done the necessary testing externally with much more precise checks and those do show the expected improvements with reduced native calls to read. I won't pursue my Windows testing, since what you have is good both from the code change as well as testing point of view. 

> I could create a jtreg test along similar lines. ... The test would construct a JAR that previously triggered one read per entry, and assert that after this change, only a single read is needed to initialize a compiler whose classpath includes that JAR.

I don't think that can be guaranteed/asserted and could lead to an intermittent failing or brittle test.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2749811146

From jpai at openjdk.org  Tue Mar 25 01:40:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Mar 2025 01:40:06 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <GYjUkXgZlT5plvlP2WEoH-TzR4iglEPCP0n6JDbxfQQ=.44f5a9eb-e964-42f5-a54c-8da113a8f886@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Looks good to me. Before integrating, you might want to wait for Jan to have a chance to review and respond to the discussion you have been having about the "else" block and the possibility of introducing a test.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24176#pullrequestreview-2712055581

From vromero at openjdk.org  Tue Mar 25 13:47:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 25 Mar 2025 13:47:14 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v5]
In-Reply-To: <2PZsCA5gssZj-sH1jpoufz_yLScKBFbVQq_JfN96WeM=.10b4ddd7-fdac-4c15-ab21-417c18de89ab@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <2PZsCA5gssZj-sH1jpoufz_yLScKBFbVQq_JfN96WeM=.10b4ddd7-fdac-4c15-ab21-417c18de89ab@github.com>
Message-ID: <gjrDPyVqfqxAkl6CXKQ5J7Rla9ZrIz3Z5J6GQgGhwjg=.f3299812-670a-412f-b604-3eb0decd0778@github.com>

On Fri, 21 Mar 2025 20:45:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
>> 
>> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
>> 
>> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
>> 
>> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce code repetition

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23875#pullrequestreview-2713831719

From acobbs at openjdk.org  Tue Mar 25 13:48:41 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 25 Mar 2025 13:48:41 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none"
Message-ID: <J1PW7hpf9e7P7u6IglvsXe7XDdrfSwFFs9q7hH1Cido=.baa456d2-da5a-452e-8e6f-7421317aabf3@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.

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

Commit messages:
 - Separate "-nowarn" and "-Xlint:none" and restrict the latter to lint warnings only.

Changes: https://git.openjdk.org/jdk/pull/24227/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24227&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352612
  Stats: 48 lines in 10 files changed: 20 ins; 6 del; 22 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  Tue Mar 25 14:27:26 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 25 Mar 2025 14:27:26 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v2]
In-Reply-To: <J1PW7hpf9e7P7u6IglvsXe7XDdrfSwFFs9q7hH1Cido=.baa456d2-da5a-452e-8e6f-7421317aabf3@github.com>
References: <J1PW7hpf9e7P7u6IglvsXe7XDdrfSwFFs9q7hH1Cido=.baa456d2-da5a-452e-8e6f-7421317aabf3@github.com>
Message-ID: <J5IGDU2uA-pWvewHTAaZb4zXgvbrQ46oXalnxBbnFXM=.b078e913-20c8-49ed-958a-49c49c59b878@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:

  Update copyright.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24227/files
  - new: https://git.openjdk.org/jdk/pull/24227/files/8702f04f..5fb4ad30

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 jlahoda at openjdk.org  Tue Mar 25 15:22:21 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 25 Mar 2025 15:22:21 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <PHN-08NaTVu0HKVEEepEdDmYNBifuaIhk09u20IzwEU=.011b8921-c6b2-4446-95aa-ab9f7e2ecacb@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <zb6wSBmuGKWfsdhqSAxmtvlTNtle_B7GMf5jCqvjN_E=.74ec98b6-16e9-409a-9625-3b3b7d575c12@github.com>
 <cy3_CmUdLBnoMVz5aFTuaTAhYGx1bqYzfIO2ZtuJC2E=.9844695a-7d07-4ced-96e1-1c204e8b851c@github.com>
 <PHN-08NaTVu0HKVEEepEdDmYNBifuaIhk09u20IzwEU=.011b8921-c6b2-4446-95aa-ab9f7e2ecacb@github.com>
Message-ID: <sRmdL8rrdJkNk0PbcmutOb5dpwOqPCnyc72JCuDBQKg=.e12fcdad-b3b1-4cb1-9c0c-84dd328267cb@github.com>

On Mon, 24 Mar 2025 23:15:06 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> I wonder if there's some suspicion of a particular problem in the other branch, or other reason to not add the flag there as well. I would expect the default should be to add it to both branches, unless there's a fairly strong reason not to.
>> 
>> There are some more new jar FileSystems created in `Locations`, but those only typically read one file, so probably not that big deal w.r.t. this flag.
>
>> There are some more new jar FileSystems created in Locations, but those only typically read one file, so probably not that big deal w.r.t. this flag.
> 
> Agreed. I initially changed those as well but when I realized they only read a single file I reverted.
> 
>> I wonder if there's some suspicion of a particular problem in the other branch, 
> 
> The `then` branch, which I've modified, was introduced in e652402ed239e171a6f87f5ef88e07d505ad3fe8 (JDK-8149757: Implement Multi-Release JAR aware JavacFileManager for javac). It became necessary to ensure exact usage of `ZipFileSystemProvider` to be able to pass in the `env` map with the `multiRelease` config.
> 
> I reviewed the discussion of that change. There was a mention of the introduction of this branch, but it didn't go as far to suggest removal of the `FileSystems.newFileSystem` call, it only justified the addition of the `jarFsProvider.newFileSystem` call.
> 
> https://mail.openjdk.org/pipermail/compiler-dev/2016-April/thread.html
> 
> 
>> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
>> FileSystems.newFileSystem(realPath, env);
>> be enough? (Calling an SPI directly from an API client seems 
>> suspicious to me.)
> 
> If I recall correctly, the NIO2 API design forced this one. The method 
> you are referring to does not exist. There is only one that takes a URI, 
> and that has very different semantics.  So we had to go with the method 
> on the provider, hence the use of getJarFSProvider.
> 
> 
> The tests introduced in e652402ed239e171a6f87f5ef88e07d505ad3fe8 don't appear to exercise the else branch.
> 
> It appears there are two ways to get there:
>   1. Direct, programatic use of the a file manager in which the initialization sequence does not populate `multiReleaseValue`
>   2. Use of javac with a `.zip` as a classpath entry (I had to check, but this does work.) Side question -- what is the expected behaviour with a classpath entry with a non-lowercase extension, `.JAR`? It is allowed by `javac` but would not respect the `multi-release` setting.

I think that's all true, but I am not sure if it quite explains why not do the same for the same for the else section. There is `FileSystems.newFileSystem(Path path, Map<String,?> env, ClassLoader loader)` since JDK 13, so there shouldn't be a big problem to call that one instead of `FileSystems.newFileSystem(Path path, ClassLoader loader)` (the latter delegates to the former, so there shouldn't be any real change in semantics).

I guess one concern could be that, in theory, this method works for other FS providers/types as well. But, presumably, those would ignore env keys they don't know, and would ignore it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2012355003

From acobbs at openjdk.org  Tue Mar 25 16:42:06 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 25 Mar 2025 16:42:06 GMT
Subject: RFR: 8352612: No way to add back lint categories after "none" [v3]
In-Reply-To: <J1PW7hpf9e7P7u6IglvsXe7XDdrfSwFFs9q7hH1Cido=.baa456d2-da5a-452e-8e6f-7421317aabf3@github.com>
References: <J1PW7hpf9e7P7u6IglvsXe7XDdrfSwFFs9q7hH1Cido=.baa456d2-da5a-452e-8e6f-7421317aabf3@github.com>
Message-ID: <09nss6nEIUcdPdrnrpYVYKaQLIHumCz5AqFfuD0F0fw=.03a95547-bb07-4464-a326-828cc2007e7a@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:

  Correct regression test expected output.

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

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

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 liach at openjdk.org  Tue Mar 25 19:04:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Mar 2025 19:04:16 GMT
Subject: RFR: 8315447: Invalid Type Annotation attached to a method instead
 of a lambda
In-Reply-To: <A-sGoN3e5D7pWKnAZm3g8FNup4f_-AKQYaGSkDfgBe0=.5f2ae49c-52f2-4cb4-934e-6fa813866984@github.com>
References: <A-sGoN3e5D7pWKnAZm3g8FNup4f_-AKQYaGSkDfgBe0=.5f2ae49c-52f2-4cb4-934e-6fa813866984@github.com>
Message-ID: <xfIrmXuMg4eJxWARdZXq6Osj2kGqQDusRVO4VB3svl4=.7a1592ae-6700-474f-92c8-961f794e4de9@github.com>

On Mon, 24 Mar 2025 20:13:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> In `LambdaToMethod`, when a type annotation is attributed to a lambda's synthetic method or the original method, the annotation's position is queried. However, for container annotations, their positions may not yet be up-to-date, and they are wrongly attributed to the outer method.
> 
> This bug was discovered because this wrong attribution can bring in an invalid BCI value referring to a lambda method code array that may be out-of-bounds for the outer method. CombinationTargetTest3 had to stay on the old internal proprietary classfile API due to this reason, as the ClassFile API throws an IAE for such a malformed type annotation attribute.
> 
> Please review this patch; this is a blocker for the removal of com.sun.tools.classfile from the JDK, which I wish to accomplish when the boot JDK is 24.
> 
> Testing: langtools/tools/javac and javap.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24206#issuecomment-2752248926

From liach at openjdk.org  Tue Mar 25 19:04:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Mar 2025 19:04:17 GMT
Subject: Integrated: 8315447: Invalid Type Annotation attached to a method
 instead of a lambda
In-Reply-To: <A-sGoN3e5D7pWKnAZm3g8FNup4f_-AKQYaGSkDfgBe0=.5f2ae49c-52f2-4cb4-934e-6fa813866984@github.com>
References: <A-sGoN3e5D7pWKnAZm3g8FNup4f_-AKQYaGSkDfgBe0=.5f2ae49c-52f2-4cb4-934e-6fa813866984@github.com>
Message-ID: <18kDZsn-LaiANJWPrF0Rz-G1FKLYFA7XYgGvIBAwGCQ=.22574ab1-af23-4d36-b1bd-248e27a816cf@github.com>

On Mon, 24 Mar 2025 20:13:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> In `LambdaToMethod`, when a type annotation is attributed to a lambda's synthetic method or the original method, the annotation's position is queried. However, for container annotations, their positions may not yet be up-to-date, and they are wrongly attributed to the outer method.
> 
> This bug was discovered because this wrong attribution can bring in an invalid BCI value referring to a lambda method code array that may be out-of-bounds for the outer method. CombinationTargetTest3 had to stay on the old internal proprietary classfile API due to this reason, as the ClassFile API throws an IAE for such a malformed type annotation attribute.
> 
> Please review this patch; this is a blocker for the removal of com.sun.tools.classfile from the JDK, which I wish to accomplish when the boot JDK is 24.
> 
> Testing: langtools/tools/javac and javap.

This pull request has now been integrated.

Changeset: f5a0db43
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5a0db43b76ea58f54d87c49d97c7d87ee1b4ba6
Stats:     238 lines in 3 files changed: 89 ins; 138 del; 11 mod

8315447: Invalid Type Annotation attached to a method instead of a lambda

Reviewed-by: vromero

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

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

From liach at openjdk.org  Tue Mar 25 19:04:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Mar 2025 19:04:22 GMT
Subject: RFR: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class [v5]
In-Reply-To: <2PZsCA5gssZj-sH1jpoufz_yLScKBFbVQq_JfN96WeM=.10b4ddd7-fdac-4c15-ab21-417c18de89ab@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
 <2PZsCA5gssZj-sH1jpoufz_yLScKBFbVQq_JfN96WeM=.10b4ddd7-fdac-4c15-ab21-417c18de89ab@github.com>
Message-ID: <1KztmIhvIOJKbDBR7oYjRp1GPMMWXWc8CTciOscNY5w=.fa04610d-d74c-428c-9b3d-ad7abef4b676@github.com>

On Fri, 21 Mar 2025 20:45:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
>> 
>> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
>> 
>> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
>> 
>> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce code repetition

Thanks for the reviews! I will also deliver the release note shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/23875#issuecomment-2752248573

From liach at openjdk.org  Tue Mar 25 19:04:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Mar 2025 19:04:23 GMT
Subject: Integrated: 8164714: Constructor.newInstance creates instance of inner
 class with null outer class
In-Reply-To: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
References: <OuuKgIDT137rw4S5kbF7AdeoDF5vorKWXJBlbHFPRSg=.04304a54-5d2a-438f-83f7-9eb06429a3ab@github.com>
Message-ID: <qOFO4KBG-MvN-ru3jSkWDWT29fDJtuAFbWLUg6-rh64=.0b7b2bc7-201d-47c6-94f6-59373def41c4@github.com>

On Mon, 3 Mar 2025 21:49:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> The Java Language Specification anticipates that inner classes always have non-null enclosing instances. It ensures the non-nullness by enforcing null checks at the use sites that provides immediately enclosing instances to inner class constructors, such as for super invocations, or an `outer.new Inner()` invocation.
> 
> However, the translations do not require a null check in the actual constructor, when the immediately enclosing instance is received through a mandated parameter and stored into a synthetic field or discarded.  As a result, class file constructs, such as core reflection, method handles, or arbitrary class files can pass in `null` for the immediately enclosing instance, and later execution may fail with NPE by chance if any enclosing instance is used.
> 
> This patch proposes to add a null check against the "outer this" in inner class constructors that call a superclass constructor, including when the "outer this" is discarded immediately thereafter (#4966) for consistency. This null check will be emitted regardless of source or target versions. This change is considered an implementation artifact like the synthetic field that captures the enclosing instance; as a result, there is no JLS change.
> 
> The reason for this eager NPE decision is that there is no compatibility of such NPE behaviors - any evolution of the inner classes constructed with null enclosing instances may suddenly start using an enclosing instance and fail with NPE. Therefore, there's no compatibility aspect in such out-of-spec usages of passing `null` as immediately enclosing instance, and this null check can be considered such an evolution.

This pull request has now been integrated.

Changeset: 60544a15
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/60544a15d6bd9fc17f362cdfb95f06e733934b05
Stats:     210 lines in 8 files changed: 175 ins; 1 del; 34 mod

8164714: Constructor.newInstance creates instance of inner class with null outer class

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Wed Mar 26 07:59:56 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Mar 2025 07:59:56 GMT
Subject: RFR: 8352621: MatchException from backwards incompatible change to
 switch expressions
Message-ID: <0AltGW3kEbkk0oV7Sxx72igWQNnW6D3y5ddKNH60HMU=.395dfbf9-1272-42db-bd62-6083f7e13daa@github.com>

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.

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

Commit messages:
 - Removing trailing whitespace.
 - 8352621: MatchException from backwards incompatible change to switch expressions

Changes: https://git.openjdk.org/jdk/pull/24241/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24241&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352621
  Stats: 181 lines in 3 files changed: 178 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24241.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24241/head:pull/24241

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

From abimpoudis at openjdk.org  Wed Mar 26 14:42:23 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 26 Mar 2025 14:42:23 GMT
Subject: RFR: 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: <cuw_gALFAzEuT8p188MdQ3BYU7CshSkszs9sWFDRSMM=.711d1a82-67d9-47fb-bfe0-66fb77a64d9a@github.com>

On Wed, 26 Mar 2025 07:47:19 GMT, Jan Lahoda <jlahoda at openjdk.org> 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.

LGTM!

test/langtools/tools/javac/patterns/NoPrimitivesAsCaseLabelsFor21.java line 72:

> 70: 
> 71:     @Test
> 72:     public void testExhaustiveSealedClasses(Path base) throws Exception {

small fix about the name of the test is needed here

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24241#pullrequestreview-2717504119
PR Review Comment: https://git.openjdk.org/jdk/pull/24241#discussion_r2014329443

From jlahoda at openjdk.org  Wed Mar 26 14:53:12 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Mar 2025 14:53:12 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v7]
In-Reply-To: <_O-rObil9n_4DlTZebVgctZ_WQmqqCseQg7ovMk3XfQ=.fc00072d-8c29-454e-9909-4adb56657bc5@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
 <_O-rObil9n_4DlTZebVgctZ_WQmqqCseQg7ovMk3XfQ=.fc00072d-8c29-454e-9909-4adb56657bc5@github.com>
Message-ID: <4hRy1MC7IN--AEgBMUqmhieqMITs1ZT71BJkJYB19xE=.f39581b5-7b58-4207-a0a9-1a769313daf0@github.com>

On Mon, 24 Mar 2025 09:49:09 GMT, David Beaumont <duke at openjdk.org> 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:
> 
>   Remove unused import.

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23699#pullrequestreview-2717552962

From duke at openjdk.org  Thu Mar 27 12:52:47 2025
From: duke at openjdk.org (Zihao Lin)
Date: Thu, 27 Mar 2025 12:52:47 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class
Message-ID: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>

Fix LambdaExpr02.java runs wrong test class.

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

Commit messages:
 - 8352896: LambdaExpr02.java runs wrong test class

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

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

From shade at openjdk.org  Thu Mar 27 15:58:31 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 27 Mar 2025 15:58:31 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class
In-Reply-To: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
Message-ID: <AJ3X1dCvsU6EFfD7UiV9PRVOKIw492I2y7_n_wZdEUs=.12aaf1de-18ea-4b32-815a-3f00ec7cc721@github.com>

On Thu, 27 Mar 2025 12:48:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

> Fix LambdaExpr02.java runs wrong test class.

Ha! Looks good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24277#pullrequestreview-2722312127

From duke at openjdk.org  Thu Mar 27 16:16:17 2025
From: duke at openjdk.org (duke)
Date: Thu, 27 Mar 2025 16:16:17 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class
In-Reply-To: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
Message-ID: <_IISvwKhr6lkvKePioR9rohba5tFTiATrqJgyN793LY=.263c35ad-2029-4809-bebd-7e593cb8ec76@github.com>

On Thu, 27 Mar 2025 12:48:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

> Fix LambdaExpr02.java runs wrong test class.

@linzihao1999 
Your change (at version 6dd3941e359c897e8dac80091aefe4635c1dd456) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24277#issuecomment-2758616055

From mintern at everlaw.com  Thu Mar 27 18:59:52 2025
From: mintern at everlaw.com (Brandon Mintern)
Date: Thu, 27 Mar 2025 11:59:52 -0700
Subject: Draft JEP: Enhanced Void return
Message-ID: <CAJW1oniH2mSyexTmpQof6LzTEM2GgijT7ViYOG+fzirwconUOQ@mail.gmail.com>

Hi all,

I'm interested in allowing `return null` to be omitted from Void-returning
methods. Apologies if I'm doing this wrong, but I've drafted the following
JEP. I'd love to get feedback and discuss the feasibility of a change like
this.

Thanks!
Brandon

Title: Enhanced Void return
Author: Brandon Mintern
Organization: Everlaw
Created: 2025/03/27
Type: Feature
State: Draft
Exposure: Open
Component: specification / language
Scope: SE
Template: 2.0

Summary
-------

Allow `Void`-returning methods to omit the `return null` statement. Method
implementations can still `return null` if desired, but they can also use a
plain `return` or omit the statement altogether.

Goals
-----

Improve ergonomics when using methods that accept a lambda and optionally
return
a result. Enhance the compiler to:

- Automatically insert `return null` (or convert `return`) in
`Void`-returning
  methods.
- Infer `Void` as the generic return type in method references and lambdas
  without a `return`.

Non-Goals
---------

- `Void`-returning methods are still free to explicitly state `return null`.
- The scope should be limited such that:
    - The compiler can do the heavy lifting, without any JVM changes.
    - No new lambda objects would be constructed implicitly.

Motivation
----------

Lambdas provide powerful abstractions for working with closeable resources
or in
temporary contexts. For example, we can define the following abstraction:

    <R> R withBufferedReader(Path path, BufferedReaderFunction<R> f) {
        try (var reader = Files.newBufferedReader(path)) {
            return f.apply(reader);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }

    @FunctionalInterface
    interface BufferedReaderFunction<R> {
        R apply(BufferedReader reader) throws IOException;
    }

Callers can use this method as follows:

    var firstLine = withBufferedReader(path, reader ->
reader.lines().findFirst());

When a caller doesn't need the return value, though, the caller must
include an
awkward `return null`:

    withBufferedReader(path, reader -> {
        this.header = reader.readLine();
        this.data = reader.lines().toList();
        return null;
    });

These examples used `BufferedReader` for familiarity, but abstractions like
this
are arguably more useful when reading from other persistent data stores
(e.g.,
databases, search indexes) or when writing context-specific code. Using a
completely hypothetical `UserContextHolder`:

    <R> R inUserContext(User user, Supplier<R> supplier) {
        var oldContext = UserContextHolder.getContext();
        UserContextHolder.setUserContext(user);
        try {
            return supplier.get();
        } finally {
            UserContextHolder.setContext(oldContext);
        }
    }

Then we might have system code that looks like the following:

    interface Report {
        User getUser();
        GeneratedReport generate();
    }

    for (var report: pendingReports) {
        save(inUserContext(report.getUser(), report::generate));
    }

    // or:

    interface Job {
        User getUser();
        void execute();
    }

    for (var job : pendingJobs) {
        inUserContext(job.getUser(), () -> {
            job.execute();
            return null;
        });
        // inUserContext(job.getUser(), job::execute) with this proposal
    }

Description
-----------

When a method has a fully instantiated return type of `Void`, all of the
following would be valid:

- `return null`
- `return`
- omitted `return` (implicit `void` return)

`Void`-returning methods can continue using `return null` without warning.
It
should be at least a warning, though, for a single method to mix `return
null`
and any `void`-style return (implicit or explicit).

When a functional interface has a generic return type parameter, lambdas
can use
`void`-style returns, and references to `void`-returning methods can be
used,
where the compiler will infer the return type to be `Void` and logically
insert
the necessary `return null` statements.

As with functional interfaces in general, an instance of one type cannot be
automatically converted to another. That is, a `Runnable` cannot be passed
as a
`Supplier<T>`, inferring `T = Void`. `Runnable::run` could be used instead.

When a method returns a generic type, and when that type is inferred as
`Void`
due to the use of an *enhanced `Void` return*, it would be an error to
assign
the result to a variable. Returning to the `inUserContext` example:

    GeneratedReport result = inUserContext(report.getUser(),
report::generate); // OK

    Void result = inUserContext(job.getUser(), () -> {
        job.execute();
        return null;
    }); // OK: result is null (backwards compatible)

    Void result = inUserContext(job.getUser(), job::execute); // ERROR

    Void result = inUserContext(job.getUser(), () -> job.execute()); //
ERROR

This enhancement would be implemented entirely by the compiler, generating
JVM
bytecode as if `return null` had been used where it's currently needed.

Alternatives
------------

Returning to the `withBufferedReader` example, without this proposal, we can
instead define sibling methods (and types) to avoid the need for `return
null`:

    void withBufferedReader(Path path, BufferedReaderProcedure f) {
        withBufferedReader(path, reader -> {
            f.accept(reader);
            return null;
        });
    }

    interface BufferedReaderProcedure {
        void accept(BufferedReader reader) throws IOException;
    }

    withBufferedReader(path, reader -> {
        this.header = reader.readLine();
        this.data = reader.lines().toList();
    });

This works, sort of, but we quickly find that it doesn't actually work.
Returning to the first example:

    var firstLine = withBufferedReader(path, reader ->
reader.lines().findFirst());

This now fails to compile, reporting "Ambiguous method call." We can work
around
that issue, of course, by standardizing on verb pairs to use in these
scenarios:

    R applyingBufferedReader(...)
    void acceptingBufferedReader(...)

In reality, though, this disambiguation is not the biggest issue. Rather, in
most codebases, it would be hard to justify defining duplicate methods and
types. Many development teams would instead use `return null` statements
where
necessary, avoid the abstraction in cases where `return null` is needed, or
avoid defining the abstraction altogether.

Risks and Assumptions
---------------------

Some codebases may have sibling methods like those described above, where
this
enhancement would cause new "Ambiguous method call." when using the
`void`-returning method. However:

- Already-compiled code would not be affected since there is no JVM change.
- Impacted code would likely benefit from this enhancement, with new
compiler
  errors pointing to duplicate code that can likely be deleted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250327/f4e8e493/attachment-0001.htm>

From mintern at everlaw.com  Thu Mar 27 19:16:18 2025
From: mintern at everlaw.com (Brandon Mintern)
Date: Thu, 27 Mar 2025 12:16:18 -0700
Subject: Draft JEP: Enhanced Void return
In-Reply-To: <CAJW1oniH2mSyexTmpQof6LzTEM2GgijT7ViYOG+fzirwconUOQ@mail.gmail.com>
References: <CAJW1oniH2mSyexTmpQof6LzTEM2GgijT7ViYOG+fzirwconUOQ@mail.gmail.com>
Message-ID: <CAJW1onhzJX6yFnxM94SwpWoMVV1H0a35_1cxQp6B5qNui7ibWw@mail.gmail.com>

I'm sorry. I see that my prior email wraps poorly when rendered in the web
interface. Here's the same email wrapped to 76 characters for better
readability:

Title: Enhanced Void return
Author: Brandon Mintern
Organization: Everlaw
Created: 2025/03/27
Type: Feature
State: Draft
Exposure: Open
Component: specification / language
Scope: SE
Template: 2.0

Summary
-------

Allow `Void`-returning methods to omit the `return null` statement. Method
implementations can still `return null` if desired, but they can also use a
plain `return` or omit the statement altogether.

Goals
-----

Improve ergonomics when using methods that accept a lambda and optionally
return a result. Enhance the compiler to:

- Automatically insert `return null` (or convert `return`) in
  `Void`-returning methods.
- Infer `Void` as the generic return type in method references and lambdas
  without a `return`.

Non-Goals
---------

- `Void`-returning methods are still free to explicitly state `return null`.
- The scope should be limited such that:
    - The compiler can do the heavy lifting, without any JVM changes.
    - No new lambda objects would be constructed implicitly.

Motivation
----------

Lambdas provide powerful abstractions for working with closeable resources
or in temporary contexts. For example, we can define the following
abstraction:

    <R> R withBufferedReader(Path path, BufferedReaderFunction<R> f) {
        try (var reader = Files.newBufferedReader(path)) {
            return f.apply(reader);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }

    @FunctionalInterface
    interface BufferedReaderFunction<R> {
        R apply(BufferedReader reader) throws IOException;
    }

Callers can use this method as follows:

    var firstLine = withBufferedReader(path, r -> r.lines().findFirst());

When a caller doesn't need the return value, though, the caller must include
an awkward `return null`:

    withBufferedReader(path, reader -> {
        this.header = reader.readLine();
        this.data = reader.lines().toList();
        return null;
    });

These examples used `BufferedReader` for familiarity, but abstractions like
this are arguably more useful when reading from other persistent data stores
(e.g., databases, search indexes) or when writing context-specific code.
Using a completely hypothetical `UserContextHolder`:

    <R> R inUserContext(User user, Supplier<R> supplier) {
        var oldContext = UserContextHolder.getContext();
        UserContextHolder.setUserContext(user);
        try {
            return supplier.get();
        } finally {
            UserContextHolder.setContext(oldContext);
        }
    }

Then we might have system code that looks like the following:

    interface Report {
        User getUser();
        GeneratedReport generate();
    }

    for (var report: pendingReports) {
        save(inUserContext(report.getUser(), report::generate));
    }

    // or:

    interface Job {
        User getUser();
        void execute();
    }

    for (var job : pendingJobs) {
        inUserContext(job.getUser(), () -> {
            job.execute();
            return null;
        });
        // inUserContext(job.getUser(), job::execute) with this proposal
    }

Description
-----------

When a method has a fully instantiated return type of `Void`, all of the
following would be valid:

- `return null`
- `return`
- omitted `return` (implicit `void` return)

`Void`-returning methods can continue using `return null` without warning.
It should be at least a warning, though, for a single method to mix `return
null` and any `void`-style return (implicit or explicit).

When a functional interface has a generic return type parameter, lambdas can
use `void`-style returns, and references to `void`-returning methods can be
used, where the compiler will infer the return type to be `Void` and
logically insert the necessary `return null` statements.

As with functional interfaces in general, an instance of one type cannot be
automatically converted to another. That is, a `Runnable` cannot be passed
as a `Supplier<T>`, inferring `T = Void`. `Runnable::run` could be used
instead.

When a method returns a generic type, and when that type is inferred as
`Void` due to the use of an *enhanced `Void` return*, it would be an error
to assign the result to a variable. Returning to the `inUserContext`
example:

    var report = inUserContext(report.getUser(), report::generate); // OK

    Void result = inUserContext(job.getUser(), () -> {
        job.execute();
        return null;
    }); // OK: result is null (backwards compatible)

    Void result = inUserContext(job.getUser(), job::execute); // ERROR

    Void result = inUserContext(job.getUser(), () -> {
        job.execute();
    }); // ERROR

This enhancement would be implemented entirely by the compiler, generating
JVM bytecode as if `return null` had been used where it's currently needed.

Alternatives
------------

Returning to the `withBufferedReader` example, without this proposal, we can
instead define sibling methods (and types) to avoid the need for
`return null`:

    void withBufferedReader(Path path, BufferedReaderProcedure f) {
        withBufferedReader(path, reader -> {
            f.accept(reader);
            return null;
        });
    }

    interface BufferedReaderProcedure {
        void accept(BufferedReader reader) throws IOException;
    }

    withBufferedReader(path, reader -> {
        this.header = reader.readLine();
        this.data = reader.lines().toList();
    });

This works, sort of, but we quickly find that it doesn't actually work.
Returning to the first example:

    var firstLine = withBufferedReader(path, r -> r.lines().findFirst());

This now fails to compile, reporting "Ambiguous method call." We can work
around that issue, of course, by standardizing on verb pairs to use in these
scenarios:

    R applyingBufferedReader(...)
    void acceptingBufferedReader(...)

In reality, though, this disambiguation is not the biggest issue. Rather, in
most codebases, it would be hard to justify defining duplicate methods and
types. Many development teams would instead use `return null` statements
where necessary, avoid the abstraction in cases where `return null` is
needed, or avoid defining the abstraction altogether.

Risks and Assumptions
---------------------

Some codebases may have sibling methods like those described above, where
this enhancement would cause new "Ambiguous method call." when using the
`void`-returning method. However:

- Already-compiled code would not be affected since there is no JVM change.
- Impacted code would likely benefit from this enhancement, with new
  compiler errors pointing to duplicate code that can likely be deleted.


On Thu, Mar 27, 2025 at 11:59?AM Brandon Mintern <mintern at everlaw.com>
wrote:

> Hi all,
>
> I'm interested in allowing `return null` to be omitted from Void-returning
> methods. Apologies if I'm doing this wrong, but I've drafted the following
> JEP. I'd love to get feedback and discuss the feasibility of a change like
> this.
>
> Thanks!
> Brandon
>
> Title: Enhanced Void return
> Author: Brandon Mintern
> Organization: Everlaw
> Created: 2025/03/27
> Type: Feature
> State: Draft
> Exposure: Open
> Component: specification / language
> Scope: SE
> Template: 2.0
>
> Summary
> -------
>
> Allow `Void`-returning methods to omit the `return null` statement. Method
> implementations can still `return null` if desired, but they can also use a
> plain `return` or omit the statement altogether.
>
> Goals
> -----
>
> Improve ergonomics when using methods that accept a lambda and optionally
> return
> a result. Enhance the compiler to:
>
> - Automatically insert `return null` (or convert `return`) in
> `Void`-returning
>   methods.
> - Infer `Void` as the generic return type in method references and lambdas
>   without a `return`.
>
> Non-Goals
> ---------
>
> - `Void`-returning methods are still free to explicitly state `return
> null`.
> - The scope should be limited such that:
>     - The compiler can do the heavy lifting, without any JVM changes.
>     - No new lambda objects would be constructed implicitly.
>
> Motivation
> ----------
>
> Lambdas provide powerful abstractions for working with closeable resources
> or in
> temporary contexts. For example, we can define the following abstraction:
>
>     <R> R withBufferedReader(Path path, BufferedReaderFunction<R> f) {
>         try (var reader = Files.newBufferedReader(path)) {
>             return f.apply(reader);
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>     }
>
>     @FunctionalInterface
>     interface BufferedReaderFunction<R> {
>         R apply(BufferedReader reader) throws IOException;
>     }
>
> Callers can use this method as follows:
>
>     var firstLine = withBufferedReader(path, reader ->
> reader.lines().findFirst());
>
> When a caller doesn't need the return value, though, the caller must
> include an
> awkward `return null`:
>
>     withBufferedReader(path, reader -> {
>         this.header = reader.readLine();
>         this.data = reader.lines().toList();
>         return null;
>     });
>
> These examples used `BufferedReader` for familiarity, but abstractions
> like this
> are arguably more useful when reading from other persistent data stores
> (e.g.,
> databases, search indexes) or when writing context-specific code. Using a
> completely hypothetical `UserContextHolder`:
>
>     <R> R inUserContext(User user, Supplier<R> supplier) {
>         var oldContext = UserContextHolder.getContext();
>         UserContextHolder.setUserContext(user);
>         try {
>             return supplier.get();
>         } finally {
>             UserContextHolder.setContext(oldContext);
>         }
>     }
>
> Then we might have system code that looks like the following:
>
>     interface Report {
>         User getUser();
>         GeneratedReport generate();
>     }
>
>     for (var report: pendingReports) {
>         save(inUserContext(report.getUser(), report::generate));
>     }
>
>     // or:
>
>     interface Job {
>         User getUser();
>         void execute();
>     }
>
>     for (var job : pendingJobs) {
>         inUserContext(job.getUser(), () -> {
>             job.execute();
>             return null;
>         });
>         // inUserContext(job.getUser(), job::execute) with this proposal
>     }
>
> Description
> -----------
>
> When a method has a fully instantiated return type of `Void`, all of the
> following would be valid:
>
> - `return null`
> - `return`
> - omitted `return` (implicit `void` return)
>
> `Void`-returning methods can continue using `return null` without warning.
> It
> should be at least a warning, though, for a single method to mix `return
> null`
> and any `void`-style return (implicit or explicit).
>
> When a functional interface has a generic return type parameter, lambdas
> can use
> `void`-style returns, and references to `void`-returning methods can be
> used,
> where the compiler will infer the return type to be `Void` and logically
> insert
> the necessary `return null` statements.
>
> As with functional interfaces in general, an instance of one type cannot be
> automatically converted to another. That is, a `Runnable` cannot be passed
> as a
> `Supplier<T>`, inferring `T = Void`. `Runnable::run` could be used instead.
>
> When a method returns a generic type, and when that type is inferred as
> `Void`
> due to the use of an *enhanced `Void` return*, it would be an error to
> assign
> the result to a variable. Returning to the `inUserContext` example:
>
>     GeneratedReport result = inUserContext(report.getUser(),
> report::generate); // OK
>
>     Void result = inUserContext(job.getUser(), () -> {
>         job.execute();
>         return null;
>     }); // OK: result is null (backwards compatible)
>
>     Void result = inUserContext(job.getUser(), job::execute); // ERROR
>
>     Void result = inUserContext(job.getUser(), () -> job.execute()); //
> ERROR
>
> This enhancement would be implemented entirely by the compiler, generating
> JVM
> bytecode as if `return null` had been used where it's currently needed.
>
> Alternatives
> ------------
>
> Returning to the `withBufferedReader` example, without this proposal, we
> can
> instead define sibling methods (and types) to avoid the need for `return
> null`:
>
>     void withBufferedReader(Path path, BufferedReaderProcedure f) {
>         withBufferedReader(path, reader -> {
>             f.accept(reader);
>             return null;
>         });
>     }
>
>     interface BufferedReaderProcedure {
>         void accept(BufferedReader reader) throws IOException;
>     }
>
>     withBufferedReader(path, reader -> {
>         this.header = reader.readLine();
>         this.data = reader.lines().toList();
>     });
>
> This works, sort of, but we quickly find that it doesn't actually work.
> Returning to the first example:
>
>     var firstLine = withBufferedReader(path, reader ->
> reader.lines().findFirst());
>
> This now fails to compile, reporting "Ambiguous method call." We can work
> around
> that issue, of course, by standardizing on verb pairs to use in these
> scenarios:
>
>     R applyingBufferedReader(...)
>     void acceptingBufferedReader(...)
>
> In reality, though, this disambiguation is not the biggest issue. Rather,
> in
> most codebases, it would be hard to justify defining duplicate methods and
> types. Many development teams would instead use `return null` statements
> where
> necessary, avoid the abstraction in cases where `return null` is needed, or
> avoid defining the abstraction altogether.
>
> Risks and Assumptions
> ---------------------
>
> Some codebases may have sibling methods like those described above, where
> this
> enhancement would cause new "Ambiguous method call." when using the
> `void`-returning method. However:
>
> - Already-compiled code would not be affected since there is no JVM change.
> - Impacted code would likely benefit from this enhancement, with new
> compiler
>   errors pointing to duplicate code that can likely be deleted.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250327/acc2f4d0/attachment-0001.htm>

From stephan.herrmann at berlin.de  Thu Mar 27 20:22:13 2025
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Thu, 27 Mar 2025 21:22:13 +0100
Subject: Draft JEP: Enhanced Void return
In-Reply-To: <mailman.5978.1743103019.109.compiler-dev@openjdk.org>
References: <mailman.5978.1743103019.109.compiler-dev@openjdk.org>
Message-ID: <18ef2424-b6d3-477a-b70a-aa9b83b4d325@berlin.de>

How would this interact with definitions void-compatible / value-compatible in 
JLS ?15.27.2.?

It seems all lambdas formerly classified as void-compatible would need to be 
re-classified as "potentially value-compatible" with an elided "return null;". 
This could entail a hole new can of worms for resolution / type inference.

BR
Stephan

> Date: Thu, 27 Mar 2025 12:16:18 -0700
> From: Brandon Mintern <mintern at everlaw.com>
> To: compiler-dev at openjdk.org
> Subject: Re: Draft JEP: Enhanced Void return
> Message-ID:
> 	<CAJW1onhzJX6yFnxM94SwpWoMVV1H0a35_1cxQp6B5qNui7ibWw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> I'm sorry. I see that my prior email wraps poorly when rendered in the web
> interface. Here's the same email wrapped to 76 characters for better
> readability:
> 
> Title: Enhanced Void return
> Author: Brandon Mintern
> Organization: Everlaw
> Created: 2025/03/27
> Type: Feature
> State: Draft
> Exposure: Open
> Component: specification / language
> Scope: SE
> Template: 2.0
> 
> Summary
> -------
> 
> Allow `Void`-returning methods to omit the `return null` statement. Method
> implementations can still `return null` if desired, but they can also use a
> plain `return` or omit the statement altogether.
> 
> Goals
> -----
> 
> Improve ergonomics when using methods that accept a lambda and optionally
> return a result. Enhance the compiler to:
> 
> - Automatically insert `return null` (or convert `return`) in
>    `Void`-returning methods.
> - Infer `Void` as the generic return type in method references and lambdas
>    without a `return`.
> 
> Non-Goals
> ---------
> 
> - `Void`-returning methods are still free to explicitly state `return null`.
> - The scope should be limited such that:
>      - The compiler can do the heavy lifting, without any JVM changes.
>      - No new lambda objects would be constructed implicitly.
> 
> Motivation
> ----------
> 
> Lambdas provide powerful abstractions for working with closeable resources
> or in temporary contexts. For example, we can define the following
> abstraction:
> 
>      <R> R withBufferedReader(Path path, BufferedReaderFunction<R> f) {
>          try (var reader = Files.newBufferedReader(path)) {
>              return f.apply(reader);
>          } catch (IOException e) {
>              throw new UncheckedIOException(e);
>          }
>      }
> 
>      @FunctionalInterface
>      interface BufferedReaderFunction<R> {
>          R apply(BufferedReader reader) throws IOException;
>      }
> 
> Callers can use this method as follows:
> 
>      var firstLine = withBufferedReader(path, r -> r.lines().findFirst());
> 
> When a caller doesn't need the return value, though, the caller must include
> an awkward `return null`:
> 
>      withBufferedReader(path, reader -> {
>          this.header = reader.readLine();
>          this.data = reader.lines().toList();
>          return null;
>      });
> 
> These examples used `BufferedReader` for familiarity, but abstractions like
> this are arguably more useful when reading from other persistent data stores
> (e.g., databases, search indexes) or when writing context-specific code.
> Using a completely hypothetical `UserContextHolder`:
> 
>      <R> R inUserContext(User user, Supplier<R> supplier) {
>          var oldContext = UserContextHolder.getContext();
>          UserContextHolder.setUserContext(user);
>          try {
>              return supplier.get();
>          } finally {
>              UserContextHolder.setContext(oldContext);
>          }
>      }
> 
> Then we might have system code that looks like the following:
> 
>      interface Report {
>          User getUser();
>          GeneratedReport generate();
>      }
> 
>      for (var report: pendingReports) {
>          save(inUserContext(report.getUser(), report::generate));
>      }
> 
>      // or:
> 
>      interface Job {
>          User getUser();
>          void execute();
>      }
> 
>      for (var job : pendingJobs) {
>          inUserContext(job.getUser(), () -> {
>              job.execute();
>              return null;
>          });
>          // inUserContext(job.getUser(), job::execute) with this proposal
>      }
> 
> Description
> -----------
> 
> When a method has a fully instantiated return type of `Void`, all of the
> following would be valid:
> 
> - `return null`
> - `return`
> - omitted `return` (implicit `void` return)
> 
> `Void`-returning methods can continue using `return null` without warning.
> It should be at least a warning, though, for a single method to mix `return
> null` and any `void`-style return (implicit or explicit).
> 
> When a functional interface has a generic return type parameter, lambdas can
> use `void`-style returns, and references to `void`-returning methods can be
> used, where the compiler will infer the return type to be `Void` and
> logically insert the necessary `return null` statements.
> 
> As with functional interfaces in general, an instance of one type cannot be
> automatically converted to another. That is, a `Runnable` cannot be passed
> as a `Supplier<T>`, inferring `T = Void`. `Runnable::run` could be used
> instead.
> 
> When a method returns a generic type, and when that type is inferred as
> `Void` due to the use of an *enhanced `Void` return*, it would be an error
> to assign the result to a variable. Returning to the `inUserContext`
> example:
> 
>      var report = inUserContext(report.getUser(), report::generate); // OK
> 
>      Void result = inUserContext(job.getUser(), () -> {
>          job.execute();
>          return null;
>      }); // OK: result is null (backwards compatible)
> 
>      Void result = inUserContext(job.getUser(), job::execute); // ERROR
> 
>      Void result = inUserContext(job.getUser(), () -> {
>          job.execute();
>      }); // ERROR
> 
> This enhancement would be implemented entirely by the compiler, generating
> JVM bytecode as if `return null` had been used where it's currently needed.
> 
> Alternatives
> ------------
> 
> Returning to the `withBufferedReader` example, without this proposal, we can
> instead define sibling methods (and types) to avoid the need for
> `return null`:
> 
>      void withBufferedReader(Path path, BufferedReaderProcedure f) {
>          withBufferedReader(path, reader -> {
>              f.accept(reader);
>              return null;
>          });
>      }
> 
>      interface BufferedReaderProcedure {
>          void accept(BufferedReader reader) throws IOException;
>      }
> 
>      withBufferedReader(path, reader -> {
>          this.header = reader.readLine();
>          this.data = reader.lines().toList();
>      });
> 
> This works, sort of, but we quickly find that it doesn't actually work.
> Returning to the first example:
> 
>      var firstLine = withBufferedReader(path, r -> r.lines().findFirst());
> 
> This now fails to compile, reporting "Ambiguous method call." We can work
> around that issue, of course, by standardizing on verb pairs to use in these
> scenarios:
> 
>      R applyingBufferedReader(...)
>      void acceptingBufferedReader(...)
> 
> In reality, though, this disambiguation is not the biggest issue. Rather, in
> most codebases, it would be hard to justify defining duplicate methods and
> types. Many development teams would instead use `return null` statements
> where necessary, avoid the abstraction in cases where `return null` is
> needed, or avoid defining the abstraction altogether.
> 
> Risks and Assumptions
> ---------------------
> 
> Some codebases may have sibling methods like those described above, where
> this enhancement would cause new "Ambiguous method call." when using the
> `void`-returning method. However:
> 
> - Already-compiled code would not be affected since there is no JVM change.
> - Impacted code would likely benefit from this enhancement, with new
>    compiler errors pointing to duplicate code that can likely be deleted.
> 
> 

From liach at openjdk.org  Thu Mar 27 22:28:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Mar 2025 22:28:17 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v10]
In-Reply-To: <yatp27I090GzJLGMIFrbF9o55VB47s717V6aqCnyLco=.7dc669bb-d90f-49b8-bfc8-70190da39620@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <yatp27I090GzJLGMIFrbF9o55VB47s717V6aqCnyLco=.7dc669bb-d90f-49b8-bfc8-70190da39620@github.com>
Message-ID: <Yv-1t606e_032NaFufWg3SgxYSDh75-52U0ajSX4K9g=.8f9c6cee-49bf-4bc2-8da8-f9012e4bb3f8@github.com>

On Wed, 5 Mar 2025 15:14:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
>> 
>> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
>> 
>> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
>> 
>> Here are some actions:
>> 1. Add section for hierarchy overview for both Type and AnnotatedType
>> 2. Specify the underlying type for different AnnotatedType subinterfaces
>> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
>> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
>> 5. Minor improvements to `ParameterizedType::getRawType`
>> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
>> 
>> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Links

Keep alive... ?

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

PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2759666276

From liach at openjdk.org  Thu Mar 27 22:35:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Mar 2025 22:35:07 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class
In-Reply-To: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
Message-ID: <wSYH56hnLPFk_Xs38qNXG5j2_2utfzEo7TlDWLnL-pU=.ea60be23-b867-442d-bd7e-47fc4017ad20@github.com>

On Thu, 27 Mar 2025 12:48:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

> Fix LambdaExpr02.java runs wrong test class.

Should we just drop `main Xxx` as this is automatically added by jtreg?

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

PR Review: https://git.openjdk.org/jdk/pull/24277#pullrequestreview-2723603844

From jzaugg at openjdk.org  Thu Mar 27 23:55:11 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Thu, 27 Mar 2025 23:55:11 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <sRmdL8rrdJkNk0PbcmutOb5dpwOqPCnyc72JCuDBQKg=.e12fcdad-b3b1-4cb1-9c0c-84dd328267cb@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <zb6wSBmuGKWfsdhqSAxmtvlTNtle_B7GMf5jCqvjN_E=.74ec98b6-16e9-409a-9625-3b3b7d575c12@github.com>
 <cy3_CmUdLBnoMVz5aFTuaTAhYGx1bqYzfIO2ZtuJC2E=.9844695a-7d07-4ced-96e1-1c204e8b851c@github.com>
 <PHN-08NaTVu0HKVEEepEdDmYNBifuaIhk09u20IzwEU=.011b8921-c6b2-4446-95aa-ab9f7e2ecacb@github.com>
 <sRmdL8rrdJkNk0PbcmutOb5dpwOqPCnyc72JCuDBQKg=.e12fcdad-b3b1-4cb1-9c0c-84dd328267cb@github.com>
Message-ID: <PPUgNOh1o6iv4lWP5auxjGX3QSqaqQJ2A9Hz0azYwFI=.f28871be-bef0-42ad-85bf-10f77dfa218a@github.com>

On Tue, 25 Mar 2025 15:19:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> There are some more new jar FileSystems created in Locations, but those only typically read one file, so probably not that big deal w.r.t. this flag.
>> 
>> Agreed. I initially changed those as well but when I realized they only read a single file I reverted.
>> 
>>> I wonder if there's some suspicion of a particular problem in the other branch, 
>> 
>> The `then` branch, which I've modified, was introduced in e652402ed239e171a6f87f5ef88e07d505ad3fe8 (JDK-8149757: Implement Multi-Release JAR aware JavacFileManager for javac). It became necessary to ensure exact usage of `ZipFileSystemProvider` to be able to pass in the `env` map with the `multiRelease` config.
>> 
>> I reviewed the discussion of that change. There was a mention of the introduction of this branch, but it didn't go as far to suggest removal of the `FileSystems.newFileSystem` call, it only justified the addition of the `jarFsProvider.newFileSystem` call.
>> 
>> https://mail.openjdk.org/pipermail/compiler-dev/2016-April/thread.html
>> 
>> 
>>> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
>>> FileSystems.newFileSystem(realPath, env);
>>> be enough? (Calling an SPI directly from an API client seems 
>>> suspicious to me.)
>> 
>> If I recall correctly, the NIO2 API design forced this one. The method 
>> you are referring to does not exist. There is only one that takes a URI, 
>> and that has very different semantics.  So we had to go with the method 
>> on the provider, hence the use of getJarFSProvider.
>> 
>> 
>> The tests introduced in e652402ed239e171a6f87f5ef88e07d505ad3fe8 don't appear to exercise the else branch.
>> 
>> It appears there are two ways to get there:
>>   1. Direct, programatic use of the a file manager in which the initialization sequence does not populate `multiReleaseValue`
>>   2. Use of javac with a `.zip` as a classpath entry (I had to check, but this does work.) Side question -- what is the expected behaviour with a classpath entry with a non-lowercase extension, `.JAR`? It is allowed by `javac` but would not respect the `multi-release` setting.
>
> I think that's all true, but I am not sure if it quite explains why not do the same for the same for the else section. There is `FileSystems.newFileSystem(Path path, Map<String,?> env, ClassLoader loader)` since JDK 13, so there shouldn't be a big problem to call that one instead of `FileSystems.newFileSystem(Path path, ClassLoader loader)` (the latter delegates to the former, so there shouldn't be any real change in semantics).
> 
> I guess one concern could be that, in theory, this method works for other FS providers/types as well. But, presumably, those would ignore env keys they don't know, and would ignore it.

Thanks for pointing that out, I was not aware of the addition of that overload.

I agree that passing `zipinfo-time` to an unknown provider is likely quite safe.

There is an argument that `CacheInfo.jarFsProvider` is no longer necessary, AFAICT it was introduced to work around the absent overload.  I would suggest this matter be considered independently.

Noting that I found `jarFsProvider` to be a useful extension point (albeit in undocumented API) for injecting performance improvements into existing `javac` versions (both the `zipinfo-time` change, and further changes to defer the `close` of `ZipFileSystem` over JARs known to be immutable).

A GitHub code search reveals this idea is also pursued in [Eclipse JDT](https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/blob/e3fd9a0c74374951d4c91663a6fd52f16f6ee9c6/org.eclipse.jdt.core.javac/src/org/eclipse/jdt/internal/javac/CachingJarsJavaFileManager.java#L45). So any change to `getJarFsProvider`.

Back to implementing your suggestion, here's how what I have prepared.  If you like this I'll add to the PR.  Maybe the comment would be better as a TODO link to a followup issue if you think that's worthwhile? 


            Map<String,String> env = new HashMap<>();
            // ignores timestamps not stored in ZIP central directory, reducing I/O
            // This key is handled by ZipFileSystem only.
            env.put("zipinfo-time", "false");

            if (multiReleaseValue != null && archivePath.toString().endsWith(".jar")) {
                env.put("multi-release", multiReleaseValue);
                FileSystemProvider jarFSProvider = fsInfo.getJarFSProvider();
                Assert.checkNonNull(jarFSProvider, "should have been caught before!");
                try {
                    this.fileSystem = jarFSProvider.newFileSystem(archivePath, env);
                } catch (ZipException ze) {
                    throw new IOException("ZipException opening "" + archivePath.getFileName() + "": " + ze.getMessage(), ze);
                }
            } else {
                // Less common case. Possible if the file manager was not initialized in JavacTask,
                // OR if non "*.jar" files are on the classpath. At the time of writing, both `javac -cp a.zip`
                // and `javac -cp x.JAR` file execute this branch.
                this.fileSystem = FileSystems.newFileSystem(archivePath, env, (ClassLoader)null);
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24176#discussion_r2017732584

From nbenalla at openjdk.org  Fri Mar 28 01:59:26 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 28 Mar 2025 01:59:26 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v3]
In-Reply-To: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
Message-ID: <0bqUaKnM69G9yJBLqrCdHjhLajH2Xt3sSYzpikjypsk=.12a13864-b736-4a90-b201-55fe4be2b14f@github.com>

> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
> 
> TIA.

Nizar Benalla 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 nine additional commits since the last revision:

 - feedback: improve api note to convey more context
 - Merge branch 'master' into elements-api-note
 - whitespace
 - Update according to review comments.
 - Merge remote-tracking branch 'upstream/master' into elements-api-note
 - Respond to feedback around the wording.
 - Respond to feedback. Using Jan's comment to not imply particular requirement on the implementation.
 - (C) 2025
 - Initial commit obtained from a cherry pick/squash of a now superseded PR.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22920/files
  - new: https://git.openjdk.org/jdk/pull/22920/files/54d6890c..e21de7d4

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

  Stats: 157736 lines in 4072 files changed: 79829 ins; 49630 del; 28277 mod
  Patch: https://git.openjdk.org/jdk/pull/22920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22920/head:pull/22920

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

From nbenalla at openjdk.org  Fri Mar 28 02:02:22 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 28 Mar 2025 02:02:22 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v2]
In-Reply-To: <RfPuVogOZlNBKvqkh1J2ik2bLNC-yT-3XIh3uqKo8cc=.00cccfcc-ec2f-4a58-b21c-d7dda3184b1d@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <VYKBD8I4cuuoEYhdtcEfCo6L_-DMGKCKSdXVKYZtTyU=.d3cfa7e6-ef3f-4e05-abb4-99d133308d91@github.com>
 <RfPuVogOZlNBKvqkh1J2ik2bLNC-yT-3XIh3uqKo8cc=.00cccfcc-ec2f-4a58-b21c-d7dda3184b1d@github.com>
Message-ID: <sG5Ey7gQFkcmQFBAjdt1gS-f2GmiJubrCEfk-h1pzZM=.dac0dede-720b-4acc-b54b-47a5eadcc2c0@github.com>

On Tue, 4 Mar 2025 03:49:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Nizar Benalla 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 seven additional commits since the last revision:
>> 
>>  - whitespace
>>  - Update according to review comments.
>>  - Merge remote-tracking branch 'upstream/master' into elements-api-note
>>  - Respond to feedback around the wording.
>>  - Respond to feedback. Using Jan's comment to not imply particular requirement on the implementation.
>>  - (C) 2025
>>  - Initial commit obtained from a cherry pick/squash of a now superseded PR.
>
> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 784:
> 
>> 782:      * return types, and method modifiers specified in JLS {@jls 8.4.8.1} and {@jls 8.4.8.3},
>> 783:      * although implementations of this method are allowed to implement these additional checks.
>> 784:      *
> 
> I don't think the current wording conveys enough context for the reader. I suggest a structure like:
> 
> apiNote
> This method must examines X, Y, and Z in determining whether one method overrides another. In addition, an implementation may have a stricter checking including  at properties A, B, and C as described in JLS ..."
> 
> HTH

Updated in [e21de7d](https://github.com/openjdk/jdk/pull/22920/commits/e21de7d42aa34994b64507660cbd368b50daedd6) -- Sorry for the delay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r2017806135

From duke at openjdk.org  Fri Mar 28 05:42:26 2025
From: duke at openjdk.org (Zihao Lin)
Date: Fri, 28 Mar 2025 05:42:26 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class
In-Reply-To: <wSYH56hnLPFk_Xs38qNXG5j2_2utfzEo7TlDWLnL-pU=.ea60be23-b867-442d-bd7e-47fc4017ad20@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
 <wSYH56hnLPFk_Xs38qNXG5j2_2utfzEo7TlDWLnL-pU=.ea60be23-b867-442d-bd7e-47fc4017ad20@github.com>
Message-ID: <T2i92LOlWQ06A7PxFjpYN8_VgVSZOexwooh9ohYQZVI=.afe873f4-d9a7-4238-b45d-e7b8ab7c4cd9@github.com>

On Thu, 27 Mar 2025 22:32:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> Should we just drop `main Xxx` as this is automatically added by jtreg?

That make sense. Just drop the `@run main` only if test have customize action.

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

PR Comment: https://git.openjdk.org/jdk/pull/24277#issuecomment-2760244424

From duke at openjdk.org  Fri Mar 28 07:25:48 2025
From: duke at openjdk.org (Zihao Lin)
Date: Fri, 28 Mar 2025 07:25:48 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class [v2]
In-Reply-To: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
Message-ID: <pOKphWyAmZVlDXQvIkRE6iQLILSZXj2sPPMguICA5Uc=.9d83d6b9-ba52-4144-93f8-6e3224959d3e@github.com>

> Fix LambdaExpr02.java runs wrong test class.

Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:

  Use default @run main

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24277/files
  - new: https://git.openjdk.org/jdk/pull/24277/files/6dd3941e..5c7cc21d

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

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

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

From mistria at redhat.com  Fri Mar 28 08:46:13 2025
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 28 Mar 2025 09:46:13 +0100
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <PPUgNOh1o6iv4lWP5auxjGX3QSqaqQJ2A9Hz0azYwFI=.f28871be-bef0-42ad-85bf-10f77dfa218a@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <zb6wSBmuGKWfsdhqSAxmtvlTNtle_B7GMf5jCqvjN_E=.74ec98b6-16e9-409a-9625-3b3b7d575c12@github.com>
 <cy3_CmUdLBnoMVz5aFTuaTAhYGx1bqYzfIO2ZtuJC2E=.9844695a-7d07-4ced-96e1-1c204e8b851c@github.com>
 <PHN-08NaTVu0HKVEEepEdDmYNBifuaIhk09u20IzwEU=.011b8921-c6b2-4446-95aa-ab9f7e2ecacb@github.com>
 <sRmdL8rrdJkNk0PbcmutOb5dpwOqPCnyc72JCuDBQKg=.e12fcdad-b3b1-4cb1-9c0c-84dd328267cb@github.com>
 <PPUgNOh1o6iv4lWP5auxjGX3QSqaqQJ2A9Hz0azYwFI=.f28871be-bef0-42ad-85bf-10f77dfa218a@github.com>
Message-ID: <CAFr6BZSU7YcAOZqvj8gw-p8C5h-w904YiYOsp6gGmPpN_UzkzQ@mail.gmail.com>

Hello,

On Fri, Mar 28, 2025 at 12:56?AM Jason Zaugg <jzaugg at openjdk.org> wrote:

> A GitHub code search reveals this idea is also pursued in [Eclipse JDT](
> https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/blob/e3fd9a0c74374951d4c91663a6fd52f16f6ee9c6/org.eclipse.jdt.core.javac/src/org/eclipse/jdt/internal/javac/CachingJarsJavaFileManager.java#L45).
> So any change to `getJarFsProvider`.
>

I've been following that thread as I'm always looking for ideas to improve
the performance of the Javac integration in JDT mentioned below. Thanks for
the discussion!
The general and not-new idea is that Javac is currently optimized for a
single run from CLI, by integration in Eclipse IDE/JDT, we want to make it
a long-living framework (so do all IDEs). So we do have to implement
several caches here and there to not spend too much CPU repeating
constantly the same tasks. Loading Jars (FileManager/FileSystem) has been
by far the most important thing for which to implement some caching. We
currently cache the FileSystems and got good results for it. But as the
discussion mention, we might also consider caching the FileObject and some
of it's commonly requested values, to save some more reading of the
streams. I actually believe it's the strategy used by Netbeans.

But ideally, we'd even go further and allow caching the Symbols from the
jars and just reuse them. They are currently always recreated by
ClassReader re-reading the zips and this isn't a cheap operation... I
believe some ClassReaderWithSymbolCache would make the biggest difference
now (basically storing a trimmed version for the symbols it has loaded, and
just copying the relevant info from these symbols it has already loaded to
further requested symbols instead of reading in the jar again); and such a
cache would probably make all lower-level optimization that we have in
place useless as the underlying filesystems used by the symbols would
remain across requests (we just have to take care of not closing them!)...
I wish to investigate that in a near-ish future. I will try to report
whether this has proven to be a good idea or not then.

Anyway, this is becoming a much divergent story from the initial
discussion, so I'll just mention here that if one uses some sufficient
caching strategy, this `zipinfo-time` tweak becomes much less critical
(since the related operations happen only once per jar, which easily
becomes neglect-able over re-reading zips several times for no new reason).

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250328/5b2c154b/attachment.htm>

From alanb at openjdk.org  Fri Mar 28 09:05:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Mar 2025 09:05:14 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <ao1t6_A7LfFjZTES2LKqjOo3BeaAUI3fwrf0UGTeyH8=.5492c0b0-317b-4071-b716-41edd8d08717@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

> I agree that passing zipinfo-time to an unknown provider is likely quite safe.

Right, although it would better to only specify this configuration property when creating a zip file system. The original motivation for this configuration property was javac so I was surprised it wasn't using it already. Now that it is being looked at again I think we will need to come up with a better name for it and also review the semantics and decide if skipping the  extended timestamp fields is okay or whether all timestamps should just report the timestamp of the zip file itself. That's not for this PR of course.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2760610843

From jpai at openjdk.org  Fri Mar 28 09:25:21 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Mar 2025 09:25:21 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <ao1t6_A7LfFjZTES2LKqjOo3BeaAUI3fwrf0UGTeyH8=.5492c0b0-317b-4071-b716-41edd8d08717@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <ao1t6_A7LfFjZTES2LKqjOo3BeaAUI3fwrf0UGTeyH8=.5492c0b0-317b-4071-b716-41edd8d08717@github.com>
Message-ID: <KBgAxQIB68QXDEvIQLSbYB5UTfC29SYl_kKP0Nys6ns=.7e019153-a3a8-4519-ad94-516e528e44c7@github.com>

On Fri, 28 Mar 2025 09:02:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Now that it is being looked at again I think we will need to come up with a better name for it and also review the semantics and decide if skipping the extended timestamp fields is okay or whether all timestamps should just report the timestamp of the zip file itself. That's not for this PR of course.

I've created https://bugs.openjdk.org/browse/JDK-8353167 to track that part.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2760674186

From shade at openjdk.org  Fri Mar 28 12:10:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Mar 2025 12:10:16 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class [v2]
In-Reply-To: <pOKphWyAmZVlDXQvIkRE6iQLILSZXj2sPPMguICA5Uc=.9d83d6b9-ba52-4144-93f8-6e3224959d3e@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
 <pOKphWyAmZVlDXQvIkRE6iQLILSZXj2sPPMguICA5Uc=.9d83d6b9-ba52-4144-93f8-6e3224959d3e@github.com>
Message-ID: <CbgL593PUq8TcwpHJHUNITwJ0hEUiZ3K9mBHgW7aKa0=.a884bd7b-1e85-4912-a91e-4ab37445e97d@github.com>

On Fri, 28 Mar 2025 07:25:48 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> Fix LambdaExpr02.java runs wrong test class.
>
> Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use default @run main

Sorry, but this is not what other tests in the same directory do. Leave it at


 * @run main LambdaExpr02

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

PR Review: https://git.openjdk.org/jdk/pull/24277#pullrequestreview-2725312657

From duke at openjdk.org  Fri Mar 28 12:17:22 2025
From: duke at openjdk.org (Zihao Lin)
Date: Fri, 28 Mar 2025 12:17:22 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class [v3]
In-Reply-To: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
Message-ID: <QnhphwsZg8VoUm8JyQDj8Yve7kFTlWCLaB686oVjR-I=.d42d9181-7bc5-49b5-b58b-501ef6a3455c@github.com>

> Fix LambdaExpr02.java runs wrong test class.

Zihao Lin has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:

  8352896: LambdaExpr02.java runs wrong test class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24277/files
  - new: https://git.openjdk.org/jdk/pull/24277/files/5c7cc21d..6dd3941e

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

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

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

From liach at openjdk.org  Fri Mar 28 12:17:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Mar 2025 12:17:22 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class [v2]
In-Reply-To: <pOKphWyAmZVlDXQvIkRE6iQLILSZXj2sPPMguICA5Uc=.9d83d6b9-ba52-4144-93f8-6e3224959d3e@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
 <pOKphWyAmZVlDXQvIkRE6iQLILSZXj2sPPMguICA5Uc=.9d83d6b9-ba52-4144-93f8-6e3224959d3e@github.com>
Message-ID: <hgCNzrolkAvyajDJoH8NDXhFpxTeQkC3oTXuVeRgffY=.308d8a80-39af-4eb1-9594-b6bb14bcef62@github.com>

On Fri, 28 Mar 2025 07:25:48 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> Fix LambdaExpr02.java runs wrong test class.
>
> Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use default @run main

Guess we will fix this when jtreg introduces something like `@this` in the future...

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

PR Comment: https://git.openjdk.org/jdk/pull/24277#issuecomment-2761189841

From liach at openjdk.org  Fri Mar 28 12:20:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Mar 2025 12:20:12 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class [v2]
In-Reply-To: <pOKphWyAmZVlDXQvIkRE6iQLILSZXj2sPPMguICA5Uc=.9d83d6b9-ba52-4144-93f8-6e3224959d3e@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
 <pOKphWyAmZVlDXQvIkRE6iQLILSZXj2sPPMguICA5Uc=.9d83d6b9-ba52-4144-93f8-6e3224959d3e@github.com>
Message-ID: <3wTYUu1pKPDV7kNBo5FkoizpCLn3DG6_a6iwYJzSyog=.56d3569b-66f1-4d6a-8342-6cd71ae7e1f5@github.com>

On Fri, 28 Mar 2025 07:25:48 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> Fix LambdaExpr02.java runs wrong test class.
>
> Zihao Lin has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.

@lahodaj What do you think on this one?

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

PR Comment: https://git.openjdk.org/jdk/pull/24277#issuecomment-2761196712

From shade at openjdk.org  Fri Mar 28 12:31:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Mar 2025 12:31:17 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class [v3]
In-Reply-To: <QnhphwsZg8VoUm8JyQDj8Yve7kFTlWCLaB686oVjR-I=.d42d9181-7bc5-49b5-b58b-501ef6a3455c@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
 <QnhphwsZg8VoUm8JyQDj8Yve7kFTlWCLaB686oVjR-I=.d42d9181-7bc5-49b5-b58b-501ef6a3455c@github.com>
Message-ID: <1mKGcWvj-XMiaiPHnrT9Im0_Sk7FX5l5X2RO93wzfcY=.e929dda2-2c6a-464e-a786-2ebc441acd78@github.com>

On Fri, 28 Mar 2025 12:17:22 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> Fix LambdaExpr02.java runs wrong test class.
>
> Zihao Lin has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8352896: LambdaExpr02.java runs wrong test class

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24277#pullrequestreview-2725363314

From jlahoda at openjdk.org  Fri Mar 28 12:37:10 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Mar 2025 12:37:10 GMT
Subject: RFR: 8352896: LambdaExpr02.java runs wrong test class [v3]
In-Reply-To: <QnhphwsZg8VoUm8JyQDj8Yve7kFTlWCLaB686oVjR-I=.d42d9181-7bc5-49b5-b58b-501ef6a3455c@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
 <QnhphwsZg8VoUm8JyQDj8Yve7kFTlWCLaB686oVjR-I=.d42d9181-7bc5-49b5-b58b-501ef6a3455c@github.com>
Message-ID: <ofG89cSx7UEmnE5HEMQZx1kmmkA_h8uVZAWCzOqs0iI=.7c5bde51-81a5-43e3-b57e-814e3f96ac49@github.com>

On Fri, 28 Mar 2025 12:17:22 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> Fix LambdaExpr02.java runs wrong test class.
>
> Zihao Lin has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8352896: LambdaExpr02.java runs wrong test class

I don't have a very strong preference between nothing, `@run main <testname>` and:

@compile <testname>.java
@run main <testname>


The latter is sometime good specifically for javac, as it forces compilation, and that is desirable while developing javac (because for `@build`/`@run main`, it may happen an updated javac is not used to compile the given test, as the test is already compiled).

But, that's not strong enough to alter long-existing test headers. So, keeping things more or less as they are, and consistent across the directory seems good.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24277#pullrequestreview-2725378845

From duke at openjdk.org  Fri Mar 28 13:22:33 2025
From: duke at openjdk.org (Zihao Lin)
Date: Fri, 28 Mar 2025 13:22:33 GMT
Subject: Integrated: 8352896: LambdaExpr02.java runs wrong test class
In-Reply-To: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
References: <0zWtWP_Elx8updBrDheBhtYLgZPWHzuf3Mlkyh8Qpd8=.0ba1c572-8023-4008-a6f0-bd7d2e62b773@github.com>
Message-ID: <QMRkSL6_jWiCmjtI3o2AhmbKqKfYLepObSqxKjFxU1o=.8f80b840-d7db-4915-ac2d-b229ce30c2ea@github.com>

On Thu, 27 Mar 2025 12:48:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

> Fix LambdaExpr02.java runs wrong test class.

This pull request has now been integrated.

Changeset: c0292203
Author:    Zihao Lin <linzihao1999 at outlook.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0292203794bf3a8bfb02eac062e226ef2d07ee1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8352896: LambdaExpr02.java runs wrong test class

Reviewed-by: shade, jlahoda

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

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

From acobbs at openjdk.org  Sat Mar 29 15:49:17 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 29 Mar 2025 15:49:17 GMT
Subject: RFR: 8352731: Compiler workaround to forcibly set "-Xlint:-options"
 can be removed
Message-ID: <fxKhh8TZZTtKg5eUJaP0l4Fze_YdhD14DazpKuu7pag=.18d62dce-bd60-44f1-ab4a-fd39bb89a51b@github.com>

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.

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

Commit messages:
 - Remove unused code.

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

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

From forax at univ-mlv.fr  Mon Mar 31 06:43:36 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 31 Mar 2025 08:43:36 +0200 (CEST)
Subject: Draft JEP: Enhanced Void return
In-Reply-To: <18ef2424-b6d3-477a-b70a-aa9b83b4d325@berlin.de>
References: <mailman.5978.1743103019.109.compiler-dev@openjdk.org>
 <18ef2424-b6d3-477a-b70a-aa9b83b4d325@berlin.de>
Message-ID: <184608024.197287891.1743403416212.JavaMail.zimbra@univ-eiffel.fr>

yes,
during the expert group discussions about lambdas, we explicitly rule out this case.

there is no boxing rules between Void and void.

we may revisit this idea in the future because at some point of Valhalla we will want to see primitive types as kind of wrapper/boxed value types, but we are not there yet.

regards,
R?mi

----- Original Message -----
> From: "Stephan Herrmann" <stephan.herrmann at berlin.de>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Thursday, March 27, 2025 9:22:13 PM
> Subject: Re: Draft JEP: Enhanced Void return

> How would this interact with definitions void-compatible / value-compatible in
> JLS ?15.27.2.?
> 
> It seems all lambdas formerly classified as void-compatible would need to be
> re-classified as "potentially value-compatible" with an elided "return null;".
> This could entail a hole new can of worms for resolution / type inference.
> 
> BR
> Stephan
> 
>> Date: Thu, 27 Mar 2025 12:16:18 -0700
>> From: Brandon Mintern <mintern at everlaw.com>
>> To: compiler-dev at openjdk.org
>> Subject: Re: Draft JEP: Enhanced Void return
>> Message-ID:
>> 	<CAJW1onhzJX6yFnxM94SwpWoMVV1H0a35_1cxQp6B5qNui7ibWw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> I'm sorry. I see that my prior email wraps poorly when rendered in the web
>> interface. Here's the same email wrapped to 76 characters for better
>> readability:
>> 
>> Title: Enhanced Void return
>> Author: Brandon Mintern
>> Organization: Everlaw
>> Created: 2025/03/27
>> Type: Feature
>> State: Draft
>> Exposure: Open
>> Component: specification / language
>> Scope: SE
>> Template: 2.0
>> 
>> Summary
>> -------
>> 
>> Allow `Void`-returning methods to omit the `return null` statement. Method
>> implementations can still `return null` if desired, but they can also use a
>> plain `return` or omit the statement altogether.
>> 
>> Goals
>> -----
>> 
>> Improve ergonomics when using methods that accept a lambda and optionally
>> return a result. Enhance the compiler to:
>> 
>> - Automatically insert `return null` (or convert `return`) in
>>    `Void`-returning methods.
>> - Infer `Void` as the generic return type in method references and lambdas
>>    without a `return`.
>> 
>> Non-Goals
>> ---------
>> 
>> - `Void`-returning methods are still free to explicitly state `return null`.
>> - The scope should be limited such that:
>>      - The compiler can do the heavy lifting, without any JVM changes.
>>      - No new lambda objects would be constructed implicitly.
>> 
>> Motivation
>> ----------
>> 
>> Lambdas provide powerful abstractions for working with closeable resources
>> or in temporary contexts. For example, we can define the following
>> abstraction:
>> 
>>      <R> R withBufferedReader(Path path, BufferedReaderFunction<R> f) {
>>          try (var reader = Files.newBufferedReader(path)) {
>>              return f.apply(reader);
>>          } catch (IOException e) {
>>              throw new UncheckedIOException(e);
>>          }
>>      }
>> 
>>      @FunctionalInterface
>>      interface BufferedReaderFunction<R> {
>>          R apply(BufferedReader reader) throws IOException;
>>      }
>> 
>> Callers can use this method as follows:
>> 
>>      var firstLine = withBufferedReader(path, r -> r.lines().findFirst());
>> 
>> When a caller doesn't need the return value, though, the caller must include
>> an awkward `return null`:
>> 
>>      withBufferedReader(path, reader -> {
>>          this.header = reader.readLine();
>>          this.data = reader.lines().toList();
>>          return null;
>>      });
>> 
>> These examples used `BufferedReader` for familiarity, but abstractions like
>> this are arguably more useful when reading from other persistent data stores
>> (e.g., databases, search indexes) or when writing context-specific code.
>> Using a completely hypothetical `UserContextHolder`:
>> 
>>      <R> R inUserContext(User user, Supplier<R> supplier) {
>>          var oldContext = UserContextHolder.getContext();
>>          UserContextHolder.setUserContext(user);
>>          try {
>>              return supplier.get();
>>          } finally {
>>              UserContextHolder.setContext(oldContext);
>>          }
>>      }
>> 
>> Then we might have system code that looks like the following:
>> 
>>      interface Report {
>>          User getUser();
>>          GeneratedReport generate();
>>      }
>> 
>>      for (var report: pendingReports) {
>>          save(inUserContext(report.getUser(), report::generate));
>>      }
>> 
>>      // or:
>> 
>>      interface Job {
>>          User getUser();
>>          void execute();
>>      }
>> 
>>      for (var job : pendingJobs) {
>>          inUserContext(job.getUser(), () -> {
>>              job.execute();
>>              return null;
>>          });
>>          // inUserContext(job.getUser(), job::execute) with this proposal
>>      }
>> 
>> Description
>> -----------
>> 
>> When a method has a fully instantiated return type of `Void`, all of the
>> following would be valid:
>> 
>> - `return null`
>> - `return`
>> - omitted `return` (implicit `void` return)
>> 
>> `Void`-returning methods can continue using `return null` without warning.
>> It should be at least a warning, though, for a single method to mix `return
>> null` and any `void`-style return (implicit or explicit).
>> 
>> When a functional interface has a generic return type parameter, lambdas can
>> use `void`-style returns, and references to `void`-returning methods can be
>> used, where the compiler will infer the return type to be `Void` and
>> logically insert the necessary `return null` statements.
>> 
>> As with functional interfaces in general, an instance of one type cannot be
>> automatically converted to another. That is, a `Runnable` cannot be passed
>> as a `Supplier<T>`, inferring `T = Void`. `Runnable::run` could be used
>> instead.
>> 
>> When a method returns a generic type, and when that type is inferred as
>> `Void` due to the use of an *enhanced `Void` return*, it would be an error
>> to assign the result to a variable. Returning to the `inUserContext`
>> example:
>> 
>>      var report = inUserContext(report.getUser(), report::generate); // OK
>> 
>>      Void result = inUserContext(job.getUser(), () -> {
>>          job.execute();
>>          return null;
>>      }); // OK: result is null (backwards compatible)
>> 
>>      Void result = inUserContext(job.getUser(), job::execute); // ERROR
>> 
>>      Void result = inUserContext(job.getUser(), () -> {
>>          job.execute();
>>      }); // ERROR
>> 
>> This enhancement would be implemented entirely by the compiler, generating
>> JVM bytecode as if `return null` had been used where it's currently needed.
>> 
>> Alternatives
>> ------------
>> 
>> Returning to the `withBufferedReader` example, without this proposal, we can
>> instead define sibling methods (and types) to avoid the need for
>> `return null`:
>> 
>>      void withBufferedReader(Path path, BufferedReaderProcedure f) {
>>          withBufferedReader(path, reader -> {
>>              f.accept(reader);
>>              return null;
>>          });
>>      }
>> 
>>      interface BufferedReaderProcedure {
>>          void accept(BufferedReader reader) throws IOException;
>>      }
>> 
>>      withBufferedReader(path, reader -> {
>>          this.header = reader.readLine();
>>          this.data = reader.lines().toList();
>>      });
>> 
>> This works, sort of, but we quickly find that it doesn't actually work.
>> Returning to the first example:
>> 
>>      var firstLine = withBufferedReader(path, r -> r.lines().findFirst());
>> 
>> This now fails to compile, reporting "Ambiguous method call." We can work
>> around that issue, of course, by standardizing on verb pairs to use in these
>> scenarios:
>> 
>>      R applyingBufferedReader(...)
>>      void acceptingBufferedReader(...)
>> 
>> In reality, though, this disambiguation is not the biggest issue. Rather, in
>> most codebases, it would be hard to justify defining duplicate methods and
>> types. Many development teams would instead use `return null` statements
>> where necessary, avoid the abstraction in cases where `return null` is
>> needed, or avoid defining the abstraction altogether.
>> 
>> Risks and Assumptions
>> ---------------------
>> 
>> Some codebases may have sibling methods like those described above, where
>> this enhancement would cause new "Ambiguous method call." when using the
>> `void`-returning method. However:
>> 
>> - Already-compiled code would not be affected since there is no JVM change.
>> - Impacted code would likely benefit from this enhancement, with new
>>    compiler errors pointing to duplicate code that can likely be deleted.
>> 

From jlahoda at openjdk.org  Mon Mar 31 15:06:56 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 31 Mar 2025 15:06:56 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v2]
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <cxMa8BqER0u1zaLLq5GrONT306JD_srvn1f5DqYWFVc=.16c0a034-825d-4b14-b8e8-8212f11cc720@github.com>

> 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 four additional commits since the last revision:

 - 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/46c8454a..cffcf851

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

  Stats: 306 lines in 18 files changed: 219 ins; 50 del; 37 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  Mon Mar 31 17:40:25 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 31 Mar 2025 17:40:25 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v3]
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <uQdqdh861qc_8dlxW7tPGmhwY1NZ43LQ8vrtI8NIAB8=.93fdceb0-8def-4b2f-8e5d-badd994b7040@github.com>

> 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/cffcf851..067a0444

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 darcy at openjdk.org  Mon Mar 31 20:53:09 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 31 Mar 2025 20:53:09 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v7]
In-Reply-To: <_O-rObil9n_4DlTZebVgctZ_WQmqqCseQg7ovMk3XfQ=.fc00072d-8c29-454e-9909-4adb56657bc5@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
 <_O-rObil9n_4DlTZebVgctZ_WQmqqCseQg7ovMk3XfQ=.fc00072d-8c29-454e-9909-4adb56657bc5@github.com>
Message-ID: <NKTX_qQryJjtHcvzeJRS5TD6GY6i3BfmmXEYjpaD38Y=.ce97f58b-04e1-4074-85ff-539e2ff965e5@github.com>

On Mon, 24 Mar 2025 09:49:09 GMT, David Beaumont <duke at openjdk.org> 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:
> 
>   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:  * <p>
> 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?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r2021748372

From darcy at openjdk.org  Mon Mar 31 21:02:13 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 31 Mar 2025 21:02:13 GMT
Subject: RFR: 8338675: javac shouldn't silently change .jar files on the
 classpath [v7]
In-Reply-To: <_O-rObil9n_4DlTZebVgctZ_WQmqqCseQg7ovMk3XfQ=.fc00072d-8c29-454e-9909-4adb56657bc5@github.com>
References: <BjORAQ9w_qS_xEVvvQFxpEzbuvEiGJXZM2l7yPkRK3k=.8b08d224-3231-4c0f-8f31-4a03ed128344@github.com>
 <_O-rObil9n_4DlTZebVgctZ_WQmqqCseQg7ovMk3XfQ=.fc00072d-8c29-454e-9909-4adb56657bc5@github.com>
Message-ID: <TnYk-xj4KRm7ZGn8e2AhGie2mG_oX-dpEMQ78RasdTU=.06a9b342-a348-4c88-9fb9-85130d416b33@github.com>

On Mon, 24 Mar 2025 09:49:09 GMT, David Beaumont <duke at openjdk.org> 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:
> 
>   Remove unused import.

test/langtools/tools/javac/processing/filer/TestNoOverwriteJarFiles.java line 87:

> 85:  * <h2>Important</h2>
> 86:  *
> 87:  * This test creates files from Java compilation and annotation processing, and

I suppose some of the desired effect could be achieved using jtreg directives instead, but this approach seems fine too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23699#discussion_r2021757352

From vromero at openjdk.org  Mon Mar 31 22:38:23 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 31 Mar 2025 22:38:23 GMT
Subject: RFR: 8348928: Check for case label validity are misbehaving when
 binding patterns with unnamed bindings are present
In-Reply-To: <WqHraZlmaTd7IY4RkdgQxxZ72zA2sfUyft3GOEIw1jE=.1266a33a-b849-4a71-827c-9a0b1eac3cdc@github.com>
References: <WqHraZlmaTd7IY4RkdgQxxZ72zA2sfUyft3GOEIw1jE=.1266a33a-b849-4a71-827c-9a0b1eac3cdc@github.com>
Message-ID: <eUYUlx2fNMRuENb-X6RHncHA0ZmXbYtqWNM_1p3keww=.72289613-b25b-479a-9f11-a86a82687bb8@github.com>

On Fri, 21 Mar 2025 14:11:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class Exp0 {
>     public static void main(String... args) {
>         Object o = "";
>         record R(int i, String s) {}
> 
>         switch (o) {
>             case Integer _, R(int i, String _) -> {}
>             default -> {}
>         }
>     }
> }
> 
> 
> This compiles OK, but it shouldn't. The JLS says:
>> It is a compile-time error for a case label to have more than one case pattern and declare any pattern variables (other than those declared by a guard associated with the case label).
> 
> Some similar cases leads to a javac crash:
> 
> $ cat Exp2.java 
> public class Exp2 {
>     public static void main(String... args) {
>         Object o = "";
>         record R(int i, String s) {}
> 
>         switch (o) {
>             case Integer _:
>             case R(int i, String _):
>                 System.err.println(i);
>                 break;
>             default: break;
>         }
>     }
> }
> 
> $ jdk-24/bin/javac Exp2.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
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.<init>(Items.java:392)
>         at jdk.compiler/com.sun.tools.javac.jvm.Items.makeLocalItem(Items.java:133)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitIdent(Gen.java:2350)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2711)
> ...
> printing javac parameters to: /tmp/javac.20250321_150757.args
> 
> 
> The root cause here is a bug when determining whether or not a given case label contains bindings - the "has-bindings" flag gets cleared when `_` is used. The "has-bindings" flags must remain set despite seeing unnamed binding variables.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24155#pullrequestreview-2730673351