On Tue, 31 Mar 2026 15:06:14 GMT, Chen Liang <[email protected]> wrote:
>> Some core reflection APIs look for methods in classfile format that are >> expected to be present from the Java compiler. These APIs are: >> `Class.getEnclosingMethod`/`Constructor` and `RecordComponent.getAccessor`. >> >> Currently, the Class ones throw `InternalError`, and the RecordComponent one >> returns null. These are not suitable behaviors as `InternalError` indicates >> an unrecoverable VM error, and a null return can propagate the error >> downstream and is not informative. >> >> I propose to make these methods all throw `NoSuchMethodError`, a subtype of >> `LinkageError` and `IncompatibleClassChangeError`, which more accurately >> reflects the cause of these scenarios. This is also more in line with other >> failure modes of APIs like `Class.getDeclaringClass`, which throws >> `NoClassDefFoundError`. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Chen Liang has updated the pull request incrementally with one additional > commit since the last revision: > > Make resolution error reporting more concise test/jdk/java/lang/Class/getEnclosingMethod/BadEnclosingMethodTest.java line 73: > 71: var cp = cb.constantPool(); > 72: var enclosingMethodName = cp.utf8Entry(name); > 73: var enclosingMethodType = cp.utf8Entry(type); // a > malformed method type This comment is no longer accurate: Suggestion: var enclosingMethodType = cp.utf8Entry(type); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30506#discussion_r3075296953
