Bazel 5.0rc1 issue with linking Java 17 records with explicit constructors from a different package

[eikemeier]

Description of the problem / feature request:

Bazel 5.0rc1 has an issue with linking Java 17 records with explicit constructors from a different package.

Demonstration in eikemeier/bazel_jdk17.

Feature requests: what underlying problem are you trying to solve with this feature?

Compile a Java 17 program with bazel.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Check out https://github.com/eikemeier/bazel_jdk17, run bazelisk run //src/main/java/com/example.

What operating system are you running Bazel on?

macOS 10.15

What's the output of bazel info release?

release 5.0.0rc1

What's the output of git remote get-url origin ; git rev-parse main ; git rev-parse HEAD ?

ssh://git@github.com/eikemeier/bazel_jdk17.git
2c85df80a77291600764d3f193437dec07a41c51
2c85df80a77291600764d3f193437dec07a41c51

Have you found anything relevant by searching the web?

Not really, if you don't count the general Java 17-discussion.

Any other information, logs, or outputs that you want to share?

See the the README.

[cushon]

ERROR: [...]/bazel_jdk17/src/main/java/com/example/hello/BUILD:3:13: Compiling Java headers src/main/java/com/example/hello/libhello-hjar.jar (1 source file) failed: (Exit 1): java failed: error executing command external/remotejdk17_macos/bin/java [...]

src/main/java/com/example/hello/Hello.java:6: error: unexpected token: {
  public Hello {
               ^

$ cat src/main/java/com/example/hello/Hello.java
package com.example.hello;

import java.util.Objects;

public record Hello(String one) {
  public Hello {
    Objects.requireNonNull(one);
  }
}

[eikemeier]

@cushon: When you move the Hello record in the same package as the Main class the error vanishes. So just the record isn't enough.

[cushon]

That's because header compilation actions only run on Java targets that are dependencies of other targets. The header jar is used as a compile-time optimization when compiling downstream targets, and the action isn't run if record is being built directly.

[eikemeier]

That's because header compilation actions only run on Java targets that are dependencies of other targets. The header jar is used as a compile-time optimization when compiling downstream targets, and the action isn't run if record is being built directly.

Yeah, thanks. So “different package” is probably wrong, it should be “compile unit” or something like that. The same example works in a single package, as long as linking is involved:

https://github.com/eikemeier/bazel_jdk17/tree/single-package

[Wyverald]

Do we think this is a 5.0 release blocker?

[eikemeier]

Do we think this is a 5.0 release blocker?

It's a very basic Java 17 program that cannot be compiled. OTOH lots of tools have problems with Java 17, for example Error Prone 2.9.0 (in Bazel 5.0rc1) has issues with records, fixed in 2.10.0:

google/error-prone@47da3af

I don't know what level of Java 17 support is targeted.

[cushon]

I agree this is a very fundamental issue with Java 17 support.

@hvadehra @comius WDYT? I'll have a fix for this ~today, your call whether it makes sense to target 5.0 at this point. (If it doesn't make it into 5.0 it'll still be possible to get the fix by updating the java_tools version, right?)

[cushon]

This is fixed in 268bedd, but will require a java_tools release to be available

[hvadehra]

I'll try and make a java_tools release today

[hvadehra]

I'll try and make a java_tools release today

Released and merged in d703b7b

[cushon]

Thanks @hvadehra!