Java ランタイムは、プログラムで使用する一連の標準システム ライブラリを提供します。これらのライブラリは、オペレーティング システムのシステム コールとどの程度似ていて、どの程度異なっているのでしょうか?
4 に答える
Java の要点の半分は、プラットフォームに依存しないようにすることでした。そのため、Java がしようとしているのは、その下にある OS に関係なく同じままの API を提供することです。
OS の能力が不足している場合、Java はそれを補うためにライブラリ コードを追加します。
OS にマップされない実装がある場合、Java はそれをマップするために最善を尽くします。
新しい機能が普及し、Java ユーザーがその機能へのアクセスを提供する必要がある場合、新しい機能にアクセスできる新しいライブラリを作成できます。このライブラリが人気がある場合、ある時点で再構築され、Java SDK に追加されます。
たとえば、いくつかの同時実行ライブラリの実装が人気を博し、すぐに投票されて標準ライブラリに追加されました。これは常に起こります。
システムコールは一般にOSごとに異なるため、それは明らかに実行しているOSに依存します:-)。
とはいえ、Java はほとんどが Unix の慣習に影響を受けていると思います (Sun は Unix ベンダーであるため、驚くべきことではありません)。そのため、一部の Java システム ライブラリは Unix システム コールに似ています。
たとえば、java.nio.MappedByteBuffer は、おそらく Unix の mmap() 呼び出しに触発されたものです。しかし、最終的にはほとんどの概念がほとんどの OS に存在するため、何が何に影響を与えたのかを実際に言うことはできません。
Java の「低レベル」関数の一部は、基本的に一部の OS システム コールの「ラッパー」です。
両方を「比較」する客観的な方法(および理由)はわかりません。
このトピックに興味がある場合は、ネイティブキーワードの Java ソース コードを検索できます。これは、「隠された」(ほとんどの場合 OS に依存する) 機能を示します。
Java の標準ライブラリは、多くの場合、ネイティブ ライブラリと比較して同様の機能セットを備えていますが、重要な違いがいくつかあります。
- 好むと好まざるとにかかわらず、Java はオブジェクト指向です。これの利点は、特定の概念が管理しやすいことです。たとえば、ほとんどのファイル関連の操作は、File オブジェクトに直接含まれています。これを Posix と比較してください。ここで、FILE は実際には単なる数値であるハンドルです。プロセスの開いているファイル リストへのインデックス。Posix のアプローチは、OS が実際に実装する方法に非常に近いものです。しかし、Java では、それを見たり、知ったり、気にしたりしません。
- Java には、特定のケースで特定の最小公分母の動作があります。AWT は多くの異なるプラットフォームで同一である必要があったため、そのままの AWT API が多数あります。それは狂気であることが判明し、Sun は AWT のほとんどをほぼ非推奨にしました。プラットフォームをサポートすることは、すべてのプラットフォームをサポートすることを意味しません。新しいライブラリである Swing は、ほぼすべてを純粋な Java で実装しているため、クロスプラットフォームの処理がはるかに優れており、より豊富な API を備えています。そして、その API は、ネイティブ ウィンドウ ライブラリとは大きく異なります。また、ネイティブ OS をほとんど使用しないため、Swing はあまりうまく統合されません。
- Java には、ネイティブ ライブラリにはない特定の制限があります。たとえば、関数ポインターがありません。したがって、C++ で関数ポインターを使用することを行うための Java パターンがあります
Listeners
。Runnable
したがって、これらの機能のいずれかを必要とする API は、ネイティブ OS と Java では大きく異なります。
結論として、Java には多くの場合、ネイティブ OS と同様の動作を提供するライブラリがあり、まったく異なる動作を提供することもありますが、Java を独自のプラットフォームと考えるのが最善です。OpenGL や超高速データ転送などの高度なパフォーマンスが必要な場合は、特定の Java API (Jogl、nio) が必要になることがありますが、ほとんどの場合、Java を独自のものとして評価する必要があります。