我最近在工作中把一个大型Groovy库逐步转成Java，碰到了一个关于继承处理的奇怪问题，想请教下有没有增量式的解决办法——因为环境限制，我没法一下子把所有文件都转成Java，而且实际项目里的继承关系比下面的最小复现案例复杂得多。

最小复现案例 #

转换前的Groovy代码（正常运行）

@CompileStatic trait A { boolean isValid() { return true; }}
@CompileStatic trait APrime extends A { boolean isValid() { return false; }}
@CompileStatic class UseA implements A {}
@CompileStatic class UseAPrime extends UseA implements APrime { void func() { isValid(); }}

这段代码运行完全正常：UseAPrime里调用isValid()会返回false，UseA里调用则返回true。

转换后的混合代码（仅A转成Java接口，其余仍为Groovy）

// A.java
interface A { default boolean isValid() { return true; }}

// APrime.groovy
@CompileStatic trait APrime implements A { boolean isValid() { return false; }}

// UseA.groovy
@CompileStatic class UseA implements A {}

// UseAPrime.groovy
@CompileStatic class UseAPrime extends UseA implements APrime { void func() { isValid(); }}

运行时错误信息 #

转换后运行时抛出了VerifyError，具体错误如下：

Caused by: java.lang.VerifyError: Bad invokespecial instruction: interface method reference is in an indirect superinterface.
Exception Details:
  Location:
    com/UsesAPrime.APrimetrait$super$isValid @43: invokespecial
  Reason:
    Error exists in the bytecode
  Bytecode:
    0x0000000: 2ac1 0071 9900 252a 1271 b800 75c0 0071
    0x0000010: b900 7901 0012 7a04 bd00 4759 032b 53b8
    0x0000020: 0080 b800 6eac 0000 bf2a 2bb7 0084 ac00
    0x0000030: 0000 0000 0000 00bf                    
  Stackmap Table:
    full_frame(@38,{},{Object[#65]})
    append_frame(@41,Object[#2],Object[#135])
    full_frame(@47,{},{Object[#65]})

    at java.lang.Class.forName0(Native Method) ~[?:1.8.0_402]
    at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_402]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_402]
    at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) ~[?:1.8.0_402]
    at java.util.concurrent.FutureTask.run(FutureTask.java) ~[?:1.8.0_402]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_402]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_402]
    at java.lang.Thread.run(Thread.java:750) ~[?:1.8.0_402]

求助问题 #

我知道最直接的解决办法是解耦这些继承关系，甚至把所有文件都转成Java，但目前环境不允许这么做，只能做增量修改。想问问有没有其他可行的处理方案？

针对这种增量迁移的场景，我整理了几个可以尝试的思路，不用一下子重构整个继承体系：

• 显式指定方法调用优先级：在UseAPrime里重写isValid方法，明确指定调用APrime trait的实现，避免Groovy字节码生成时的模糊调用问题。修改后的代码如下：

@CompileStatic class UseAPrime extends UseA implements APrime { 
    @Override
    boolean isValid() {
        // 强制调用APrime trait的实现
        return APrime.super.isValid()
    }

    void func() { isValid(); }
}

这样能让JVM明确找到要执行的方法版本，绕过原本的字节码验证错误。

• 调整Java接口方法名避免直接覆盖：把Java接口A里的默认方法改个名称，比如defaultIsValid，然后让APrime的isValid方法显式调用这个新方法，把原本的覆盖关系改成主动调用，消除冲突：

// A.java
interface A { 
    default boolean defaultIsValid() { return true; }
}

// APrime.groovy
@CompileStatic trait APrime implements A { 
    boolean isValid() { return defaultIsValid() ? false : false; }
}

这个方案需要调整所有原本调用isValid的地方，但属于增量兼容修改，后续可以逐步统一方法名。

• 临时回退A的实现，先迁移其他文件：如果允许的话，先把A.java改回Groovy trait，等把APrime和所有依赖这些类的文件都转成Java后，再把A改成Java接口。毕竟Groovy的trait和Java的默认方法在字节码层面的处理逻辑差异很大，混合使用容易出现这类底层冲突。

• 用委托模式替代多重继承：在UseAPrime里不再同时继承UseA和实现APrime，而是把APrime的功能委托给内部实例，解耦继承关系：

@CompileStatic class UseAPrime extends UseA { 
    private final APrime aPrime = new APrime() {}

    @Override
    boolean isValid() {
        return aPrime.isValid()
    }

    void func() { isValid(); }
}

这种方式不需要修改上层的继承结构，是非常友好的增量修改方式，后续可以逐步把委托逻辑改成纯Java实现。

这些方案的核心都是消除方法调用的模糊性，让JVM能明确找到要执行的方法版本，从而绕过Groovy与Java混合继承时的字节码验证问题。

备注：内容来源于stack exchange，提问作者E.D.