>> 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.
Yes > 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. Yes. one has to specially request multi-release processing when the file system is opened.
