Bug in attribute writing

[Brian Goetz]

>> I'd like a fourth option, which maybe involves some sort of classfile
>> processing option to give us better guidance, but so far we are not sure
>> what is best here.
> A fourth option already exists in the Classfile API: we already
> process some attributes closely tied to others as an integral unit
> instead of separately, such as Code-StackMapTable, constant
> pool-BootstrapMethods. Maybe we can try singling out each element of a
> type annotation structure and bind it to its respective parent
> (exception catch, local variable, signature etc.) during processing.
> If a piece of information the annotation is trying to apply to does
> not exist, we can simply leave it and not transform or drop it
> (configured by classfile options), since it wouldn't be useful in the
> beginning.

So, this is viable (at some cost) but only for the subset of indexes 
that are routinely touched by classfile processing -- code array offsets 
and exception table offsets.  Others, such as "mth bound of nth type 
parameter" are strictly about signature attributes, which are 
(currently) opaque to the API.  So if we did this, we'd be trading 
incremental fidelity against incremental cost, but getting to full 
fidelity would be a heavy lift.

One of the costs of the model we've chosen is that it is somewhat hard 
to detect whether a transformation (or a delimited portion of it, such 
as on a method of a class) is the identity operation.  We do so with the 
Code attribute (if the code array is unchanged, we can reuse the stack 
map) but this is ad-hoc and expensive (it just happens to be less 
expensive than recomputing stack maps.)  But doing this more generally 
would have a significant cost that we have not yet paid.