C SharpとJavaの比較
C#とJavaの比較(シーシャープとジャバのひかく)の記事では、プログラミング言語C#とJavaの比較について説明する。
いずれの言語もオブジェクト指向言語であり、その文法はC++に類似しているが、C++との互換性はない。メモリ再利用の手段として、従来の手動で解放する方法ではなくガベージコレクションを使用する。また、スレッド同期の手段を言語構文に組み込んでいる。
いずれの言語も強い参照と弱い参照の両方をもつ。Javaでは参照がガベージコレクタによって回収された時に通知を受けるリスナーを登録することができる。これはjava/utilの性能を考慮したものである。C#にはこれに相当する機能はなく、ファイナライザ(Javaにも存在する)を使用する方法しかない。その一方、C#は指定したオブジェクトのファイナライザ呼び出しをプログラマが抑止することができる。「世代」の概念をもつガベージコレクション(Javaと.NETいずれにも当てはまる)においてファイナライザの呼び出しは性能に大きな影響を与えるため、またファイナライザはプログラマがオブジェクトを破棄しなかった場合のフェイルセーフであるため、これは非常に有効である。ファイナライザをもつオブジェクトは通常余分な世代が与えられ、回収されるまでに長くかかる。
C#は、一部の言語設計者から危険であると指摘されるポインタを使用した演算が制限つきながら利用できる。C#はポインタを使用するコードブロックあるいはメソッドをunsafeキーワードで修飾することでこの懸念に対応している。これにより、このコードを利用する者はそれが他の部分に比べて危険であるということを知ることができる。また、このようなコードをコンパイルする際にはコンパイラに対して<tt>/unsafe</tt>スイッチを指定する必要がある。一般に、<tt>unsafe</tt>コードが使われるのはアンマネージなAPIやシステムコールとの相互運用が必要な時、あるいは性能の向上が必要な時のみである。
Javaには大別して参照型(クラス型)とプリミティブ型(基本型)が存在する。参照型はjava.lang.Objectクラスから派生するが、プリミティブ型はスーパークラスを持たない。
一方、C#には大別して参照型、値型、ポインタ型が存在する。このうちポインタ型を除き、あらゆる型はすべてSystem.Objectクラスから派生する。クラス (class) は参照型であり、数値型や論理型を含む構造体 (struct) および列挙型 (enum) は抽象クラスSystem.ValueTypeから暗黙的に派生する値型である。
Javaの組み込み型 (built-in type) はプリミティブ型と呼ばれる。C#は組み込み型をJavaよりも多く持ち、すべての組み込み型はSystem名前空間に存在する型へのエイリアスである。組み込み型には以下のようなものがある。
整数型: Javaには符号付き整数のみをサポートし、符号なし整数が存在しない。C#では符号付き整数と符号なし整数の両方をサポートする。
浮動小数点数型: いずれの言語もIEEE 754準拠の32bit単精度浮動小数点数と64bit倍精度浮動小数点数を持つ。
C#ではさらに、10の累乗の形で指数部を表す浮動小数点数であるdecimal型をサポートする。decimal型は値型かつ組み込み型であるが、CLRのプリミティブではない。
文字型: いずれの言語もUTF-16ベースの文字型を持つ。
ブーリアン型: いずれの言語もtrue/falseのいずれかを表すブーリアン型を持つ。
オブジェクト型: C#では組み込み型としてobject型を持つ。Javaのオブジェクト型java.lang.Objectは組み込み型ではない。
文字列型: C#では組み込み型としてstring型を持つ。Javaの文字列型java.lang.Stringは組み込み型ではない。
文字列はいずれの言語においても不変 (immutable) なオブジェクトとして扱われるが、特殊な構築方法として文字列リテラルを利用することができる。C#ではエスケープ文字を処理しないような逐語的文字列リテラル(verbatim文字列: ヒアドキュメントを参照)をサポートする。
C#言語自体にはプリミティブ型という用語は存在しないが、.NET Frameworkの共通言語ランタイム (CLR) では、System.Type.IsPrimitiveプロパティによって、型がCLRプリミティブ型であるかどうかを判定できる。.NET言語組み込みの値型は必ずしもCLRプリミティブ型ではないが、CLRプリミティブ型はすべて値型である。
いずれの言語もプリミティブ型(もしくは値型)と参照型との間で変換するためにボックス化 (boxing) とボックス化解除 (unboxing) が可能である。これによってプリミティブ型(もしくは値型)は参照型のサブセットとみなすことができる。値型は仮想メソッドテーブルを持たず、したがってそのままでは多態性を利用できないが、C#においては、ボックス化によって値型で多態性を利用することが可能である(例えばobject型のToString()メソッドをオーバーライドすることができる)。C#では数値リテラルもオブジェクトであり、たとえば42.ToString()のようにint型のリテラルからメソッドを呼び出すことも可能である。Javaではこのような用途のためにプリミティブ型をラップするクラスが別に定義される。すなわち、42.toString()のようなインスタンスメソッド呼び出しでなくInteger.toString(42)のような静的メソッド呼び出しが必要になる。もう一つの相違点として、Javaではジェネリクスにおいてこのような型を多用するため、暗黙的なボックス化解除が可能になっている(C#ではボックス化せずにジェネリクスを利用できる)。このような変換はnullポインタ例外を発生する可能性があるが、Javaではそれがコード上で明白ではない。
C#では、structキーワードによって構造体を定義することができる。構造体にはフィールドやメソッド、プロパティなどの任意のメンバーを定義できる。引数を持たないコンストラクタ(デフォルトコンストラクタ)をプログラマが定義することはできないが、一つ以上の引数を持つパラメータ化されたコンストラクタを定義することはできる。デフォルトコンストラクタはすべてのメンバーを各々の既定値(通例ゼロ相当の値)で初期化する。C# 10.0以降の構造体は、引数のないコンストラクタをユーザー定義することもできるようになった。また構造体を定義する際、メンバーのメモリレイアウトを属性によって細かく制御することができるため、P/Invokeなどによるネイティブコードとの相互運用にも便利である。なお、構造体は継承元となる基底型を指定することはできず、派生型を定義することもできない。ただし任意のインターフェイスの実装は可能である。Javaには構造体が存在せず、ユーザー定義の値型を作成することはできない。
C#の列挙型は抽象クラスSystem.Enumから暗黙的に派生する値型の一種であり、組み込みの整数型をベースとしている。ベースとなる整数型のどの値も列挙型の値として有効になる(明示的なキャストは必要であるが)。このため、ビットフラグにおいてビットごとのOR演算で列挙型の値を組み合わせることが可能である。ただし構造体と違って任意のインターフェイスを実装することはできない。一方、Javaの列挙型は抽象クラスjava.lang.Enumから暗黙的に派生する参照型である。Javaの列挙型として有効な値は定義においてリストされたものだけである。列挙型の値を組み合わせるためには列挙セットクラスを使用する必要がある。Javaの列挙型では、値によって異なるメソッドの実装が可能である。JavaとC#はいずれも列挙型を文字列に変換することができるが、Javaにおいてはこの変換をカスタマイズすることができる。また、Javaの列挙型は任意のインターフェイスを実装することができる。
プリミティブ型(あるいは値型)は参照型(クラス)とは異なり、インスタンスはヒープ領域ではなくスタックに置かれる。また、(フィールドとして、あるいはボックス化された状態で)クラスの一部になることも、配列の要素になることも可能である。クラスのインスタンスはメモリ上で間接的に参照される必要があるが、プリミティブ型(あるいは値型)はその必要がない。プログラマの視点からは、C#の値型は軽量なクラスとみなせる。しかし、プリミティブ型(あるいは値型)には前述のように多数の制限がある。値型は通常nullの値をとることができないが、.NET Framework 2.0でnull許容型 (System.Nullable) が導入され、C#でも擬似的にnull値を取り得る値型が利用可能となった。
型そのものをコード上で表現するメタデータ型(メタクラス)として、Javaではjava.lang.Classを、C#ではSystem.Typeを利用する。これらはいずれもリフレクションやイントロスペクションで重要な役割を果たす。
C#およびJavaの配列は参照型であり、第一級オブジェクトである。C#の配列は共通の基本クラスSystem.Arrayから派生するが、Javaの配列はjava.lang.Objectから派生する。代わりに、配列のユーティリティクラスとしてjava.util.Arraysが用意されている。
いずれの言語も配列は共変性 (covariance) を持つ。
なお、Java 1.5で拡張for文がサポートされた。これはC#のforeach文に相当する。配列を始めとするコレクション型を、イテレータにより走査することができる。
C#は真の多次元配列(矩形配列)をサポートするが、Javaはサポートしない。C#およびJavaはともに「配列の配列」をサポートする(C#ではジャグ配列と呼ばれる)。
いずれの言語もネストされた型(入れ子にされた型:クラスや構造体のブロックの中で定義されたクラス・構造体・列挙型・インターフェイス)をサポートする。Javaではインターフェイス内部にクラスや列挙型を定義することもできる。C#ではインターフェイス内部にクラス・構造体・列挙型・インターフェイスを定義することはできない。
Javaでは、ネストされたクラス (nested class) は既定で内部クラス (inner class) となる。内部クラスは外側のクラスのインスタンスを暗黙的にキャプチャすることで、静的メンバ、非静的メンバいずれにもアクセスすることができる。ネストされたクラスがstatic修飾されていた場合は静的メンバのみにアクセスできる。メソッドの内部にクラスを定義することもでき、これはローカルクラス (local class) と呼ばれる。ローカルクラスでは、外側のローカル変数には読み取りアクセスのみできる。また、型の名前を持たないローカルクラス(匿名クラス: anonymous class)を定義し、同時にインスタンス生成をすることもできる。
C#では、ネストされたクラス/構造体から外側のクラス/構造体の非静的メンバにアクセスするためには外側のクラス/構造体のインスタンスへの明示的な参照が必要になる。Javaの内部クラスやローカルクラスに相当する機能は存在しない。代わりに、C# 2.0以降では匿名メソッド (anonymous method) が、C# 3.0以降ではラムダ式が、そしてC# 7.0以降ではローカル関数がサポートされ、外側の変数をキャプチャするクロージャとして利用できる。なお、C# 3.0では限定的なローカルクラスとして、匿名型(読み取り専用プロパティのみを持つ、匿名のクラス型)がサポートされる。
Javaではジェネリクスは型消去 (type erasure) によって実装されている。これによってジェネリック型についての情報は実行時には失われ、リフレクションを通してのみ取得できるようになる。.NET 2.0では、ジェネリック型についての情報は完全に保存される。Javaはプリミティブ型に対するジェネリック型は定義できないが、C#では参照型・値型(プリミティブ型を含む)いずれに対してもジェネリック型を定義できる。Javaはその代わりにボックス化した型を使用することができる(List<int>の代わりにList<Integer>など)が、全ての値をヒープに確保し直す必要があるため、パフォーマンスコストが高い。JavaとC#はいずれも、参照型に特殊化されたジェネリック型は、型によらず共通のコードが実行される。しかし、C#において値型に特殊化された場合、CLRは型に最適化されたコードを動的に生成する。.NETにおいては、ジェネリック型に対する型安全性はコンパイル時にチェックされ、CLRにロードされる時に強制される。Javaにおいてはコンパイル時に部分的にチェックされるのみであり、Java VMは実行時にジェネリック型に関する情報を持たないため、キャスト操作を行う必要がある。
C#、Java共に、ジェネリクスの型制約を持つ。C#では基底型指定以外に、class(参照型)、struct(値型)、new()(デフォルトコンストラクタ有)の各制約を指定できる。
C#、Java共に、ジェネリクスの共変性と反変性 (covariance and contravariance) を持つ。ただしC#における共変性・反変性のサポートはバージョン4.0以降である。
C#では、型定義側で共変性outあるいは反変性inを指定し、利用側では変性の指定を行わない。なお、C#の値型は不変 (invariant) であり、共変性・反変性は適用されない。
Javaでは、型定義側では変性の指定を行わず、利用側で共変性extendsあるいは反変性superを指定する。
Javaではさらに、上限と下限のいずれも指定しないワイルドカード?による型引数の指定が可能である。以下にJava 8の例を示す。
C# 3.0でコンテキストキーワードvarによる限定された型推論が導入された。ローカル変数の宣言時に、型を右辺から推論できる。メソッド引数やフィールドには使えない。また、ラムダ式の戻り値および仮引数は型推論により決定される。ラムダ式の仮引数は型を省略することで型推論されるが、型推論が困難な場合には明示的に型を指定する。
Java 7で導入されたダイヤモンド演算子<>は宣言文の右辺ジェネリクスの型を省略できる程度のものでしかなかったが、Java 10ではC#同様に予約型名varによるローカル変数の型推論が導入された。Java 8で導入されたラムダ式では、仮引数の型を省略することで型推論されるが、さらにJava 11ではラムダ式の仮引数の型にvarを使用して型推論できるようになった。
Java 1.5で、あるクラスの静的メソッド・静的フィールドを短い名前で使用するためにstatic import構文が導入された。これにより、例えばClassAクラスのfoo()メソッドを静的インポートして、無関係のClassBクラスにてClassA.foo()のように型名で修飾することなく、foo()を直接使用できる。C# 6.0でも同様の機能としてstatic usingディレクティブがサポートされた。
C#は静的クラス(Javaの静的内部クラスとは異なる)の構文をもち、これによってクラスは静的メソッドのみを持つことができるようになる。C# 3.0から、型に静的にメソッドを追加するための拡張メソッドが導入されている(Foo型のインスタンスfooについての処理を行うBar()拡張メソッドを定義することで、あたかもFooにインスタンスメソッドが追加されたかのように、foo.Bar()と記述できる)。この機能は、クラスの外部で定義した静的メソッドを、そのクラスのインスタンスメソッドであるかのように見せかけて呼び出せるようにする糖衣構文であり、またターゲットとなるクラスのプライベートメンバにアクセスすることはできないため、カプセル化は維持される。
Javaでは、Observer パターンの記述を容易にするために匿名クラスという糖衣構文が用意されている。匿名クラス構文により、クラス本体の定義とインスタンスの生成を同時に行なうことができ、また定義と生成がひとつの式として扱えるため、インターフェイス実装クラスのインスタンスを一度限りしか生成しない場面、例えば特定のインターフェイス実装(あるいは特定のスーパークラスのメソッドのオーバーライド)を要求するイベントハンドラーの設定時などによく用いられる。Java 8ではラムダ式がサポートされ、匿名クラスの代わりに使うこともできる。Java 7まではC#のデリゲートに相当するものは存在しなかったが、Java 8では類似機能としてメソッド参照がサポートされるようになった。
C#ではデリゲート (delegate) 型をはじめ、イベント処理をサポートするための機能が広範囲に渡って言語レベルでサポートされている。デリゲート型はメソッドへの型安全な参照であり、複数のデリゲートを結合してマルチキャスティングすることもできる。デリゲートを結合/分離するための+, -演算子、イベントハンドラーをカプセル化するためのイベント構文 (event, add/remove) や、イベントハンドラーを登録/削除するための+=, -=演算子が用意されている。デリゲートは共変性と反変性 (covariance and contravariance) をサポートし、完全なクロージャとしての性質をもつ匿名関数(匿名メソッドおよびラムダ式)を作成することができる。
JavaおよびC#はともに標準ライブラリでスレッドをサポートしている。OSのスレッドに対する薄い抽象化を提供するクラスとして、Javaにはjava.lang.Thread、C# (.NET) にはSystem.Threading.Threadが用意されている。そのほか、セマフォなどの同期オブジェクトやアトミック演算なども標準ライブラリでサポートされている。
言語組み込みの同期構文として、Javaにはsynchronizedブロックおよびsynchronizedメソッドが用意されている。C#にはlockステートメントが用意されている。
C# 5.0以降はasync/awaitコンテキストキーワードによる非同期メソッド構文がサポートされた。async/awaitはイテレータおよび.NET 4以降で追加されたタスク並列ライブラリ (Task Parallel Library; TPL) を実行基盤とする糖衣構文であり、非同期タスクの完了待機と実行結果の取得をあたかも同期メソッドのように記述することができる。
数学・科学計算・金融分野のアプリケーション開発に十分対応するための言語仕様が、それぞれに存在する。Javaでは厳密な浮動小数点計算を強制するためにstrictfpキーワードが存在する。これによってあらゆるプラットフォームで必ず同じ値が結果として得られることを保証することができる。C#にはこれに相当する機能はないが、厳密な浮動小数点計算のためにdecimal型が存在する。これによって二進浮動小数点表現(float、double)に存在する問題が解決される(二進表現の浮動小数点数は十進数を正確に表現することができないため、丸め誤差が生じてしまう)。金融分野のアプリケーションソフトウェアでは厳密な十進表現は必須である。Javaでは、このような用途のためにjava.math.BigDecimalが導入されている。また、Java 1.1では巨大な整数を扱うためのクラス型としてjava.math.BigIntegerが導入されている。BigDecimalとBigIntegerは最大で約21億桁程度までの数を任意精度で表現できる。C#においては、.NET Framework 4よりSystem.Numerics.BigInteger型が導入されている。
Javaでは、BigDecimalや複素数型といったライブラリ定義の型をプリミティブ型と同じレベルで使用することは不可能である。また、Javaではユーザー定義型はすべて参照型扱いとなり、メモリブロックの実体はヒープに確保される。一方、C#は次のような機能をサポートする。
演算子多重定義やインデクサ。
暗黙的または明示的な型変換。C++のキャスト演算子オーバーロードに似た、ユーザー定義の型変換を定義できる。これにより、例えばプリミティブ数値型同士の変換と類似の機能を提供できる。
値型と値型に対するジェネリック型。値型はスタックに確保される。これは実行時の性能面に影響を及ぼす。
これらに加え、C#では数値処理アプリケーションのために、コード中の特定領域の数値オーバーフローの実行時チェックの有効・無効を制御することができるchecked/uncheckedキーワードを使用できる。
Javaは言語仕様をシンプルに保つため、また乱用による難読化を防ぐため、ユーザー定義の演算子オーバーロードをサポートしていない。一方でコードの書きやすさおよび直感性は犠牲になっている。
C#は表記法の多くの点でJavaよりも多機能である。演算子多重定義やユーザー定義キャストなど、それらの多くはC++プログラマによって既に親しまれているものである。
C#はインデクサ(C++のoperator[]に相当)をサポートする。インデクサの定義構文はプロパティと似ているが、this[]という名前をもち、一つ以上の引数(インデックス)を持つ点が異なる。インデクサを定義する際、インデックスには任意の型を使用することができる。
C#は(論理的一貫性を保つための制限はあるものの)ユーザー定義の演算子オーバーロードをサポートしており、注意深く使用すれば簡潔で可読性の高いコードを記述することができる。
また、C#では明示的メンバ実装 (Explicit Member Implementation) が可能である。これによって、インターフェイスメソッドの実装とクラス自身のメソッドの実装とを分離することができ、また同じシグネチャ(名前および引数の数と型の順序)を持つメソッドが異なるインターフェイスにそれぞれ存在した場合に、インターフェイス名を指定して区別することでそれらの実装を別々に行うことができる。
C#のメソッドはデフォルトで非仮想(非virtual)であり、仮想メソッドにする必要がある場合は明示的にvirtualと宣言しなければならない。Javaのメソッドは常に仮想 (C#でvirtual指定された状態) であり、非仮想にすることはできないが、final修飾子を指定することでオーバーライドを禁止することはできる。
Javaでは、メソッドを非仮想的にする方法はない。これは、派生クラスが同名の無関係なメソッドを再定義することが不可能であることを意味する。これは基底クラスが別のプログラマによって書かれており、バージョン更新の際に、派生クラスに既に存在していたものと同じシグネチャのメソッドが追加されてしまった場合に問題になる。Javaでは、この場合どちらのプログラマの意図とも異なり、派生クラスのメソッドは暗黙的に基底クラスのオーバーライドになってしまう(基底クラスでfinal宣言されていた場合はコンパイルエラーになってしまう)。
これらのバージョン更新の問題を部分的に解決するため、Java SE 5.0では@Overrideアノテーションが導入された。これにより、基底クラスが同一シグネチャのメソッドを持ち、それが派生クラスで正しくオーバーライドされていることを保証することはできる。しかし後方互換性維持のため、この指定は必須ではない。従ってIDEやツールなしに上記のように思いがけずオーバーライドしてしまうような問題を防ぐことはできない。
C#では、派生クラスで仮想メソッドをオーバーライドする際には、明示的にその旨を宣言する必要がある。メソッドが基底クラスのオーバーライドである場合、override修飾子が指定されていなければならない。また、オーバーライドではなく同名の無関係なメソッドを派生クラスで再定義することができるが、コンパイラが警告を発する。コンパイラ警告を抑制したい場合、new修飾子を指定しなければならない。
JavaはC/C++でしばしば問題を引き起こしていたプリプロセッサを採用しなかった。一方でC#は限定的にプリプロセッサディレクティブを使用可能である。
Javaではプリプロセッサがサポートされないため、コンパイル時の分岐は不可能となっている。
一方、C#ではプリプロセッサディレクティブを用いた条件付きコンパイル (条件コンパイル、conditional compilation) が実装されている。また、指定されたコンパイル定数が定義されている時のみ呼び出されるようConditional属性 (System.Diagnostics.ConditionalAttribute) をメソッドに指定することができる。この方法によって、DEBUG定数が定義されている時のみ評価される表明(アサート)機能 (System.Diagnostics.Debug.Assert()メソッド) が提供されている。
Java 1.4からは実行時に有効・無効を切り替えられるassert文が言語仕様として導入されている。
C#の名前空間はC++のそれと類似している。Javaのパッケージとは異なり、名前空間はソースファイルの物理的位置とは無関係である。Javaではパッケージ構造とソースファイルの位置が必ずしも一致している必要はないものの、デフォルトではそのような振る舞いをする。
Javaではアクセスレベルがpublicのクラス名はソースファイル名 (*.java) と一致していなければならない。つまり1つのソースファイルにpublicクラスは1つだけしか定義できない。デフォルトのアクセスレベルのクラスであれば、1つのソースファイルに複数のクラスをまとめて記述することができる。
C#ではそのような制約はなく、クラス名と無関係の1つのソースファイル (*.cs) に任意のクラスを複数記述することができる。C# 2.0からはpartialキーワードによってクラスの定義を複数のファイルに分けて記述することが可能になった。
Javaは非チェック例外 (unchecked exception) に加えてチェック済み例外 (checked exception) をサポートする。C#では非チェック例外のみである。チェック済み例外は、プログラマがメソッドから発生し得るものを全て宣言し、捕捉する必要がある。
全てのエラーが処理されることを保証できるため、チェック済み例外は非常に便利だとする者もいる。一方、C#の設計者であるアンダース・ヘルスバーグのように、Javaのチェック済み例外はある程度実験的な仕様であり、小さなプログラムでの例を除いては実装する価値を見出せなかった、とする者もいる。一つの批判として、チェック済み例外はプログラマが空のcatchブロックを記述するのを促進し、catch (java/lang e) {}のような危険なコードを増やす結果になってしまったというものがある。また別の批判として、メソッドの実装に変更を加えた結果新しいチェック済み例外が発生するようになる可能性があり、これによって契約が破壊されてしまう、というものがある。これは限られた例外のみが宣言されたインタフェースを実装するメソッドや、メソッドの内部実装が変更された場合に起こり得る。中には、このような予期しない例外が発生することを見越し、あらゆる型の例外が発生し得る、と宣言 (throws Exception) するプログラマもいる。これはチェック済み例外の利点を無にしている。しかしながら、いくつかの場面では例外連鎖 (exception chaining)、すなわち捕捉した例外を別の例外でラップして投げ直す、という手法が適用できる。例えば、ファイルにアクセスするコードがデータベースにアクセスするよう変更された場合、呼び出し側は内部で何が行われているかを知る必要がないため、java/sqlが捕捉された場合でもjava/ioとして投げ直すことが可能である。