[External] : Re: ClassHierarchyResolver using Reflection information
Brian Goetz
brian.goetz at oracle.com
Mon Mar 20 16:51:14 UTC 2023
After looking over this corner of the API, I think there's a little more
design work that needs to go into it. So let's step back from the
details of "what's the default" until we have a chance to look a little
more holistically at this part of the API. I'll try to write more about
it soon.
On 3/20/2023 11:47 AM, - wrote:
> If the choice of default resolver is still subject to debate, I can
> remove the delegation to system class loader based resolver in
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/13082__;!!ACWV5N9M2RV99hQ!K7UWlrg2NHotSKOzMvmfnenKZ1dDuOZ9zXcQvlKOdB21VvwTRIDuI2NyRNK6Hq844XIkt_6Q-qFt5DsFDUzgKJ31$ , and we can change it in
> another patch once we reach a consensus. The addition of lookup and
> class loader based resolvers can be used by users who explicitly
> specify a resolver in the options.
>
> On Mon, Mar 20, 2023 at 9:00 AM Adam Sotona<adam.sotona at oracle.com> wrote:
>> New behavior is “no assumptions” and throw IllegalArgumentException if information about type necessary to build stack map (or verify stack map) is not obtained from the resolver (or better say chain of resolvers).
>>
>>
>>
>> If user provides no resolver – the default is used.
>>
>>
>>
>> The way how default resolver gets the information from system classloader is subject of discussion below (resource parsing and fallback to class loading).
>>
>> Custom resolver can be constructed as a fallback chain from all provided resolver types (including the default resolver instance).
>>
>>
>>
>>
>>
>>
>>
>> On 20.03.2023 14:25, "Brian Goetz"<brian.goetz at oracle.com> wrote:
>>
>>
>> If the user provides no resolver at all, what is the new behavior? Do we just assume Object is the common supertype for any pair of classes?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230320/203d4c80/attachment-0001.htm>
More information about the classfile-api-dev
mailing list