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