RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Jan Lahoda jlahoda at openjdk.org
Mon Mar 24 19:23:13 UTC 2025


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


More information about the compiler-dev mailing list