On Mon, 21 Oct 2024 15:53:18 GMT, ExE Boss <d...@openjdk.org> wrote: >> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains nine commits: >> >> - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final >> >> # Conflicts: >> # src/java.base/share/classes/java/lang/classfile/AccessFlags.java >> # src/java.base/share/classes/java/lang/classfile/ClassBuilder.java >> # src/java.base/share/classes/java/lang/classfile/ClassElement.java >> # src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java >> # >> src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java >> # src/java.base/share/classes/java/lang/classfile/ClassModel.java >> # src/java.base/share/classes/java/lang/classfile/ClassReader.java >> # src/java.base/share/classes/java/lang/classfile/ClassSignature.java >> # src/java.base/share/classes/java/lang/classfile/CodeBuilder.java >> # src/java.base/share/classes/java/lang/classfile/CodeElement.java >> # src/java.base/share/classes/java/lang/classfile/CodeModel.java >> # src/java.base/share/classes/java/lang/classfile/CompoundElement.java >> # src/java.base/share/classes/java/lang/classfile/FieldBuilder.java >> # src/java.base/share/classes/java/lang/classfile/FieldElement.java >> # src/java.base/share/classes/java/lang/classfile/Instruction.java >> # src/java.base/share/classes/java/lang/classfile/MethodBuilder.java >> # src/java.base/share/classes/java/lang/classfile/MethodElement.java >> # src/java.base/share/classes/java/lang/classfile/TypeKind.java >> # >> src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java >> # >> src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java >> # >> src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java >> # >> src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java >> # >> src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java >> # >> src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynamicEntry.java >> # >> src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java >> # >> src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java >> # >> src/java.base/share/classes/java/lang/classfile/constantpool/ConstantValueEntry.java >> # src/java.base/share/classes/java/lang/classfile/cons... > > src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1: > >> 1: /* > > It should probably be possible for `ClassFile::verify(…)` to be able to > verify the bytecode of `java.lang.Object`, `java.lang.Class`, > `java.lang.String`, and `java.lang.Throwable`, as the main reason the HotSpot > verifier skips those is that there’s circular verification bootstrap > dependencies between those, but the Class‑File API verifier uses the offline > `ClassHierarchyResolver` instead for determining assignability checks. > > https://github.com/openjdk/jdk/blob/18bcbf7941f7567449983b3f317401efb3e34d39/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java#L144-L150
VerifierImpl should be the best possible 1:1 transcription of the HotSpot verifier (for easy maintenance). I also have to suppress itching to rewrite it ;) Fortunately why would someone need to verify Object, Class, String or Throwable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1838065287
