RFR: 8373436: Cleanup JRTIndex usages [v4]
Jan Lahoda
jlahoda at openjdk.org
Mon Dec 15 19:38:02 UTC 2025
On Mon, 15 Dec 2025 17:48:13 GMT, David Beaumont <duke at openjdk.org> wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Making the EMPTY field private.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 464:
>
>> 462: * {@return Accessor for additional class properties.}
>> 463: */
>> 464: public static LegacyCtPropertiesAccess getLegacyCtPropertiesInfo(JavaFileManager fm) {
>
> If this were in LegacyCtPropertiesAccess, NOOP could then be private and means only two static methods need to be visible to users. Of course there's an argument that LegacyCtPropertiesAccess shouldn't need to know about JavacFileManager logic, so it's fairly marginal.
>
>
> legacyCtPropertiesInfoAccess =
> JavacFileManager.getLegacyCtPropertiesInfo(fileManager);
>
>
> could become:
>
>
> legacyCtPropertiesInfoAccess = LegacyCtPropertiesAccess.from(fileManager);
Currently with this patch, the decision to use or not use the ct.properties is done only in `JavacFileManager`. If we moved this code to `LegacyCtPropertiesAccess`, it would be done partly there and (inevitably) partly in `JavacFileManager` (because at least the value of `isSymbolFileEnabled()` is also a standalone decision, and that one requires `Context`. Also, we would need to get the `JRTIndex` from the `JavacFileManager`. I was briefly thinking of moving this the code to `LegacyCtPropertiesAccess`, but I think it is better to make the decision in `JavacFileManager`.
Note the difference between "public" and "non-public" here is relatively small - as "public" is only "module-public".
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28761#discussion_r2620595272
More information about the compiler-dev
mailing list