On Thu, 30 Jul 2026 00:18:53 GMT, David Holmes <[email protected]> wrote:
> I don't think this is correct or appropriate. The specification for the > assertion related methods is incomplete. Assertions (per JLS) pertain to > top-level classes and interfaces (and assertion status is inherited by nested > types). The spec says nothing about how these methods should behave for > non-top-level classes e.g. array classes or classes for the primitives. This > needs to be fixed on the JDK side by updating the specification and > performing the necessary actions in Java code. Correction. The treatment of array types can be inferred: > * otherwise, if this class is not a system class (i.e., it has a > * class loader) its class loader's default assertion status is returned; > * otherwise, the system class default assertion status is returned. but the treatment of primitive types is less clear. Primitive types do not have a class loader but nor are they classes as such. So I would still want to see a spec clarification for the primitive type Class objects. The implementation on the Java side assumes a null classloader means it is a system class and so defers to the VM for the boot-loader assertion status. I would prefer to see `isPrimitive` checked on the Java side - arguably we should always return false for primitives because it is a meaningless question as there is no way to have an assert statement that can depend on it. For arrays where the component-type is loaded by the boot-loader we do need to fix the VM side of things. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32086#issuecomment-5124917831
