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 是这样说的：

确定此 Class 对象表示的类或接口是否与指定的 Class 参数表示的类或接口相同，或者是其超类或超接口。

查看Class的代码，看到如下：

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

所以Serializable 是Class 的超接口并且应该总是 可以从Class 分配。但 Spring 代码中的检查表明有时不是。

怎么会？在什么情况下会发生这种情况？为什么它们不违反 Java 语言规范？

Answer 1

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

• 自定义类加载器可以配置为加载任何类，甚至包括 Java 标准库类（当然不鼓励这样做，但仍然可以）
• 自定义类加载器通常配置为将不知道如何加载的类委托给系统类加载器。
• 当 A 类引用 B 类时，将使用用于加载 A 类的任何类加载器来解析该引用
• 可以配置多个类加载器来处理同一个类，这可能会导致将一个类的多个版本加载到 JVM 中，您获得的实际实现取决于您询问的类加载器

假设有一个自定义类加载器，无论出于何种原因，它被配置为自行加载java.io.Serializable，但委托给系统类加载器以加载其他类，包括java.lang.Class。

现在假设这个自定义类加载器用于加载SerializableTypeWrapper。这意味着它还将用于解析SerializableTypeWrapper 中对java.io.Serializable 的引用。通过引用java.lang.Class，自定义类加载器会将其委托给系统类加载器。系统类加载器将用于加载java.lang.Class，但它也将用于从java.lang.Class 中加载对java.io.Serializable 的引用。

所以现在我们可以问这个问题 - java.io.Serializable [custom] 可以从 java.lang.Class [standard] 分配吗？答案是否定的——java.lang.Class 确实实现了java.io.Serializable [standard]，但它没有实现java.io.Serializable [custom]。