Java 9 should be supported

[dfabulich]

java_toolchain requires a bootstrap classpath, including rt.jar, but Java 9 no longer has rt.jar or anything like that.

java_toolchain has to be rethought for Java 9 support

[lberki]

Sadly, this will have to wait until we get proper support for Java 9, which means quite a bit of work internally.

/cc @cushon

[davido]

@lberki can you quantify "quite a bit of work" in term of time frame? Google is usually years behind bumping its internal Java tool chain to very recent JDK after the day it was released. Final Java 9 release was previously scheduled to July 2017 and was postponed to September 2017. My expectation would be that the day, Java 9 final is released, Bazel supports it. Your comment sounds like, it could happen, that Bazel users would have to wait for months (or years?) for that to happen.

[lberki]

It will happen and definitely not within years, but also probably not sooner than months. It's just another thing we have to fit into our schedule and unfortunately, it's not amenable to being done by non-Googler contributors since we need to make sure that it integrates well with our internal repository. We can shuffle around priorities if there is good reason but my best understanding is that Java 9 is not a hard blocker for anyone, at least for the time being.

[iirina]

Hi all,

I posted a question about the interest in java 9 on bazel-discuss. It also contains an update on when we might support it. Can you comment there about your expectations? Thanks!

[shs96c]

I'd echo @davido's comment above, and @dfabulich's experience: bazel must, at the very least, be able to run on a system with java 9 installed, and that needs to happen ASAP.

Compiling to java 9 is less urgent. Early Q1 2018 might be okay, but end of Q1 is too long --- I want to start taking advantage of new language features RSN. I guess I could specify a java_toolchain to make this work as a hack, but I'd need to be able to do that on a per-clone basis (so I can work on my Mac and have CI on a linux box)

Actually taking advantage of java modules would be a killer feature, but given the slow adoption of java 8, it's the least pressing feature.

[cushon]

bazel must, at the very least, be able to run on a system with java 9 installed

@shs96c does this mean supporting blaze build --host_javabase=<jdk9> ..., or something else?

[dfabulich]

Something else. If you export JAVA_HOME=<jdk9>, Bazel refuses to start, even when you install a version of Bazel that embeds its own JVM.

…

-Dan

On Sep 25, 2017, at 6:46 PM, Liam Miller-Cushon ***@***.***> wrote: bazel must, at the very least, be able to run on a system with java 9 installed @shs96c <https://github.com/shs96c> does this mean supporting blaze build --host_javabase=<jdk9> ..., or something else? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3410 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAF3lhlicrZcj9wSmx8sGJyFL9jMzhR1ks5smFeHgaJpZM4Ob8zC>.

[davido]

I think this diff should fix Bazel start:

diff --git a/src/main/cpp/startup_options.cc b/src/main/cpp/startup_options.cc
index 27c3d7184..fdfb3c8e2 100644
--- a/src/main/cpp/startup_options.cc
+++ b/src/main/cpp/startup_options.cc
@@ -460,17 +460,8 @@ string StartupOptions::GetJvm() {
     }
     exit(1);
   }
-  // If the full JDK is installed
-  string jdk_rt_jar = blaze_util::JoinPath(GetHostJavabase(), "jre/lib/rt.jar");
-  // If just the JRE is installed
-  string jre_rt_jar = blaze_util::JoinPath(GetHostJavabase(), "lib/rt.jar");
-  if (blaze_util::CanReadFile(jdk_rt_jar) ||
-      blaze_util::CanReadFile(jre_rt_jar)) {
-    return java_program;
-  }
-  fprintf(stderr, "Problem with java installation: "
-      "couldn't find/access rt.jar in %s\n", GetHostJavabase().c_str());
-  exit(1);
+  // TODO(davido): Find out a better way to check whether full JDK installed.
+  return java_program;
 }

The next failure if I try to use JDK9 with custom built bazel to compile one single java source file is:

$ /home/davido/projects/bazel/bazel-bin/src/bazel build :printy_lib --verbose_failures
INFO: Found 1 target...
ERROR: missing input file '@local_jdk//:jre/lib/rt.jar'.
ERROR: Process terminated by signal 15.

I think, that this is defined here: https://github.com/bazelbuild/bazel/blob/master/tools/jdk/BUILD#L110-L116.

BOOTCLASS_JARS = [
    "rt.jar",
    "resources.jar",
    "jsse.jar",
    "jce.jar",
    "charsets.jar",
]

If I remove them:

diff --git a/tools/jdk/BUILD b/tools/jdk/BUILD
index 5c8baac96..af80081ea 100644
--- a/tools/jdk/BUILD
+++ b/tools/jdk/BUILD
@@ -107,13 +107,7 @@ filegroup(
     srcs = ["//tools/jdk:VanillaJavaBuilder_deploy.jar"],
 )
 
-BOOTCLASS_JARS = [
-    "rt.jar",
-    "resources.jar",
-    "jsse.jar",
-    "jce.jar",
-    "charsets.jar",
-]
+BOOTCLASS_JARS = []
 
 alias(
     name = "bootclasspath",

and rebuild bazel with JDK8, and try again to use JDK8 to build one single java source, I get this failure now:

$ /home/davido/projects/bazel/bazel-bin/src/bazel build :printy_lib --verbose_failures
.................
INFO: Found 1 target...
ERROR: /home/davido/projects/bazel_printy/BUILD:1:1: Building libprinty_lib.jar (1 source file) failed: IOException while borrowing a worker from the pool:

---8<---8<--- Exception details ---8<---8<---
java.io.IOException: Cannot run program "/home/davido/.cache/bazel/_bazel_davido/1d26503054d6b6be1850338cefd090db/execroot/__main__/external/local_jdk/bin/java" (in directory "/home/davido/.cache/bazel/_bazel_davido/1d26503054d6b6be1850338cefd090db/execroot/__main__"): error=2, No such file or directory
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1128)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
	at com.google.devtools.build.lib.worker.Worker.createProcess(Worker.java:83)
	at com.google.devtools.build.lib.worker.WorkerFactory.create(WorkerFactory.java:69)
	at com.google.devtools.build.lib.worker.WorkerFactory.create(WorkerFactory.java:30)
	at org.apache.commons.pool2.BaseKeyedPooledObjectFactory.makeObject(BaseKeyedPooledObjectFactory.java:62)
	at org.apache.commons.pool2.impl.GenericKeyedObjectPool.create(GenericKeyedObjectPool.java:1036)
	at org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:356)
	at org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:278)
	at com.google.devtools.build.lib.worker.WorkerPool.borrowObject(WorkerPool.java:41)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.execInWorker(WorkerSpawnRunner.java:259)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.actuallyExec(WorkerSpawnRunner.java:155)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.exec(WorkerSpawnRunner.java:110)
	at com.google.devtools.build.lib.exec.AbstractSpawnStrategy.exec(AbstractSpawnStrategy.java:96)
	at com.google.devtools.build.lib.exec.AbstractSpawnStrategy.exec(AbstractSpawnStrategy.java:64)
	at com.google.devtools.build.lib.analysis.actions.SpawnAction.internalExecute(SpawnAction.java:259)
	at com.google.devtools.build.lib.analysis.actions.SpawnAction.execute(SpawnAction.java:266)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor.executeActionTask(SkyframeActionExecutor.java:850)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor.prepareScheduleExecuteAndCompleteAction(SkyframeActionExecutor.java:793)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor.access$900(SkyframeActionExecutor.java:107)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$ActionRunner.call(SkyframeActionExecutor.java:661)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$ActionRunner.call(SkyframeActionExecutor.java:618)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor.executeAction(SkyframeActionExecutor.java:404)
	at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.checkCacheAndExecuteIfNeeded(ActionExecutionFunction.java:440)
	at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.compute(ActionExecutionFunction.java:201)
	at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:338)
	at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:352)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
	at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.io.IOException: error=2, No such file or directory
	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:339)
	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:270)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1107)
	... 30 more
---8<---8<--- End of exception details ---8<---8<---.
Target //:printy_lib failed to build
INFO: Elapsed time: 4.101s, Critical Path: 0.24s

To reproduce, bazel_printy is here: [1]. The CL is here: [2].

• [1] https://github.com/davido/bazel_printy
• [2] https://bazel-review.googlesource.com/17350

[ilovezfs]

What is the status here? I'm not eager to use wrapper scripts on bazel in Homebrew but we will if we have to.

[davido]

As mentioned in my previous comments: it will take years, for Java 9 to be supported in Bazel.

[ilovezfs]

In Homebrew, we're doing this:

iMac-TMP:~ joe$ cat `which bazel`
#!/bin/bash
JAVA_HOME="$(/usr/libexec/java_home --version 1.8+)" exec "/usr/local/Cellar/bazel/0.7.0_1/libexec/bin/bazel" "$@"

iMac-TMP:~ joe$ cat `which bazel-real`
#!/bin/bash
JAVA_HOME="$(/usr/libexec/java_home --version 1.8+)" exec "/usr/local/Cellar/bazel/0.7.0_1/libexec/bin/bazel-real" "$@"
iMac-TMP:~ joe$

It would be nice if this were something bazel could handle internally since I don't think it makes sense to force every downstream to use wrapper scripts just so it doesn't break on systems that have both Java 8 and Java 9 installed.

[cheister]

@davido Can you look at #4045 it should solve some of @ilovezfs issue.

[kamalmarhubi]

Can we separate out the issues of bazel compiling Java 9 source from bazel running under jvm 9? This seems to cover both, but it seems like it should be possible to run bazel with embedded jdk under jvm 9. I propose reopening #3789 to track the running under jvm 9 issue.

[hhclam]

I have gotten a bazel build that works for both JDK8 and JDK9. I created the fork is here: https://github.com/hhclam/bazel/commits/java9. The fork has only one commit with very little code change: hhclam@64212c8.

It's fair to say that it is tricky but Bazel is mostly capable to run in both JDKs. If you build bazel from source with a JDK8 with the fork, e.g.:
bazel build src:bazel

The resultant bazel binary should work with both JDK8 and JDK9. For JDK9 specifically you have to run Bazel with:
bazel build //something --host_java_toolchain=@bazel_tools//tools/jdk:jdk9 --java_toolchain=@bazel_tools//tools/jdk:jdk9

Worker process works with this toolchain. However Turbine (java header compilation) is disabled. The neat things like strict deps and error prone are still intact.

The major non-code change in this commit is to define a new toolchain called "jdk9" which does not have -Xbootclasspath/p and does not use the javac that is bundled with Bazel. It could work with the Bazel-bundled javac since it is a build from OpenJDK 9 but it's confusing. I went even further to stripping the javac (com.sun) classes from the deploy jar to provide a new JavaBuilder without javac and JDK internal classes.

The minor code change is to suppress warnings from jigsaw. The major code change is to accept --patch-module, --add-modules and --add-exports for "javacopts" for java_* and "misc" for java_toolchain. This is needed because a lot of existing code uses JDK internals.

This patch should work with a simple Java application. I was able to build a large-ish swagger application with this patch. The real pain being jigsaw complaining about javax.annotation and jsr305. This affects a lot of generated code including grpc (which uses javax.annotation.Generated). The solution is to create your own java_toolchain (make a copy from the jdk9 toolchain) and then add --patch-module and --add-modules to patch the javax.annotation module with the jsr305 jar.

[davido]

@hhclam Thanks, this is very promising!

I started to use your Bazel patch to build Gerrit Code Review, on Java 9, but it didn't really worked. So far I discovered two problems:

• Error Prone reported false positive
• Auto-Value refused to work (even after upgrading to latest relase 1.5.2)

For the former problem:

ERROR: /home/davido/projects/gerrit2/java/com/google/gerrit/common/BUILD:32:1: Building java/com/google/gerrit/common/libserver.jar (57 source files) failed (Exit 1)
java/com/google/gerrit/common/RawInputUtil.java:34: error: [CheckReturnValue] Ignored return value of method that is annotated with @CheckReturnValue
    Preconditions.checkNotNull(bytes);
                              ^
    (see http://errorprone.info/bugpattern/CheckReturnValue)
  Did you mean to remove this line?
[...]
ERROR: /home/davido/projects/gerrit2/java/com/google/gerrit/util/cli/BUILD:1:1: Building java/com/google/gerrit/util/cli/libcli.jar (6 source files) failed (Exit 1)
java/com/google/gerrit/util/cli/CmdLineParser.java:229: error: [CheckReturnValue] Ignored return value of method that is annotated with @CheckReturnValue
        map.put(ent.getKey(), val);
               ^
    (see http://errorprone.info/bugpattern/CheckReturnValue)
  Did you mean to remove this line?
Target //java/com/google/gerrit/server:server failed to build

I filed this issue: google/error-prone#850, and was able to turn off EP/Bazel integration with javacopt -XepDisableAllChecks" option for now.

For the latter auto-value integration problem: NoClassDefFoundError: javax/annotation/Generated, I haven't found a workaround so far, and filed this issue upstream: google/auto#560. The only way I managed to move forward is to include javax.annotation:javax.annotation-api:1.3.1 as java_plugin dependency:

java_plugin(
    name = "auto-annotation-plugin",
    processor_class = "com.google.auto.value.processor.AutoAnnotationProcessor",
    deps = [
        ":javax-annotation",
        "@auto_value//jar",
    ],
)

but then annotation processor was failing with a NPE on an innocent @AutoAnnotation line of code.

I extracted this reproducer from gerrit and verified, that the reproducer can be built with Java 9, with Maven's compiler-plugin 3.7.0. So that this seems to be a Bazel related issue.

[hhclam]

@davido The issue you are hitting is not Bazel specific but caused by jigsaw. However there's no easy way to solve it in Bazel.

This commit is getting a bit hacky by patching the offending module for all java invocation hhclam@776d7b6

I tested your example that this Bazel build passed. However you'll probably hit another issue with the javax.annotation package. This thread has a lot of relavent information: google/dagger#880

I think to summarize this is: a lot of 3rd party libraries have issue with javax.annotation (potentially other packages as well) due to jigsaw and Bazel provides no way to workaround that easily.

[davido]

@hhclam At least auto-value specific problem can be easily avoided by adding dependency on javax.annotation-api to java_plugin: [1].

The next issue, as you noticed, is gerrit -> rules_closure -> dager related: [2]. Gerrit has two UIs: GWT and JS, so I disabled JS UI for now: [3] and was able to build GWT UI based gerrit with Java 9. This is already not bad, besides that, trying to initialize with Java 9 built gerrit site is failing with NPE: [4].

• [1] http://paste.openstack.org/show/628312
• [2] http://paste.openstack.org/show/628314
• [3] http://paste.openstack.org/show/628315
• [4] http://paste.openstack.org/show/628316

[hhclam]

The NPE issue is with auto-value I believe. I don't know what version of gerrit you're building as the latest revision seems to being using it's own Nullable. You might find more helpful information here: google/auto#283. This is another issue with JDK9 caused by jigsaw and javax.annotation.

[hhclam]

Awsome! Is there a way to do select based on the java version?

[cushon]

Targeting a specific JDK version usually involves setting --java_toolchain and --javabase, which can be selected on.

[davido]

@cushon

On bazel master (db65f80) Java 9 support seems to be broken again: [1].

java.lang.IllegalStateException: option --add-modules not allowed with target 1.8

I think it worked already, or should i pass in addition to Java 9 specific options: -target 9 option now? I'm seeing this problem with both JGit: [2] and Protobuf: [3] CLs.

• [1] http://paste.openstack.org/show/658102/
• [2] https://git.eclipse.org/r/#/c/113368
• [3] Bazel: Support building with Java 9 protocolbuffers/protobuf#4257

[cushon]

AFAIK the combination of --add-modules and -source 8 -target 8 has never been accepted by javac.

Also, a stock javac 9 with --release 8 doesn't allow access to sun.misc.Unsafe, that's not unique to the way Bazel is invoking javac:

$ cat T.java 
class T {
  sun.misc.Unsafe u;
}
$ javac -fullversion --release 8 T.java
javac full version "9.0.4+11"
T.java:2: error: package sun.misc does not exist
  sun.misc.Unsafe u;

[davido]

AFAIK the combination of --add-modules and -source 8 -target 8 has never been accepted by javac

Except that I don't specify "-source 8 -target 8" in any place. All I say in JGit is:

 java_library(
     name = "jgit",
     srcs = SRCS,
+    javacopts = select({
+        "//:jdk9": ["--add-modules=java.xml.bind"],
+        "//conditions:default": [],
+    }),

And javac complaining that: option --add-modules not allowed with target 1.8.
Can it be that Bazel now implicitly set -source 8 -target 8?

Or am I invoking the java 9 wrong now (on Bazel master)? I'm saying that:

  $ bazel --host_javabase=/usr/lib64/jvm/java-9-openjdk build --java_toolchain=@bazel_tools//tools/jdk:toolchain_jdk9 :all

[davido]

OK, figured it out, I must specify --release in Bazel@HEAD:

  $ bazel --host_javabase=/usr/lib64/jvm/java-9-openjdk build --javacopt='--release 9' --java_toolchain=@bazel_tools//tools/jdk:toolchain_jdk9 :all

[wltjr]

Just passing by a unrelated search brought me here. You may find my Java 9 Cheat Sheet of interest. Also if you have any specific build issues I may be able to help. I am not familiar with bazelbuild, but I have some 800-1K packages built from source under Java 9. Albeit in abnormal Gentoo ways.... Otherwise sorry for unrelated noise!

[cushon]

For the Java EE stuff like java.activation and java.xml.bind we've been migrating to the explicit dependencies recommended in http://openjdk.java.net/jeps/320, since those modules are deprecated in 9 and will eventually be removed.

[davido]

It seems, that on most recent Bazel master (b7d65cd), with only two small tweaks: [1] I'm able to build bazel itself with Java 9. However, if I try to build gerrit with that version of bazel on Java 9 with this CL: [2], it's failing to build java headers in rules_closure dependency:

  $ bazel --host_javabase=/usr/lib64/jvm/java-9-openjdk build --javacopt='--release 9' --java_toolchain=@bazel_tools//tools/jdk:toolchain_jdk9 :release
[...]

ERROR: /home/davido/.cache/bazel/_bazel_davido/5c01f4f713b675540b8b424c5c647f63/external/io_bazel_rules_closure/java/io/bazel/rules/closure/webfiles/compiler/BUILD:17:1: Compiling Java headers external/io_bazel_rules_closure/java/io/bazel/rules/closure/webfiles/compiler/libcompiler-hjar.jar (1 files) and running annotation processors (ComponentProcessor) failed (Exit 1): java failed: error executing command 
  (cd /home/davido/.cache/bazel/_bazel_davido/5c01f4f713b675540b8b424c5c647f63/execroot/gerrit && \
  exec env - \
    LC_CTYPE=en_US.UTF-8 \
  external/local_jdk/bin/java -Xverify:none '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED' '--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED' '--patch-module=java.compiler=external/bazel_tools/third_party/java/jdk/langtools/java_compiler.jar' '--patch-module=jdk.compiler=external/bazel_tools/third_party/java/jdk/langtools/jdk_compiler.jar' -jar external/bazel_tools/tools/jdk/turbine_deploy.jar @bazel-out/host/bin/external/io_bazel_rules_closure/java/io/bazel/rules/closure/webfiles/compiler/libcompiler-hjar.jar-2.params)

Use --sandbox_debug to see verbose messages from the sandbox
Fatal Error: Unable to find package java.lang in classpath or bootclasspath
Target //:release failed to build
INFO: Elapsed time: 218.634s, Critical Path: 47.17s
INFO: 781 processes: 725 linux-sandbox, 9 local, 47 worker.

The turbine param file is here: [3].

[1] https://bazel-review.googlesource.com/q/topic:support-build-bazel-with-java-9
[2] https://gerrit-review.googlesource.com/#/c/gerrit/+/147234/
[3] http://paste.openstack.org/show/718446/

[cushon]

@davido - 538e5c6 should fix the "unable to find package java.lang" thing. The other fixes for full JDK 9 support are in progress

[davido]

@cushon Thanks for the quick fix. It works now.

The only opened issues for full JDK 9 support in Bazel are:

1. gRpc dependency on javax.annotation.Generated: [1], with current workaround: [2]
2. Bazel's autocodec package dependency on --add-modules=jdk.unsupported: [3], with current workaround: [4]

[1] grpc/grpc-java#3633
[2] https://bazel-review.googlesource.com/c/bazel/+/49490
[3] https://bazel-review.googlesource.com/c/bazel/+/49491/2/src/main/java/com/google/devtools/build/lib/skyframe/serialization/autocodec/BUILD#15
[4] https://bazel-review.googlesource.com/c/bazel/+/49491

[davido]

@cushon It seems, that once the alternative fix for gRpc's @Generated annotation problem is merged: [1], this issue can be closed, right? ;-)

[1] https://bazel-review.googlesource.com/#/c/bazel/+/49490

[cushon]

@davido acknowledged, thanks. There's other work that needs to happen to Bazel's release process that @philwo is helping with. We're hoping this will be ready to go in 0.14.0.

[cushon]

Bazel at head can now build itself with a JDK 9 host_javabase, and the tentative plan is still to ship this in 0.14.0:

bazel build //src:bazel
cp -f bazel-bin/src/bazel /tmp/bazel
/tmp/bazel --host_javabase /google/data/ro/projects/java-platform/linux-amd64/jdk-9-latest build //src:bazel

[cushon]

The default Bazel binaries now include an embedded JDK 9, which is used as the default javabase for Bazel itself and for host tools (JAVA_HOME is still the default target --javabase).

The default language level is still Java 8 for now, but to use the Java 9 language level you can use:

bazel build \
  --java_toolchain=@bazel_tools//tools/jdk:toolchain_java9 \
  --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_java9 ...

If you encounter any problems using Java 9 with Bazel, please file additional bugs.