RFR: Superfluous classes archive created for modules with no files

[Alan Bateman]

On 15/02/2012 11:49, Chris Hegarty wrote:
> Hi,
>
> There is an incorrect assertion in the SimpleLibrary resource location 
> code, loadContent(). Essentially it expects an installed module to 
> always have a 'classes' archive. This may not always be the case, e.g. 
> 'jdk' & 'jdk.jre'.
>
> This wasn't noticed before, at least in the system library, as modules 
> installed using 'jmod install -L <lib> classes' actually creates an 
> empty classes jar archive. Example,
> >: ../bin/jmod create -L m.lib
> >: ../bin/jmod install -L m.lib ../modules/jdk/classes jdk
> >: ls m.lib/jdk/8-ea
>    .        ..       classes  index    info
> >: unzip -l m.lib/jdk/8-ea/classes
>    Archive:  m.lib/jdk/8-ea/classes
>    warning [m.lib/jdk/8-ea/classes]:  zipfile is empty
>
> This is not the case when the module is install from the jmod file, 
> i.e. no 'classes' archive is created if there are no classes or 
> resources in the jmod file. Example,
> >: ../bin/jmod create -L m.lib
> >: ../bin/jmod install -L m.lib ../jigsaw-pkgs/jmod/jdk at 8-ea.jmod
> >: ls m.lib/jdk/8-ea
>    .      ..     index  info
>
> The solution is to simply remove the incorrect assertion and change 
> the installer so that it only creates a 'classes' archive if it is 
> needed.
>
> http://cr.openjdk.java.net/~chegar/jigsaw/classless_webrev.00/webrev/
Is this causing a problem or is it just the warning from unzip? I 
remember Dave Bristor pushed several changes to ensure that the empty 
zip case was handled and I'm just wondering if something was missed.

As regards the change then I think listFiles would be nicer if it 
returned a List<Path> rather than populated the given collection, ie: 
List<Path> files = listAll(src.toPath());

What would you about removing Files.copy(File,OutputStream) from 
org.openjdk.jigsaw.Files and using 
java.nio.file.Files.copy(Path,OutputStream). That would avoid some of 
the conversion in this case. One difference to be aware of is that 
Files.copy(Path,OutputStream) does not close the output stream. The 
rational for this is for the "cat f1 f2 f2 > out" type case.

Minor comment is just to check that the style is consistent (indentation 
of "throws IOException" and use of curly braces with single statements).

-Alan.