Classfile API tracking RFEs

[Michael van Acken]

Below some minor comments based on my experience from last summer.

Am Di., 7. März 2023 um 15:40 Uhr schrieb Adam Sotona <
adam.sotona at oracle.com>:

> Hi,
>
> Some of the proposed RFEs fall beyond the initial Classfile API pull
> request and we should probably start filling them to JBS or find another
> way to track them.
>
>
>
> Here are listed citations (for temporary tracking purpose) what I’ve
> collected from the feedback:
>
>
>
>    1. switch seems the one instruction for which an high-level variant
>    (like trying) could be useful, as generating code for that can be
>    quite painful.
>
>
I'm not a user of trying and I probably would not use switch as well, but a
method wrapping
tableSwitchInstruction() and lookupSwitchInstruction() would be useful to
me.  As Brian pointed
out, one is optimizing for byte code size when choosing between the two.
Being effectively
isolated from byte codes and their size by the Classfile API, I would
appreciate if there was a
way to delegate this decision to the API.

(This is not a vote against a trying-like higher level switch variant.  My
last major code
generation bug was the bytecode equivalent of omitting the breaks from a
switch, i.e. forgetting
the GOTO at the end of paths that did not end with a RETURN.)

In a similar vein and along the lines of constantInstruction(), a method
moving newarray(),
anewarray(), and multianewarray() under a single umbrella would be helpful.

Oh, and constantInstruction() properly handling -0.0d and -0.0f would be
nice.  This is the
one patch I have been carrying around since the very beginning that has not
been resolved.

-- mva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230307/30bfd429/attachment.htm>