Bazel 7 regression: Deploy JARs no longer contain Add-Exports/Opens manifest lines

[timothyg-stripe]

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_exports and add_opens, we also see that info.hermetic is not being passed to create_deploy_archives.
• Within create_deploy_archives, add_exports and add_opens are not being passed to create_deploy_archive in the if strip_as_default branch.

cc @hvadehra

[fmeum]

@bazel-io fork 7.1.0

[hvadehra]

Thanks for the report, this was an oversight, fixing shortly.

we also see that info.hermetic is not being passed to create_deploy_archives.

AFAICT, that is an internal attribute that is a no-op for Bazel.

add_exports and add_opens are not being passed to create_deploy_archive in the if strip_as_default branch.

Yes, but looks like that was the always the case, even in the native JavaBinary rule. But the discrepancy was likely just unintentional. Will fix as well.

[xieyuxi-stripe]

Hi @hvadehra, this bug fix is currently scheduled for 7.1.0. Given it will likely be a quick fix, do you think you are able to cherry-pick it and release this fix in 7.0.3? It will help us upgrade Bazel sooner without having to fork or apply our own patch. Thanks in advance!

[hvadehra]

I don't think a 7.0.3 release is planned. @meteorcloudy to confirm.

[meteorcloudy]

Yes, 7.1.0 is around the corner and will contain many other bug fixes and improvements, so I prefer to just wait for it unless this is a serious regression that has wide impact.

[iancha1992]

A fix for this issue has been included in Bazel 7.1.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks!