Javaに対する批判

Javaでは、メソッドがスローするチェック例外をメソッドシグネチャ内で宣言する必要があるチェック例外が導入されました。これは、不必要に冗長な定型コードにつながる可能性があります。主要なプログラミング言語で、Javaに続いてチェック例外を実装したものはまだありません。

Java 5.0 にジェネリクスが追加されたとき、既に大規模なクラスのフレームワークが存在していた（その多くは既に非推奨になっていた）ため、ジェネリクスは型消去を使用して実装され、移行の互換性とこれらの既存クラスの再利用を可能にした。これにより、他の言語と比較して提供できる機能が制限された。^{[ 2 ] [ 3 ]}

ジェネリクスは型消去を使用して実装されているため、テンプレートパラメータ E の実際の型は実行時には利用できません。したがって、Java では次の操作は不可能です。^{[ 4 ]}

public class MyClass < E > { public static void myMethod ( Object item ) { if ( item instanceof E ) { // コンパイラエラー// ... } E item2 = new E (); // コンパイラエラーE [] iArray = new E [ 10 ] ; // コンパイラエラー} }

さらに、2016年に、Javaが健全でないことが明らかになり、その結果、ClassCastExceptionやその他の種類のランタイムエラーをスローするJVMが技術的に適合していないことが判明しました。^{[ 5 ]}これはJava 10で修正されました。

class Nullless < T , U > { class Constrain < B extends U > { // ここに何か} final Constrain <? super T > constrain ; final U u ;Nullless ( T t ) { u = coerce ( t ); constrain = getConstrain (); }< B extends U > U upcast ( Constrain < B > constrain , B b ) { return b ; }U coerce ( T t ) { return upcast ( constrain , t ); }Constrain <? super T > getConstrain () { return constrain ; }public static void main ( String [] args ) { String zero = new Nullless < Integer , String > ( 0 ). u ; } }

Javaは設計上、プログラマーが互いに相互作用する名詞（クラス）の観点から解決策を考え、動詞（メソッド）をその名詞に対して、またはその名詞によって実行できる操作として考えるように促します。^{[ 6 ]}スティーブ・イェッゲは、クラスはそれに対して操作する複数の関数を持つことができるが、関数はクラスに束縛されており、複数の型に対して操作することはできないため、これは言語の表現力に不必要な制限をもたらすと主張しています。^{[ 7 ]}

他の多くのマルチパラダイム言語は、関数をトップレベルの構成要素としてサポートしています。関数オーバーロード（1つの動詞、複数の名詞）やジェネリック関数（1つの動詞、特定の特性を持つ名詞のファミリー）などの他の機能と組み合わせることで、プログラマは特定の問題を名詞で解決するか動詞で解決するかを決定できます。Javaバージョン8では、いくつかの関数型プログラミング機能が導入されました。

Javaにはネイティブの符号なし整数型がありません。符号なしデータはC言語で書かれたプログラムから生成されることが多く、これらの型がないためにC言語とJavaの間で直接データを交換できません。符号なしの大きな数値は暗号化を含む多くの数値処理分野でも使用されており、これらのタスクでJavaを使用するのが不便になる場合があります。^{[ 8 ]} 変換コードとより大きなデータ型を使用してこの問題を回避することは可能ですが、Javaで符号なしデータを扱うのは面倒になります。32ビットの符号付き整数を使用して16ビットの符号なし値を損失なく保持でき、64ビットの符号付き整数を使用して32ビットの符号なし整数を保持できますが、64ビットの符号なし整数を保持するためのより大きな型はありません。いずれの場合も、消費されるメモリは2倍になる可能性があり、通常、2の補数オーバーフローに依存するロジックはすべて書き直す必要があります。抽象化すると、他の言語ではネイティブである多くの操作で関数呼び出しが必要になります。あるいは、Java の符号付き整数を使用して同じサイズの符号なし整数をエミュレートすることも可能ですが、これにはビット演算の詳細な知識が必要です。^{[ 9 ]} JDK 8 では符号なし整数型が一部サポートされていましたが、符号なしバイト型はサポートされておらず、Java 言語でもサポートされていませんでした。^{[ 10 ]}

Java は、ユーザー定義演算子をサポートしていないことで批判されてきました。演算子のオーバーロードは可読性を向上させますが、^{[ 11 ]}その欠如は、特に複素数や行列などの数学的オブジェクトを表すクラスの場合、Java コードの可読性を低下させる可能性があります。Java には、文字列連結のための演算子の非数値的な使用例が 1 つしかありません。ただし、これはコンパイラによって実装され、インスタンスを作成するコードが生成されます。ユーザー定義の演算子オーバーロードを作成することは不可能です。++=StringBuilder

Java には、C の構造体のような複合値型がありません。これは、参照を介して間接的に操作するのではなく、直接操作されるデータの束です。値型は、参照を持つクラスよりも高速で小さい場合があります。^{[ 12 ] [ 13 ] [ 14 ]}例えば、Java の は、オブジェクトHashMapへの参照の配列として実装されています。 ^{[ 15 ]}これらのオブジェクトには、キーと値のオブジェクトへの参照が含まれています。何かを検索するには、非効率的な二重の逆参照が必要です。が値型であれば、配列はキーと値のペアを直接格納でき、最初の間接参照がなくなり、参照の局所性が向上し、メモリ使用量とヒープの断片化が削減されます。さらに、Java が汎用プリミティブ型をサポートしていれば、キーと値を配列に直接格納でき、両方のレベルの間接参照がなくなります。HashMap.EntryEntry

^{Javaは、 2³¹}（約21億）以上の要素を持つ配列をサポートしていないことで批判されてきた。 ^{[ 16 ] [ 17 ]}これは言語の制限であり、Java言語仕様書のセクション10.4には次のように記載されている。

配列はint値でインデックス付けする必要があります... longインデックス値で配列コンポーネントにアクセスしようとすると、コンパイル時エラーになります。^{[ 18 ]}

大規模な配列をサポートするには、JVM の変更も必要になります。^{[ 19 ]}この制限は、コレクションが 20 億要素に制限されていること^{[ 20 ]}や、2 GB を超える連続したファイル セグメントをメモリ マップできないこと^{[ 21 ]} などの領域で現れます。Javaには (2D 配列以外に) 多次元配列 (単一の間接参照でアクセスされる連続して割り当てられた単一のメモリ ブロック) もないため、科学技術計算のパフォーマンスが制限されます。^{[ 13 ]}

配列とプリミティブはやや特殊であり、クラスとは異なる扱いが必要です。汎用ライブラリを作成する際に多くの関数のバリエーションが必要になるため、これは批判されています^{[ 22 ] 。}

Per Brinch Hansenは1999年に^{[ 23 ]}、Javaの並列処理の実装全般、特にモニタは、安全で信頼性の高い並列プログラミングに必要な保証や強制を提供していないと主張した。プログラマは設計やコーディングの規約を確立できるが、コンパイラはそれらを強制する試みをしないため、プログラマは意図せず安全でない、または信頼性の低いコードを書いてしまう可能性がある。

Java はオブジェクトシリアライゼーションのメカニズムを提供しており、オブジェクトは、そのデータフィールドと、オブジェクト自身およびそのフィールドに関する型情報を含むバイト列として表現できます。オブジェクトがシリアライズされた後、後でデシリアライズできます。つまり、そのデータを表す型情報とバイトを使用して、メモリ内でオブジェクトを再構築できます。^{[ 24 ]}これは、理論的にも実際的にも非常に深刻なセキュリティリスクを引き起こします。^{[ 25 ] [ 26 ]}

Java の浮動小数点演算は、大部分がIEEE 754 (バイナリ浮動小数点演算の標準)に基づいているものの、例外フラグや指向丸めなど、 (現在では冗長な^{[ 27 ]} )修飾子を使用した場合でも、必須の標準機能の一部はサポートされていません。IEEE 754 で定義され、多くのプロセッサでサポートされている拡張精度型は、Java ではサポートされていません。^{[ 28 ] [ 29 ] [ 30 ]}strictfp

Javaはタプルをネイティブにサポートしていないため、プログラマがインポートして処理する必要のあるサードパーティの実装が多数存在する。^{[ 31 ]}汎用タプルクラスに反対する理由は、保守性の低いコードが増殖する危険性があるからである。^{[ 32 ]}

Java 7 より前は、インストーラーは古い Java インストールを削除しませんでした。Windows システムでは、同じコンピューターに複数の Java インストールが存在することはよくありました。^{[ 49 ] [ 50 ] [ 51 ]}複数のインストールが許可されており、悪意のあるプログラムを含む、特定のバージョンに依存するプログラムで使用される可能性がありました。この問題は Java 7 で解決されました。ユーザーの許可があれば、インストーラーは以前のインストールを削除します。^{[ 52 ]}

JITコンパイルは基本的に実行可能データを使用するため、セキュリティ上の課題や悪用される可能性が生じる。