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

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

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

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

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

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