Bazel: Running with a Java 9 JVM fails because of a check

[damienmg]

See https://groups.google.com/d/msgid/bazel-discuss/CAMXKpGCw9ZYF_4y3Tf0%2BNbEGEg%2BqY1Hxmk7wvjk0%2Bkvf5EeKRw%40mail.gmail.com?utm_medium=email&utm_source=footer

[damienmg]

Ok there's a bit more check behind that. I won't probably be finished before wednesday.

[damienmg]

More errors.

So we do compute the bootclasspath with finding the jar in the JDK and that's prevent our Java support to work correctly using JDK 9.

[damienmg]

So here what I have done so far:

• remove the rt_jar test, only the java test is sufficient
• Try to support bootclasspath jar to be absent and add lib/modules/bootmodules.jimage to it.

This still block on building using a JDK 9. @cushon is looking into this.

[suiyuan2009]

any update, this problem still exists. but since java8 and java9 both on my machine, I can set JAVA_HOME in .bash_profile to solve it.

[oxydron]

Same problem while trying to install TensorFlow.

Problem with java installation: couldn't find/access rt.jar in /usr/lib/jvm/java-9-openjdk-amd64

[aj-michael]

The android rules currently use the rt.jar for desugaring java8 for android. @kevin1e100, do you have anythoughts on how desugaring could work without it?

[kevin1e100]

I'm guessing this about compiling android_library targets, and specifically building tools/android:desugar_java8_extra_bootclasspath from a JDK9? Or is the issue with building or running the desugaring tool? Some kind of more verbose output that shows the failing step would be helpful to diagnose this. In any event, whatever contains java.lang.* packages in JDK9 should be usable as a replacement for rt.jar.

[gbolcer]

Quick workaround:
cd /usr/lib/jvm/java-9-oracle/lib
sudo ln -s ../../java-8-oracle/jre/lib/rt.jar .

Comments from this older thread: required j8 runtime.
https://github.com/bazelbuild/bazel/issues/1068

[4cm4k1]

Here’s something you all might find helpful in the meantime: https://github.com/gcuisinier/jenv

It's just like rbenv in that it allows you to manage multiple Java versions (eg, use 8 while waiting for 9 support), switch between them, and even export/expose JAVA_HOME and other environment variables to the shell or gradle, etc. 😄

[pcj]

Adding to what @kevin1e100 said (even though rt.jar no longer there, the tools they provide should be):

• The internal files rt.jar, tools.jar, and dt.jar have been removed. The content of these files is now stored in a more efficient format in implementation-private files in the lib directory. Class and resource files previously in tools.jar and dt.jar are now always visible via the bootstrap or application class loaders in a JDK image.
• A new, built-in NIO file-system provider can be used to access the class and resource files stored in a run-time image. Tools that previously read rt.jar and other internal jar files directly should be updated to use this file system.

Source: http://marxsoftware.blogspot.com/2017/01/jdk-9-is-end-of-road-for-some-features.html, https://issues.jenkins-ci.org/browse/JENKINS-25993