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

[Eirik Bjørsnøs]

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.

The loading of 50 extra classes (comprising 9 percent of 576 classes) seems
like a high price to pay for this caching mechanism!

As an experiment, I added File::fileKey which on Unix calls stat and
retrieves the device and inode information in similar fashion to what
NIO's BasicFileAttributes::fileKey does. This allows us to still consider
the same "file key" information as today, but without loading these 50
extra classes.

Perhaps we should consider adding File::fileKey as a public class? If not,
perhaps we can keep it private and expose it internally through a shared
secret?

See the draft implementation/experiment in this branch:

https://github.com/openjdk/jdk/compare/master...eirbjo:zipfile-java.io-filekey?expand=1

Thoughts and opinions are welcome.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260126/90aeb131/attachment.htm>