Classfile API proposal to integrate basic print functionality directly to ClassModel and MethodModel

[Eric Bruneton]

Le 21/07/2022 à 16:15, Brian Goetz a écrit :
> I think the root of the problem here is that CodeBuilder combines the 
> “build my method” with stackmap generation, and if the latter fails, 
> nothing is produced.  And when stack map generation fails, you’d like to 
> see a javap-like output so you can see what you did wrong.
> 
> You can suppress stack map generation with an Option, and then you’ll 
> get a classfile out, but that is probably a little hard to discover.
> 
> This is a more general problem, not just for stack maps; there are other 
> things that can cause code generation to fail (e.g., forward branch to a 
> label that is never defined; invalid labels in exception tables; etc.) 
>   The main vector we have for feeding back information is the exception 
> message, but putting the entire javap output of the method body in the 
> exception message might be too much (but might not be, since any 
> exception from building a classfile will trigger a round of debugging.)
> 
> Any thoughts on how you would like to see this information fed back?

For debugging, could you replace the builder with a dummy builder which 
would print the class instead of actually building a byte array? More 
generally could you insert a "no-op" class transform anywhere in a 
transformation chain, which would print the class instead of 
transforming it? This is how we do this in ASM, with the 
TraceClassVisitor (which can be used instead of ClassWriter, or anywhere 
in a chain of visitors). But maybe this is not possible/desirable with 
this API?

Maybe a "ClassModelBuilder" (ClassModel build(ClassDesc thisClass, 
Consumer<ClassBuilder> handler)) could be useful too?

Eric

> 
>> Is there a way to print out a trace of parts fed to CodeBuilder instances?
>>
>> Just this morning I had Classfile die on me because of a stack underflow,
>> and it was quite hard to find out which parts were missing from the Code
>> attribute.  And that with a Code totalling just 5 instructions...
>>
>> If there would have been bytes output, then I could have inspected the
>> situation with javap.  But if I mess up and pass inconsistent data to
>> CodeBuilder, causing it to throw instead of producing a byte array, then
>> I have an observability gap.
>>
>> -- mva
>>
>