RFR: 8304502: Classfile API class hierarchy makes assumptions when class is not resolved [v2]
Jaikiran Pai
jpai at openjdk.org
Tue Mar 21 09:49:45 UTC 2023
On Mon, 20 Mar 2023 14:06:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:
>> Classfile API class hierarchy makes assumptions when class is not resolved and that may lead to silent generation of invalid stack maps. Only debug-level log information of case is actually provided.
>>
>> Proposed patch throws IllegalArgumentException when the class is not resolved instead.
>>
>> Thanks for review.
>>
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>
> Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
>
> Co-authored-by: liach <7806504+liach at users.noreply.github.com>
Looks OK to me. Just a minor comment, which I've added inline.
src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 172:
> 170: public StaticClassHierarchyResolver(Collection<ClassDesc> interfaceNames, Map<ClassDesc, ClassDesc> classToSuperClass) {
> 171: map = HashMap.newHashMap(interfaceNames.size() + classToSuperClass.size() + 1);
> 172: map.put(ConstantDescs.CD_Object, new ClassHierarchyInfo(ConstantDescs.CD_Object, false, null));
Hello Adam, for this `Object` class representation, perhaps you could just have a `static final` field which is instantiated to this value and reused instead of creating a new instance each time?
-------------
Marked as reviewed by jpai (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/13099#pullrequestreview-1350037496
PR Review Comment: https://git.openjdk.org/jdk/pull/13099#discussion_r1143113268
More information about the core-libs-dev
mailing list