Hi, I've started working on implementing support for modular JARs in Plexus Archiver but as I research the matter I found that they are more complex than I expected. I've updated the GitHub issue[1] with the details but I'll post the findings here as well. The modular JAR files contain not only version and main class but also:
* List of the packages contained - usually populated by the compiler, but there are some caveats here. The most obvious one is that for jars created by the Shade Plugin this attribute will almost certainly be incorrect - the plugin will most likely introduce additional packages and the list produced by the compiler will be out of date. The other caveat are the resources - they could be located in packages and encapsulated the same way as the classes. The jar tools records not only the class packages but the resource ones too. Packaging resources together with the classes may result in incorrect module descriptor if this attribute is not updated. * The module main class - passed as argument to the jar tool and it seems that it cannot be set using the compiler. * The module version - passed as argument to the jar tool. Could be set using the compiler(again passed as argument) as well. * Hashes - calculates the hashes of given external modules that depend on this one. During runtime java checks the recorded hashes against the resolved module and and if don't match it will fail. The primary use case is a module A that exports packages to B and C. An easy way to break the encapsulation of A is to create module named B. To prevent that you can record the hash of B and C inside A. Then A will export the packages only to the intended modules. It is used by the OpenJDK but could be useful for platforms and frameworks as well. * Module resolution - marks the module to not be resolved by default or marks it as deprecated or incubating so at run time a warning is displayed if it is resolved. I don't think you can set it using the JDK 9 jar tool but it's present in the code. Maybe it will be implemented in future version of the jar tool. To me it looks like the packaging of modular JAR file is more complex than just packing module-info.class file and the jar tool is no longer just a ZIP program. Something similar is stated in the tool documentation[2]: > The jar command is a general-purpose archiving and compression tool, > based on the ZIP and ZLIB compression formats. > Initially, the jar command was designed to package Java applets > or applications; however, beginning with JDK 9, users can use the > jar command to create modular JARs. > For transportation and deployment, it’s usually more convenient to > package modules as modular JARs. While not at all that complex from technical point of view, I don't think it is worth implementing, and whats more maintaining, all this functionality. Probably it would be better if the plugins that produce JAR files use the jar tool, the same way the compiler plugin does not compile by itself but uses the Java compiler. What do you think? [1] https://github.com/codehaus-plexus/plexus-archiver/issues/69#issuecomment-349095101 [2] https://docs.oracle.com/javase/9/tools/jar.htm --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
