Code Review request for new "jsign" tool
Mandy Chung
mandy.chung at oracle.com
Fri Jul 1 10:22:23 PDT 2011
On 6/29/11 3:12 AM, Sean Mullan wrote:
> Mandy,
>
> I have updated the webrev for the new jsign tool:
>
> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/jsign/webrev.01/
>
> This should address most of your comments (see below).
>
> Please let me know if it is ok to push this.
>
It looks good with one minor comment embedded below.
>
> For now, I have left the options as they are, but I agree we need to
> define a more consistent option naming syntax across all of the new
> jigsaw tools.
I'm fine with leaving the options as they are and revisit all new jigsaw
tools' cli together.
> ...
>> ModuleFileFormat.java
>> L630-637: I believe if noExtract is true, destination will be null;
>> otherwise,
>> destination is non-null. Looks like you don't need the noExtract flag
>> and
>> perhaps replaced with needExtract method? Just a thought.
>
> I have not done this. Since there are several public methods that are
> affected by this flag, I think it is better (and the code is easier to
> understand) to use a flag to denote this behavior.
It's fine to keep the flag. There are a couple places of the double
negative check "if (!noExtract)"? Would it be better to change the flag
to "extract" rather than "noExtract"?
> I also fixed several unit test failures that were failing on Windows
> due to the usage of FileChannel.map [1]. I replaced these with
> FileChannel.read (and non-direct ByteBuffers). I did not see any
> noticeable performance degradation, but we will probably need to do
> some tests with larger module files to see if it makes any difference.
> Also, these calls are only made when packaging the module files, and
> not while reading.
>
Thanks for chasing this down. Replacing FileChannel.map with
FileChannel.read is a reasonable workaround.
Mandy
More information about the jigsaw-dev
mailing list