-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Bazel@HEAD on JDK 17: GoogleTestSecurityManager WARNING: System::setSecurityManager will be removed in a future release #14502
Comments
cc @cushon |
This warning is being emitted by the JDK, and is the expected result of https://openjdk.java.net/jeps/411 I don't think anything here is specific to Bazel? |
It's Bazel's |
Of course, thanks. We're looking at alternatives to the test runner. We may end up remove the use of As far as I know there isn't a timeline for the removal yet, but we'll keep an eye on this and try to have something in place before it actually goes away. In the interim the warnings are not very actionable, but I'm not sure they're suppressible. IIUC there is some ongoing discussion upstream about provide alternatives to some of the supported functionality, e.g. discouraging calls to |
Reading https://openjdk.java.net/jeps/411,
|
Are you sure that's true? The JEP seems to imply that this flag only makes the startup warning go away, not the runtime warning when |
Entirely possible I'm missing something here, but I thought it did check the property? See: |
It does check it in these places and will not print the startup warning if it's set to |
Thanks, @cushon. This works on Java 17: the warning is disappeared with this option. However, it cannot be set unconditionally, because, with this option Java 11 doesn't work, as the setting is not backwards compatible:
At least for Gerrit Code Review, this diff seems to work in both cases (Java 11 and Java 17): diff --git a/BUILD b/BUILD
index f6ec40e2aa..30d6547da5 100644
--- a/BUILD
+++ b/BUILD
@@ -4,9 +4,9 @@ load("//tools/bzl:pkg_war.bzl", "pkg_war")
package(default_visibility = ["//visibility:public"])
config_setting(
- name = "java11",
+ name = "java17",
values = {
- "java_toolchain": "@bazel_tools//tools/jdk:toolchain_java11",
+ "java_language_version": "17",
},
)
diff --git a/tools/bzl/junit.bzl b/tools/bzl/junit.bzl
index 0e7ea3a7e1..0e1fa5db49 100644
--- a/tools/bzl/junit.bzl
+++ b/tools/bzl/junit.bzl
@@ -75,6 +75,10 @@ POST_JDK8_OPTS = [
"-Djava.locale.providers=COMPAT,CLDR,SPI",
]
+POST_JDK17_OPTS = [
+ "-Djava.security.manager=allow",
+]
+
def junit_tests(name, srcs, **kwargs):
s_name = name.replace("-", "_") + "TestSuite"
_gen_suite(
@@ -82,7 +86,12 @@ def junit_tests(name, srcs, **kwargs):
srcs = srcs,
outname = s_name,
)
- jvm_flags = kwargs.get("jvm_flags", []) + POST_JDK8_OPTS
+ jvm_flags = kwargs.get("jvm_flags", [])
+ jvm_flags = jvm_flags + select({
+ "//:java17": POST_JDK8_OPTS + POST_JDK17_OPTS,
+ "//conditions:default": POST_JDK8_OPTS,
+ })
+ POST_JDK8_OPTS
java_test(
name = name,
test_class = s_name, The better question is: can we somehow move the fix to upstream Bazel, to avoid proliferation of this diff to downstream projects? Alone for Gerrit Code Review, we have 100+ plugins, where Bazlets Repository is used, and we also have JGit and Gitiles, that have their own Bazel build tool chains. See also this CL: [1] for the whole fix in Gerrit. [1] https://gerrit-review.googlesource.com/c/gerrit/+/291864 |
I agree it would be good to solve this in Bazel. Medium term we may want to use the API for preventing calls to It would be nice to have a short term fix, and automatically passing -Djava.security.manager=allow to |
Right. However, at least for RBE to work with remote JDK, we need to pass
So that config_setting(
name = "java17",
values = {
"java_runtime_version": "remotejdk_17",
},
) |
As of jdk 18, this has become a hard failure. What are the current thoughts on upstreaming the ‘allow’ setting conditional on jdk runtime >= 17? Or is there some other approach being considered? Thanks! |
An alternative could be to have the test runner attach a Java agent that modifies the behavior of System.exit using ByteBuddy or ASM. |
To confirm, isn't it a failure by default in 18 that can still be disabled by passing Internally we are currently passing that flag and waiting to see if https://bugs.openjdk.java.net/browse/JDK-8199704 happens before the API is removed. Another option being considered is to remove the test SecurityManager sooner and rely on static analysis to prevent calls to System.exit. |
Right, true, it can be worked around by everyone doing that. I was just wondering whether in the interim, instead of everyone c&p'ing that into various bits of their code, it would be possible to handle it upstream. |
I think it makes sense to add a shared workaround to Bazel in the interim. I'm not sure what the cleanest way only pass |
I recently ran into this issue with JNI Bind and your solution worked! That said, it would be great to have a solution that's future proof. Is this expected to be fixed in Bazel itself? I would think this would effect all Bazel users that use Sorry for the basic question, I didn't think I'd done anything special in my setup, but I'm not very competent with setting this stuff up so I'm wondering if I'm doing something non-standard. Thanks! |
This is another example where something like Related: #6354 (comment) |
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.)
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.)
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.)
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.)
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.)
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.)
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.)
@bazel-io flag |
@bazel-io fork 6.2.0 |
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.) Closes bazelbuild#17775. PiperOrigin-RevId: 518860040 Change-Id: I8223b6407dd09528a4e5a6bf12354e5fc68278c6
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.) Closes bazelbuild#17775. PiperOrigin-RevId: 518860040 Change-Id: I8223b6407dd09528a4e5a6bf12354e5fc68278c6
1. As suggested in #6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes #14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.) Closes #17775. PiperOrigin-RevId: 518860040 Change-Id: I8223b6407dd09528a4e5a6bf12354e5fc68278c6 (cherry picked from commit 7556e11)
As suggested in Use @argument files in the Java binary wrapper script #6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes Bazel@HEAD on JDK 17: GoogleTestSecurityManager WARNING: System::setSecurityManager will be removed in a future release #14502. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.) Closes #17775. PiperOrigin-RevId: 518860040 Change-Id: I8223b6407dd09528a4e5a6bf12354e5fc68278c6
1. As suggested in #6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes #14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.) Closes #17775. PiperOrigin-RevId: 518860040 Change-Id: I8223b6407dd09528a4e5a6bf12354e5fc68278c6 (cherry picked from commit 7556e11)
* Add version to JavaRuntimeInfo. 1. As suggested in #6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes #14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.) Closes #17775. PiperOrigin-RevId: 518860040 Change-Id: I8223b6407dd09528a4e5a6bf12354e5fc68278c6 (cherry picked from commit 7556e11) * Use string.replace() instead of string.format() to avoid issues with select{} in the template string * Remove test and fix formatting * Fix starlark_repository_test Change the grep pattern to exactly match what the test is looking for. The old pattern would match BUILD file content from the jdk_build_file.bzl template --------- Co-authored-by: Benjamin Peterson <benjamin@engflow.com>
* Bump minimum JRE to 11 (from 8). * Change testing matrix from {8,11,15,17} to {11,17,21-ea}. (Except the bazel build has trouble parsing "21-ea" as a java version, so s/21-ea/20 for bazel.) * Also test on macos (but only with jdk17). (Attempted to test on windows too, but there's issues right now.) * Cleanup the POMs a little bit (remove unused mailing list reference, fix CI link) * Bump bazel version to 6.2.0, otherwise the tests fail b/c they try to set a security manager (see bazelbuild/bazel#14502, which was fixed in bazelbuild/bazel@7556e11, which was cherrypicked into the 6.2.0 release). This also required suppressing the "BanJNDI" errorprone check in the JNDI extension, which was also added to 6.2.0. (A future change should probably just remove the JNDI extension altogether.) PiperOrigin-RevId: 532797192
* Bump minimum JRE to 11 (from 8). * Change testing matrix from {8,11,15,17} to {11,17,21-ea}. (Except the bazel build has trouble parsing "21-ea" as a java version, so s/21-ea/20 for bazel.) * Also test on macos (but only with jdk17). (Attempted to test on windows too, but there's issues right now.) * Cleanup the POMs a little bit (remove unused mailing list reference, fix CI link) * Bump bazel version to 6.2.0, otherwise the tests fail b/c they try to set a security manager (see bazelbuild/bazel#14502, which was fixed in bazelbuild/bazel@7556e11, which was cherrypicked into the 6.2.0 release). This also required suppressing the "BanJNDI" errorprone check in the JNDI extension, which was also added to 6.2.0. (A future change should probably just remove the JNDI extension altogether.) PiperOrigin-RevId: 532797192
* Bump minimum JRE to 11 (from 8). * Change testing matrix from {8,11,15,17} to {11,17,21-ea}. (Except the bazel build has trouble parsing "21-ea" as a java version, so s/21-ea/20 for bazel.) * Also test on macos (but only with jdk17). (Attempted to test on windows too, but there's issues right now.) * Cleanup the POMs a little bit (remove unused mailing list reference, fix CI link) * Bump bazel version to 6.2.0, otherwise the tests fail b/c they try to set a security manager (see bazelbuild/bazel#14502, which was fixed in bazelbuild/bazel@7556e11, which was cherrypicked into the 6.2.0 release). This also required suppressing the "BanJNDI" errorprone check in the JNDI extension, which was also added to 6.2.0. (A future change should probably just remove the JNDI extension altogether.) PiperOrigin-RevId: 532849632
1. As suggested in bazelbuild#6354 (comment), add a JDK version attribute to the java_runtime rule. This will allow changing behavior based on the Java runtime's version. 2. As an application of the above, pass -Djava.security.manager=allow to Java tests on JDK 17+. This makes the Bazel Java test runner to work on JDK 19. Fixes bazelbuild#14502. 3. To make the above generally useful, the remote_java_repository and local_java_repository must set the new version attribute in the java_runtime rules that they create. This means the old static jdk.BUILD file no longer suffices. Move the contents of jdk.BUILD into a Starlark file, so the version can be interpolated in by JDK repository rules and macros. (This isn't the nicest, but local_java_repository is not a repository rule, so the template cannot be in a non-Starlark file.) Closes bazelbuild#17775. PiperOrigin-RevId: 518860040 Change-Id: I8223b6407dd09528a4e5a6bf12354e5fc68278c6
Bazel specific issue was resolved: [1] so that there is no need to set this parameter to allow. Also remove java17 configuration, because it's not used any more. [1] bazelbuild/bazel#14502 Release-Notes: skip Change-Id: I93f7069a20fe55f8cfdfa8ec1f046b85554361f5
Conditionally set -Djava.security.manager=allow for jdk >= 17 rules_scala uses SecurityManager which is deprecated and fails at runtime on jdk21+ (no replacement for this yet) Bazel's approach to solve this is conditionally add a jvm flag see bazelbuild/bazel#14502 CI builds were failing for some time because jdk was updated to 21
…uild#1555) Conditionally set -Djava.security.manager=allow for jdk >= 17 rules_scala uses SecurityManager which is deprecated and fails at runtime on jdk21+ (no replacement for this yet) Bazel's approach to solve this is conditionally add a jvm flag see bazelbuild/bazel#14502 CI builds were failing for some time because jdk was updated to 21
I'm running Gerrit tests on JDK 17 and seeing this warning:
To reproduce, clone recursively Gerrit apply this CL: [1], and run with Bazel@HEAD (at least 5.0.0rc3):
Related: #11146.
[1] https://gerrit-review.googlesource.com/c/gerrit/+/291864
The text was updated successfully, but these errors were encountered: