-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Comments
This seems similar to the issue with the 0.15.1 release: #5591 (comment) |
I see the same on Windows 10 with Bazel 0.16.0 vs. Bazel 0.15.2:
Solution was to define JAVA_HOME:
|
/cc @buchgr -- do you know what's going on? |
While we're on the subject, how does one actually go about building a Bazel binary with the fully embedded JDK? If I try |
@schroederc which JDK version to you have installed on your system? Are you specifying a |
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
But 0.16.0 fails to build the same target in the same environment:
0.16.0 complains about a missing input file:
|
@cushon any ideas? |
We're defaulting to the embedded JDK as a target Can you install a JDK 8 and use that as the target? In the medium term
|
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). |
They mention the first part:
|
It's missing in https://github.com/bazelbuild/bazel/releases/tag/0.16.0. |
…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
Even though our longer-term intention is to fully hide the embedded JDK, we should not break people without prior announcement. |
…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
…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
This is fixed at head, and the fixes will be included in the upcoming 0.16.1 and 0.17 releases. |
…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
…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
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.
…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
…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
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.
The text was updated successfully, but these errors were encountered: