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.
