RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]

[Jorn Vernee]

On Fri, 31 Mar 2023 02:34:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Just to clarify: I'm looking for the kind of errors that don't get caught by just generating the class, but are also more informative than the default VerifyError you would get from loading an invalid class.
>
> Classfile API does have some sort of error reporting mechanism in verification; at least it tracks the error context.
> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java#L1810-L1828
> The method dumping is providing a yaml tree representation of the class file to the provided Consumer, and the VerifyError itself already includes the error context. What exact specific information are you looking for that's provided by ASM? We might be able to add it to Classfile API too.

I'm not really looking for anything specific. I'm just trying to figure out if it's worth it to keep the `PERFORM_VERIFICATION` flag, and change it to call the verifier in the new impl. i.e. does it catch more errors than just generating and loading the class would (or does it output the errors in a better format).

I had a brief look at the implementation, and it seems that the consumer is for detailed logging of the verification process. I think in this case we're just interested in catching errors.

I already tried switching the code to call `Classfile.parse(newBytes).verify(null).forEach(System.err::println)`, but the error I artificially introduced was already being caught during class generation. So I'm wondering if having a separate verification pass will actually catch any additional errors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1153974112