Observation: The cost of using NIO BasicFileAttributes in ZipFile.Source.Key

[Alan Bateman]

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