はじめに (対象読者・この記事でわかること)

本記事は、Java と Scala の両方で開発を行っているエンジニア、特にメソッドオーバーロードの挙動に悩んだことがある方を対象としています。Java 側で定義されたオーバーロードメソッドが Scala から呼び出された際に、コンパイラがどのシグネチャを選択すべきか判別できず「曖昧です」というエラーになるケースを取り上げます。この記事を読むと、
- Java のオーバーロードが持つ曖昧さの根本原因
- Scala からその曖昧さを回避し、意図したシグネチャを明示的に指定する手法
- 実装例とよくある落とし穴の対策
が理解でき、実務で即座に適用できるようになります。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。
- Java の基本的な文法とメソッドオーバーロードの概念
- Scala の型推論、暗黙的パラメータ（implicit）および型アサーション（ascription）の基礎
- SBT または Maven など、ビルドツールでのプロジェクト構成経験

オーバーロードの曖昧さとは何か（概要・背景）

Java では、同名メソッドが異なるパラメータ型や個数で定義されるとオーバーロードが成立します。呼び出し側は渡す引数の型情報だけで最も適切なシグネチャをコンパイラが選択しますが、暗黙的型変換（例: int → long、float → double）が絡むと複数候補が同等に見えるケースがあります。

Scala から Java メソッドを呼び出すとき、Scala の型推論が Java の暗黙的変換規則と完全に合致しないことが原因で「overloaded method value ... is ambiguous」というエラーが頻出します。典型的な例として次のような Java クラスがあります。

Java

public class Converter {
    public String convert(int   v) { return "int:"   + v; }
    public String convert(long  v) { return "long:"  + v; }
    public String convert(double v) { return "double:"+ v; }
}

Scala から new Converter().convert(42) と呼び出すと、42 が Int でも Long でも Double に暗黙的に拡張可能なため、コンパイラはどのシグネチャを選べば良いか判断できません。このような曖昧さは、コードの可読性や保守性を低下させるだけでなく、バグの温床にもなります。

Scalaで明示的にオーバーロードを解決する実装パターン（具体的な手順や実装方法）

以下では、Scala 側で Java のオーバーロードを安全に選択できる代表的な手法を３つ紹介します。実装例はすべて SBT プロジェクトを前提にしています。

パターン1：型アサーション（ascription）で呼び出し側の型を固定する

最もシンプルなのは、引数に明示的な型付けを行うことです。

Scala

val conv = new Converter()

val resultInt: String    = conv.convert(42: Int)    // int が選択される
val resultLong: String   = conv.convert(42L)        // long が選択される
val resultDouble: String = conv.convert(42.0)      // double が選択される

ポイントは、42: Int のようにリテラルに型アノテーションを付与するだけで、コンパイラは唯一の一致候補を見つけられます。42L はリテラル自体が Long 型なので、同様に曖昧さは解消されます。

ハマった点やエラー解決

  • リテラル以外の変数に対しては型推論が働くため、val x = 42 だけでは不十分です。val x: Int = 42 のように変数宣言時に型を明示してください。
  • Java 側がジェネリックの場合、型アサーションだけでは不十分になることがあります。その際はパターン2を参照してください。

パターン2：暗黙的パラメータ（implicit）と型クラスで解決策をカプセル化

複数箇所で同じ曖昧さが発生する場合、暗黙的パラメータと型クラスを使って「どのシグネチャを呼び出すか」を抽象化できます。

Scala

// 型クラス定義
trait ConvertTarget[T] {
  def apply(conv: Converter, v: T): String
}

// 各型ごとのインスタンス
object ConvertTarget {
  implicit val intTarget: ConvertTarget[Int] = (c, v) => c.convert(v)
  implicit val longTarget: ConvertTarget[Long] = (c, v) => c.convert(v)
  implicit val doubleTarget: ConvertTarget[Double] = (c, v) => c.convert(v)
}

// ユーティリティメソッド
def convert[T](conv: Converter, v: T)(implicit ct: ConvertTarget[T]): String =
  ct(conv, v)

// 使用例
val conv = new Converter()
val r1 = convert(conv, 100)    // Int が暗黙的に選択され "int:100"
val r2 = convert(conv, 100L)   // Long が選択され "long:100"
val r3 = convert(conv, 100.0)  // Double が選択され "double:100.0"

この手法の利点は、呼び出し側が型情報だけを渡せば内部で正しいオーバーロードが選択される点です。新たなシグネチャを追加したい場合は、型クラスにインスタンスを足すだけで拡張可能です。

ハマった点やエラー解決

  • 暗黙的インスタンスが衝突するとコンパイルエラーになるので、同一型に対して複数の implicit val を定義しないように注意。
  • Java 側が プリミティブ以外のラッパークラス（Integer, Long）を受け取る場合は、ConvertTarget[java.lang.Integer] なども用意する必要があります。

パターン3：java.lang.invoke.MethodHandle を使ってシグネチャを直接指定

高度なケースでは、Java の MethodHandle（または java.lang.reflect.Method）を利用し、メソッドシグネチャを文字列で指定して呼び出す方法があります。

Scala

import java.lang.invoke.{MethodHandles, MethodType}
import scala.jdk.CollectionConverters._

val conv = new Converter()
val lookup = MethodHandles.lookup()

// int 版ハンドル取得
val mhInt = lookup.findVirtual(
  classOf[Converter],
  "convert",
  MethodType.methodType(classOf[String], classOf[Int])
)

// long 版ハンドル取得
val mhLong = lookup.findVirtual(
  classOf[Converter],
  "convert",
  MethodType.methodType(classOf[String], classOf[Long])
)

// 呼び出し
val resInt = mhInt.invoke(conv, Int.box(10)).asInstanceOf[String]
val resLong = mhLong.invoke(conv, Long.box(10L)).asInstanceOf[String]

MethodHandle は、実行時にシグネチャを固定できるため、コンパイル時の曖昧さとは無関係です。特にリフレクションが許容できない高パフォーマンス環境や、動的にシグネチャを選択したい場合に有効です。

ハマった点やエラー解決

  • MethodHandles.lookup() がアクセス制御で例外を投げることがあるので、対象メソッドが public であることを確認。
  • プリミティブ型は ラッパークラスにボックス化して渡す必要があります。Int.box、Long.box を忘れないように。

まとめ

本記事では、Java のオーバーロードが Scala から呼び出された際に起きる曖昧さを、以下の三つの実装パターンで明示的に解決する方法を紹介しました。

  • 型アサーションでリテラルや変数に明示的な型付与
  • 暗黙的パラメータ＋型クラスで呼び出し側のコードをシンプルに保ちつつ拡張性を確保
  • MethodHandle を利用し、実行時にシグネチャを固定して安全に呼び出し

これらのテクニックを活用すれば、Scala の型推論に依存しすぎて起こるコンパイルエラーを防ぎ、コードの可読性と保守性を向上させることができます。次回は、Scala 3 のオプション型と暗黙的コンバージョンを組み合わせたさらに洗練された解決策について取り上げる予定です。

参考資料