RFR 8192986: Inconsistent handling of exploded modules in jlink

Claes Redestad claes.redestad at oracle.com
Thu Dec 7 15:24:37 UTC 2017


Hi Sundar,

thanks for picking this up so quick!

On 2017-12-07 16:21, Sundararajan Athijegannathan wrote:
> Updated: http://cr.openjdk.java.net/~sundar/8192986/webrev.01/

Looks ok, butunless my understanding is flawed it seems the logic is now 
getting more strict about a directory on the module path containing a 
well-formed module. Should this be made more graceful, say ignore empty 
directories? Maybe just warn about malformed and/or missing modules?

Nits:

JlinkTask: resolves module-info.class twice (resolve once and pass as 
parameter?)

ExplodedModuleNameTest:

   58         if (helper == null) {
   59             System.err.println("Test not run");
   60             return;
   61         }

Should this fail the test (by throwing an exception)?

   66         // rename the module containing directory
   67         Path renamedModDir = modDir.resolveSibling("modified_mod8192986");
   68         // copy the content from original directory to modified name directory
   69         copyDir(modDir, renamedModDir);

Any reason not to use Files.move(modDir, renamedModDir|,StandardCopyOption.REPLACE_EXISTING|) instead of copying here?

Thanks!

/Claes



More information about the jigsaw-dev mailing list