On 06/04/2016 15:20, Kumar Srinivasan wrote:
Alan,
http://cr.openjdk.java.net/~ksrini/8152622/webrev.02/
I made the changes as you suggested below, I have retained
Files.createDirectories,
here is why, changing it to createDirectory will throw
FileAlreadyExistsException,
which means, that if
Alan,
http://cr.openjdk.java.net/~ksrini/8152622/webrev.02/
I made the changes as you suggested below, I have retained
Files.createDirectories,
here is why, changing it to createDirectory will throw
FileAlreadyExistsException,
which means, that if the output zip/jar file exists then an
On 06/04/2016 14:09, Kumar Srinivasan wrote:
- Is Files.createDirectories needed? The walk is specified to be
depth first so you'll also visit parent directories first.
Yes, zipfs does not allow me to create the file without creating the
enclosing directory
first, so if I were to do
Alan,
Thanks for the review. Please see inline comments.
Creating a zip file from the classes in the jrt file system make
sense, and should be fast.
A few comments on Utils.JrtToZip:
- the URI creation in the run() method isn't reliable, could you use
this instead:
URI uri =
On 06/04/2016 04:47, Kumar Srinivasan wrote:
Hi,
I made some adjustments, based on private feedback.
New Webrev:
http://cr.openjdk.java.net/~ksrini/8152622/webrev.01/
Changes
* Modified ModuleAttributes test to use the new utility method,
this also requires a way to filter/select
Hi,
I made some adjustments, based on private feedback.
New Webrev:
http://cr.openjdk.java.net/~ksrini/8152622/webrev.01/
Changes
* Modified ModuleAttributes test to use the new utility method,
this also requires a way to filter/select filename patterns.
* Use preVisitDirectory to
sorry missed the subject.
Kumar
Hi,
The issue here was jimage extract was taking too long, exploding
the modules onto certain slow filesystems, thus causing test
timeouts. Now using jrtfs to zipfs, it takes a small fraction of
that time.
Please review:
