Unsure about the actual msgpack-java library, but the jackson-dataformat-msgpack does not support JPMS properly.
Motivation
JPMS is used by the vast majority of publically released libraries. The performance benefits it provides over the generic classpath, and better compile-time verification is very important. Without native support for JPMS, nobody can release a public library using JPMS and msgpack-java safely.
Changes to be made
There are two options that can be considered in order to get proper compatibility:
- The
Automatic-Module-Name header in MANIFEST.MF can be set to something suitable, such as org.msgpack.core/org.msgpack.jackson. This maintains compatibility with Java versions before JPMS, such as Java 8.
- Making a
module-info file and making the project use JPMS. This has stronger encapsulation and is the more future-proof method. The issue with this is that you will need Java 9 or above to build the module-info file. There are ways around this:
- Build the
module-info with Java 9 (or Java 11, the following LTS, as most people do) seperately, and build the rest of the project with Java 8.
- Build the whole project with Java 9/11 and break compatibility with Java 8 entirely (the better option at the end of the day).
Option 1 is the easiest, fastest way to solve the issue.
In any case, the reason this needs to be solved is that nobody can use this library in their libraries otherwise, as it is not safe to publish an artifact that depends on the filename of the module. In this case, as the JAR file is published as jackson-dataformat-msgpack-0.9.3.jar, Java (and Maven/most build tools) automatically resolves it as the module jackson.dataformat.msgpack.
If somebody were to rename the JAR file and add it to their module path, it would not work, and if the project was updated to support JPMS, it would not work anymore, so people using a library previously using this filename based link would have to add this old version to the module path too in order to keep compatibility.
Unsure about the actual
msgpack-javalibrary, but thejackson-dataformat-msgpackdoes not support JPMS properly.Motivation
JPMS is used by the vast majority of publically released libraries. The performance benefits it provides over the generic classpath, and better compile-time verification is very important. Without native support for JPMS, nobody can release a public library using JPMS and
msgpack-javasafely.Changes to be made
There are two options that can be considered in order to get proper compatibility:
Automatic-Module-Nameheader in MANIFEST.MF can be set to something suitable, such asorg.msgpack.core/org.msgpack.jackson. This maintains compatibility with Java versions before JPMS, such as Java 8.module-infofile and making the project use JPMS. This has stronger encapsulation and is the more future-proof method. The issue with this is that you will need Java 9 or above to build the module-info file. There are ways around this:module-infowith Java 9 (or Java 11, the following LTS, as most people do) seperately, and build the rest of the project with Java 8.Option 1 is the easiest, fastest way to solve the issue.
In any case, the reason this needs to be solved is that nobody can use this library in their libraries otherwise, as it is not safe to publish an artifact that depends on the filename of the module. In this case, as the JAR file is published as
jackson-dataformat-msgpack-0.9.3.jar, Java (and Maven/most build tools) automatically resolves it as the modulejackson.dataformat.msgpack.If somebody were to rename the JAR file and add it to their module path, it would not work, and if the project was updated to support JPMS, it would not work anymore, so people using a library previously using this filename based link would have to add this old version to the module path too in order to keep compatibility.