RFR: 8298065: Provide more information in message of NoSuchFieldError
Matias Saavedra Silva
matsaave at openjdk.org
Thu Dec 22 16:06:49 UTC 2022
On Wed, 21 Dec 2022 08:28:14 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> A java.lang.NoSuchFieldError is typically thrown when you remove a field but do not recompile the client code that calls the field. However, the message does not indicate in which class the field was not found.
>>
>> Additionally, java.lang.NoSuchFieldError is thrown if the field is still present but the types are incompatible. For example, if a field is first defined as int, and later changed to long without recompiling the client. The error text has been expanded to include the class name and field type. Verified with tier 1-4 tests.
>>
>> Old output:
>> `Exception in thread "main" java.lang.NoSuchFieldError: x
>> at NoSuchFieldMain.main(NoSuchFieldMain.java:3)`
>> Example output:
>> `Exception in thread "main" java.lang.NoSuchFieldError: Class Other does not have field 'int x'
>> at NoSuchFieldMain.main(NoSuchFieldMain.java:3)`
>
> src/hotspot/share/interpreter/linkResolver.cpp line 977:
>
>> 975: THROW_MSG(vmSymbols::java_lang_NoSuchFieldError(),
>> 976: err_msg("No resolved class, field '%s %s'",
>> 977: type2name(Signature::basic_type(sig->char_at(0))),
>
> Isn't this going to report "object" for all non-primitive types?
You're absolutely right, this would output "object" for all references and "array" for all array types. Ideally this should be more detailed about these types.
-------------
PR: https://git.openjdk.org/jdk/pull/11745
More information about the hotspot-runtime-dev
mailing list