On 26/01/2026 15:36, Eirik Bjørsnøs wrote:
Hi,
Where available, ZipFile.Source.Key uses the "file key" from
BasicAttributes:fileKey to determine if paths refer to the same file
instance.
For a "hello world" program in a jar on the classpath, this dependency
on the NIO file system API pulls in just about 50 classes. (See diff
below).
If we rewrite ZipFile to not consider the file key and to use
File::lastModified instead of BasicFileAttributes::lastModifiedTime,
these classes are no longer loaded.
I don't think we should go back to that. Part of it is the FileKey,
which was some of motivation for the use in ZipFile There are also
experiments that re-implement most of java.io and ZipFile to use
FileChannel so these classes will be loaded anyway. Actually, anything
non-trivial causes these classes to be loaded.
-Alan
