0

Let's consider a very simple Java snippet:

String pathUriStr = Paths.get(args[0]).toUri().toASCIIString();
URI zipUri = URI.create("jar:" + pathUriStr);

FileSystem zip = null;
try {
  zip = FileSystems.newFileSystem(zipUri, Collections.emptyMap());
} catch (IOException e1) {
  // TODO Auto-generated catch block
  e1.printStackTrace();
}
Path zipRoot = zip.getPath("/");

System.out.println("ZipFileSystem:");
FileVisitor<Path> visitor = new SimpleFileVisitor<Path>() {

  @Override
  public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
      throws IOException {
    System.out.println(file);
    return super.visitFile(file, attrs);
  }

  @Override
  public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs)
      throws IOException {
    System.out.println(dir);
    return super.preVisitDirectory(dir, attrs);
  }

};
try {
  Files.walkFileTree(zipRoot, visitor);
} catch (IOException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
}

The output is:

ZipFileSystem:
/
/images
/images/ant_logo_large.gif
/org
/org/apache
...
/META-INF
/META-INF/LICENSE.txt
/META-INF/MANIFEST.MF

Doing the same with `ZipInputStream:

System.out.println("ZipInputStream:");
try (InputStream is = Files.newInputStream(Paths.get(args[0]), StandardOpenOption.READ);
     ZipInputStream zipIs = new ZipInputStream(is)) {
  ZipEntry entry = null;

  while((entry = zipIs.getNextEntry()) != null) {
    System.out.println(entry);
    zipIs.closeEntry();
  }
} catch (IOException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
}

gives me:

ZipInputStream:
META-INF/
META-INF/MANIFEST.MF
org/
org/apache/
...
META-INF/LICENSE.txt
images/
images/ant_logo_large.gif

just the same output as with unzip(1):

$ unzip -l ~/ant-1.5.jar
Archive:  /net/home/osipovmi/ant-1.5.jar
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  07-09-2002 11:13   META-INF/
      460  07-09-2002 11:13   META-INF/MANIFEST.MF
        0  07-09-2002 11:12   org/
        0  07-09-2002 11:12   org/apache/
.......................................................
     2766  07-09-2002 11:10   META-INF/LICENSE.txt
        0  04-30-2002 10:10   images/
     5360  03-18-2002 14:57   images/ant_logo_large.gif
---------                     -------
  1329851                     435 files

While this looks not like a problem in the first place, though it is a tremendous problem because this JAR would be rejected because META-INF/ and META-INF/MANIFEST.MF arent the first entries according to the JAR spec.

My usecase is quite similar, I want to consume ZIP files and would like to require some entries to be the first to quickly validate the input without having to seek to the end of the file.

All tested with Java 8, 10 and 11-ea.

So the question is, why does the Zip file system not retain the order of appearance in the stream?

Michael-O
  • 18,123
  • 6
  • 55
  • 121
  • So what's the question? If the documentation doesn't specify that it retains the physical order there's no issue here. It's also logical, as it's a `FileSystem`, that it works like you'd expect, i.e. start from the root. Besides, if you want to check for the first files, why wouldn't use use a `ZipInputStream` anyway? – Kayaman Aug 22 '18 at 07:32
  • @Kayaman you are right, it does not specify that, but it looked awkward to me. So you considering this not to be a bug, but my usecase isn't suited for the Zip filesystem? – Michael-O Aug 22 '18 at 07:37
  • `ZipFileSystem` is great, if you need to treat a zip file as if it weren't a zip file at all (copying things transparently from your file system into a zip file, etc.). It's completely wrong for your use case, where you want to treat it as a zip file, and check the first entries. That's exactly the purpose of `ZipInputStream`. – Kayaman Aug 22 '18 at 07:47
  • @Kayaman, so the opposite case would be to create a ZIP file with the first entries to be my special files this provider would be not suited for this? – Michael-O Aug 22 '18 at 07:49

1 Answers1

3

ZipFileSystem is an abstraction of the underlying zip file, allowing you to treat it in the same way as any other implementation of FileSystem. It makes perfect sense to have it work in the regular tree-like structure you'd expect, starting from the root /. This is great if you want to easily copy files from/to zips, just like you'd do between regular directories. The downside of this is that you lose some control over the zip itself.

ZipInputStream is a much lower level abstraction where you have control over the structure and other zip file specific things. The downside is that you might have to write more code.

Example: you want to copy or move a file from one zip to another:

With ZipFileSystem this is the equivalent of moving a file from one directory to another, and the code works for any implementation of FileSystem. Using zip streams you would have to manually process the source zip file, find the correct entry, remove the entry, then add it to the second zip file, rewriting files along the way. That's 1 line of code vs. several lines, loops and other boilerplate.

So ZipFileSystem provides you the benefits of higher abstraction, but has downsides such as memory usage, less control with the details of zip files and so on. ZipXXXStream provides you with a low level view to the zip, dealing with zip entries and other internal details which is not something you always need.

Kayaman
  • 72,141
  • 5
  • 83
  • 121