Bug in attribute writing

[-]

For writing, I don't think unknown attributes are ever created when
they are presented in the first place; so we can assume "support
unknown attributes" is always true.

A tricky part of unknown attribute handling is that
AttributedElement::attributes() return value may contain null if
unknown attributes aren't supported. This should be explicitly
specified.

The bound type annotation attributes indeed may not properly be
rewritten when its dependencies (exception handlers, labels, parameter
indices, etc.) are updated. Should users be advised to track these
changes to attributes on their own?

I think we can alleviate such dependencies by exposing pointers in the
model: for instance, we will use Label instead of int for startPc for
LocalVariableTable; the catch table index in type annotation targets
can refer to ExceptionCatch. Then, in the writeDirect checks, we
propagate checks to the components: if the dependencies of the Labels
or ExceptionCatchs are the same (much like how a constant pool is
still the same), we will perform direct write; otherwise we perform a
clean write.

Chen Liang

On Thu, May 18, 2023 at 9:34 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> I just noticed that in BoundAttribute.BoundUnknownAttribute:
>
>         private void checkWriteSupported(Function<ConstantPool, Boolean> condition) {
>             if (!condition.apply(classReader))
>                 throw new UnsupportedOperationException("Write of unknown attribute " + attributeName() + " not supported to alien constant pool");
>         }
>
> we should at least be checking the option "support unknown attributes" before we say OK.
>
> Overall, I am not sure we have a fully consistent story for unsupported attributes here.  The basic problem with attributes for which we don't have an AttributeMapper is that we can't be sure about validity.  We don't know where the CP indexes are (though if we are sharing CPs, this is OK), and we don't know what other data might be off.
>
> (We also have a bigger problem with the type annotations attributes, which are known to have all sorts of non-CP offsets (nth bound of mth type variable, nth exception, indexes into code array, etc) which could easily but thrown off by transformation and there is no practical way to detect whether the original RVTA is still valid.)