Review Request: JDK-8166860 Add magic number to jmod file

[Alan Bateman]

On 29/09/2016 05:56, Mandy Chung wrote:

> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166860/webrev.00/index.html
>
> The change adds a magic number in jmod file to enable future revision of the JMOD format. It's currently a zip file and may change in a future release.  JmodFile opens the file to validate the magic header and version.  Module path, module reader, jlink are updated in this patch.  This implementation opens zip file as well to support look up of a named entry.  There isn’t any simple way to avoid opening the jmod file twice unless it digs into the ZipFile internals.  Since jmod is not performance critical (not supported at runtime) and pure Java modules can be packaged as modular JARs, I go with this approach and can look into it when this becomes a real issue.
>
> Mandy
I think I agree on keep out of the ZipFile internals. As you noted, this 
is just packaging and link time so it's not a magic issue if the file is 
opened twice (assuming the file system isn't changing under your feet of 
course).

A minor comment on JmodOutputStream is that the newOutputStream 
description should be clearer to say that it creates (or overrides) the 
JMOD file, returning the the output stream to write to the JMOD. You 
might want to check the indentation of the throws in the writeEntry 
methods as it's hard to see where the method body starts.

JmodFile::stream - I wonder if it would be better to leave the filtering 
at the use sites.

In ModuleInfoExtender then toByteArray might be nicer than getBytes.

-Alan