-
Notifications
You must be signed in to change notification settings - Fork 4.4k
Description
Description of the bug:
In Bazel 6, if a java_binary depends on a java_library with add_exports/add_opens set, the deploy JAR would include lines like Add-Exports: … in its manifest. However, this longer happens on Bazel 7.
Which category does this issue belong to?
Java Rules
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
java_library(
name = "hello",
add_exports = ["java.base/java.util"],
)
java_binary(
name = "hello_bin",
main_class = "nonexistent_but_thats_ok",
runtime_deps = [":hello"],
)$ bazel build //:hello_bin_deploy.jar
$ jar -xf bazel-bin/hello_bin_deploy.jar META-INF/MANIFEST.MF
$ cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Created-By: singlejar
Main-Class: nonexistent_but_thats_ok
Multi-Release: true
Compared to Bazel 6.3.2:
$ cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Created-By: singlejar
Main-Class: nonexistent_but_thats_ok
Add-Exports: java.base/java.util
Which operating system are you running Bazel on?
Linux
What is the output of bazel info release?
release 7.0.0
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
Yes. The regression comes from the overall Java rule Starlarkification work.
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
We have identified the exact bug: this line does not pass info.add_exports and info.add_opens to create_deploy_archives.
bazel/src/main/starlark/builtins_bzl/bazel/java/bazel_java_binary_deploy_jar.bzl
Lines 41 to 51 in 773942f
| create_deploy_archives( | |
| ctx, | |
| info.java_attrs, | |
| info.launcher_info, | |
| info.main_class, | |
| info.coverage_main_class, | |
| info.strip_as_default, | |
| build_info_files, | |
| str(ctx.attr.binary.label), | |
| manifest_lines = info.manifest_lines, | |
| ) |
We have confirmed that the InternalDeployJarInfo provider is populated correctly for hello_bin (see below, pretty-printed). So in all likelihood, this bug would not occur if info.add_exports were passed correctly.
$ bazel cquery --output=starlark --starlark:expr='providers(target)["@@_builtins//:common/java/java_binary.bzl%InternalDeployJarInfo"]' //:hello_bin 2>/dev/null
struct(
add_exports = depset(["java.base/java.util"]),
add_opens = depset([]),
coverage_main_class = "nonexistent_but_thats_ok",
hermetic = False,
java_attrs = struct(
classpath_resources = depset([]),
resources = depset([]),
runtime_classpath = depset([<generated file hello_bin.jar>], order = "preorder"),
runtime_classpath_for_archive = depset([], order = "preorder"),
runtime_jars = depset([<generated file hello_bin.jar>])
),
launcher_info = struct(
launcher = None,
runtime_jars = [],
unstripped_launcher = None
),
main_class = "nonexistent_but_thats_ok",
manifest_lines = [],
shared_archive = None,
stamp = -1,
strip_as_default = False
)
Two additional bugs:
- Other than
add_exportsandadd_opens, we also see thatinfo.hermeticis not being passed tocreate_deploy_archives. - Within
create_deploy_archives,add_exportsandadd_opensare not being passed tocreate_deploy_archivein theif strip_as_defaultbranch.
cc @hvadehra