On 02/10/2015 15:52, Steve Drach wrote :
To elaborate a bit, the implementation is quite straight forward. ZipFileSystem builds an
Inode tree on open. That tree is implemented as a Map<Inode,Inode>. For regular
zip/jar files both the key and the value are the same Inode. For multi-release jar files
the value is the Inode of the appropriate versioned entry. Configuration is through the
Map<String,?> env parameter to the FileSystems.newFileSystem parameter.
It sounds like you have a handle on this, the main thing is that by
default it's just a file system, irrespective of whether
META-INF/versions exists or not. If there is configuration specified via
the env map then it can work multi-versioned, it just can't be the
default because the file system provider has no knowledge as to how the
API is being used.
-Alan
