RFR: 8373436: Cleanup JRTIndex usages [v2]

[Jan Lahoda]

On Mon, 15 Dec 2025 11:31:34 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup: JRTIndex implements LegacyCtPropertiesAccess directly, as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java line 207:
> 
>> 205: 
>> 206:         JavaFileManager fm = context.get(JavaFileManager.class);
>> 207:         if (fm instanceof JavacFileManager javacFileManager) {
> 
> Optional: Feels a bit odd to have one case here for returning a no-op, and one case inside `getLegacyCtPropertiesInfo()`. Obviously this method only exists on `JavacFileManager`, so we can't trivially fold this test into the method, but we could have a `JavacFileManager` static helper taking in a `JavaFileManager`.
> 
> 
> /**
>  * Returns the legacy <maybe say what 'ct' is here> properties supplier from the given file
>  * manager, or a "no-op" instance if legacy properties are not available.
>  */
> public static LegacyCtPropertiesAccess getLegacyCtPropertiesInfo(JavaFileManager fm) {
> }
> 
> 
> This puts all the no-op logic in one place and lets the caller assign on declaration of `legacyCtPropertiesInfoAccess`, keeping the "legacy stuff" a bit more encapsulated.

Done.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java line 250:
> 
>> 248:                 ModuleSymbol owningModule = packge.modle;
>> 249:                 if (owningModule == syms.noModule) {
>> 250:                     LegacyCtPropertiesInfo info = legacyCtPropertiesInfoAccess.getInfo(packge.flatName());
> 
> Optional nit: If we are changing the name here, I might suggest `legacyInfo` just to keep the "it's legacy stuff" obvious.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28761#discussion_r2619971736
PR Review Comment: https://git.openjdk.org/jdk/pull/28761#discussion_r2619971439