Skip to content

Add extra information to the module JAR files module descriptors #69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
plamentotev opened this issue Aug 29, 2017 · 8 comments
Closed

Comments

@plamentotev
Copy link
Member

The JDK jar tool adds additional information to the module JAR files module descriptors. Such information includes the list of the packages part of the module and hashes of the module.

It would be nice if Plexus Archiver provides similar functionality where it is applicable.

@plamentotev
Copy link
Member Author

plamentotev commented Dec 4, 2017

I dug some more and here is a least with all the additional attributes that the JDK jar tool adds to the module descriptor:

  • 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:

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.

I don't think it is worth implementing, and whats more maintaining, all this functionality. Probably it will 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?

@plamentotev
Copy link
Member Author

plamentotev commented May 27, 2018

With the release of 3.6.0 we have support for the module main class and version. The list of contained packages is automatically updated. So the only two items left are the hashes and module resolution(as far as I know there is no way to configure it using the JDK jar tool too so I would say we don't have to support it for the time being).

@rfscholte
Copy link
Member

@plamentotev @hboutemy this would be the standalone solution, but seems pretty complicated.
The implementation of the JarToolModularJarArchiver has one problem: it is not reproducible.

@plamentotev
Copy link
Member Author

Yes, unfortunately JarToolModularJarArchiver is not reproducible. The jar tool itself does not produce reproducible jars. @rfscholte do you think we have any chance asking the OpenJDK team to make the jar tool produce reproducible jars?

@michael-o
Copy link
Member

There is already an issue with JBS.

@hboutemy
Copy link
Member

hboutemy commented Jun 5, 2022

fixed in #205

@hboutemy hboutemy closed this as completed Jun 5, 2022
@plamentotev
Copy link
Member Author

@hboutemy maybe I'm missing, but I'm not sure how #205 fixes this.

@jorsol
Copy link
Contributor

jorsol commented Jul 15, 2022

@plamentotev I think there is confusion with the comment about JarToolModularJarArchiver is not reproducible, the #205 fixes the reproducible part (at least the timestamp issue).

But adding the extra information to the module JAR is definitely not related to that issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants