-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Comments
Hello @dmlloyd, thank you for reporting this issue. We will be taking a look at this shortly. |
@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:
The referenced field is supposed to be of type |
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... :) |
Looks like the problem is on our end after all. Thanks for the hint. 👍 |
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 thejava.util.logging.Level#ALL
field by way of the subclassorg.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 viajavap
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.
The text was updated successfully, but these errors were encountered: