如何解决Kotlin调用泛型重载Java类时的重载解析歧义

问题场景 #

有如下泛型Java集合类：

public class SomeSet<T> {
    public void add(int value) {  }
    public void add(long value) {  }
    public void add(T value) {   }
}

在Java中调用该类的重载add方法完全正常：

SomeSet<Long> set = new SomeSet<Long>();
set.add(1);
set.add(1L);

但在Kotlin中调用时，传入Long类型参数会触发重载解析歧义错误：

val set = SomeSet<Long>()
set.add(1 as Int) // 正常
set.add(1L) // ⚡ 重载解析歧义
set.add(1L as Long) // ⚡ 重载解析歧义

完整编译错误：

Overload resolution ambiguity. All these functions match.
public open fun add(value: Long): Unit defined in de.itscope.platform.producttracking.test.SomeSet
public open fun add(value: Long!): Unit defined in de.itscope.platform.producttracking.test.SomeSet

问题原因 #

Java与Kotlin的类型系统映射规则导致了这个冲突：

1. Java的原始类型long在Kotlin中会被映射为非空的kotlin.Long，对应add(long)方法的签名为fun add(value: Long): Unit。
2. 当泛型参数T指定为Long时，add(T)方法在Kotlin中会被解析为平台类型Long!（因为Java泛型没有可空性约束），签名为fun add(value: Long!): Unit。
3. Kotlin无法区分这两个方法的实际调用逻辑，因为它们接收的参数类型在Kotlin看来本质都是Long，因此触发重载歧义。

注：该问题来源于Google ZetaSketch库中的com.google.zetasketch.HyperLogLogPlusPlus类的实际实现。

解决方案 #

方案1：编写Java包装类（推荐） #

由于无法修改第三方库的Java代码，可编写一个Java包装类，明确区分两个重载方法的调用：

public class HyperLogLogWrapper {
    private final HyperLogLogPlusPlus<Long> sketch;

    public HyperLogLogWrapper(HyperLogLogPlusPlus<Long> sketch) {
        this.sketch = sketch;
    }

    // 调用原始long类型的add方法
    public void addPrimitive(long value) {
        sketch.add(value);
    }

    // 调用泛型T的add方法
    public void addGeneric(Long value) {
        sketch.add(value);
    }
}

在Kotlin中直接调用包装类的方法即可避免歧义：

val sketch = HyperLogLogPlusPlus<Long>()
val wrapper = HyperLogLogWrapper(sketch)
wrapper.addPrimitive(1L)
wrapper.addGeneric(1L)

方案2：Kotlin反射调用 #

通过反射明确指定要调用的方法：

val sketch = HyperLogLogPlusPlus<Long>()

// 调用原始long类型的add方法
val primitiveAddMethod = HyperLogLogPlusPlus::class.java.getMethod("add", Long.TYPE)
primitiveAddMethod.invoke(sketch, 1L)

// 调用泛型T的add方法
val genericAddMethod = HyperLogLogPlusPlus::class.java.getMethod("add", Any::class.java)
genericAddMethod.invoke(sketch, 1L)

方案3：抑制歧义警告（权宜之计） #

如果能确定实际要调用的方法，可使用注解抑制编译错误，但存在调用逻辑不符合预期的风险：

val sketch = HyperLogLogPlusPlus<Long>()
@Suppress("OVERLOAD_RESOLUTION_AMBIGUITY")
sketch.add(1L)

内容的提问来源于stack exchange，提问作者Tobse