[External] : Re: ClassHierarchyResolver using Reflection information

- liangchenblue at gmail.com
Mon Mar 20 15:47:35 UTC 2023


If the choice of default resolver is still subject to debate, I can
remove the delegation to system class loader based resolver in
https://github.com/openjdk/jdk/pull/13082, 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?
>
>


More information about the classfile-api-dev mailing list