JmodTask
—
839
840 hashesBuilder.computeHashes(modules).entrySet().forEach(e -> {
You can use the Map.forEach method accepting BiFunction of key and value.
970 private Path moduleToPath(ModuleFinder moduleFinder, String name) {
971 ModuleReference mref = moduleFinder.find(name).orElseThrow(
972 () -> new InternalError("Selected module " + name + " not
on module path"));
973
974 URI uri = mref.location().get();
975 Path path = Paths.get(uri);
976 String fn = path.getFileName().toString();
977 if (!fn.endsWith(".jar") && !fn.endsWith(".jmod")) {
978 throw new InternalError(path + " is not a modular JAR or
jmod file");
979 }
980 return path;
981 }
Make static?
Paul.
> On 11 Jan 2017, at 15:47, Mandy Chung <mandy.ch...@oracle.com> wrote:
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160286/webrev.00/
>
> jmod and jar -—hash-modules option to specify a pattern of modules
> to be hashed in the module M being created. It records the modules
> that depend on M directly and indirectly.
>
> jmod hash command records the hashes in modules that have already
> been packaged. It will identify the base module(s) with no going
> edges and record the hashes in that module. This patch fixes
> jmod hash command how the base modules are identified. For example,
>
> $ jmod hash -—dry-run —-module-path jmods -—hash-modules
> "jdk.jdeps|jdk.compiler|java.compiler”
>
> java.compiler should be the only module recording the hashes of jdk.compiler
> and jdk.jdeps.
>
> It first builds a graph of the modules matching the pattern
> specified in the --hash-module option. It traverses the graph in
> topological order, for each module, it is a base module if it’s a
> matching module and not hashed and then record the matching
> modules that directly and indirectly depend on it. This also cleans
> up the duplicated code and shared by jar and jmod tools now.
>
> I found that jar -—module-path is a repeating option and this patch
> fixes it to be the last-one-wins, consistent with the runtime option,
> and other tools.
>
> Mandy
