[lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling with preview mode [v2]

[David Beaumont]

On Wed, 10 Dec 2025 10:34:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove note about StableValue (not possible)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java line 88:
> 
>> 86: 
>> 87:         // Synchronized by FileSystemResources.class, NOT instance.
>> 88:         private final Set<JRTIndex> owners = new HashSet<>();
> 
> This seems like a ref counter -- e.g. we want to keep track of how many JRTIndex instances there are that point at the same underlying resources. This seems sensible, and doing it this way seems better than using a refcount, so that you can check that the guy who did the close is the same as that who did the open.
> 
> Since there's only one set for both modes, correctness currently hinges (I think) on the fact that JRTIndex does *not* override equals/hashCode. This means that, if the same client opens two indices, one for preview, one for non-preview, you will see two distinct entries in the set (because the comparison is an identity comparison).
> 
> We might want to leave a comment about this "hidden" dependencies. Or, we could split the owner set in two. If we do the latter, we might improve the "already opened" check -- so that we can say "index already opened _in mode XYZ_"

Yes, it's "ref counting" but with non-fungeable counters. And yes, it implicitly relies on identity hashing (which should be made note of somewhere).

Splitting the owner-set into two or having a different internal key would be an option, but I think there's no reason to expect a class like JRTIndex to ever need more than system identity semantics (it's a service provider not a data object), so a comment is probably good for now.

I think JRTIndex can (and should) be made final, and I think a class-level comment should then suffice for future maintainers.

Thanks for bringing this up.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2619965833