Byte Buddy: down to 2 test errors only, and more feedback

[Rafael Winterhalter]

I can happily report that I am down to two test errors (out of over 10.000
tests!) when only using the adapters for the ASM API that I wrote. Those
two are related to the inability of assigning line numbers late since the
attribute requires BCI instead of labels, as I discussed prior. If it
becomes possible to translate labels from an attribute writer, or if the
standard attribute for line numbers becomes based on labels, I would be
able to fully build Byte Buddy without ASM class readers and class writers.

With that being said, I still encounter some problematic bits:

1. It is rather hard to translate between attributes in ASM and the Class
File API. Ideally, I would want to bridge the Class File APIs
AttributeMapper interface to write and read from ASM and the other way
round. In ASM, this requires some API extensions as the current API for
reading and writing is not accessible for outside users. It therefore
requires some hacks and the use of reflection. The other way is even more
difficult since I cannot implement interfaces as BufWriter myself to direct
to ASM. Could it be considered to create a superinterface of the parameters
in the AttributeMapper that only contain the relevant methods and keep
those unsealed? This way, they are not bound to the JDK's implementation.

2. I find it a bit confusing that the AttributeMapper reads the attribute
name automatically (this is needed anyways to find the right mapper), but
does not write it automatically. Writing the name is always required to
create a valid class file, and right now reading and writing is asymmetric
as a result. I suggest to write the attribute name before invoking
AttributeMapper::writeAttribute as it can be read from
AttributeMapper::name. Or was this intentional to allow multifaceted
attribute translations?

3. I would still like to control what stack map frames are generated when
placing the attribute manually. In theory, I can write my own
AttributeMapper for this once the mapper allows to translate BCI to Labels,
but I wonder if the JDK should offer this? As a general rule I experienced
byte code manipulation to be the most reliable when as much as possible is
retained in its original state since some tools make assumptions.

4. I would still love to control the values for max size and local variable
array for the same reason as just stated. Also, if the computation in the
JDK would show a bug, the bug can be adressed by the using tool rather than
requiring a JDK upgrade. Byte Buddy, for instance, does a lot of book
keeping and is battle tested for many corner cases. I would assume that its
computation can normally be considered reliable.

Thanks for the great job so far and for addressing my suggestions!
Best regards, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20240822/255f930f/attachment-0001.htm>