RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion

[Lance Andersen]

I updated the patch and the CSR.

The updated webrev is: http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html <http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html>


> On Sep 20, 2019, at 1:43 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Fri, Sep 20, 2019 at 10:18 AM Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
> 
>> On Sep 20, 2019, at 12:59 PM, Martin Buchholz <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>> 
>> 
>> 
>> On Fri, Sep 20, 2019 at 9:02 AM Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>> On 20/09/2019 16:54, Martin Buchholz wrote:
>> > Thanks.
>> >
>> > When we document these properties, we should make it clearer what the 
>> > default behavior is, e.g. what happens if a multi-release jar is used 
>> > and releaseVersion is unspecified.
>> The table of properties that we've started to build up in the JDK 14 
>> builds has a column for the default value so hopefully the defaults will 
>> be clear.
>> 
>> Right - I missed that.  I read 
>> https://download.java.net/java/early_access/jdk14/docs/api/jdk.zipfs/module-summary.html <https://download.java.net/java/early_access/jdk14/docs/api/jdk.zipfs/module-summary.html>
>> and I now see I also confused "system properties" with "file system properties"
>>  
>> Also the description for "releaseVersion" has proposed text to 
>> say that the JAR file will be considered unversioned when the property 
>> is not specified, maybe you are saying that wording needed to be improved?
>> 
>> I re-read the proposed spec for releaseVersion, and I don't see where it says that.  A very pedantic reading is that the default value is null, which does not represent  a valid version number, so the default behavior should be to throw IllegalArgumentException ?!
> 
> I can add a sentence that  says if releaseVersion is not set  and a  multi-release JAR accessed via the ZIP FS, the JAR will be treated as an un-versioned JAR 
> 
> More simply?
> "If the property is null or unset, then the JAR will be treated as an un-versioned JAR."
> (do we make sure an explicit null is actually accepted?)
>  
>> I agree the noCompression property should be examined to allow for other 
>> potential compression methods.
>> 
> 
> Alan and I talked off-line.    I will add a compressionMode Property which will currently accept the strings: STORED or DEFLATED which will take precedence over  the noCompression  property which we will leave undocumented.
> 
> Thanks!  Consistency demands we name it "method" not “mode"

Agree and that is what I meant to do originally, the brain however thought otherwise ;-) 
> 
> <oracle_sig_logo.gif>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190922/6aa987ee/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190922/6aa987ee/oracle_sig_logo.gif>