java - Serializable.class 怎么不能从 Class.class 分配？

Question

在 org.springframework.core.SerializableTypeWrapper (版本 5.2.3)，第 112 行有以下代码:

    if (GraalDetector.inImageCode() || !Serializable.class.isAssignableFrom(Class.class)) {
        // Let's skip any wrapping attempts if types are generally not serializable in
        // the current runtime environment (even java.lang.Class itself, e.g. on Graal)
        return providedType;
    }

我很好奇第二次检查( !Serializable.class.isAssignableFrom(Class.class) ):它是否有可能评估为 true (也就是说， Serialazable.class 不能从 Class.class 分配)？
这是 Class#isAssignableFrom() javadoc 说:

Determines if the class or interface represented by this Class object is either the same as, or is a superclass or superinterface of, the class or interface represented by the specified Class parameter.

查看 Class 的代码，我看到以下内容:

public final class Class<T> implements java.io.Serializable

所以 Serializable是 Class 的超接口(interface)并且应该始终可以从 Class 分配.但 Spring 代码中的检查表明有时并非如此。
怎么会？在什么情况下会发生这种情况，为什么它们不违反 Java 语言规范？

Answer 1

一个定制class loader是表达式返回 false 的一种可能(如果不太可能)机制.自定义类加载器可以做一些疯狂的事情，包括加载他们自己版本的标准 Java 类。关于类加载器的一些知识:

自定义类加载器可以配置为加载任何类，甚至包括 Java 标准库类(当然不鼓励，但仍有可能)

自定义类加载器通常会配置为将不知道如何加载的类委托(delegate)给系统类加载器。

当 A 类引用 B 类时，将使用用于加载 A 类的任何类加载器解析该引用

可以配置多个类加载器来处理同一个类，这可能会导致一个类的多个版本被加载到 JVM 中，您获得的实际实现取决于您询问的类加载器

假设有一个自定义类加载器，无论出于何种原因，它被配置为加载 java.io.Serializable本身，但委托(delegate)给系统类加载器来加载其他类，包括 java.lang.Class .
现在假设这个自定义类加载器用于加载 SerializableTypeWrapper .这意味着它也将用于解析对 java.io.Serializable 的引用。在 SerializableTypeWrapper .引用 java.lang.Class ，自定义类加载器会将其委托(delegate)给系统类加载器。系统类加载器将用于加载 java.lang.Class , 但它也将用于加载对 java.io.Serializable 的引用来自 java.lang.Class .
所以现在我们可以问这个问题 - 是 java.io.Serializable [custom]可从 java.lang.Class [standard] 分配?答案是否定的 - java.lang.Class确实实现了 java.io.Serializable [standard] ，但它没有实现 java.io.Serializable [custom] .