Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.16.0 release binary requires local JDK #5744

Closed
schroederc opened this issue Aug 2, 2018 · 13 comments
Closed

0.16.0 release binary requires local JDK #5744

schroederc opened this issue Aug 2, 2018 · 13 comments

Comments

@schroederc
Copy link
Contributor

Description of the problem / feature request:

Bazel release 0.15.2 could build Java targets without a local system JDK installed. Bazel release 0.16.0 cannot.

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

$ # Be on a system without a local JDK installed
$ git clone https://github.com/google/protobuf.git
$ cd protobuf
$ bazel-0.16.0 build //:protobuf_java
INFO: Analysed target //:protobuf_java (0 packages loaded).
INFO: Found 1 target...
ERROR: missing input file '@local_jdk//:jre/lib/jce.jar'
ERROR: /protobuf/BUILD:609:1: //:protobuf_java: missing input file '@local_jdk//:jre/lib/jce.jar'
Target //:protobuf_java failed to build
Use --verbose_failures to see the command lines of failed build steps.
ERROR: /protobuf/BUILD:609:1 1 input file(s) do not exist
INFO: Elapsed time: 0.426s, Critical Path: 0.15s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

$ bazel-0.15.2 build //:protobuf_java
INFO: Analysed target //:protobuf_java (12 packages loaded).
INFO: Found 1 target...
Target //:protobuf_java up-to-date:
  bazel-bin/libprotobuf_java.jar
INFO: Elapsed time: 65.287s, Critical Path: 28.78s
INFO: 163 processes: 162 processwrapper-sandbox, 1 worker.
INFO: Build completed successfully, 168 total actions
@schroederc
Copy link
Contributor Author

This seems similar to the issue with the 0.15.1 release: #5591 (comment)

@laszlocsomor
Copy link
Contributor

laszlocsomor commented Aug 3, 2018

I see the same on Windows 10 with Bazel 0.16.0 vs. Bazel 0.15.2:

C:\src\bazel>c:\src\bazel-releases\0.16.0\bazel.exe --output_user_root=c:\tmp1 build --python_path=c:/anaconda3/python.exe @local_jdk//:bootclasspath
...
INFO: Found 1 target...
ERROR: missing input file '@local_jdk//:jre/lib/jce.jar'
ERROR: C:/tmp1/o2bbs3hu/external/local_jdk/BUILD.bazel:75:1: @local_jdk//:bootclasspath: missing input file 'LabelCause{label=@local_jdk//:jre/lib/jce.jar, msg=missing input file '@local_jdk//:jre/lib/jce.jar'}'
Target @local_jdk//:bootclasspath failed to build
ERROR: C:/tmp1/o2bbs3hu/external/local_jdk/BUILD.bazel:75:1 1 input file(s) do not exist
INFO: Elapsed time: 0.989s, Critical Path: 0.00s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

C:\src\bazel>c:\src\bazel-releases\0.15.2\bazel.exe --output_user_root=c:\tmp2 build --python_path=c:/anaconda3/python.exe @local_jdk//:bootclasspath
...
INFO: Found 1 target...
Target @local_jdk//:bootclasspath up-to-date (nothing to build)
INFO: Elapsed time: 1.279s, Critical Path: 0.01s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action

Solution was to define JAVA_HOME:

set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_152

@laszlocsomor
Copy link
Contributor

/cc @buchgr -- do you know what's going on?

@schroederc
Copy link
Contributor Author

While we're on the subject, how does one actually go about building a Bazel binary with the fully embedded JDK? If I try bazel build --stamp //src:bazel on https://github.com/bazelbuild/bazel/tree/0.15.2 or https://github.com/bazelbuild/bazel/tree/0.16.0, then I get either the issue from #5591 (comment) or this issue, respectively.

@buchgr
Copy link
Contributor

buchgr commented Aug 6, 2018

@schroederc which JDK version to you have installed on your system? Are you specifying a --javabase via a flag (in .bazelrc maybe?).

@schroederc
Copy link
Contributor Author

The point is that the system doesn't have any JDK installed. 0.15 did not need a local JDK installed but 0.16.0 now does.

As a repro, this Docker container builds a java_library successfully using 0.15.2 with no local JDK:

FROM debian:jessie
RUN apt-get update && \
    apt-get install -y pkg-config zip g++ zlib1g-dev unzip curl git

RUN curl -L -o /usr/bin/bazel https://github.com/bazelbuild/bazel/releases/download/0.15.2/bazel-0.15.2-linux-x86_64 && chmod +x /usr/bin/bazel

RUN git clone https://github.com/google/protobuf.git && \
    cd protobuf && \
    bazel build //:protobuf_java

But 0.16.0 fails to build the same target in the same environment:

FROM debian:jessie
RUN apt-get update && \
    apt-get install -y pkg-config zip g++ zlib1g-dev unzip curl git

RUN curl -L -o /usr/bin/bazel https://github.com/bazelbuild/bazel/releases/download/0.16.0/bazel-0.16.0-linux-x86_64 && chmod +x /usr/bin/bazel

RUN git clone https://github.com/google/protobuf.git && \
    cd protobuf && \
    bazel build //:protobuf_java

0.16.0 complains about a missing input file:

ERROR: missing input file '@local_jdk//:jre/lib/jsse.jar'
ERROR: /protobuf/BUILD:609:1: //:protobuf_java: missing input file '@local_jdk//:jre/lib/jsse.jar'
Target //:protobuf_java failed to build

@buchgr
Copy link
Contributor

buchgr commented Aug 6, 2018

@cushon any ideas?

@cushon
Copy link
Contributor

cushon commented Aug 6, 2018

We're defaulting to the embedded JDK as a target --javabase, and we don't support JDK > 8 as a target --javabase.

Can you install a JDK 8 and use that as the target?

In the medium term

  • there's some work happening to use remote repos for java runtimes so Bazel can fetch a JDK 8 for you to use as the target
  • we will eventually support JDK 9 as a target --javabase

@schroederc
Copy link
Contributor Author

I did add the JDK 8 to our Docker container as a workaround. If this was intentional, then the release notes should be updated to reflect the breaking change (as well as the fact that the embedded JDK was updated to 9).

@cushon
Copy link
Contributor

cushon commented Aug 6, 2018

They mention the first part:

The embedded JDK has been upgraded to JDK 9, and is now used as both the default startup --host_javabase and build --host_javabase.

https://blog.bazel.build/2018/07/31/bazel-0.16.html

@schroederc
Copy link
Contributor Author

buchgr pushed a commit to buchgr/bazel that referenced this issue Aug 8, 2018
…classpath

instead of indirecting through javac's bootclasspath handling and attempting
to pin to a particular source version. This is a stop-gap until we can just
use javac's --release flag.

Using the output of DumpPlatformClasspath as the bootclasspath for the default
java_toolchain side-steps issues with @local_jdk (see bazelbuild#5744, bazelbuild#5594).

PiperOrigin-RevId: 207687432
Change-Id: I1c7996d4aeb96e1ac4996d58115e105854e80127
@dslomov
Copy link
Contributor

dslomov commented Aug 8, 2018

Even though our longer-term intention is to fully hide the embedded JDK, we should not break people without prior announcement.
We will be issuing the patch release of 0.16 that fixes this: track status in #5792

bazel-io pushed a commit that referenced this issue Aug 8, 2018
…classpath

instead of indirecting through javac's bootclasspath handling and attempting
to pin to a particular source version. This is a stop-gap until we can just
use javac's --release flag.

Using the output of DumpPlatformClasspath as the bootclasspath for the default
java_toolchain side-steps issues with @local_jdk (see #5744, #5594).

PiperOrigin-RevId: 207890272
buchgr pushed a commit to buchgr/bazel that referenced this issue Aug 8, 2018
…classpath

instead of indirecting through javac's bootclasspath handling and attempting
to pin to a particular source version. This is a stop-gap until we can just
use javac's --release flag.

Using the output of DumpPlatformClasspath as the bootclasspath for the default
java_toolchain side-steps issues with @local_jdk (see bazelbuild#5744, bazelbuild#5594).

PiperOrigin-RevId: 207687432
Change-Id: I1c7996d4aeb96e1ac4996d58115e105854e80127
@cushon
Copy link
Contributor

cushon commented Aug 9, 2018

This is fixed at head, and the fixes will be included in the upcoming 0.16.1 and 0.17 releases.

iirina pushed a commit that referenced this issue Aug 9, 2018
…classpath

instead of indirecting through javac's bootclasspath handling and attempting
to pin to a particular source version. This is a stop-gap until we can just
use javac's --release flag.

Using the output of DumpPlatformClasspath as the bootclasspath for the default
java_toolchain side-steps issues with @local_jdk (see #5744, #5594).

PiperOrigin-RevId: 207890272
buchgr pushed a commit to buchgr/bazel that referenced this issue Aug 9, 2018
…classpath

instead of indirecting through javac's bootclasspath handling and attempting
to pin to a particular source version. This is a stop-gap until we can just
use javac's --release flag.

Using the output of DumpPlatformClasspath as the bootclasspath for the default
java_toolchain side-steps issues with @local_jdk (see bazelbuild#5744, bazelbuild#5594).

PiperOrigin-RevId: 207890272
bazel-io pushed a commit that referenced this issue Aug 13, 2018
Baseline: 4f64b77

Cherry picks:
   + 4c9a0c8:
     reduce the size of bazel's embedded jdk
   + d3228b6:
     remote: limit number of open tcp connections by default. Fixes
     #5491
   + 8ff87c1:
     Fix autodetection of linker flags
   + c4622ac:
     Fix autodetection of -z linker flags
   + 1021965:
     blaze_util_posix.cc: fix order of #define
   + ab1f269:
     blaze_util_freebsd.cc: include path.h explicitly
   + 68e92b4:
     openjdk: update macOS openjdk image. Fixes #5532
   + f45c224:
     Set the start time of binary and JSON profiles to zero correctly.
   + bca1912:
     remote: fix race on download error. Fixes #5047
   + 3842bd3:
     jdk: use parallel old gc and disable compact strings
   + 6bd0bdf:
     Add objc-fully-link to the list of actions that require the
     apple_env feature. This fixes apple_static_library functionality.
   + f330439:
     Add the action_names_test_files target to the OSS version of
     tools/buils_defs/cc/BUILD.
   + d215b64:
     Fix StackOverflowError on Windows. Fixes #5730
   + 366da4c:
     In java_rules_skylark depend on the javabase through
     //tools/jdk:current_java_runtime
   + 30c601d:
     Don't use @local_jdk for jni headers
   + c56699d:
     'DumpPlatformClasspath' now dumps the current JDK's default
     platform classpath

This release is a patch release that contains fixes for several serious
regressions that were found after the release of Bazel 0.16.0.

In particular this release resolves the following issues:

 - Bazel crashes with a StackOverflowError on Windows (See #5730)
 - Bazel requires a locally installed JDK and does not fall back
   to the embedded JDK (See #5744)
 - Bazel fails to build for Homebrew on macOS El Capitan (See #5777)
 - A regression in apple_static_library (See #5683)

Please watch our blog for a more detailed release announcement.
@cushon cushon closed this as completed Aug 15, 2018
laurentlb pushed a commit that referenced this issue Sep 12, 2018
…classpath

instead of indirecting through javac's bootclasspath handling and attempting
to pin to a particular source version. This is a stop-gap until we can just
use javac's --release flag.

Using the output of DumpPlatformClasspath as the bootclasspath for the default
java_toolchain side-steps issues with @local_jdk (see #5744, #5594).

PiperOrigin-RevId: 207890272
werkt pushed a commit to werkt/bazel that referenced this issue Oct 19, 2018
…classpath

instead of indirecting through javac's bootclasspath handling and attempting
to pin to a particular source version. This is a stop-gap until we can just
use javac's --release flag.

Using the output of DumpPlatformClasspath as the bootclasspath for the default
java_toolchain side-steps issues with @local_jdk (see bazelbuild#5744, bazelbuild#5594).

PiperOrigin-RevId: 207890272
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants