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