Skip to content

Conversation

@dpratt
Copy link

@dpratt dpratt commented Jun 14, 2022

Ensure that an Automatic-Module-Name entry is added to the final
MANIFEST.MF file in the produced jar. This will allow users of the
library to properly import and use it on the module path with a
stable, well-known name.

This commit does not change this library itself to be a modular jar,
nor does it incorporate any features that would break backwards
compatibility with JDK 7-8 clients.

Ensure that an Automatic-Module-Name entry is added to the final
MANIFEST.MF file in the produced jar. This will allow users of the
library to properly import and use it on the module path with a
stable, well-known name.

This commit does *not* change this library itself to be a modular jar,
nor does it incorporate any features that would break backwards
compatibility with JDK 7-8 clients.
@vickenty
Copy link
Contributor

vickenty commented Jul 4, 2022

Thank you for the suggestion! As it changes the module name, I believe this would be a breaking change for module aware builds, wouldn't it?

@dpratt
Copy link
Author

dpratt commented Jul 5, 2022

Thank you for the suggestion! As it changes the module name, I believe this would be a breaking change for module aware builds, wouldn't it?

This introduces a module name rather than changing it. Prior to this PR, the published jar artifact does not contain a module name in either a module-info.class file or an Automatic-Module-Name entry in the manifest. I don’t think this change can ‘break’ a modular build, in that they likely aren’t working in any meaningful sense without it. If you don’t have an explicit module name supplied, both the compiler and the runtime will create one based off the file name of the jar, which is basically a completely unstable and not recommended way to deal with a module. In fact, most build tools will emit all kinds of warnings if you attempt to use a non-modular jar in the modulepath in this way.

This PR adds an Automatic-Module-Name entry to the manifest, which is the recommended step to take for all artifacts that want to have a stable name (and thus be able to be consumed as modules) but do not want to go through the effort of fully upgrading to be a first class modular jar themselves.

edit: to distill down the point made above, without this PR you just can’t use this library on the module path in any meaningful sense.

@rob-bygrave
Copy link

I am wondering why this PR isn't merged? Is there a reason we don't want an Automatic-Module-Name entry in the manifest?

If this library stays at the current Java level and there are no plans for a increase of the Java level to 9+ ... then I think we would desire the Automatic-Module-Name entry in the manifest in order to support module path.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants