Scala中将类内方法替换为成员对象是否真的满足二进制兼容要求？

问题背景 #

metrics-scala项目收到了一则pull-request，建议将代码：

class Meter {
  def exceptionMarker: new AnyRef() {
    def apply[A](f: => A): A = ???
  }
}

修改为更简洁的写法：

class Meter {
  object exceptionMarker {    // 仅该行有改动
    def apply[A](f: => A): A = ???
  }
}

担心该改动会导致二进制不兼容问题，使用Mima检测后并未报出相关异常。请问Mima的检测结果是否正确，该提议的改动是否真的具备二进制兼容性？

回答 #

Mima的检测结果是正确的，只要你的业务代码没有依赖原写法中exceptionMarker每次调用返回新实例的特性，该改动就完全具备二进制兼容性，具体原因如下：

• 从Scala编译为JVM字节码的规则来看：
  • 原代码中的def exceptionMarker定义，编译后会在Meter类生成一个无参方法exceptionMarker()，返回值类型为java.lang.Object（结构类型的约束仅在Scala编译期生效，JVM层面无法识别结构类型，只会识别其声明的上界类型AnyRef）。
  • 改动后的成员object exceptionMarker，Scala编译器会自动为其在Meter类生成完全同签名的无参方法exceptionMarker()，返回值类型同样为java.lang.Object，和原方法的字节码描述符完全一致，因此Mima不会检出兼容性问题。
• 从旧版本调用端的执行逻辑来看：
  原写法下调用端使用meter.exceptionMarker(xxx)时，本质是先调用exceptionMarker()方法拿到实例，再通过反射调用结构类型的apply方法。改动后旧的调用端逻辑完全不需要修改，反射调用依然可以匹配到exceptionMarker单例对象上的apply方法，运行不会报错。
• 额外的优化点：
  改动后不再需要每次调用exceptionMarker都创建新的匿名类实例，仅全局保留一个单例，性能更优；新编译的调用端还可以避免结构类型的反射开销，直接调用apply方法。

唯一需要注意的兼容风险：如果原业务代码有依赖exceptionMarker每次返回不同对象的逻辑（比如在匿名类中定义了可变状态、依赖对象地址比较等），那该改动会导致逻辑异常，但这类问题属于业务逻辑层面的差异，不属于二进制兼容性问题，Mima也不会检出这类问题。

内容的提问来源于stack exchange，提问作者Erik van Oosten