<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
This seems a pragmatic direction to me.<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Apr 14, 2023, at 11:42 AM, Adam Sotona <<a href="mailto:adam.sotona@oracle.com" class="">adam.sotona@oracle.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class="">Throwing<span class="Apple-converted-space"> </span></span><span style="font-size: 11pt;" class="">ConstantPoolException</span><span style="font-size: 11pt;" class=""><span class="Apple-converted-space"> </span><span lang="EN-US" class="">also
for symbol conversions is another option. Classfile API have to catch all the IAEs whenever the conversion happen and wrap them to<span class="Apple-converted-space"> </span></span></span><span style="font-size: 11pt;" class="">ConstantPoolException</span><span lang="EN-US" style="font-size: 11pt;" class="">.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class="">There are actually approx. 30 places across Classfile API, where the conversions to symbols happen.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class="">Some of them are in constantpool package, however many symbol conversions are spread in methods across annotations, models, attribute infos and instructions.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class="">Should all of them wrap IAE and throw<span class="Apple-converted-space"> </span></span><span style="font-size: 11pt;" class="">ConstantPoolException</span><span lang="EN-US" style="font-size: 11pt;" class=""><span class="Apple-converted-space"> </span>instead?
For example for annotations the ClassDesc is constructed from class descriptor stored in Utf8Entry, so it is not technically a ConstantPoolException.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class="">On the other side if ClassEntry::asSymbol will throw ConstantPoolException and Annotation::classSymbol will throw IAE – that would be even more confusing.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class="">I think it is a bit overkill for the very specific use case in javap and I’m not sure it is worth the price.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class="">I propose to unify on IAE (for simplicity in major use cases) and possible refine on ConstantPoolException (or more) as sub-class(es) of IAE (for the specific cases where we might want to differentiate).<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class="">Thanks,<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class="">Adam<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(181, 196, 223); padding: 3pt 0cm 0cm;" class="">
<p class="MsoNormal" style="margin: 0cm 0cm 12pt; font-size: 10pt; font-family: Calibri, sans-serif;">
<b class=""><span style="font-size: 12pt;" class="">From:<span class="Apple-converted-space"> </span></span></b><span style="font-size: 12pt;" class=""><a href="mailto:liangchenblue@gmail.com" class="">liangchenblue@gmail.com</a> <<a href="mailto:liangchenblue@gmail.com" class="">liangchenblue@gmail.com</a>><br class="">
<b class="">Date:<span class="Apple-converted-space"> </span></b>Thursday, 13 April 2023 19:53<br class="">
<b class="">To:<span class="Apple-converted-space"> </span></b>Adam Sotona <<a href="mailto:adam.sotona@oracle.com" class="">adam.sotona@oracle.com</a>><br class="">
<b class="">Cc:<span class="Apple-converted-space"> </span></b>Brian Goetz <<a href="mailto:brian.goetz@oracle.com" class="">brian.goetz@oracle.com</a>>,
<a href="mailto:classfile-api-dev@openjdk.org" class="">classfile-api-dev@openjdk.org</a> <<a href="mailto:classfile-api-dev@openjdk.org" class="">classfile-api-dev@openjdk.org</a>><br class="">
<b class="">Subject:<span class="Apple-converted-space"> </span></b>Re: Exceptions from invalid constant pool indices in the API<o:p class=""></o:p></span></p>
</div>
<div class="">
<div style="margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif;" class="">
<span style="font-size: 11pt;" class="">In your example, I don't think that would constitute a valid class<br class="">
constant pool entry: per JVMS 4.4.1<br class="">
<a href="https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.4.1" style="color: blue; text-decoration: underline;" class="">https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.4.1</a>,<br class="">
the CONSTANT_Class_info is not valid without a valid Utf8 entry<br class="">
content. I think the 3rd case is essentially the same as the 2nd case<br class="">
you've listed, and they can both be converted from<br class="">
IllegalArgumentException to ConstantPoolException, as they fall in the<br class="">
same error category (invalid name_index) under the VM spec. They can<br class="">
just be distinguished by different messages.<br class="">
<br class="">
On Thu, Apr 13, 2023 at 11:18 AM Adam Sotona <<a href="mailto:adam.sotona@oracle.com" class="">adam.sotona@oracle.com</a>> wrote:<br class="">
><br class="">
> By failing symbols validation I mean when for example index points to correct ClassEntry pointing to correct Utf8Entry name, however the name is not valid class name and ClassDesc construction throws IAE.<br class="">
><br class="">
> Each such case must be individually safeguarded to do not prematurely terminate the whole javap.<br class="">
><br class="">
><br class="">
><br class="">
> From: Brian Goetz <<a href="mailto:brian.goetz@oracle.com" class="">brian.goetz@oracle.com</a>><br class="">
> Date: Thursday, 13 April 2023 17:46<br class="">
> To: Adam Sotona <<a href="mailto:adam.sotona@oracle.com" class="">adam.sotona@oracle.com</a>><br class="">
> Cc: <a href="mailto:liangchenblue@gmail.com" class="">liangchenblue@gmail.com</a> <<a href="mailto:liangchenblue@gmail.com" class="">liangchenblue@gmail.com</a>>,
<a href="mailto:classfile-api-dev@openjdk.org" class="">classfile-api-dev@openjdk.org</a> <<a href="mailto:classfile-api-dev@openjdk.org" class="">classfile-api-dev@openjdk.org</a>><br class="">
> Subject: Re: Exceptions from invalid constant pool indices in the API<br class="">
><br class="">
> So, I think there are two reasons we might consider a more precise exception here. One is Chen’s concern of “what do I catch”, and the other is simply getting a more human-readable explanation of what went wrong. Exceptions like AIOOBE and IAE are often
not helpful in explaining what actually went wrong (what index? Into what? Where did the bad value come from?).<br class="">
><br class="">
><br class="">
><br class="">
> Part of this is the exception type (which helps both of these audiences), and part of this is the exception message (which helps only the latter.). We should probably do a pass and make sure we have informative error text in all throw points.<br class="">
><br class="">
><br class="">
><br class="">
> What do you mean “when the symbol fails validation”?<br class="">
><br class="">
><br class="">
><br class="">
> On Apr 13, 2023, at 9:00 AM, Adam Sotona <<a href="mailto:adam.sotona@oracle.com" class="">adam.sotona@oracle.com</a>> wrote:<br class="">
><br class="">
><br class="">
><br class="">
> I’ve tried to convert all CP related exceptions to a new ConstantPoolException, however IllegalArgumentException is still in the game (in javap) as a secondary exception thrown during validation of symbols.<br class="">
><br class="">
> For example printing of Signature attribute or any ClassDesc can now fail with:<br class="">
><br class="">
> IndexOutOfBoundsException when the index is invalid<br class="">
> IllegalArgumentException when the CP entry is invalid<br class="">
> IllegalArgumentException when the symbol is invalid<br class="">
><br class="">
><br class="">
><br class="">
> After merge of CP-related IndexOutOfBoundsException and IllegalArgumentException into ConstantPoolException we can get:<br class="">
><br class="">
> ConstantPoolException when the index is invalid<br class="">
> ConstantPoolException when the CP entry is invalid<br class="">
> IllegalArgumentException when the symbol fails validation<br class="">
><br class="">
><br class="">
><br class="">
> Is it still worth to introduce a new exception when javap still must individually safeguard also IllegalArgumentExceptions ?<br class="">
><br class="">
><br class="">
><br class="">
> What about to replace CP-relate IndexOutOfBoundsException with IllegalArgumentException so we will have one single type of exception to catch when class reading?<br class="">
><br class="">
> Or what if we make ConstantPoolException a sub-class of IllegalArgumentException?<br class="">
><br class="">
><br class="">
><br class="">
> Thanks,<br class="">
><br class="">
> Adam<br class="">
><br class="">
><br class="">
><br class="">
> From: classfile-api-dev <<a href="mailto:classfile-api-dev-retn@openjdk.org" class="">classfile-api-dev-retn@openjdk.org</a>> on behalf of Brian Goetz <<a href="mailto:brian.goetz@oracle.com" class="">brian.goetz@oracle.com</a>><br class="">
> Date: Tuesday, 11 April 2023 2:15<br class="">
> To: <a href="mailto:liangchenblue@gmail.com" class="">liangchenblue@gmail.com</a> <<a href="mailto:liangchenblue@gmail.com" class="">liangchenblue@gmail.com</a>><br class="">
> Cc: <a href="mailto:classfile-api-dev@openjdk.org" class="">classfile-api-dev@openjdk.org</a> <<a href="mailto:classfile-api-dev@openjdk.org" class="">classfile-api-dev@openjdk.org</a>><br class="">
> Subject: Re: Exceptions from invalid constant pool indices in the API<br class="">
><br class="">
> Good suggestion!<br class="">
><br class="">
> > On Apr 10, 2023, at 4:34 PM, <a href="mailto:liangchenblue@gmail.com" class="">
liangchenblue@gmail.com</a> wrote:<br class="">
> ><br class="">
> > When I was taking a peek at the conversion of javap to Classfile API,<br class="">
> > I found that the old API has a feature that the API might be<br class="">
> > interested in: a dedicated exception ConstantPoolException for invalid<br class="">
> > constant pool indices, caused by incorrect types or out-of-bounds. We<br class="">
> > currently throw IllegalArgumentException and IndexOutOfBoundsException<br class="">
> > in the Classfile API, so it is a bit harder to catch such invalid<br class="">
> > indices.<br class="">
> ><br class="">
> > Javap is tolerant to invalid class file formats while the reading part<br class="">
> > of Classfile API is not so much; in general, Classfile API fails fast<br class="">
> > if it encounters invalid constant pool entries; this I agree, that<br class="">
> > invalid entries render a classfile invalid, but maybe we can unify the<br class="">
> > reading exceptions from ConstantPoolReader into a common type like in<br class="">
> > the old API, so we can more easily report constant pool errors or skip<br class="">
> > invalid but optional entries.<br class="">
> ><br class="">
> > Chen Liang<br class="">
><br class="">
></span></div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>