Re: main-class + module-version

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Plamen Totev-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Plamen Totev-2
Hi,

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
> haves.

I guess you're right. We already have the version and main class[1] -
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.

Regards,
Plamen Totev

[1] https://github.com/codehaus-plexus/plexus-archiver/pull/75

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Plamen Totev-2
Hi,

I've done some work on implementing `PlexusArchiver` that creates
modular JAR files using the JDK `jar` tool (`ToolProvider`)[1]. It is
still work in progress but I wanted to ask for you opinion - if there
are no objections I'll polish it(fix the code formatting, implement the
TODO items, etc) and would like eventually to merge it in master. Here
are some key points:

* It requires Java 9. This of course is not the minimum required version
for the rest of the archivers, but `java.util.spi.ToolProvider` is
introduced in Java 9. I'll fix the source and target to be 7, but it
will still require Java 9 to compile and currently Plexus Archiver does
not compile on Java 9. This is easy to fix - requires only update of
some of the plugins to yet to be released versions.

* A new class is added `ModularJarArchiver`. This would allow a "normal"
JARs to be created on Java 7 using `JarArchiver` while modular JARs will
require Java 9 (I don't think this is an issue as you need Java 9 to
compile modules anyway).

* `ModularJarArchiver` uses `JarArchiver` to create a "normal" JAR file
and then uses the JDK `jar` tool to update it to modular one. This may
require some additional work during the build compared to creating the
archive using only the `jar` tool, but `JarArchiver` provides some nice
additional features not available in the `jar` tool(such as not
re-compressing the zip files, generating manifest entries, etc).

What do you think? Any objections to implement it this way? I think this
is better approach than my previous attempt[2].

Regards,
Plamen Totev

[1] https://github.com/plamentotev/plexus-archiver/commit/b124aceb3f6a912a9dca44f5d14b9f3f2919bc6d
[2] https://github.com/codehaus-plexus/plexus-archiver/pull/75

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]