RFR 8192986: Inconsistent handling of exploded modules in jlink
Sundararajan Athijegannathan
sundararajan.athijegannathan at oracle.com
Thu Dec 7 15:45:24 UTC 2017
Hi,
Comments below...
On 07/12/17, 8:54 PM, Claes Redestad wrote:
> 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?
I'd prefer stricter checks. But I'd like to hear from others as well...
> Nits:
>
> JlinkTask: resolves module-info.class twice (resolve once and pass as
> parameter?)
Yes, I'll fix that.
>
> ExplodedModuleNameTest:
>
> 58 if (helper == null) {
> 59 System.err.println("Test not run");
> 60 return;
> 61 }
>
> Should this fail the test (by throwing an exception)?
This is similar to other tests. For eg. ModuleNamesOrderTest
> 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?
>
https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#move(java.nio.file.Path,%20java.nio.file.Path,%20java.nio.file.CopyOption...)
"To move a file tree may involve copying rather than moving directories
and this can be done using the copy method in conjunction with the
Files.walkFileTree utility method."
Thanks,
-Sundar
> Thanks!
>
> /Claes
>
More information about the jigsaw-dev
mailing list