Javaに対する批判

これらのクラスパス問題は環境変数CLASSPATHを使用せず、サン・マイクロシステムズが推奨する-classpathオプションを使用することで解決する。開発時は、-classpathオプションはバッチファイルやmakeや Apache Ant や統合開発環境を使うことで便利に指定することができる。Javaアプリケーションを利用する実行エンドユーザに対しては、開発者がマニフェストファイルにクラスパスを記述するか、FatJarやOneJar[4]という、複数のjarファイルを一つにまとめるツールを使うことで解決できる。

Javaのライセンスの問題は徐々に解決されつつある。時間が解決していると言える面もあるといえる。今後も新たなライセンスの問題に直面しそうであれば、Java Community Process に提案するよう働きかけてみるという手段もある。フリーソフトウェア財団や Eclipse Foundation など他のオープンソースコミュニティの助けを借りることで問題を解決に向けて進めることができる可能性がある。

Javaはガベージコレクションによるメモリ管理機能を備える。これによって、完全ではないもののプログラマがメモリリークを起こすようなプログラムを作ってしまう危険性を減らした。Javaではオブジェクトは常にヒープ領域に（JITコンパイラによって最適化されてスタックやレジスタに割り当てられない限り）確保される。ローカル変数はスタックやレジスタに確保される。C++ではオブジェクトをヒープ領域に割り当てるかスタック領域に割り当てるかをプログラマが選択することができたが、Javaではそれが不可能になっている。

オブジェクトはガベージコレクションによって管理されるが、Javaはプログラマにガベージコレクションがいつ起こるかを保証しない。プログラマはガベージコレクションを阻止することができないし、たとえSystem.gc()を用いても任意のオブジェクトを任意のタイミングで解放することはできない[13][14]。これはプログラミングを簡易にしメモリリークの可能性を軽減するが、決定論的でより効果的なメモリ処理を行うための柔軟性が犠牲になっている。C言語やアセンブリ言語のような低水準言語はこの柔軟性を提供する。

C++などで書かれた多くのプログラムはメモリリークの犠牲になりがちだが、問題はメモリリークだけではない。ファイルハンドルやデータベース、ネットワーク接続のような他のリソースのリークは特に例外が投げられたときに常に起こりうる。C++ではRAIIと呼ばれるイディオムによっていずれの問題も克服することができるが、Javaプログラマは忘れずにfinally節でリソースを解放する必要があり、Javaが何を解放するかということとプログラマは何を解放しなければならないのかということをきちんと理解する必要がある。

この問題は、メモリを増設する、最大ヒープメモリサイズを拡大するなどで解決できるケースもある。弱い参照 (WeakReference/SoftReference/PhantomReference) を用いることで多少の解決策になることはある。だが、JREやJDKのバージョンが特定の古いものであることが要因となっていることもある。最新版のJREやJDKで実行、開発すれば問題発生率を下げることもできる。

finally節の問題は、場合によっては、ライブラリやフレームワークによって解決できることもある。ファイル入出力の場合はApache Commons IOを、データベース接続の場合はApache Commons DBUtils、HibernateやApache Cayenneなどのオブジェクト関係マッピングフレームワークを用いることでfinally節のことをあまり多く気にしなくても良いようにする手段がある。Java 7ではtry-with-resources文でこの問題に対処している（例外安全の確保）。

Javaの設計者らは、現在他の言語にあるいくつかの機能（多重継承、演算子多重定義、タプルなど）を実装しないことを決めた。

総称型（ジェネリクス）がJava 5.0に導入されたとき、すでにJavaにはクラスの大規模な枠組みがあった（それらの多くはすでに非推奨となっていた）、そして後方互換性を保つため、総称型の実装方法として既存のクラスを維持することを可能にする（コンパイル時の）型消去（型削除、type erasure）が選ばれた。これは、他の言語と比べると、総称型の導入によって提供される機能を限定してしまう結果になった[15][16]。

Javaのプリミティブ型はオブジェクトではない。プリミティブ型は値への参照ではなく値そのものをスタック領域に保持している。この設計選択はパフォーマンス上の理由により行われた。このためJavaは純粋なオブジェクト指向言語と見なされていない。またこのことによりリフレクションがより複雑になっている。配列を除き、Javaのコレクションクラスはプリミティブ型を直接扱うことができず、プリミティブラッパークラスへのボックス化が必要となる。この制約はジェネリクスにおいても変わりない。Javaのジェネリクスは型安全性が担保されるだけであり、ジェネリクスを使わない場合と比べてパフォーマンス上のメリットはない。

また、Java 5.0は、コンパイル中に要求された場合にプリミティブ型を対応するプリミティブラッパークラスのオブジェクトに自動変換する機能（オートボクシング）をサポートしているが、オートボクシングではNullPointerExceptionが投げられる可能性がある。オートボクシングは暗黙のうちに起こる（キャストやメソッド呼び出しを伴わない）ため、このNullPointerExceptionという非チェック例外はJavaプログラムのコードに目を通しただけでは明確にはならない恐れがある。

Javaはメソッドを非virtualにする手段を提供しない（オーバーライドを禁止するためにfinal修飾子を使用することで封印することはできる）。これは派生クラスに、同じ名前の関係の無いメソッドを定義させる方法がないことを意味する。これは基底クラスが別の人間によって設計されるときに問題となることがあり、また、新しいバージョンが、派生クラスで同じ名前のメソッドがすでに存在するときに、同じ名前とシグネチャのメソッドを導入することで問題となることがある。これは、どちらのクラスの設計者の意図にも反して、派生クラスのメソッドが基底クラスのメソッドを暗黙のうちにオーバーライドするであろうことを意味する。これらのバージョン問題にある程度適合するためにJava 5.0は@Overrideアノテーションを導入しているが、後方互換性を保つには、それをデフォルトでは強制できない。

Javaは主にオブジェクト指向の単一パラダイム言語である。すべてのデータと処理は必ず何らかのクラス内に記述しなければならないため、必要以上にコードが冗長になってしまうことがある。Java 5.0で追加された静的インポート (static imports) はこれまでのJavaよりも手続きパラダイムによりよく順応する。

JavaではC++でオプションとされていた例外処理の仕様を取り込んだが、この際チェック対象の例外に対応するthrows文を必須とした。例外のチェックは小規模なシステムにとっては役立つが、大規模なシステムについても有益であるかどうかについては統一的な見解には至っていない。特に上位のコードでは下位のコードから発生するエラーを意識したくない（例としては、名前解決例外であるNamingException）。名前クラスの作成者は名前解決例外をチェック対象の例外として上位コードに対応を強制するか、コンパイル時のチェックを使わずに下位のコードからの例外を連鎖的に通知するかを選択する必要がある[17]。

Javaでは、内部クラス、ローカルクラス、匿名クラスを使用することで、基本的なクロージャに近い記述が実現できる。しかしこれは完全ではなく、ローカルクラス／匿名クラス外の変数に対する参照を、ローカルクラス／匿名クラスのフィールドとして暗黙キャプチャできるように、final修飾子付きで宣言する必要がある。これは、変数のスコープを抜けたときに削除できるような、様々な寿命に対応したスタックモデルをJVM実装者が選択できるようにするためである。Java 8では実質的にfinalとみなせる変数は明示的にfinal修飾する必要がなくなったが、依然として再代入は許可されない。

また匿名クラスの構文も冗長であり、例えばRunnableインタフェースを要求する場面で、同インタフェースを実装する匿名クラスを定義する場合、単純なコードブロックとして定義することはできず、Runnable.run()メソッドを実装するようなクラスのブロックを定義する必要がある。Java 8ではラムダ式と関数型インタフェースによりこの問題を改善している。

Java 7以前にはC/C++の関数ポインタやC#のデリゲートに相当するメソッド参照の機能がなく、インタフェースで代用するしかなかった。Java 8ではメソッド参照が追加された。

この問題は、開発者がJavaのバージョンを Java SE 6以降にアップグレードすることで解決する。Java SE 6になってからJavaのデスクトップまわり、GUI環境は一新され、開発効率は高まっているため、以前のバージョンよりも開発の手間はかからなくなっている。

Javaプログラムのパフォーマンスに関して一般論を述べることは不可能である。なぜなら、実行時の性能は、言語自身が持つ固有の特性よりも、JavaコンパイラやJava仮想マシンの品質に非常に大きく影響されるからである。Javaバイトコードの実行方法は、仮想マシンによって実行時に翻訳して実行する方法と、ロード時もしくは実行時に機械語にコンパイルしてハードウェアによって直接的に実行する方法がある。前者の翻訳実行する方法は機械語の実行よりも遅く、後者のロード時もしくは実行時にコンパイルして実行する方法は、最初のコンパイル時にパフォーマンスが犠牲になる。これはJavaにかぎらず、.NET Frameworkなど他の仮想マシンベースのプログラミング環境においても同様である。

コンピュータハードウェア性能の向上と、Javaのバージョンアップに伴う最適化技術の進歩によって、Javaプログラムの初回起動時のオーバーヘッドなどは誤差の範囲内になりつつあるが、ヴィルトの法則が示すように、総じてソフトウェアの複雑化やシステム要求の上昇にハードウェアの性能向上が追い付いていないのが現状である。C/C++ではJavaよりも細やかな最適化を手動で施すことができるが、プログラマが手作業で施した最適化よりも、JITコンパイルによる自動最適化のほうが性能面で上回るケースもすでに存在する。C/C++でJavaの実行時最適化技術を真似することは困難である。

Javaだけに限ったことではないが、パフォーマンス上の障壁となる言語仕様や言語仕様の欠落がいくつか存在する。それは例えば配列境界チェックや実行時型チェック、非仮想メソッドの欠如などである。ただしコードの安全性と性能はトレードオフの関係にあるため、チェック機構が一概に悪とは言えない。また、コンパイル時の最適化やJVMの実装次第で解消できるものもある。そのほか、Javaは構造体（ユーザー定義の値型）および矩形配列（真の多次元配列）を持たず、それぞれクラス（参照型）およびジャグ配列（配列の配列）などで代替する必要がある。また、Javaではメソッドから複数の値を返すためにはクラスや配列といった参照型を使用する以外の方法がない。これらの制約によってJavaのプログラムコードは、他の言語で書かれたコードよりも頻繁にヒープを使用しなければならなくなっている。

不要オブジェクトの自動回収を行うガベージコレクションは明示的なメモリ解放に比べそのオーバーヘッドは大きいが、ガベージコレクタの実装やアプリケーションでのオブジェクトの利用状況によってその影響はまちまちに変化する。多くのJava仮想マシンは世代別ガベージコレクションの採用によって動的メモリ管理を高速化しているため、多くのアプリケーションでは高い性能を示している。

一般に、プログラミング言語とその実行方法は、直交するのが普通で、コンパイラだったり、インタプリタだったり、バイトコード方式だったりする実装があっても構わないはずである。しかし、Javaには、実装上制限があり、あまりに自由度がない。

ジャストインタイムコンパイル（JITコンパイル）とネイティブコンパイルの性能差はほとんど無いとされるが、よく議論の種にもなる。JITコンパイルには時間が掛かるため、短時間で起動終了することが求められるアプリケーションや、起動と終了を頻繁に繰り返すアプリケーション、またプログラム内容が巨大なアプリケーションでは問題となる。しかし、一旦ネイティブコードに変換すれば数値計算においてもネイティブコンパイルと同等の性能を示す。

Javaはメソッド呼び出しの明示的なインライン化をサポートしないものの、多くのJITコンパイラではバイトコード読み込み時にインライン展開を行い、また実行時のプロファイリングを利用してその効率をより高めている。HotSpot仮想マシンが採用している動的再コンパイルでは、実行時でしか取得できない情報を利用することで、多くのプログラミング言語が採用する静的コンパイル方式を超える性能を得る場合もある。

ハードウェアに直にアクセスするクライアントサイドまたはサーバシステムは、ネイティブコードとJavaライブラリを橋渡しするJava Native Interface (JNI) を使って、C/C++およびアセンブリ言語とJavaを組み合わせる方法を取る。また、ハードウェアアクセスを担うネイティブコードとJavaとの通信をファイルやデータベース、共有メモリやソケットを介して行う方法もあるが、理想的なやり方ではない。

JNIを使うことで、プラットフォーム依存性、潜在的なデッドロック、メモリリーク、場合によっては性能の著しい劣化などの問題が発生しうる。また、2つの異なるコードベースをメンテナンスするために必要となるコードの複雑性は、言うまでもない。しかし、それは、例えば.NET Frameworkの共通言語ランタイムにおけるP/Invokeのように、他の仮想マシン環境と共通する事例である。

現在では今のところ、Javaはまだまだハードウェア開発、デバイスドライバ開発には適していない点が多い。この問題について、JavaでUSBドライバ開発ができる Java Communication API という技術がすでにある。他にも、Jini対応機器を端末に接続すると、サーバから自動的にJava製ドライバを端末にダウンロードしてその機器を使うことができる技術Jiniというものが考えられている。なおこのJiniは、Java Native Interfaceを意味するJNIとは別物である。

この問題も、サン・マイクロシステムズのJavaコーディング規約をJavaプログラマが守っていればほぼ起きることがなく、Javaソースコード上のimport宣言や新しく加わったJavaキーワード（enumやassert）と重複するものが無ければほぼ心配することもなくなる。とくに、多くの場合において、これらの問題はコーディング規約だけでなく、統合開発環境やCheckStyle、FindBugsなど各種ツールなどによって解決できるケースがある。Javaプログラマは、日頃からCheckStyleやFindBugsを使ってプログラミングしていれば、後方互換性の問題につき当たる可能性は下がる。しかし、Javaアプレットなどのように、方針転換による大規模な機能廃止もありうる。JDK/JREにはサポート期間が定められており、古いJDK/JREを永久に使い続けることはできないため、廃止予定となったAPIが完全廃止される前に代替技術に移行するなど、最新のJava技術動向に追随していく必要がある。