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 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
> 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.
On Mon, Jan 15, 2018 at 8:23 PM, Robert Scholte <[hidden email]> wrote:
> So maybe we simply have to split it up into smaller pieces.
> I think we can already make people happy by adding the version to the
> module-info file, assuming all other added features are actually nice to
I guess you're right. We already have the version and main class -
I'll update the PR so it compiles and passes the tests.
As for the version - the module version could be set by the compiler
as well. I was thinking that maybe it would be nice if the compiler
plugin passes the project version to the Java compiler.