RFR 8230870: Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java

[Lance Andersen]

> On Sep 16, 2019, at 9:43 AM, Martin Buchholz <martinrb at google.com> wrote:
> 
> Thanks for doing this.

Thank you
> Looks Good To Me, but as always I have some comments

:-) Feedback always welcome as that is the only way to continue to get better and learn from others experience ;-)
> 
> EntryCount64k was written before testng infrastructure was common.  I might have done some surgery on EntryCount64k to accommodate zipfs instead of writing an entirely new test.  zipfs adds to the number of ways that zip files can be written - I generally only thought about ZipOutputStream.  One can structure zip tests using front-end/back-end strategy:  Combine N ways to write a zip file with M ways to read it, and verify that they all work together.  But we've never written tests that way.

I had thought about reworking your original test but decided against it at this time as I wanted to keep the ZIP FS tests together.

 I will add it to my todo list to  look at your suggestion.  Right now I am more concerned on the added coverage and circling back later for consolidation
> 
> Stop using System.currentTimeMillis for measuring elapsed time, and switch to System.nanoTime.

Yes I know, old habits are hard to break and I was just looking for a ballpark with Mach5.    I will switch it to nanoTime prior to pushing


>   Hmmm .... probably even better here is to hop over nanoTime to using java.time APIs like Duration.between as in https://www.baeldung.com/java-measure-elapsed-time <https://www.baeldung.com/java-measure-elapsed-time> section 3.2
> 
> On Wed, Sep 11, 2019 at 10:26 AM Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
> Hi all,
> 
> Please review the addition of a ZIP FS test which is similar to test/jdk/java/util/zip/EntryCount64k.java
> 
> The test exercises the ZIP FS properties noCompression and forceZIP64End which we do not have much coverage for.
> 
> The test runs clean Mach5 and and I run it 100 times each on windows-x64, macosx-x64, linux-x64 and linux-x64-open platforms  to sanity check there are no potential timeout issues due to the test run
> 
> I have left some basic timing methods in the test but have disabled them in the unlikely event we have to revisit a timeout issue.
> 
> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8230870/webrev.00/ <http://cr.openjdk.java.net/~lancea/8230870/webrev.00/>
> 
> Best
> Lance
> <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 <tel:(781)%20442-2037>
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 

 <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/20190916/b4d2aa4e/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/20190916/b4d2aa4e/oracle_sig_logo-0001.gif>