Skip to content
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

Java: Add Automatic-Module-Name entries to the Manifest #6568

Merged
merged 1 commit into from Aug 30, 2019

Conversation

@ennerf
Copy link
Contributor

commented Aug 26, 2019

This PR adds Automatic-Module-Name entries to the Manifest files. This allows Java9+ users to depend on protobuf, without having any impact for users of earlier versions.

The module names match the OSGI symbolic names as recommended in JLBP-20

This fixes #3903 and #6493

@googlebot googlebot added the cla: yes label Aug 26, 2019

@ennerf ennerf changed the title Add Automatic-Module-Name entries to the Manifest Java: Add Automatic-Module-Name entries to the Manifest Aug 26, 2019

@TeBoring TeBoring requested a review from rafi-kamal Aug 28, 2019

@elharo
Copy link
Contributor

left a comment

I think this one should go into the release notes.

@elharo
Copy link
Contributor

left a comment

As @netdpb suggested, the question here is the relation ship between the lite and regular artifacts. If both can reasonably appear in a classpath at the same time this won't work. Anyone know the distinction between these two?

Since lite is mostly for android which doesn't use Java 9+, it might make sense to drop the lite/pom.xml from this PR until we're sure.

@ennerf

This comment has been minimized.

Copy link
Contributor Author

commented Aug 30, 2019

At the moment the lite version is a subset of the regular artifact. Considering that both artifacts use the same package and filenames they are guaranteed to always conflict, and users should really avoid having both of them in the same project.

For example, a regular and a lite runtime with different versions may end up loading a shared class like com.google.protobuf.Utf8 that is incompatible with the other. (At the moment it looks like pretty much everything is shared because all messages extend AbstractMessageLite)

The worst case would be if a dependency transitively adds the lite-runtime, but in that case users could manually exclude it. Any generated lite-messages would still run fine against the regular runtime.

Personally, I'd actually prefer to get a compile time error rather than potentially running into obscure issues at runtime.

@elharo

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2019

FWIW in Java 9 and later you will get a compile time error if both of these appear in the classpath.

@elharo
elharo approved these changes Aug 30, 2019

@rafi-kamal rafi-kamal merged commit bc1773c into protocolbuffers:master Aug 30, 2019

56 checks passed

Bazel Kokoro build successful
Details
Dist artifact installation Kokoro build successful
Details
Linux 32-bit Kokoro build successful
Details
Linux C# Kokoro build successful
Details
Linux C++ Distcheck Kokoro build successful
Details
Linux C++ TC Malloc Kokoro build successful
Details
Linux Golang Kokoro build successful
Details
Linux Java Compatibility Kokoro build successful
Details
Linux Java JDK 7 Kokoro build successful
Details
Linux Java Linkage Monitor Kokoro build successful
Details
Linux Java Oracle 7 Kokoro build successful
Details
Linux JavaScript Kokoro build successful
Details
Linux PHP Kokoro build successful
Details
Linux Python Kokoro build successful
Details
Linux Python 2.7 Kokoro build successful
Details
Linux Python 2.7 C++ Kokoro build successful
Details
Linux Python 3.3 Kokoro build successful
Details
Linux Python 3.3 C++ Kokoro build successful
Details
Linux Python 3.4 Kokoro build successful
Details
Linux Python 3.4 C++ Kokoro build successful
Details
Linux Python 3.5 Kokoro build successful
Details
Linux Python 3.5 C++ Kokoro build successful
Details
Linux Python 3.6 Kokoro build successful
Details
Linux Python 3.6 C++ Kokoro build successful
Details
Linux Python 3.7 Kokoro build successful
Details
Linux Python 3.7 C++ Kokoro build successful
Details
Linux Python C++ Kokoro build successful
Details
Linux Python Compatibility Kokoro build successful
Details
Linux Python Release Kokoro build successful
Details
Linux Ruby 2.3 Kokoro build successful
Details
Linux Ruby 2.4 Kokoro build successful
Details
Linux Ruby 2.5 Kokoro build successful
Details
Linux Ruby 2.6 Kokoro build successful
Details
Linux Ruby Release Kokoro build successful
Details
MacOS C++ Kokoro build successful
Details
MacOS C++ Distcheck Kokoro build successful
Details
MacOS JavaScript Kokoro build successful
Details
MacOS Obj-C CocoaPods Integration Kokoro build successful
Details
MacOS Obj-C OS X Kokoro build successful
Details
MacOS Obj-C iOS Debug Kokoro build successful
Details
MacOS Obj-C iOS Release Kokoro build successful
Details
MacOS PHP5.6 Kokoro build successful
Details
MacOS PHP7.0 Kokoro build successful
Details
MacOS Python Kokoro build successful
Details
MacOS Python C++ Kokoro build successful
Details
MacOS Python Release Kokoro build successful
Details
MacOS Ruby 2.3 Kokoro build successful
Details
MacOS Ruby 2.4 Kokoro build successful
Details
MacOS Ruby 2.5 Kokoro build successful
Details
MacOS Ruby 2.6 Kokoro build successful
Details
MacOS Ruby Release Kokoro build successful
Details
Mergeable Mergeable Run has been Completed!
Details
Windows C# Kokoro build successful
Details
Windows Csharp Release Kokoro build successful
Details
Windows Python Release Kokoro build successful
Details
cla/google All necessary CLAs are signed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.