6.2.0: Unexpected output "Unknown constant: 11"

[joeljeske]

Description of the bug:

After upgrading to 6.2.0, I am seeing many messages in build log that do not seem possible when reading the source code:

(02:31:14) INFO: From Extracting interface //my_target:my_target_with_header:
--
  | Unknown constant: 11. Passing class through.
  | Unknown constant: 11. Passing class through.
  | Unknown constant: 11. Passing class through.
  | Unknown constant: 11. Passing class through.
  | Unknown constant: 11. Passing class through.
  | Unknown constant: 11. Passing class through.
  | Unknown constant: 11. Passing class through.

This is the default case for https://github.com/bazelbuild/bazel/blob/release-6.2.0/third_party/ijar/classfile.cc#L1660-L1662
however the switch should have a case for constant 11 https://github.com/bazelbuild/bazel/blob/release-6.2.0/third_party/ijar/classfile.cc#L1593.

I am wanting to understand this error to see if there is anything I need to change on my end, or if its a bug here.

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

https://github.com/joeljeske/bazel-repo-iss18360

Which operating system are you running Bazel on?

Linux, and darwin

What is the output of bazel info release?

release 6.2.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 master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

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

No response

[sgowroji]

Hi @joeljeske, Can you provide minimal steps followed to reproduce this issue. Thanks!

[joeljeske]

Hey @sgowroji I'm working towards a minimal reproduction, but have been debugging along the way.

Currently, HEAD of rules_java is referencing remote_java_tools v12.1, which supplies pre-built ijar binaries that should not be able to log this message according to ijar source code.

I am unable to traceback to the source code that built these binaries, as its not contained in the bazelbuild/java_tools repo itself. If I upgrade to 12.2 by specifying my own remote_java_tools in my WORKSPACE, then this message no longer appears. Edit: I was incorrect, I do experience this error with every version of java_tools/ijar. I think there may be something incorrect about origin of java_tools prebuilt binaries.

[joeljeske]

@sgowroji Alright, here is a minimum reproduction! Its pretty simple and it does not occur in 6.1.0.

https://github.com/joeljeske/bazel-repo-iss18360

[joeljeske]

Another realization: The message Unknown constant: 11. Passing class through. is printing a hexadecimal number 11, not the decimal number 17. This is why the message is printing in the first place. But I still do not know why this symbol is appearing 🤔

[dmivankov]

17 is not present in https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140 or https://github.com/bazelbuild/bazel/blob/release-6.2.0/third_party/ijar/classfile.cc#L57

but it also wasn't present in 6.1.0 https://github.com/bazelbuild/bazel/blob/release-6.1.0/third_party/ijar/classfile.cc#L57

[dmivankov]

same with jdk17 via build --java_runtime_version=remotejdk_17 --java_language_version=17 --tool_java_runtime_version=remotejdk_17 --tool_java_language_version=17

but it seems that the trigger is --collect_code_coverage=true, without it there's no warning

[dmivankov]

17 is Constant_Dynamic from https://openjdk.org/jeps/309 which is part of jdk11

$ javap -c -v -classpath bazel-bin/src/liblib_b.jar lib/ClassB
...
public class lib.ClassB
  minor version: 0
  major version: 61
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER
  this_class: #7                          // lib/ClassB
  super_class: #2                         // java/lang/Object
  interfaces: 0, fields: 0, methods: 2, attributes: 2
Constant pool:
...
  #24 = Dynamic            #0:#23         // #0:$jacocoData:Ljava/lang/Object;
...

so looks like third_party/ijar is missing support for that, not sure about the impact

[dmivankov]

Probably it means generated ijar would be same as full jar and that may result in more recompilations

[dmivankov]

Here it is suggested that jacoco uses it for jdk11 since 0.8.4 https://issuetracker.google.com/issues/178400721
Unclear why it pops up only now, third_party/java/jacoco is 0.8.6/0.8.7 in 6.1.2 and 6.2.0

[joeljeske]

Great information, thank you! I was able to bypass this issue and generate proper ijars by downgrading remote_java_tools to 11.2.

There is this patch https://github.com/bazelbuild/bazel/blob/6.2.0/third_party/java/jacoco/0001-Disable-use-of-constant-dynamic-bytecode.patch that appears to workaround this exact issue, but was removed in 7.x. This made me question if remote_java_tools 12.x was generated from bazel 7.x... 🤔

[dmivankov]

Is this going to be fixed in 6.2.2 or 6.3.0? Has been some time since 6.2.0 is out and non-upgradeable due to this regression

[fmeum]

CC @meteorcloudy

[meteorcloudy]

/cc @hvadehra Can you take a look?

I guess this has something to do with the java_tools upgrade (-> 12.3) happened in 6.2.0, and I guess java_tools are built from the master branch of Bazel therefore contains newer changes?

@dmivankov I tried to reproduce this, it isn't a hard failure, why is this blocking your upgrade?

[dmivankov]

I think it creates a performance regression where generated ijar would be same as jar and would cause more frequent recompilations especially on bigger projects

[meteorcloudy]

I'll leave this to @hvadehra @cushon and the java team to investigate.

[cushon]

The fix in #18406 LGTM

[dmivankov]

Can probably be closed as fixed in 6.3.0 that was just released

[meteorcloudy]

SG, thanks!