0.16.1 javac cannot find nashorn symbols

[BrentDouglas]

Description of the problem / feature request:

Updating bazel from 0.16.0 to 0.16.1 causes java_library rules using classes from jdk.nashorn.api.scripting to fail to compile with the error error: package jdk.nashorn.api.scripting does not exist

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

This repo has a minimal test that shows the failure on 0.16.1 and success with 0.16.0 https://github.com/BrentDouglas/bazel-nashorn

What operating system are you running Bazel on?

Archlinux

What's the output of bazel info release?

release 0.16.1- (@non-git)

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

It is from pacman, installed with pacman -S bazel

[davido]

I can build your reproducer on Bazel 0.16.1, 0.17-rc1 and Bazel@HEAD (c8e6796) without any issue (on openSUSE Linux). The problem should be on your side.

Moreover, trying to run your example (you missed to add java_binary, that I fixed) revealed that console.log didn't work. I know nothing about rhino/nashorn JS engines in JDK, but this SO question provided a solution that worked: [1]. With my patch in place all is fine here (I also formatted the code with google-java-format 1.6):

  $ bazel version
Build label: 0.16.1

 $ bazel run src/test
INFO: Analysed target //src/test:test (0 packages loaded).
INFO: Found 1 target...
Target //src/test:test up-to-date:
  bazel-bin/src/test/test.jar
  bazel-bin/src/test/test
INFO: Elapsed time: 0.245s, Critical Path: 0.13s
INFO: 1 process: 1 worker.
INFO: Build completed successfully, 2 total actions
INFO: Build completed successfully, 2 total actions
Hello world

My environment:

  $JAVA_HOME/bin/java -fullversion
openjdk full version "1.8.0_171-b11"

Here is my patch: [2].

• [1] https://stackoverflow.com/questions/27636806/using-react-with-nashorn-throws-referenceerror-console-is-not-defined
• [2] http://paste.openstack.org/show/729298

[BrentDouglas]

On my laptop it compiles correctly for every dev build I've done (building bazel build //src:bazel-bin from all the commits I tried it at), it compiles correctly from a release build (I'm just running ./compile.sh) of https://github.com/bazelbuild/bazel/releases/download/0.16.0/bazel-0.16.0-dist.zip, and it consistently fails to compile using a version built from https://github.com/bazelbuild/bazel/releases/download/0.16.1/bazel-0.16.1-dist.zip

[BrentDouglas]

I did a bit of digging today into why nashorn.jar is not available and afaict nothing in jre/lib/ext is available for me in 0.16.1. I didn't really have time to work out how platformclasspath is meant to get access to it when generating the combined jar but at least on my system it doesn't seem to have it. Adding extclasspath back to toolchain_hostjdk8 makes this work for me though I assume the correct fix would be to make it available when generating the combined jar.

--- tools/jdk/BUILD	2018-09-04 13:40:19.613158086 +1000
+++ tools/jdk/BUILD	2018-09-04 13:40:01.456491617 +1000
@@ -207,6 +207,7 @@
 default_java_toolchain(
     name = "toolchain_hostjdk8",
     bootclasspath = [":platformclasspath"],
+    extclasspath = [":extclasspath"],
     jvm_opts = JDK8_JVM_OPTS,
     source_version = "8",
     target_version = "8",

[cushon]

it consistently fails to compile using a version built from https://github.com/bazelbuild/bazel/releases/download/0.16.1/bazel-0.16.1-dist.zip

I can reproduce. That build produces a binary without an embedded JDK, so if it picks up a JDK 8 from JAVA_HOME, and the compile-time bootclasspath handling hits this code path:

bazel/tools/jdk/DumpPlatformClassPath.java

Line 72 in f3f960c

Arrays.asList("rt.jar", "resources.jar", "jsse.jar", "jce.jar", "charsets.jar")) {

... which doesn't include jre/lib/ext/nashorn.jar.

The issue is the same as Bazel at head (f3f960c) in this configuration:

bazel build \
  --host_javabase=:jdk8 \
  --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 \
  --java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 //...
...
ERROR: src/test/BUILD:8:1: Building src/test/libtest.jar (1 source file) failed (Exit 1)
src/test/Main.java:3: error: package jdk.nashorn.api.scripting does not exist
src/test/Main.java:4: error: package jdk.nashorn.api.scripting does not exist
src/test/Main.java:15: error: cannot find symbol
  symbol:   class NashornScriptEngine
  location: class test.Main

Using the default --host_javabase and --java_toolchain uses different bootclasspath handling, which does include the nashorn APIs.

[philwo]

@laurentlb @cushon Is this a release blocker for Bazel 0.17?

[laurentlb]

It's too late for 0.17, but you can try to have it in 0.18 (#5963).

[cushon]

I'll defer to @lberki on the priority. Note that this only affects --host_javabase=:jdk8 --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 --java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 and isn't a regression in 0.17.

[lberki]

Let's not try extra hard to get it in 0.18 then. Cherry-picks are supposed to be for regressions only and cutting 0.18 is imminent.

[lberki]

@cushon re: priority -- do I understand correctly that this applies for every class under jre/lib/ext? If so, I think it's a P1 because, well, we can't compile Java properly.

[BrentDouglas]

How is this not a regression? The project I am working on built with 0.16.0 and doesn't build with 0.16.1 and by the sounds of it, won't build with 0.17.

[lberki]

Erm, I misread this -- it's indeed a regression, but not between 0.16.1 and 0.17. @cushon , is the fix reasonably simple? If so, let's cherry-pick it (/cc @aehlig )

[BrentDouglas]

@lberki I would be super grateful if we can get this in 0.17.

The company that I work for has had a bazel build in place for like a year while some higher ups in our company have compared it against our maven and decided if its a thing that they think is worth going ahead with. Very recently they decided that they were onboard with it and that they are going to remove the maven build in favour of bazel because of the ridiculous difference in build time. We are now looking at a bunch of devs being about to install bazel for the first time on their devices and the version that they will download will not able to compile our project.

[lberki]

0.17 will definitely not work since we are busy getting 0.18 out. Was that a typo?

[BrentDouglas]

Sorry, I guess I mean I would appreciate a fix for this being in a release as soon as you guys can make it work, whatever version that may be.

[cushon]

(@lberki has a fix in progress. Thanks!)

I realized I'm still confused about something here:

it consistently fails to compile using a version built from https://github.com/bazelbuild/bazel/releases/download/0.16.1/bazel-0.16.1-dist.zip

I can reproduce. That build produces a binary without an embedded JDK, so if it picks up a JDK 8 from JAVA_HOME, and the compile-time bootclasspath handling hits this code path:

why does bazel-0.16.1-dist.zip produce a binary without an embedded JDK? Is that deliberate?

Generally we always recommend the embedded JDK binaries. They also allow Bazel to use the default java_toolchain which isn't affected by this bug, instead of the hostjdk8 toolchain.

@BrentDouglas is it possible to use one of the binaries we distribute, or if you prefer to build it yourself to use bazel build //src:bazel instead of the -dist.zip archive?

[cushon]

I split my question above out into #6131.

[laurentlb]

After discussion with @dslomov, it's a regression of 0.16.1. So we should ideally try to cherrypick the fix in 0.16.2, 0.17.1 and 0.18.0.

(I can't promise yet, because there are other issues and cherrypicks tend to conflict with each other)