RFR: 8373436: Cleanup JRTIndex usages

[Maurizio Cimadamore]

On Thu, 11 Dec 2025 08:29:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `com.sun.tools.javac.file.JRTIndex` class serves two purposes: a) the keeps a package-oriented cache of directories and files inside the JRT FileSystem; b) allows to get the additional flags for classes in packages on the default classpath. Sadly, it is not easy to completely disentangle these two purposes, as the directories cache also holds the additional flags.
> 
> The `JRTIndex` is used on two places, the `ClassFinder`, and in `JavacFileManager`, but the former is only using the additional flags, and the latter is using the cache/index. The logic determining whether the `JRTIndex` is used in `ClassFinder` is also not trivial.
> 
> The goal of this PR is to attempt to clean this a bit:
> - there's a separate abstraction for getting the additional flags (`LegacyCtPropertiesAccess`), with the non-trivial implementation residing in `JavacFileManager`. This allows to concentrate the complex almost completely  inside the file manager.
> - the `JRTIndex` itself is now a package-private class inside the `....file` package.
> 
> It is not a goal of this PR to change the behavior, just make the implementation more understandable.
> 
> Note this removal from `ClassFinder`:
> 
> -        if (fm instanceof DelegatingJavaFileManager delegatingJavaFileManager) {
> -            fm = delegatingJavaFileManager.getBaseFileManager();
> -        }
> 
> 
> The `DelegatingJavaFileManager` is used when `--release` is specified, so this allows to get the underlying base file manager. But, regardless of the underlying base manager, the system classes should always come from the `--release` data, which are not in the underlying base manager, and hence (ultimately), the `JRTIndex` data should not be used by `ClassFinder` when `--release` is used. The removal makes this more obvious.

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

> 464:                 private final JRTIndex jrtIndex = getJRTIndex();
> 465:                 @Override
> 466:                 public boolean supportsLegacyFlags(JavaFileObject fo) {

Question (possibly naive) -- couldn't `LegacyCtProperties` access be an interface that is implemented directly by `JRTIndex` ? Then this method could return the jrtIndex -- and that would also be a `LegacyCtPropertiesAccess`. You still achieve the separation you are aiming for, but a bit more directly?

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

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