...

Zip files may contain data in addition to the archive entries such as executable code for self-extracting archives or text comments describing the archive.

Zip Indexing

TBD

URI Structure

The FileSystem API allows a Path to be converted to a URI and a URI to be converted to a Path. The scheme component of the URI is used to identify the FileSystemProvider but the remaining components are provider specific. The Path.toUri() method mentions that the URI may be used to encode the URI of the enclosing FileSystem but does not define how that should be done. We define a mechanism based on encoding the parent in the authority component of a hierarchical URI.

Following RFC 3986, the format for a Path's URI will be:

uri           = scheme ":" "//" authority 1*( "/" segment )
authority     = host
host          = reg-name
reg-name      = *( unreserved / pct-encoded / sub-delims )
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pct-encoded   = "%" HEXDIG HEXDIG

where the authority component is used to contain the URI of the Path to the archive. Any characters not allow in a reg-name (specifically including "/" and ":") will be pct-encoded.

As an example, the entry com/example/Main.class located in the archive /tmp/example.jar whose Path has the URI file:///tmp/example.jar would have the URI

archive:file%3a%2f%2f%2ftmp%2fexample.jar/com/example/Main.class

If that JAR was included in the WEB-INF/lib directory of a WAR located at /tmp/example.war the full compound URI of the Main class would be

archive:archive%3afile%253a%252f%252f%252ftmp%25%2fexample.war%2fWEB-INF%2flib%2fexample.jar/com/example/Main.class

URL Support

URL support is required to allow references to resources to be returned by a ClassLoader or ServletContext. To enable Path URIs to be converted to URLs, a !URLStreamHandlerFactory that supports the URI's scheme is required. When connecting, the !URLStreamHandler can convert the URL to a URI and then to a Path.

URLClassLoader Support

Classes may be loaded from an archive by converting the Path of its root directory to a URL and using a URLClassLoader:

  Path archivePath = ... ; // path to archive
  URI archiveURI = new URI("archive", archivePath.toUri().toString(), null, null, null);
  FileSystem archiveFS = FileSystems.newFileSystem(archiveURI, null);
  URL rootURL = archiveFS.getPath("/").toUri().toURL();
  ClassLoader loader = new URLClassLoader({rootURL});

ToDos

• a way to read the zip’s central directory
• a way to seek into a deflated zip entry without inflating the entire thing
• is a ClassLoader from a list of Path helpful?
• how to deal with the locking model on Windows platform
• how to work with Paths that are directories - do we get this for free?
• how to use the WatchService to detect changes e.g. web.xml or *.jsp touched?
  

Performance Measurements

TBD

Limitations in standard JDK APIs

...

The JDK API dealing with Zip archives have not been updated to work with the NIO File APIs:

• ZipFile's constructor only accepts a java.io.File or a String relating to a file on the default filesystem
• A zip entry may only be accessed as a sequential InputStream rather than a SeekableByteChannel
• A ZipInputStream may only be constructed over an InputStream rather than a SeekableByteChannel
  

...

• The archive content must be accessible from native code
• Memory mapping a file on some operating systems (e.g. Microsoft Windows) asserts a mandatory file lock which interferes with the "overwrite to re-deploy" mechanism often used in development environments
  

URL Support

The jar scheme syntax is now formally defined as:

...