Repository: bazelbuild/bazel
Issue: incompatible_load_proto_toolchain_for_javalite_from_com_google_protobuf: Use javalite toolchain from Protobuf master
Labels: P2
team-Rules-Server
incompatible-change

Flag: `--incompatible_load_proto_toolchain_for_javalite_from_com_google_protobuf`
Available since: 2.2
Will be flipped in: 3.0
Tracking issue: #9992

Historically, the runtime for `java_lite_proto_library` was developed in a dedicated branch of the [Protobuf repository](https://github.com/protocolbuffers/protobuf/tree/javalite). Recently, this was changed, and the latest javalite runtime/toolchain is now available on master (and will be in future releases). This incompatible flag changes the default value of `--proto_toolchain_for_javalite` to point to the new toolchain on master.

To become compatible with this incompatible change, users will have to update their version of Protobuf. We will not flip this flag before a compatible Protobuf release has been available for at least 6 weeks.

Note for triage: This is probably `P2` and `team-Rules-Server`. Please also add `incompatible-change` and `breaking-change-3.0` (and maybe assign it to me).

# Migration

If you are using `java_proto_library`, you need to update your `WORKSPACE` to load Protobuf (`@com_google_protobuf`) to version 3.11.3 or later. Starting with Bazel 3.0, you can start removing uses of `@com_google_protobuf_javalite` from your `BUILD`-files and delete it from `WORKSPACE`.

//cc @steeve @lberki @hlopko

Issue comments:
@irengrig This flag was added in https://github.com/bazelbuild/bazel/commit/613de1fbbff10de5d6f99f15882fb145a5007f7e. Can you add the labels to get this tested on the incompatible pipeline?
If this flag is not available in 2.0 and 2.1, can we remove the labels so bazelisk works well?
We're supposed to cut Bazel 3.0 now. Was this flag flipped?
Argh, no. Let me send a change.
I prepared a PR for flipping this some time ago, but it was blocked on the release of Bazel 2.2.
Feel free to use https://github.com/bazelbuild/bazel/pull/10745 as inspiration :).
Indeed! Let me just import it then.

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/com/google/devtools/build/lib/bazel/rules/java/proto/BazelJavaLiteProtoAspect.java b/src/main/java/com/google/devtools/build/lib/bazel/rules/java/proto/BazelJavaLiteProtoAspect.java
index 636aab18349995..1e9e4f79409828 100644
--- a/src/main/java/com/google/devtools/build/lib/bazel/rules/java/proto/BazelJavaLiteProtoAspect.java
+++ b/src/main/java/com/google/devtools/build/lib/bazel/rules/java/proto/BazelJavaLiteProtoAspect.java
@@ -22,7 +22,7 @@
 public class BazelJavaLiteProtoAspect extends JavaLiteProtoAspect {
 
   public static final String DEFAULT_PROTO_TOOLCHAIN_LABEL =
-      "@com_google_protobuf_javalite//:javalite_toolchain";
+      "@com_google_protobuf//:javalite_toolchain";
 
   public BazelJavaLiteProtoAspect(RuleDefinitionEnvironment env) {
     super(BazelJavaSemantics.INSTANCE, DEFAULT_PROTO_TOOLCHAIN_LABEL, env);
diff --git a/src/main/java/com/google/devtools/build/lib/rules/proto/ProtoConfiguration.java b/src/main/java/com/google/devtools/build/lib/rules/proto/ProtoConfiguration.java
index 941638dba6dd00..ba8725eb45bf87 100644
--- a/src/main/java/com/google/devtools/build/lib/rules/proto/ProtoConfiguration.java
+++ b/src/main/java/com/google/devtools/build/lib/rules/proto/ProtoConfiguration.java
@@ -187,7 +187,7 @@ public static class Options extends FragmentOptions {
 
     @Option(
         name = "incompatible_load_proto_toolchain_for_javalite_from_com_google_protobuf",
-        defaultValue = "false",
+        defaultValue = "true",
         documentationCategory = OptionDocumentationCategory.UNDOCUMENTED,
         effectTags = {OptionEffectTag.LOADING_AND_ANALYSIS},
         metadataTags = {


Test patch: