Skip to content

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

@timothyg-stripe

Description

@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.

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

Metadata

Metadata

Assignees

Labels

P1I'll work on this now. (Assignee required)team-Rules-JavaIssues for Java rulestype: bug

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions