<div dir="ltr"><div>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.</div><div><br></div><div>With that being said, I still encounter some problematic bits:</div><div><br></div><div>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.</div><div><br></div><div>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?<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Thanks for the great job so far and for addressing my suggestions!</div><div>Best regards, Rafael<br></div></div>