RFR: 8333377: Migrate Generic Signature parsing to ClassFile API [v6]
ExE Boss
duke at openjdk.org
Thu Oct 23 19:33:59 UTC 2025
On Wed, 9 Apr 2025 15:34:25 GMT, Chen Liang <liach at openjdk.org> wrote:
>> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
>>
>> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>
> - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
> - Improve BytecodeDescriptor error message
> - Years, test facelift
> - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
> - 8333377: Migrate Generic Signature parsing to ClassFile API
Since [JDK‑8368331] has been fixed now, this PR should probably be linked to [JDK‑8351103] as well.
[JDK‑8351103]: https://bugs.openjdk.org/browse/JDK-8351103 "[JDK‑8351103] JVMS class signature specification disagrees with implementation"
[JDK‑8368331]: https://bugs.openjdk.org/browse/JDK-8368331 "[JDK‑8368331] ClassFile Signature parsing fails for type parameter with no supertype"
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19281#issuecomment-3438779549
More information about the core-libs-dev
mailing list