Long-term maintenance of verifier

[Adam Sotona]

Java copy of the class file verifier played critical role in the Class-File API development.
Now it is important for the Class-File API tests, and it also serves as useful tool to Class-File API users.
Despite its effort to identify all violations of the JVMS 4.10, it does not cover 100%.

There were (and still are) three options how to handle this situation:

  1.  Use the native class file verifier in the Class-File API.
An attempt to implement this option failed at the early stage of the Class-File development. It requires significant implementation changes on the native verifier side or class loading of each involved class.

  2.  A Java copy of the native class file verifier.
That is the current solution, which serves its limited purpose, and it requires synchronization.

  3.  A single Java-based class file verifier implementation.
Complexity of such solution is the highest because it needs to perfectly serve two different purposes. We can start think of the native class file verifier as soon as all the coverage, compatibility, API design, bootstrap, and performance obstacles are resolved.

My suggestion would be to keep the “easy-to-synchronize” Java copy of the native class file verifier and keep it up to date.
Until a new class file verifier implementation appears, with capability to replace them both. However, that would not be an easy task.

Thanks,
Adam

From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of Chen Liang <liangchenblue at gmail.com>
Date: Friday, 6 June 2025 at 4:01
To: classfile-api-dev <classfile-api-dev at openjdk.org>
Subject: Long-term maintenance of verifier
Hello,
I have noted that the classfile API's copy of migrated verifier seems to naturally diverge from the c++ code: for example, JDK-8350029 that restricts invokespecial to not allow invoking arbitrary interface methods is not shadowed to the classfile verifier. This problem will only get more serious once strict fields are added. Meanwhile, people expect ClassFile.verify to be up-to-date with the runtime verifier.

What should we do to resolve this discrepancy? Should we have a separately maintained Java-based verifier implementing JVMS 4.10, or should we just increase our frequency of synchronizing with runtime?

Regards,
Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250606/2ab12970/attachment-0001.htm>