On Wed, 9 Apr 2025 15:34:25 GMT, Chen Liang <[email protected]> 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

Reply via email to