Sun JDK から OpenJDK に切り替えるとしたら、どのような驚きに備える必要がありますか?
よくある失敗の原因と、これがどれほど難しいことか?
もちろん、すべてのアプリケーションには個別の問題がある可能性がありますが、JDK を切り替えるときに多くの人がすでに苦労している問題のクラスを探しています。
OpenJDK で問題が発生する可能性はほとんどありません。現在のところ、100% 互換性があると見なされています。しかし、どの部分を書き直す必要があり、したがって SunJDK と同じコードを使用していないかを知ることは良いことだと思います。
ウィキペディアのエントリには、これについての概要があります。
2008 年 5 月の時点で、独自仕様でクローズド ソースのままであるクラス ライブラリの唯一の部分 (2007 年 5 月時点で OpenJDK 7 の 4%、2008 年 5 月時点および OpenJDK 6 の時点で 1% 未満) は SNMP 実装です。
2007 年 5 月の最初のリリース以来、Sun Microsystems は、コミュニティの助けを借りて、フリーでオープンソースのソフトウェアとしてリリースするか、ほとんどすべての障害のあるコードをフリーでオープンソースの代替物に置き換えました。
ソフトウェア シンセサイザーを含むすべてのオーディオ エンジン コードは、オープン ソースとしてリリースされています。クローズド ソースのソフトウェア シンセサイザーは、OpenJDK 用に特別に開発された Gervill と呼ばれる新しいシンセサイザーに置き換えられました。
クラス ライブラリで使用されるすべての暗号化クラスは、オープン ソースとしてリリースされています。
フォントをスケーリングおよびラスタライズするコードは、FreeType に置き換えられました。
ネイティブのカラー管理システムは、LittleCMS に置き換えられました。JDK にはプラグ可能なレイヤーがあり、商用バージョンでは古いカラー マネージメント システムを使用でき、OpenJDK では LittleCMS を使用できます。
アンチエイリアシング グラフィックス ラスタライザー コードは、phoneME プロジェクトで使用されているオープンソースの Pisces レンダラーに置き換えられました。このコードは完全に機能しますが、パフォーマンスを向上させる必要があります。
JavaScript プラグインはオープンソース化されています (Rhino JavaScript エンジン自体は最初からオープンソース化されていました)。
フォントが文字化けしているように見えることはわかっているので、Sun は OpenJDK から元のフォントを削除する必要がありました。これらは「オープン ソース」ではなく、JVM はあまり良くないデフォルトを使用するためです...
OpenJDK はオリジナルの Java ソースに基づく Sun プロジェクトであるため、多くの問題はないと思います。壊れる可能性のある唯一の領域は、置き換えが必要なコード (GPL の下でリリースできなかったため)、または新しい機能のために変更されたコード (ただし、それらは公式の JDK とほとんど同じである必要があります) です。
一部のスイング UI は完全には一致しませんでした (金属には気づくほどにずれているパディングがありました)。これは8か月前であることに注意してください。
TCK を渡すことが知られている OpenJDK ビルドを使用して、驚きを最小限に抑えます。
Linux でのOpenJDK (IcedTea) アプレットは大きな問題です。私はすでに数時間、かなりさびたコードの一部をリモートでデバッグするのに苦労しています。ブラウザでアプレットにアタッチする方法に関する公式ドキュメントは、私にとってはうまくいきません。ところで、デフォルトでは Java コンソールはありません。ブラウザでホストされている JVM をデバッグする代わりに、アプレット構成を複製し、JDK 組み込みのアプレット ビューアーを使用することを真剣に検討しています。
UPD : OpenJDK にブラウザ プラグイン自体がないことはよくわかりません。たぶん、これは最近変更されました。
OpenJDK は、IcedTea により、Oracle バイナリよりも安全です。