<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">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?</font></font><br>
<br>
<div class="moz-cite-prefix">On 3/20/2023 7:17 AM, Adam Sotona
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CY4PR1001MB2150B3C0F8976FCE8963E2A58C809@CY4PR1001MB2150.namprd10.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt" lang="EN-US">FYI:
I’ve filled a new bug and proposed patch:
</span><b><span style="font-size:11.0pt"><a href="https://github.com/openjdk/jdk/pull/13099" moz-do-not-send="true">8304502: Classfile API class
hierarchy makes assumptions when class is not
resolved #13099</a><o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt" lang="EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt" lang="EN-US">Adam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt" lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt">On 20.03.2023 10:50, "Adam
Sotona" <a class="moz-txt-link-rfc2396E" href="mailto:adam.sotona@oracle.com"><adam.sotona@oracle.com></a> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">I agree with your
concerns. The benevolence of the CHR was decision of an
early development stage, it supposed to be temporary and now
it is a clear bug.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">So from my perspective
- yes, fail fast and fail when any required class is not
resolved.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">Classfile API as well
as ASM are designed to handle majority of cases without user
knowledge of CHR or class loading details. I guess only few
ASM users know how to pass custom class loader for correct
CHR for stack maps generation. I’ll try to summarize
benefits and negatives of my proposal to extend default CHR
to fall back to a class loading CHR.
</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">Benefits of CHR by
classfile parsing:</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level1 lfo3">
<!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]--><span style="font-size:11.0pt" lang="EN-US">Performance – “skip-parsing” of constant pool +
classfile header is in order of magnitude faster than class
loading</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level1 lfo3">
<!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]--><span style="font-size:11.0pt" lang="EN-US">Simplicity/Stability – it is not necessary to
provide all dependencies to identify if the type is an
interface or what is its super. It is not necessary to have
complete classpath with implementation of some API to
generate code using the API.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">Negatives of CHR by
classfile parsing:</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level1 lfo3">
<!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]--><span style="font-size:11.0pt" lang="EN-US">Availability - a classfile may not be
available or accessible as a resource for parsing</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1
level1 lfo3">
<!--[if !supportLists]--><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]--><span style="font-size:11.0pt" lang="EN-US">Different results – a classfile may be modified
when loaded, however the modification would have to change
its super class or its status of being an interface to make
any impact.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">By adding a fallback
to class loading CHR we will eliminate the “Availability“
negative, with no performance loose.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">I think that the
default should be rock-solid, because 99% of users will use
the default.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">Adam</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US">BTW: Maybe even more
beneficial would be an ability to question already loaded
classes first (without loading them), parse them as resource
if not already loaded and fallback to load them if not
available as resource. </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt" lang="EN-US"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt">On 18.03.2023 5:06, "Michael van
Acken" <a class="moz-txt-link-rfc2396E" href="mailto:michael.van.acken@gmail.com"><michael.van.acken@gmail.com></a> wrote:</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt">Am Fr., 17. März 2023 um
19:34 Uhr schrieb Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@oracle.com</a>>:</span><o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt">I'm not so comfortable adding
this to DEFAULT_CHA. In addition to
<br>
adding another degree of environmental dependence, and
the issues of <br>
additional exceptions you raise, I suspect it may also
have a <br>
performance cost. I would like for programmers to opt
into which CHA <br>
they use, and the default should be the most minimal.
This means having <br>
a menu of CHAs to choose from, rather than guessing
what the user wants.</span><o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt">The default
classHierarchyResolver has an opaque (to me) error<br>
mode that tripped me up. Similar to my experience
with ASM some<br>
years ago, it works fine for a lot (most?) of code,
but then some<br>
input causes it to silently produce a stack map the
verifier does<br>
not agree with. For me, this happens usually quite
late in the<br>
game and at first is completely baffling. Back in
July it was<br>
mostly luck and half buried memories that sent me into
the<br>
direction of CHR as the solution to the verifier
error. If the<br>
default CHR had raised an exception at the point where<br>
information was missing, the path to the fix
(preloading the CHR<br>
with information about future classes) would have been
clearer.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt">--mva</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:72.0pt"><span style="font-size:11.0pt"><br>
On 3/17/2023 2:25 PM, - wrote:<br>
> I've submitted a patch at <a href="https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/13082__;!!ACWV5N9M2RV99hQ!IckIM3pDx0kj8-sYmKqh2mYHCcMDA3jEXIwOwzMAsirh8YKg1N949owV5wzMUHjA8_uF8Seb8GjSAMGhFN0zL4nTfIE$" target="_blank" moz-do-not-send="true">
https://github.com/openjdk/jdk/pull/13082</a><br>
> Yet with it comes 3 questions:<br>
><br>
> 1. Should the resolver fail fast on
IllegalAccessException from the<br>
> lookup? This usually indicates the hierarchy
resolver is set up<br>
> improperly, and proceeding may simply yield
verification errors in<br>
> class loading that are hard to track. For
bytecode-generating APIs,<br>
> throwing access errors for the Lookup eagerly is
also more preferable<br>
> than later silent generation failure.<br>
><br>
> The main concern for me to fail fast is that I
don't understand how<br>
> the Classfile API propagates resolver exceptions.
If wrapping the<br>
> IllegalAccessException in an IllegalAccessError
is safe, then I may<br>
> change it and add a test case with HashMap.<br>
><br>
> 2. Whether the default resolver should be reading
from jrt alone,<br>
> reflection alone, or jrt then reflection. I
personally believe<br>
> reflection alone is more reliable, for classes
may be redefined with<br>
> instrumentation or jfr, which may not be
reflected in the system<br>
> resources.<br>
><br>
> This idea came to me while I was working on jfr
and instrumentation<br>
> tests. Luckily, it seems they don't touch class
hierarchy that the<br>
> default resolver suffices.<br>
><br>
> 3. In addition, I don't think chaining system
class loader reflection<br>
> after system resource retrieval is really
meaningful: is there any<br>
> case where reflection always works while the
system resource retrieval<br>
> always fails?<br>
><br>
> Chen<br>
><br>
> On Fri, Mar 17, 2023 at 7:11 AM Adam Sotona <<a href="mailto:adam.sotona@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">adam.sotona@oracle.com</a>>
wrote:<br>
>> I like your proposal and I would like to see
it as a fallback solution for
DEFAULT_CLASS_HIERARCHY_RESOLVER when the class is not
available as resource stream.<br>
>><br>
>><br>
>><br>
>> /**<br>
>><br>
>> * Default singleton instance of
{@linkplain ClassHierarchyResolver}<br>
>><br>
>> * using {@link
ClassLoader#getSystemResourceAsStream(String)}<br>
>><br>
>> * as the {@code ClassStreamResolver}
with fallback to<br>
>><br>
>> * {@link
ClassLoader.getSystemClassLoader()} class loading
resolver.<br>
>><br>
>> */<br>
>><br>
>> ClassHierarchyResolver
DEFAULT_CLASS_HIERARCHY_RESOLVER<br>
>><br>
>> = new
ClassHierarchyImpl.CachedClassHierarchyResolver(<br>
>><br>
>> new Function<ClassDesc,
InputStream>() {<br>
>><br>
>> @Override<br>
>><br>
>> public InputStream
apply(ClassDesc classDesc) {<br>
>><br>
>> return
ClassLoader.getSystemResourceAsStream(Util.toInternalName(classDesc)
+ ".class");<br>
>><br>
>> }<br>
>><br>
>>
}).orElse(ClassHierarchyResolver.of(ClassLoader.getSystemClassLoader()));<br>
>><br>
>><br>
>><br>
>> Thanks,<br>
>><br>
>> Adam<br>
>><br>
>><br>
>><br>
>> On 16.03.2023 17:05, "<a href="mailto:liangchenblue@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">liangchenblue@gmail.com</a>"
<<a href="mailto:liangchenblue@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">liangchenblue@gmail.com</a>>
wrote:<br>
>><br>
>><br>
>><br>
>> For context, in 8294961<br>
>> <a href="https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/10991/files*r1133086265__;Iw!!ACWV5N9M2RV99hQ!IckIM3pDx0kj8-sYmKqh2mYHCcMDA3jEXIwOwzMAsirh8YKg1N949owV5wzMUHjA8_uF8Seb8GjSAMGhFN0zkG4CkgE$" target="_blank" moz-do-not-send="true">
https://github.com/openjdk/jdk/pull/10991/files#r1133086265</a> I
wondered<br>
>> about whether to use a hierarchy resolver for
LambdaMetafactory, that<br>
>> I think resolution may encounter problems as
the default resolver may<br>
>> not be able to resolve user-supplied
interfaces.<br>
>><br>
>> In addition, many of the class file
generation usages I've seen<br>
>> include firing events via an event bus,
calling patched external addon<br>
>> code (as seen in Minecraft modding), in which
Reflection-based<br>
>> hierarchy resolution would work better than
reading bytecode files.<br>
>><br>
>> Thus, I've prepared a patch creating
ClassHierarchyResolver<br>
>> <a href="https://urldefense.com/v3/__https:/github.com/openjdk/jdk/commit/0c888ba1e2953cf946012244446f4f8c05ba5d77__;!!ACWV5N9M2RV99hQ!IckIM3pDx0kj8-sYmKqh2mYHCcMDA3jEXIwOwzMAsirh8YKg1N949owV5wzMUHjA8_uF8Seb8GjSAMGhFN0zl_RRNVo$" target="_blank" moz-do-not-send="true">
https://github.com/openjdk/jdk/commit/0c888ba1e2953cf946012244446f4f8c05ba5d77</a><br>
>> to ease up resolution with reflection, when a
ClassLoader (for older<br>
>> APIs) or a MethodHandle.Lookup (for modern
APIs) is available.<br>
>><br>
>> Does this appear feasible?<br>
>><br>
>> Chen</span><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>