On Fri, 31 Mar 2023 03:24:22 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> 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. I believe that, in order to generate the actual bytecodes, the classfile API does a full verification pass (as it needs to infer the stackmap information). This leads me to believe that, yes, most (but probably all) errors would be detected simply by generating code. Maybe @asotona can clarify. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1154355885
