C SharpとJavaの比較
Javaでは、Observer パターンの記述を容易にするために匿名クラスという糖衣構文が用意されている。匿名クラス構文により、クラス本体の定義とインスタンスの生成を同時に行なうことができ、また定義と生成がひとつの式として扱えるため、インターフェイス実装クラスのインスタンスを一度限りしか生成しない場面、例えば特定のインターフェイス実装(あるいは特定のスーパークラスのメソッドのオーバーライド)を要求するイベントハンドラーの設定時などによく用いられる。Java 8ではラムダ式がサポートされ、匿名クラスの代わりに使うこともできる。Java 7まではC#のデリゲートに相当するものは存在しなかったが、Java 8では類似機能としてメソッド参照がサポートされるようになった。
C#ではデリゲート (delegate) 型をはじめ、イベント処理をサポートするための機能が広範囲に渡って言語レベルでサポートされている。デリゲート型はメソッドへの型安全な参照であり、複数のデリゲートを結合してマルチキャスティングすることもできる。デリゲートを結合/分離するための+, -演算子、イベントハンドラーをカプセル化するためのイベント構文 (event, add/remove) や、イベントハンドラーを登録/削除するための+=, -=演算子が用意されている。デリゲートは共変性と反変性 (covariance and contravariance) をサポートし、完全なクロージャとしての性質をもつ匿名関数(匿名メソッドおよびラムダ式)を作成することができる。
Javaは非チェック例外 (unchecked exception) に加えてチェック済み例外 (checked exception) をサポートする。C#では非チェック例外のみである。チェック済み例外は、プログラマがメソッドから発生し得るものを全て宣言し、捕捉する必要がある。
全てのエラーが処理されることを保証できるため、チェック済み例外は非常に便利だとする者もいる。一方、C#の設計者であるアンダース・ヘルスバーグのように、Javaのチェック済み例外はある程度実験的な仕様であり、小さなプログラムでの例を除いては実装する価値を見出せなかった、とする者もいる。一つの批判として、チェック済み例外はプログラマが空のcatchブロックを記述するのを促進し、catch (Exception e) {}のような危険なコードを増やす結果になってしまったというものがある。また別の批判として、メソッドの実装に変更を加えた結果新しいチェック済み例外が発生するようになる可能性があり、これによって契約が破壊されてしまう、というものがある。これは限られた例外のみが宣言されたインタフェースを実装するメソッドや、メソッドの内部実装が変更された場合に起こり得る。
↑ Intrinsic Locks and Synchronization (The JavaTM Tutorials > Essential Classes > Concurrency)
↑ Synchronized Methods (The JavaTM Tutorials > Essential Classes > Concurrency)
↑ lock ステートメント - C# リファレンス | Microsoft Docs
↑ The Trouble with Checked Exceptions
↑ Why doesn't C# have exception specifications?
↑ .NET Core とオープン ソース | Microsoft Docs
↑ 「Javaはオラクルのもの?」、「いいえ、これからもJavaコミュニティのものです!」――Javaエバンジェリスト 寺田佳央氏が、Javaの現在、未来を語る