Opcode, LabelResolver & NewMultiArrayInstruction

[Brian Goetz]

> Sorry for another post with three points.

It’s like you have a buffer :)

> In Opcode.java, the TypeKind of ISHR & LSHR does not match the opcode:
> 
>     ISHR(Classfile.ISHR, 1, CodeElement.Kind.OPERATOR, TypeKind.FloatType),
>     LSHR(Classfile.LSHR, 1, CodeElement.Kind.OPERATOR, TypeKind.DoubleType),

Whoops :)

I’m not sure how much depends on these ancillary properties of Opcode, so this may not trigger any bad behavior, but obviously this is some sort of cut and paste error.  In an earlier iteration there were tons of ancillary properties and over time they migrated elsewhere (or were not needed.).  Before we fix this, we should look at how widely the “primary type kind” property is used, and whether this is the right place for it.

> Both CodeModel and CodeAttribute (from the published API) depend on
> jdk.classfile.impl.LabelResolver (from the implementation package) for
> the method labelToBci().  Maybe LabelResolver should be moved into the
> published API as well?

I’m surprised we didn’t see a warning for that, as there are supposed to be warnings for when encapsulated types leak into the API of exported types.  But, the LabelResolver type mostly serves the implementation, not the API, so I don’t think there’s a benefit of exposing it by name (the behavior it has is of course public.). 

> Finally, may I ask for an overload `of(ClassDesc,int)` in
> j.cf.i.NewMultiArrayInstruction similar to the one e.g. offered by
> TypeCheckInstruction?  Being able to create simple instructions
> outside of a CodeBuilder simplifies my intermediate representation
> significantly.  I can handle all the simple instructions with a single
> node class, and only have to define dedicated classes for more
> complicated higher-level stuff.  Without the ClassDesc overload, I
> would have to move NMAI from the generic into the dedicated category.

This seems reasonable enough.  This is in the category of “convenience factories”, of which we have many, but have not yet does a fully disciplined pass through the API to ensure that they are consistent across all the instructions / attributes / etc.  One of the risks of adding convenience factories like this is that each one we add sometimes raises “but why then isn’t there an anologous one here.”  It helps to proceed from some principles about what kinds of convenience factories we want, and then ensure they are all consistently implemented, rather than adding them one by one.