RFR: jdk.classfile.transforms package cleanup + javadoc

[Brian Goetz]

>  - Does CodeLocalsShifter::addLocal work in concert with the 
> local-allocation feature of BlockBuilder?
>
> Good point :)
>
> It does not yet, however I’ll try to reimplement it to do so. We may 
> get rid of counting the method arguments, local counting of “next”, 
> use BlockBuilders instead of the “fork”, etc...
>

The local-allocation feature of BlockBuilder and friends is very "green" 
right now.  So I would not be surprised if you found potholes.  It also 
needs more tests.  As you point out in your other mail, there is nothing 
to stop the user from just "making up" local slot allocations, and then 
of course there would be conflicts between the automatic allocation and 
the user choices.  We try to detect this with this check:

         if (terminalMaxLocals != topLocal(terminal))
             throw new IllegalStateException("Interference in local 
variable slot management");

in BlockBuilder::end.  (One case we do not have a test for is where a 
stateful transform allocates a local in its atStart() method with 
builder::allocateLocal, and then the transform uses 
BlockBuilder::allocateLocal inside that.)

The package Javadoc probably needs a section for local variable 
management too, to explain how allocateLocal works, and what not to do 
when using it.  With some examples.

>
> The ASM "util" package contains: Trace/CheckClassAdapter and friends, 
> ClassPrinter, etc.  This feels in roughly the same category -- stuff 
> you may want to use, but which are "components" rather than framework.
>
> I think “commons” was not the best choice for ASM, as it represent 
> common (the bottom) parts of complex APIs in many external Java libraries.
>
> And I agree “transform” is too specific and “util” is probably too 
> general.
>
> My personal preference would be “components”.
>
>

I think that's a fair choice.  Just to validate that, here's some other 
things I can imagine going in that bucket:

  - ClassPrinter
  - Utilities for parsing descriptor strings.  To start with we might 
cleanup the most useful ones that are currently internal.  (Its possible 
that these could eventually be used by java.lang.constant too; there are 
too many ad-hoc copies of descriptor string parsers in java.base.)

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