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

[Lance Andersen]

Thank you for the feedback Alan.

More below

> On Sep 23, 2019, at 2:32 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 22/09/2019 23:43, Lance Andersen wrote:
>> I updated the patch and the CSR.
>> 
>> The updated webrev is: http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html
>> 
> I went through the spec updates in module-info.java.
> 
> "when adding entries ...". Is that also true when someone re-writes a file?
Yes it does.  I can change “adding” to “writing"
> 
> Do we need quotes around "STORED" and "DEFLATED"  value to make it clearer that they are strings?
Sure I can add the quotes
> 
> "an IllegalArgumentException will be thrown". This could be expanded to say that will be thrown when creating the file system.
I can include the additional wording
> 
> For releaseVersion there are 3 list items that start "If the value ..." and one that starts with "If the Object". We should keep the wording consistent. Also it feels like it accepts too many possible value types and maybe some of these should be dropped.

Please see below WRT dropping Version
> 
> Could we link "multi-release JAR" to the "Multi-release JAR files" section of the JAR file spec. I think {@docRoot}/../specs/jar/jar.html should work.
> 
Sure I can add that…

> When the value of releaseVersion is a String or Integer then it's the feature version.  In MR JARs the version is the major version of the Java platform release so "11.0.1" shouldn't be in the example.
I can drop  11.0.1 from the example.  Runtime.Version.parse() will accept “11.0.1” and return “11” which is the only reason I included the example .  I can remove the “11.0.1” from the example.
> 
> The paragraph for a value of "runtime" or Runtime.Version is a bit difficult to read. I think you want "runtime" to use Runtime.version().feature(). If a Runtime.Version object is provided then it's feature() method will be invoked. Maybe it would be better to split these out or maybe allowing a Runtime.Version object should be dropped to reduce the number of possible value types.

I am more than happy to drop the Runtime.Version object.  However as you are probably aware it was there previously and while it is probably highly unlikely that anyone is passing a Version object, if we drop it from the new”runtimeVersion” property, I assume we drop it from the “multi-release” property as well?  I can update the CSR to indicate we are dropping Version.

Best
Lance
> 
> -Alan
> 
> 

 <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/20190923/746c31d2/attachment-0001.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/20190923/746c31d2/oracle_sig_logo-0001.gif>