Javaに対する批判
この問題は、開発者がJavaのバージョンを Java SE 6以降にアップグレードすることで解決する。Java SE 6になってからJavaのデスクトップまわり、GUI環境は一新され、開発効率は高まっているため、以前のバージョンよりも開発の手間はかからなくなっている。
一般に、プログラミング言語とその実行方法は、直交するのが普通で、コンパイラだったり、インタプリタだったり、バイトコード方式だったりする実装があっても構わないはずである。しかし、Javaには、実装上制限があり、あまりに自由度がない。
ジャストインタイムコンパイル(JITコンパイル)とネイティブコンパイルの性能差はほとんど無いとされるが、よく議論の種にもなる。JITコンパイルには時間が掛かるため、短時間で起動終了することが求められるアプリケーションや、起動と終了を頻繁に繰り返すアプリケーション、またプログラム内容が巨大なアプリケーションでは問題となる。しかし、一旦ネイティブコードに変換すれば数値計算においてもネイティブコンパイルと同等の性能を示す。
Javaはメソッド呼び出しの明示的なインライン化をサポートしないものの、多くのJITコンパイラではバイトコード読み込み時にインライン展開を行い、また実行時のプロファイリングを利用してその効率をより高めている。HotSpot仮想マシンが採用している動的再コンパイルでは、実行時でしか取得できない情報を利用することで、多くのプログラミング言語が採用する静的コンパイル方式を超える性能を得る場合もある。
不幸にも、(2006年8月の時点で)Java実行環境 (JRE) のデフォルトのインストールでは、Swingデフォルトの埋め込みMetal (メタル) ルックアンドフィールの代わりに、システムの「ネイティブ」なルックアンドフィールを使わなかった。プログラマがUIManagerを使ってシステムネイティブなルックアンドフィールを設定しなかった場合、ユーザーは外観がネイティブアプリケーションのそれとは非常に異なるアプリケーションに遭遇するだろう。 macOSの配布元に限って含まれるApple自身のJava実行環境の最適化バージョンは、デフォルトで「デフォルト」をセットし、"Aqua" のルックアンドフィールを実装し、Macintosh上のSwingアプリケーションは、ネイティブなソフトウェアに似た外観を提供している。macOSの環境でさえ、プログラマはそのアプリケーションがAquaのように見えることを確実とするために、若干の余分の作業をまだしなければならない(例えば、メニューバーをWindowsのように各アプリケーションウィンドウ内部に表示するのではなく、macOSのメニューバー内部に表示させるために、システムプロパティをセットする必要がある)。