【ITニュース解説】Same named methods in Java. Part 1: Don’t Underestimate Overloading

Javaプログラミングでは、同じ名前を持つメソッドが複数存在することがあり、これを「メソッドオーバーロード」と呼ぶ。一見すると簡単そうに見えるこの仕組みも、実はJavaのコンパイラがどのメソッドを実行するかを判断する際に、多くの開発者を戸惑わせる複雑な側面を持っている。この記事では、特にシステムエンジニアを目指す初心者がJavaのオーバーロードを深く理解できるよう、その仕組みと注意点を詳しく解説する。

オーバーロードの基本的な考え方は、概念的に同じ処理を行うが、扱うデータの型や数が異なる場合に、同じメソッド名を使用することでコードの可読性を高め、APIの一貫性を保つことにある。例えば、数値を加算するメソッドが、整数と浮動小数点数でそれぞれ用意されていても、どちらも「add」という名前であれば直感的に理解しやすい。Javaでは、メソッドだけでなく、クラスのコンストラクタもオーバーロードの対象となる。メソッドがオーバーロードされていると判断されるのは、同じクラス内で同じ名前を持つ複数のメソッドがあり、それらの引数の型や数が異なる場合だ。戻り値の型やstatic/インスタンスメソッドの違い、アクセス修飾子の違いは、オーバーロードの判断には影響しない。

このオーバーロードで最も重要な注意点の一つは、どのメソッドが呼び出されるかの決定が「コンパイル時」に行われるという事実だ。一度コンパイラがどのメソッドを呼び出すか決定すると、その選択はプログラムの実行時には変わらない。このコンパイル時解決の性質は、予期せぬ問題を引き起こす可能性がある。例えば、別のチームが提供するHelperクラスを利用するMainクラスを考えてみよう。最初にMainクラスがHelperクラスのm(Object o)メソッドを呼び出すようにコンパイルされたとする。もし後からHelperクラスにm(String o)という、より具体的なメソッドが追加されたとしても、Mainクラスを再コンパイルしない限り、以前と同じm(Object o)が呼び出され続ける。これは、コンパイラが新しいm(String o)メソッドの存在を知らないためであり、たとえ新しく追加されたメソッドの方が引数に「最も適している」場合でも、以前の選択が維持される。新しいメソッドを呼び出させるためには、Mainクラスを新しいHelperクラスのJARファイルと共に再コンパイルする必要があるのだ。このように、クラスの変更や新しいメソッドの追加が、警告やエラーなしに既存の呼び出しの動作を変えてしまうことがあるため、オーバーロードの理解は非常に重要となる。

コンパイラが呼び出すメソッドを選択するプロセスは、いくつかのステップと優先順位のルールに基づいて行われる。 まず、呼び出し元のコードと引数から、呼び出すメソッドの名前と、そのメソッドが定義されている型を特定する。次に、その型内で、メソッド名と引数の型が一致する可能性のある、アクセス可能なメソッド候補を洗い出す。この際、引数の数（arity）が一致する固定引数を持つメソッドが優先的に考慮される。もし固定引数のメソッドが適用できなければ、可変長引数（varargs）を持つメソッドが候補となる。

複数のメソッド候補がある場合、コンパイラは「最も具体的なメソッド」を選択する。この具体的なメソッドを選ぶための優先順位は以下の通りだ。

• 完全一致: 引数の型と完全に一致するメソッドが最優先される。
• プリミティブ型の拡張（Widening Primitive Conversion）: intからlong、charからdoubleのように、情報が失われることなくより広い範囲の型へ自動的に変換される場合。
• ボクシング/アンボクシング（Boxing/Unboxing Conversion）: プリミティブ型（例:int）とそれに対応する参照型（例:Integer）の間での自動変換。
• 参照型のアップキャスト（Reference Upcast Conversion）: 子クラスの型（例:Integer）から親クラスの型（例:NumberやObject）への変換。
• 可変長引数（Varargs）: 最後に考慮されるのは、引数の数を可変にできる可変長引数を持つメソッド。

参照型の変換では、より子クラスの型（サブタイプ）を引数とするメソッドの方が、親クラスの型（スーパータイプ）を引数とするメソッドよりも具体的なため優先される。例えば、ObjectよりもComparableが、NumberよりもIntegerが優先される。もし、これらのルールを適用しても複数の「最も具体的」なメソッドが残ってしまい、どちらか一つに決められない場合は、コンパイルエラーとなる。

これらのルールを具体的な例で見ていこう。

最初のパズル、Example1とExample2でh.m('a')が異なる結果を出す理由を考える。 Example1では、HelperクラスがExample1クラスの内部クラスなので、m(double num)がprivateであってもExample1クラスのmainメソッドからはアクセス可能だ。引数'a'はchar型である。これはdouble型にプリミティブ型拡張で変換できる。また、Character型にボクシングされ、その後Comparable型やObject型にアップキャストもできる。しかし、優先順位は「プリミティブ型の拡張」が「ボクシング/アンボクシング」や「参照型のアップキャスト」よりも高いため、m(double)が選択される。可変長引数は固定引数のメソッドが見つかったため考慮されない。

一方、Example2ではHelperクラスが別ファイルで定義されており、m(double num)はprivateなため、Example2クラスのmainメソッドからはアクセスできない。利用できる候補はm(char... chars)、m(Comparable c)、m(Object obj)だ。引数'a'はCharacterにボクシングされ、これはComparableやObjectにアップキャストできる。ComparableはObjectよりも具体的な型（サブタイプ）なので、m(Comparable)が選択される。ここでも、固定引数のメソッドが選ばれたため可変長引数は考慮されない。

別の例として、m(Double a)とm(int...a)がある場合を考える。m(Integer.valueOf(1))を呼び出すと、Integer.valueOf(1)はInteger型であり、これはDouble型に変換できない。そのため、m(int...a)が唯一の候補となり選択される。 もしm(double a)とm(int...a)があった場合は、Integer.valueOf(1)はint型にアンボクシングされ、そのint型はdouble型にプリミティブ型拡張で変換できるため、m(double)が選択される。ここでのポイントは、アンボクシング→プリミティブ型拡張という変換経路は可能だが、アンボクシング→プリミティブ型拡張→ボクシングのような複雑な連鎖は行われないという点だ。

複数の引数を持つケースも見てみよう。 m(Object a, Object b)とm(int...a)があり、m(1,1)を呼び出す場合、1はint型だがObject型に参照アップキャストできるため、固定引数のm(Object, Object)が選択される。しかし、m()、m(1)、m(1,1,1)のような呼び出しでは、固定引数のm(Object, Object)には一致しないため、m(int...)が選択される。 m(float a, long b)とm(int a, Character b)があり、m(1,'a')を呼び出す場合、1はint型でfloatにプリミティブ型拡張でき、'a'はchar型でlongにプリミティブ型拡張できる。一方、'a'はCharacterにボクシングもできる。しかし、「プリミティブ型の拡張」が「ボクシング」よりも優先されるため、m(float, long)が選択される。

このように、メソッドオーバーロードはコンパイル時に厳密に解決される。コンパイラは利用可能なメソッドを洗い出し、必要に応じて型の変換ルールを適用し、最終的に最も具体的なメソッドを選ぶ。一度この選択がなされると、実行時に変わることはない。これが、新しいオーバーロードの追加や既存のシグネチャのわずかな変更が、予期せずどのメソッドが呼び出されるかに影響を与える理由だ。privateメソッドの可視性、staticとインスタンスメソッドの違い、可変長引数、ボクシングとアンボクシング、プリミティブ型の拡張、参照型の変換など、多くの要素が複雑に絡み合い、シンプルなケースでさえ非自明な結果を招くことがある。

今回の解説では、一つのクラスやインターフェース、enum内で定義された具体的な型のオーバーロードに焦点を当てた。しかし、次回はジェネリクスが絡んだ場合のオーバーロード解決について、型推論や型消去といった要素がどのように影響するかをさらに深く掘り下げていく。