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

Brian Goetz brian.goetz at oracle.com
Thu Jul 21 14:15:07 UTC 2022


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?

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220721/e8404f16/attachment.htm>


More information about the classfile-api-dev mailing list