Javaはメソッドを非virtualにする手段を提供しない（オーバーライドを禁止するためにfinal修飾子を使用することで封印することはできる）。これは派生クラスに、同じ名前の関係の無いメソッドを定義させる方法がないことを意味する。これは基底クラスが別の人間によって設計されるときに問題となることがあり、また、新しいバージョンが、派生クラスで同じ名前のメソッドがすでに存在するときに、同じ名前とシグネチャのメソッドを導入することで問題となることがある。これは、どちらのクラスの設計者の意図にも反して、派生クラスのメソッドが基底クラスのメソッドを暗黙のうちにオーバーライドするであろうことを意味する。これらのバージョン問題にある程度適合するためにJava 5.0は@Overrideアノテーションを導入しているが、後方互換性を保つには、それをデフォルトでは強制できない。
この問題は、メモリを増設する、最大ヒープメモリサイズを拡大するなどで解決できるケースもある。弱い参照 (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ではオブジェクトは常にヒープ領域に（JITコンパイラによって最適化されてスタックやレジスタに割り当てられない限り）確保される。ローカル変数はスタックやレジスタに確保される。C++ではオブジェクトをヒープ領域に割り当てるかスタック領域に割り当てるかをプログラマが選択することができたが、Javaではそれが不可能になっている。オブジェクトはガベージコレクションによって管理されるが、Javaはプログラマにガベージコレクションがいつ起こるかを保証しない。プログラマはガベージコレクションを阻止することができないし、たとえSystem.gc()を用いても任意のオブジェクトを任意のタイミングで解放することはできない。これはプログラミングを簡易にしメモリリークの可能性を軽減するが、決定論的でより効果的なメモリ処理を行うための柔軟性が犠牲になっている。C言語やアセンブリ言語のような低水準言語はこの柔軟性を提供する。C++などで書かれた多くのプログラムはメモリリークの犠牲になりがちだが、問題はメモリリークだけではない。ファイルハンドルやデータベース、ネットワーク接続のような他のリソースのリークは特に例外が投げられたときに常に起こりうる。C++ではRAIIと呼ばれるイディオムによっていずれの問題も克服することができるが、Javaプログラマは忘れずにfinally節でリソースを解放する必要があり、Javaが何を解放するかということとプログラマは何を解放しなければならないのかということをきちんと理解する必要がある。
Javaはメモリを管理するが、他のリソース（ファイルやJDBCデータベース接続など）は管理しない。これらはC言語およびC++でヒープに動的確保したメモリを明示的に解放する必要があったのと同様、プログラマによって解放されなければならない。
Javaのライセンスの問題は徐々に解決されつつある。時間が解決していると言える面もあるといえる。今後も新たなライセンスの問題に直面しそうであれば、Java Community Process に提案するよう働きかけてみるという手段もある。フリーソフトウェア財団や Eclipse Foundation など他のオープンソースコミュニティの助けを借りることで問題を解決に向けて進めることができる可能性がある。
サン・マイクロシステムズ（サン）のJavaの財産的価値はフリーソフトウェアコミュニティで議論を呼んだ。なぜならばサンのJavaの実装はフリーソフトウェアではなかったため、フリーソフトウェアや主にDebianや$100ラップトップ、Fedora CoreのようなGPL互換ライセンスが要求されるプロジェクトにはサンのJavaを含めることはできなかった。サンは JavaOne 2006 で、Javaはオープンソースソフトウェアになるだろうと公表した。この声明はSun Softwareの上級副社長Rich Greenによって公表された。「オープンソースソフトウェアにするか否かという問題はない。どのような方法でオープンソースにするかが問題である。つまり我々はこれを実行する。」2006年7月には、サンの最高技術責任者Robert BrewinはJavaは2007年6月に部分的にオープンソースになるが、全体のプラットフォームが完全なオープンソースになるには時間がかかるだろうとコメントしている。2006年11月13日、サンは標準版Java実行環境は2007年3月にGPLの下でリリースされる予定であることを公表した。Java実行環境のソースコードはGPLの下で利用可能になる予定である。リチャード・ストールマンによると、これはJavaの罠の終焉を意味するとのことである。マーク・シャトルワースはJavaのオープンソース化についての最初のSunによる発表を「フリーソフトウェアコミュニティにとっての確かなマイルストーン」と評価した。
地元の伝説では、1850年に遊牧民であるナマ人の羊飼いがヒツジを追っているときに温泉を発見したという。温泉は河床の地下深くから湧出し、砂漠気候の地にオアシスを生成した。ヘレロ・ナマクア虐殺の期間中、温泉はドイツ軍がベースキャンプとして利用した。1915年に、南西アフリカ戦線で傷ついた兵士を癒すため南アフリカ軍が基地として使用した。1962年に温泉は地元の起業家に貸与され、その後国の天然記念物として宣言された。1969年に保護区となり、1971年3月16日に基地は公式に開放された。泉温は平均しておよそ60 °Cである。温泉はパイプで引水し、屋内のプールやジャグジーに供給されている。1972年、1974年、1988年の度重なる洪水の際には一時的に閉鎖された。1972年の洪水では、高台にあった1軒の施設を除き、すべての施設が破壊された。フィッシュ川渓谷保護区は1987年に渓谷の西部が拡張された。1987年から1988年にかけてアイアイのキャンプは大規模な改造が実施された。2003年に締結された条約により, アイアイ温泉は南アフリカ共和国のリフタスフェルト国立公園に組み込まれることになり、アイアイ/リフタスフェルト・トランスフロンティアパークが設立された。温泉はケートマンスフープの南約200 km、カラスバーグの西約120 kmに位置する。