Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inherited static field not found at build time/"Discovered unresolved field during parsing" #8016

Closed
dmlloyd opened this issue Dec 13, 2023 · 4 comments
Assignees

Comments

@dmlloyd
Copy link
Contributor

dmlloyd commented Dec 13, 2023

Describe the issue

According to JVMS 17 §5.4.3.2, searching for fields involves recursively traversing superinterfaces and superclasses. However, we have found an issue (quarkusio/quarkus#37598) with searching superclasses for static fields under GraalVM, specifically the class parser which misses them.

Steps to reproduce the issue
Try a simple Java file which inherits a static field. In our case, the user included the jboss-logmanager project, and referenced the java.util.logging.Level#ALL field by way of the subclass org.jboss.logmanager.Level. The subclass does not define the field, so the resolution relies on the JVM recursing to the superclass. Examine the test file via javap to ensure that the field reference is targeting the subclass.

There is a more comprehensive reproducer in quarkusio/quarkus#37598.

Describe GraalVM and your environment:
The original issue was produced via Mandrel: Java version: 21.0.1+12-LTS, vendor version: Mandrel-23.1.1.0-Final

I thought we had previously reported this bug but I couldn't find any evidence/history of such a report, so I guess I hallucinated it.

@solaanan
Copy link

Hello @dmlloyd, thank you for reporting this issue. We will be taking a look at this shortly.

@christianwimmer
Copy link

@dmlloyd the native image generator uses the class file loader and field/method/class resolution code from the hosting HotSpot VM, via JVMCI. So while it is always possible that there is a bug, it is not the most likely case. If you have a simple Java file to reproduce the problem, please send it to me (together with the .class files for completeness).

For the failing Quarkus reproducer, I would say that the problem is wrong bytecode produced by Quarkus. The unresolved field is the result of the following bytecode:

io.quarkus.runtime.generated.Target_org_jboss_logmanager_Logger.isLoggable(Unknown Source) [bci: 11, intrinsic: false]
  11: getstatic     #2          // org.jboss.logmanager.Level.ALL:org.jboss.logmanager.Level

The referenced field is supposed to be of type org.jboss.logmanager.Level. That field does not exist in any superclass, because the superclass java.util.logging.Level defines the field ALL of type java.util.logging.Level - matching the name but not matching the type. The existing field in the superclass is therefore not a valid resolution for this field lookup.

@dmlloyd
Copy link
Contributor Author

dmlloyd commented Dec 21, 2023

The referenced field is supposed to be of type org.jboss.logmanager.Level. That field does not exist in any superclass, because the superclass java.util.logging.Level defines the field ALL of type java.util.logging.Level - matching the name but not matching the type. The existing field in the superclass is therefore not a valid resolution for this field lookup.

Ah, that's likely the problem, good catch. I guess I need new glasses. I'll confirm that this is the issue, thanks.

I thought it was a pretty strange and unlikely thing... :)

@dmlloyd
Copy link
Contributor Author

dmlloyd commented Dec 21, 2023

Looks like the problem is on our end after all. Thanks for the hint. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants