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

[Eirik Bjørsnøs]

For the interested, here's a diff of classes loaded before and after the
removal of the NIO dependency:

33a34
> java.io.UnixFileSystem$UnixFileKey
140,142d140
< java.lang.ThreadLocal
< java.lang.ThreadLocal$ThreadLocalMap
< java.lang.ThreadLocal$ThreadLocalMap$Entry
242,256d239
< java.nio.file.CopyOption
< java.nio.file.FileSystem
< java.nio.file.Files
< java.nio.file.LinkOption
< java.nio.file.OpenOption
< java.nio.file.Path
< java.nio.file.StandardOpenOption
< java.nio.file.Watchable
< java.nio.file.attribute.AttributeView
< java.nio.file.attribute.BasicFileAttributeView
< java.nio.file.attribute.BasicFileAttributes
< java.nio.file.attribute.FileAttributeView
< java.nio.file.attribute.FileTime
< java.nio.file.attribute.PosixFileAttributes
< java.nio.file.spi.FileSystemProvider
296,299d278
< java.util.IdentityHashMap
< java.util.IdentityHashMap$IdentityHashMapIterator
< java.util.IdentityHashMap$KeyIterator
< java.util.IdentityHashMap$KeySet
348d326
< java.util.concurrent.TimeUnit
438d415
< jdk.internal.misc.CarrierThreadLocal
446,447d422
< jdk.internal.misc.TerminatingThreadLocal
< jdk.internal.misc.TerminatingThreadLocal$1
547,571d521
< sun.nio.fs.AbstractBasicFileAttributeView
< sun.nio.fs.AbstractFileSystemProvider
< sun.nio.fs.BsdFileAttributeViews
< sun.nio.fs.BsdFileAttributeViews$Basic
< sun.nio.fs.BsdFileSystem
< sun.nio.fs.BsdFileSystemProvider
< sun.nio.fs.DefaultFileSystemProvider
< sun.nio.fs.DynamicFileAttributeView
< sun.nio.fs.MacOSXFileSystem
< sun.nio.fs.MacOSXFileSystemProvider
< sun.nio.fs.NativeBuffer
< sun.nio.fs.NativeBuffer$Deallocator
< sun.nio.fs.NativeBuffers
< sun.nio.fs.NativeBuffers$1
< sun.nio.fs.UnixFileAttributeViews$Basic
< sun.nio.fs.UnixFileAttributes
< sun.nio.fs.UnixFileAttributes$UnixAsBasicFileAttributes
< sun.nio.fs.UnixFileKey
< sun.nio.fs.UnixFileStoreAttributes
< sun.nio.fs.UnixFileSystem
< sun.nio.fs.UnixFileSystemProvider
< sun.nio.fs.UnixMountEntry
< sun.nio.fs.UnixNativeDispatcher
< sun.nio.fs.UnixPath
< sun.nio.fs.Util

On Mon, Jan 26, 2026 at 4:36 PM Eirik Bjørsnøs <eirbjo at gmail.com> 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.
>
> 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/09446765/attachment.htm>