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
