Why is java_executable_exec_path giving me a legacy "external" runfiles path

Question

Suppose I've got a minimal Scala WORKSPACE file like this:

workspace(name = "scala_example")

git_repository(
    name = "io_bazel_rules_scala",
    commit = "e9e65ada59823c263352d10c30411f4739d5df25",
    remote = "https://github.com/bazelbuild/rules_scala",
)

load("@io_bazel_rules_scala//scala:scala.bzl", "scala_repositories")
scala_repositories()

load("@io_bazel_rules_scala//scala:toolchains.bzl", "scala_register_toolchains")
scala_register_toolchains()

And then a BUILD:

load("@io_bazel_rules_scala//scala:scala.bzl", "scala_binary")

scala_binary(
    name = "example-bin",
    srcs = glob(["*.scala"]),
    main_class = "Example",
)

And an Example.scala:

object Example { def main(args: Array[String]): Unit = println("running") }

I can run bazel run example-bin and everything works just fine. My problem is that this recent rules_scala PR changed the way the Java binary path is set to use the following:

ctx.attr._java_runtime[java_common.JavaRuntimeInfo].java_executable_exec_path

…instead of the previous ctx.executable._java.short_path.

After this change the Java binary path includes an external directory in the path, which seems to be a legacy thing (?). This means that after this change, if I run the following:

bazel run --nolegacy_external_runfiles example-bin

It no longer works:

INFO: Running command line: bazel-bin/example-bin
.../.cache/bazel/_bazel_travis/03e97e9dbbfe483081a6eca2764532e8/execroot/scala_example/bazel-out/k8-fastbuild/bin/example-bin.runfiles/scala_example/example-bin_wrapper.sh: line 4: .../.cache/bazel/_bazel_travis/03e97e9dbbfe483081a6eca2764532e8/execroot/scala_example/bazel-out/k8-fastbuild/bin/example-bin.runfiles/scala_example/external/local_jdk/bin/java: No such file or directory
ERROR: Non-zero return code '127' from command: Process exited with status 127

It also breaks some scripts I have that expect non-external paths.

Why is java_executable_exec_path giving me this external path? Is there some option I can give bazel to convince it not to do this?

Answer 1

Sorry for the slow reply -- it appears that this is because the Scala rules erroneously used java_executable_exec_path whereas they should have used java_executable_runfiles_path.

I sent a pull request to fix it, then I realized that you already did in https://github.com/bazelbuild/rules_scala/commit/4235ef58782ce2ec82981ea70b808397b64fe7df

Since the latter is now available at HEAD with Bazel, I'll remove the ugly if at least.