Automatic-Module-Name entry missing since release 3.21.12

[xazap]

Issue Any newer release of protobuf-java after 3.21.12 is missing the Automatic-Module-Name entry in the META-INF/MANIFEST.MF file. This prevents using the protobuf module with a stable name instead. Instead, we are forced to the bad practice of using a filename-inferred module name.

Please restore the Automatic-Module-Name entry in the manifest or (alternatively) provide a proper module-info.class in the library.

What version of protobuf and what language are you using? Versions containing the issue are 3.22.0, 3.22.1, 3.22.2, 3.22.3 and 3.23.0-RC2 Last version to be correct: 3.21.12 Language: Java

What operating system (Linux, Windows, ...) and version? Irrelevant as issue pertains to the Java Platform Module System.

What runtime / compiler are you using (e.g., python version or gcc version) Java 17

What did you do?

1. Add "requires transitive com.google.protobuf;" to the module-info.java of a project using protobuf-java.
2. Find compilation error due to "com.google.protobuf" cannot be resolved to a module.
3. Find that the protobuf manifest contains no Automatic-Module-Name since version 3.21.12

What did you expect to see I expected an Automatic-Module-Name entry in META-INF/MANIFEST.MF. This was last seen in version 3.21.12.

What did you see instead? I found no Automatic-Module-Name entry in META-INF/MANIFEST.MF.

Note I reported this before in #12175, which was closed because it was suggested the fix for #12017 would also restore the Automatic-Module-Name entry. However with #12017 fixed the OSGi entries are restored but the Automatic-Module-Name entry is still missing from the manifest.

[yeefan]

Versions 3.22.4 and 3.23.0 also have this issue. Therefore modular projects have difficulty upgrading protobuf-java beyond 3.21.12.

[charphi]

Automatic-Module-Name entry is still missing in version 3.23.2

[bowbahdoe]

Bumping to see if there is any reason not to add a full module-info? Is it just the build process that needs to be figured out? Would be helpful so that downstream libraries like http://www.jbox2d.org/ or many others can become jlink-compatible

[charphi]

Automatic-Module-Name entry is still missing in version 3.24.3

[dornand]

Please fix this. We're stuck with 3.21.12 for the moment. Any newer version is basically useless on the Java platform.

[Sineaggi]

I've opened https://github.com/protocolbuffers/protobuf/pull/14562 to address this.

[deannagarcia]

Thanks for surfacing this, and thanks for the PR! Reviewing it now.

[bowbahdoe]

@deannagarcia If #14562 gets merged, can we have another issue for adding an actual module-info? I don't want that to get lost

[deannagarcia]

I thought that PR added a module-info. What more is needed?

[bowbahdoe]

@deannagarcia

It adds an Automatic-Module-Name, that is just a manifest entry. An actual module-info would be a class file that says what modules are required, what packages are exported, service provider usages, and whether classes are open to deep reflection.

For projects that want to forever support Java < 8, this means making a multi-release jar, which in turn means tweaking the build process.

I know how to do that with Maven and have submitted PRs to other repos and I know the flags to use with javac and jar, but I have no clue how to do that with bazel.

if protobuf was java 9+, it would mean adding a module-info.java to the top level like

module com.google.protobuf {
    exports com.google.protobuf;
}

When everything in a dependency tree has those explicit module-infos, then tools like jlink and jpackage work for people without any extra configuration. But that only happens when everything does.

So take the example I used http://www.jbox2d.org/. If someone wants to make a game and they use jbox2d, if it and every dependency of it have module descriptors, they can use jpackage to get an installer for their game very similarly to minecraft (in fact, I think that is what minecraft does).

With just the automatic module name, someone can publish a module to maven central and just know that the module name for the dependency is stable and not based on a file name. Thats not nothing, but its not the ideal end state for the ecosystem.

[omarkj]

Thanks for getting this change in. I'm looking at version 3.25.1 of the library and it does not look like this fix made it in before it was cut as Automatic-Module-Name is not present in MANIFEST.MF. Do you expect to cut another minor version to include this change?

I do notice that the attribute is set for version 4 RCs.

[je-ik]

Unfortunately the module name is still missing in 3.25.2.

[pedrolamarao]

I have just been hit (again) by this issue. For those coming here unawares, version 4.0.0-rc-2 is bogus: it is in fact an abandoned major version number. Those of us who need JPMS ready JARs need to stick to the old 3.21.12 version for now.

[zhangskz]

https://github.com/protocolbuffers/protobuf/commit/d580fde63aa8ea5c6f4619396e68aaf017fc9d61#diff-580cdf6ec10b074d78ecc4a185c2f5ca053ae488c7ec41cd957f6dab0d9cf9e8 should have been released in 26.x which should add back Automatic-Module-Name to manifest.

Please reopen if this is still not working with 26.x+. Note that 26.x was a breaking release for Java, so we may backport this back to 25.x.

Another issue should be filed to track request to add add module-info.java, though I'm not sure we have capacity to do this right now and our support is for Java 8+ per https://cloud.google.com/java/docs/supported-java-versions

[dornand]

Thanks! Backporting to 25.x would be great.