<div dir="ltr"><div>Hi,</div><div><br></div><div>Where available, ZipFile.Source.Key uses the "file key" from BasicAttributes:fileKey to determine if paths refer to the same file instance.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>The loading of 50 extra classes (comprising 9 percent of 576 classes) seems like a high price to pay for this caching mechanism!</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>See the draft implementation/experiment in this branch:</div><div><br></div><div><a href="https://github.com/openjdk/jdk/compare/master...eirbjo:zipfile-java.io-filekey?expand=1">https://github.com/openjdk/jdk/compare/master...eirbjo:zipfile-java.io-filekey?expand=1</a></div><div><br></div><div>Thoughts and opinions are welcome.</div><div><br></div><div>Eirik. </div><div><br></div><div><br></div></div>