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 <[email protected]> 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. > > >
