この問題も、サン・マイクロシステムズのJavaコーディング規約をJavaプログラマが守っていればほぼ起きることがなく、Javaソースコード上のimport宣言や新しく加わったJavaキーワード（enumやassert）と重複するものが無ければほぼ心配することもなくなる。とくに、多くの場合において、これらの問題はコーディング規約だけでなく、統合開発環境やCheckStyle、FindBugsなど各種ツールなどによって解決できるケースがある。Javaプログラマは、日頃からCheckStyleやFindBugsを使ってプログラミングしていれば、後方互換性の問題につき当たる可能性は下がる。しかし、Javaアプレットなどのように、方針転換による大規模な機能廃止もありうる。JDK/JREにはサポート期間が定められており、古いJDK/JREを永久に使い続けることはできないため、廃止予定となったAPIが完全廃止される前に代替技術に移行するなど、最新のJava技術動向に追随していく必要がある。
Javaは、Java仮想マシン (JVM) の上部で動くバイトコード言語である。異なるプラットフォームで実行できる能力と言語の互換性は、最終的にはJVM実装の安定性とJVMのバージョンに依存している。Javaは非常に様々なシステム上で動くとうたわれているが、最新のJVM（とJRE）はWindows、Linux、Solaris対応だけ活発に更新されている状況である。HP-UX（Java for HP-UXなど）とIBM (for MVS、AIX、OS/400) は、それぞれのプラットフォームファミリー独自の実装を提供するが、必ずしも最新のサン・マイクロシステムズのリリースを反映していない。他のプラットフォームにおけるJVM実装も、たいてい今後も続くが、時々一般の実装例よりも何年か何ヶ月か遅れるので、互換性問題が生じる。具体的な例を示すと、Java 2 Platform Standard Edition 1.5 (J2SE 1.5) をサン・マイクロシステムズがリリースしたのは2004年9月30日だが、Mac OS X用J2SE 1.5をアップルが公開したのは2005年3月であり、5か月余りの差が生じている。
現在では今のところ、Javaはまだまだハードウェア開発、デバイスドライバ開発には適していない点が多い。この問題について、JavaでUSBドライバ開発ができる Java Communication API という技術がすでにある。他にも、Jini対応機器を端末に接続すると、サーバから自動的にJava製ドライバを端末にダウンロードしてその機器を使うことができる技術Jiniというものが考えられている。なおこのJiniは、Java Native Interfaceを意味するJNIとは別物である。
ハードウェアに直にアクセスするクライアントサイドまたはサーバシステムは、ネイティブコードとJavaライブラリを橋渡しするJava Native Interface (JNI) を使って、C/C++およびアセンブリ言語とJavaを組み合わせる方法を取る。また、ハードウェアアクセスを担うネイティブコードとJavaとの通信をファイルやデータベース、共有メモリやソケットを介して行う方法もあるが、理想的なやり方ではない。JNIを使うことで、プラットフォーム依存性、潜在的なデッドロック、メモリリーク、場合によっては性能の著しい劣化などの問題が発生しうる。また、2つの異なるコードベースをメンテナンスするために必要となるコードの複雑性は、言うまでもない。しかし、それは、例えば.NET Frameworkの共通言語ランタイムにおけるP/Invokeのように、他の仮想マシン環境と共通する事例である。
Javaはセキュリティと移植性を重視して設計されたので、Javaではマシンアーキテクチャとアドレス空間への直接アクセスをサポートしていない。スキャナ（デジタルカメラ、オーディオレコーダ、ビデオキャプチャ）ないし実質的に直接メモリ空間の制御（一般的に、ドライバインストールを必要とするハードウェアやそれらの部品）を必要とする特定の一部のハードウェアを動かすことはJavaでは容易に実現できないことを意味する。この問題の実例はJavaのバージョン1.0で見られた。様々なプリンタドライバへのインタフェースコードがこの初期のJava実行環境に含まれず、プリンタへのアクセスが可能でなかった。
一般に、プログラミング言語とその実行方法は、直交するのが普通で、コンパイラだったり、インタプリタだったり、バイトコード方式だったりする実装があっても構わないはずである。しかし、Javaには、実装上制限があり、あまりに自由度がない。ジャストインタイムコンパイル（JITコンパイル）とネイティブコンパイルの性能差はほとんど無いとされるが、よく議論の種にもなる。JITコンパイルには時間が掛かるため、短時間で起動終了することが求められるアプリケーションや、起動と終了を頻繁に繰り返すアプリケーション、またプログラム内容が巨大なアプリケーションでは問題となる。しかし、一旦ネイティブコードに変換すれば数値計算においてもネイティブコンパイルと同等の性能を示す。Javaはメソッド呼び出しの明示的なインライン化をサポートしないものの、多くのJITコンパイラではバイトコード読み込み時にインライン展開を行い、また実行時のプロファイリングを利用してその効率をより高めている。HotSpot仮想マシンが採用している動的再コンパイルでは、実行時でしか取得できない情報を利用することで、多くのプログラミング言語が採用する静的コンパイル方式を超える性能を得る場合もある。
不要オブジェクトの自動回収を行うガベージコレクションは明示的なメモリ解放に比べそのオーバーヘッドは大きいが、ガベージコレクタの実装やアプリケーションでのオブジェクトの利用状況によってその影響はまちまちに変化する。多くのJava仮想マシンは世代別ガベージコレクションの採用によって動的メモリ管理を高速化しているため、多くのアプリケーションでは高い性能を示している。
ペンブロークシャーのセント・デイビッズに生まれる。父親も音楽家で、聖デイヴィッド大聖堂の楽長代理でオルガニストであった。3人の異母兄弟も音楽家になったが、トマス・トムキンズほどの名声を勝ち得たものはいない。1596年にウースター大聖堂聖歌隊の指導者に任命される。マドリガーレ集の一つを恩師ウィリアム・バードに捧げるとしていることから、ロンドンでバードに師事した可能性が高い。トマス・モーリーが重要な曲集『オリアーナの勝利 The Triumphs of Oriana 』（1601年出版）にトムキンズのマドリガーレの一つを掲載していることから、トムキンズはロンドン時代におそらくモーリーと出会っているらしい。1620年より少し前に王室礼拝堂のジェントルマンに列せられ、1625年に王室礼拝堂の長老オルガニストに指名されるが、1628年ごろには隠退したらしい。どうやらその後も20年間ウースター大聖堂に奉職したらしい。だが1646年、清教徒革命の間にウースターが議会軍に占拠されると、職を失うが、大聖堂の近くに住み続けることは許された。音楽は清教徒にとって忌むべきものであったため、詩篇唱の斉唱を除いて、ことごとく教会で禁じられた。トムキンズが1614年に発注したウースター大聖堂のオルガンは破壊され、聖歌隊は解散された。トムキンズは息子とともにウースターを出て、亡くなるまで息子の許に身を寄せた。