On 29/09/2016 16:26, Mandy Chung wrote:
On Sep 29, 2016, at 7:07 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
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.
The indentation was fine. I updated the comment and have a line-break before
the open curly bracket.
JmodFile::stream - I wonder if it would be better to leave the filtering at the
use sites.
I believe we don’t create an empty directory in the custom image and so all
entries can simply be considered for file only. Perhaps we can change this
(very simple change) when there is such need?
That should be okay.
In ModuleInfoExtender then toByteArray might be nicer than getBytes.
toByteArray is better.
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166860/webrev.01/
Looks good to me.
-Alan
