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