incompatible_use_toolchain_providers_in_java_common: pass JavaToolchainInfo and JavaRuntimeInfo providers to java_common APIs instead of configured targets

[cushon]

The option --incompatible_use_toolchain_providers_in_java_common makes java_toolchain and host_javabase APIs in java_common accept the java_common.JavaToolchainInfo and java_common.JavaRuntimeInfo providers instead of configured targets.

This change is being made in preparation for migrating the Java to use Toolchain Resolution (#4592).

Migration Notes

Update all java_common APIs with the parameters java_toolchain or host_javabase to use the find_java_runtime_toolchain and find_java_toolchain utilities:

+@load("@bazel_tools//tools/jdk:toolchain_utils.bzl", "find_java_runtime_toolchain", "find_java_toolchain")

java_common.compile(
  ...,
-  java_toolchain = ctx.attr._java_toolchain,
-  host_javabase = ctx.attr._host_javabase,
+  java_toolchain = find_java_toolchain(ctx, ctx.attr._java_toolchain),
+  host_javabase = find_java_runtime_toolchain(ctx, ctx.attr._host_javabase),
)

The ctx and java_toolchain_attr parameters of java_common.default_javac_opts have been replaced with java_toolchain:

+@load("@bazel_tools//tools/jdk:toolchain_utils.bzl", "find_java_toolchain")

javacopts = java_common.default_javac_opts(
-    ctx,
-    java_toolchain_attr = "_java_toolchain",
+    find_java_toolchain(ctx, ctx.attr._java_toolchain),
)

[ittaiz]

Is this already available? Asking since I’m planning on moving rules_scala to new java_common and JavaInfo APIs and would rather not have another round later

…

On Sat, 19 Jan 2019 at 2:36 Liam Miller-Cushon ***@***.***> wrote: The option --incompatible_use_toolchain_providers_in_java_common makes java_toolchain and host_javabase APIs in java_common accept the java_common.JavaToolchainInfo and java_common.JavaRuntimeInfo providers instead of configured targets. This change is being made in preparation for migrating the Java to use Toolchain Resolution (#4592 <#4592>). Migration Notes Update all java_common APIs with the parameters java_toolchain or host_javabase to use java_common.JavaToolchainInfo and java_common.JavaRuntimeInfo: java_common.compile( ...,- java_toolchain = ctx.attr._java_toolchain,- host_javabase = ctx.attr._host_javabase,+ java_toolchain = ctx.attr._java_toolchain[java_common.JavaToolchainInfo],+ host_javabase = ctx.attr._host_javabase[java_common.JavaRuntimeInfo], ) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7186>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF1i45DgiRKBF4Rd-GOIM1pVlTUTzks5vEmifgaJpZM4aI29U> .

[cushon]

It isn't available yet. Support for passing providers instead of targets will probably make it into 0.23, and support for passing targets will be removed some time that after.

[meteorcloudy]

Why did this flag get flipped? 0.22 is not a migration window for it and 0.23.0 is not released.

[hlopko]

Reopening because of a rollback.

[hlopko]

Pls wait with this at least for 0.23 release.

[cushon]

For posterity the rollback was ce74927 for #7537.

@meteorcloudy the flag was flipped after the baseline was cut for 0.23, which was consistent with the policy requirements.

Please re-open incompatible change bugs and coordinate with the release manager if you have to roll back flag flips for incompatible change.

[ejona86]

As discussed in grpc/grpc-java#5383, it seems it is not possible to migrate in Bazel 0.23 because it is missing functionality in find_java_toolchain and find_java_runtime_toolchain. So can the migration-0.23 label be removed?