Sealed Class作为JPA实体在IntelliJ运行时的Hibernate代理异常排查

使用Kotlin密封类Attribute作为JPA实体父类并配置单表继承策略后，应用在Docker容器中运行完全正常，但在IntelliJ本地运行时抛出异常：
java.lang.IncompatibleClassChangeError: class com.nemethlegtechnika.products.model.Attribute$HibernateProxy$D0WxdNVz cannot inherit from sealed class com.nemethlegtechnika.products.model.Attribute

将密封类改为抽象类后，IntelliJ和Docker环境下均无报错。

实体类代码 #

package com.nemethlegtechnika.products.model

import jakarta.persistence.*
import org.hibernate.annotations.DiscriminatorFormula

@Entity
@Table(name = "attribute")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorFormula("case when stringValues is not null then 'string' else 'boolean' end")
sealed class Attribute : BaseEntity() {

    @ManyToOne(fetch = FetchType.EAGER, optional = false)
    @JoinColumn(name = "product_id")
    val product: Product? = null

    @ManyToOne(fetch = FetchType.EAGER, optional = false)
    @JoinColumn(name = "group_id")
    val group: Group? = null

    abstract val value: Any
}

@Entity
@DiscriminatorValue("boolean")
class BooleanAttribute : Attribute() {

    @Column(name = "boolean_value", nullable = true)
    val booleanValue: Boolean = false

    override val value: Boolean
        get() = booleanValue
}

@Entity
@DiscriminatorValue("string")
class StringAttribute : Attribute() {

    @Column(name = "string_value", nullable = true)
    val stringValue: String = ""

    override val value: String
        get() = stringValue
}

错误栈信息 #

Caused by: java.lang.IncompatibleClassChangeError: class com.nemethlegtechnika.products.model.Attribute$HibernateProxy$D0WxdNVz cannot inherit from sealed class com.nemethlegtechnika.products.model.Attribute
    at java.base/java.lang.ClassLoader.defineClass0(Native Method) ~[na:na]
    at java.base/java.lang.System$2.defineClass(System.java:2307) ~[na:na]
    at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2439) ~[na:na]
    at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2416) ~[na:na]
    at java.base/java.lang.invoke.MethodHandles$Lookup.defineClass(MethodHandles.java:1843) ~[na:na]
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[na:na]
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
    at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[na:na]
    at net.bytebuddy.utility.Invoker$Dispatcher.invoke(Unknown Source) ~[na:na]
    at net.bytebuddy.utility.dispatcher.JavaDispatcher$Dispatcher$ForNonStaticMethod.invoke(JavaDispatcher.java:1032) ~[byte-buddy-1.12.23.jar:na]
    at net.bytebuddy.utility.dispatcher.JavaDispatcher$ProxiedInvocationHandler.invoke(JavaDispatcher.java:1162) ~[byte-buddy-1.12.23.jar:na]
    at jdk.proxy2/jdk.proxy2.$Proxy118.defineClass(Unknown Source) ~[na:na]
    at net.bytebuddy.dynamic.loading.ClassInjector$UsingLookup.injectRaw(ClassInjector.java:1638) ~[byte-buddy-1.12.23.jar:na]
    at net.bytebuddy.dynamic.loading.ClassInjector$AbstractBase.inject(ClassInjector.java:118) ~[byte-buddy-1.12.23.jar:na]
    at net.bytebuddy.dynamic.loading.ClassLoadingStrategy$UsingLookup.load(ClassLoadingStrategy.java:519) ~[byte-buddy-1.12.23.jar:na]
    at net.bytebuddy.dynamic.TypeResolutionStrategy$Passive.initialize(TypeResolutionStrategy.java:101) ~[byte-buddy-1.12.23.jar:na]
    at net.bytebuddy.dynamic.DynamicType$Default$Unloaded.load(DynamicType.java:6317) ~[byte-buddy-1.12.23.jar:na]
    at org.hibernate.bytecode.internal.bytebuddy.ByteBuddyState$1.run(ByteBuddyState.java:203) ~[hibernate-core-6.1.7.Final.jar:6.1.7.Final]
    at org.hibernate.bytecode.internal.bytebuddy.ByteBuddyState$1.run(ByteBuddyState.java:199) ~[hibernate-core-6.1.7.Final.jar:6.1.7.Final]
    at org.hibernate.bytecode.internal.bytebuddy.ByteBuddyState.lambda$load$0(ByteBuddyState.java:212) ~[hibernate-core-6.1.7.Final.jar:6.1.7.Final]
    at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:168) ~[byte-buddy-1.12.23.jar:na]

问题根源 #

1. Kotlin密封类的JVM限制：Kotlin密封类在JVM字节码层面有严格的继承限制，仅允许预先定义的子类（同一文件或模块内的子类）继承，JVM会拒绝其他未授权类的继承请求。
2. Hibernate代理生成冲突：Hibernate通过ByteBuddy动态生成代理类实现延迟加载等特性，即使关联配置为FetchType.EAGER，本地开发环境下Hibernate仍可能尝试生成代理类。该动态代理类不属于密封类允许的子类范围，触发IncompatibleClassChangeError。
3. 环境差异原因：Docker环境中可能因生产级编译优化、Hibernate配置（如默认禁用代理生成）或类加载机制不同，导致Hibernate未生成代理类，因此未触发错误。

解决方案 #

方案1：禁用Hibernate代理生成 #

在密封类Attribute上添加@Proxy(lazy = false)注解，明确禁止Hibernate为该类生成代理，保留密封类特性的同时解决冲突：

@Entity
@Table(name = "attribute")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorFormula("case when stringValues is not null then 'string' else 'boolean' end")
@Proxy(lazy = false) // 添加此注解
sealed class Attribute : BaseEntity() {
    // ... 原有代码
}

方案2：改用抽象类 #

如果禁用代理的方案不生效，或不需要密封类的严格继承限制，直接将sealed class改为abstract class，这是最直接的兼容方案。

方案3：全局调整Hibernate配置（不推荐） #

在application.properties中全局禁用代理生成，可能影响其他实体的延迟加载特性，需谨慎使用：

spring.jpa.hibernate.proxy.lazy_initialization=false

内容的提问来源于stack exchange，提问作者Botond Németh