Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This changeset attempts to discover the minimal set of changes necessary to add
module-info.java
definitions to Protocol Buffers. Fixes and closes #16133.This is a draft PR for now. I'm looking for feedback and to setup an integration testsuite downstream with popular Protobuf-based projects to make sure things work as expected.
Note
Re-filing after a bad rebase on #16178.
PR Tree
This PR is applied on top of the following:
6.3.2
#16171Relevant PRs + issues upstream
annotations
google/error-prone#4311annotations
module google/j2objc#2302JAR Structure
JARs issued as part of the Protobuf Java release now have
Multi-Release: true
instead ofAutomatic-Module-Name
within theirMANIFEST.MF
, making them eligible to be considered as Multi-Release JARs (or, MRJARs). Such JARs can include amodule-info.class
without interfering with bytecode targeting at JDK8 or earlier, where modules are not supported yet. These JARs are thus called "modular MRJARs."For example, after building Protobuf Java with
bazel build //java:release
,vim bazel-bin/java/core/amended_lite_mvn-project.jar
shows:JAR structure:
In the
MANIFEST.MF
:Modular Java downstream
For projects that build with Protobuf Java on the
classpath
, no change is experienced by the end-user; for projects which build onmodulepath
:Open module
Protobuf, Protobuf Util, and Protobuf Kotlin are expressed as
open
modules. This is the case because Protobuf Java is often used reflectively by library consumers. By default, all packages provided by Modular Java protobuf artifacts areopen
as a result.Exports + Lite Variants
Protobuf Java Core, Protobuf Java Util, and Protobuf Kotlin all reside in one package path each, which is extremely lucky and convenient for Modular Java because there is no split package problem.
Kotlin Lite/Kotlin and Java Core/Java Lite are meant to be used exclusively within the
classpath
, but there is no enforcement possible for this case from the compiler or VM, at least not in a consistent way across environments. Building on themodulepath
solves this because Kotlin Lite/Kotlin and Java Core/Java Lite share a module coordinate and export an identical package path.Thus, only one of (Kotlin/Kotlin Lite) and (Java Core/Java Lite) can be used at a time when building on the
modulepath
. This guarantee is enforced by the compiler and by the JVM at runtime.Changelog
rules_kotlin