Javaの3種類の移植性

Javaは、ポータブルアプリケーションとアプレットを約束するため、プログラミングコミュニティで多くの興奮を生み出しています。実際、Javaには、ソースコードの移植性、CPUアーキテクチャの移植性、OS / GUIの移植性という3つの異なるタイプの移植性があります。移植性には3つの異なるタイプがあるという事実は重要です。これは、これらのタイプの1つだけがMicrosoftにとって脅威であるためです。Microsoftは、Javaをサポートしていると主張している間、他の2つを採用しながら、その1つのタイプの移植性を損なうことが予想されます。3種類の移植性とそれらがどのように連携するかを理解することは、マイクロソフトに対する脅威とマイクロソフトの考えられる対応を理解するために重要です。

ただし、これら3種類の移植性のそれぞれについて詳しく説明する前に、いくつかの基本的な用語を確認しましょう。

いくつかの用語の定義

この記事では、次の用語が使用されています。

エンディアニズム
エンディアニズムとは、特定のCPUでのマルチバイト量のバイトの格納順序を指します。たとえば、unsigned short 256(10進数)には、0x01と0x00の2バイトのストレージが必要です。これらの2バイトは、次のいずれかの順序で格納できます: 0x01, 0x00または 0x00, 0x01。エンディアニズムは、2バイトが格納される順序を決定します。実用的な目的では、エンディアニズムは通常、異なるエンディアニズムのCPUがデータを共有する必要がある場合にのみ重要です。
Java
Javaは、Javaプログラミング言語、Java仮想マシン(JVM)、およびその言語に関連付けられたクラスライブラリなど、一緒にパッケージ化されたいくつかの異なるテクノロジです。この記事では、これらすべての側面について説明します。
Java仮想マシン(JVM)

JVMは、ほとんどのJavaコンパイラがコードを発行する架空のCPUです。この架空のCPUのサポートにより、Javaプログラムを別のCPUで再コンパイルせずに実行できます。Javaプログラミング言語では、Javaソースコードをネイティブオブジェクトコードではなく、JVM用のコードにコンパイルする必要はありません。

実際、AsymetrixとMicrosoftは、ネイティブのMicrosoftWindowsアプリケーションを発行するJavaコンパイラを発表しました。(詳細については、この記事の「リソース」セクションを参照してください。)

Jコード
Jコードは、ほとんどのJavaコンパイラによってクラスファイルに出力される出力です。Jコードは、Java仮想マシンのオブジェクトコードと考えることができます。
移植性
移植性とは、さまざまなマシンでプログラムを実行する機能を指します。特定のプログラムをさまざまなマシンで実行するには、さまざまな量の作業が必要になる場合があります(たとえば、作業がまったくない、再コンパイルする、ソースコードに小さな変更を加えるなど)。人々がJavaアプリケーションとアプレットをポータブルと呼ぶとき、それらは通常、アプリケーションとアプレットが変更なしで(ソースコードの再コンパイルや微調整など)さまざまなタイプのマシンで実行されることを意味します。

いくつかの重要な用語について説明したので、3種類のJava移植性のそれぞれについて説明します。

言語としてのJava:ソースコードの移植性

プログラミング言語として、Javaは最も単純で最も馴染みのある形式の移植性、つまりソースコードの移植性を提供します。特定のJavaプログラム基盤となるCPU、オペレーティングシステム、またはJavaコンパイラに関係なく、同じ結果が生成されます。このアイデアは新しいものではありません。CやC ++などの言語は、長年にわたってこのレベルの移植性の機会を提供してきました。ただし、CおよびC ++には、移植性のないコードを作成する機会も数多くあります。CおよびC ++で記述されたプログラムが最初から移植可能であるように設計されていない限り、異なるマシンに移動する機能は実際的というより理論的です。CおよびC ++は、アトミックデータ型のサイズとエンディアニズム、浮動小数点演算の動作、初期化されていない変数の値、解放されたメモリにアクセスしたときの動作など、未定義の詳細を残します。

つまり、CおよびC ++の構文は明確に定義されていますが、セマンティクスは明確ではありません。このセマンティックの緩みにより、CまたはC ++ソースコードの単一ブロックをプログラムにコンパイルして、さまざまなコンパイラ設定に応じて、異なるCPU、オペレーティングシステム、コンパイラ、さらには単一のコンパイラ/ CPU / OSの組み合わせで実行したときに異なる結果が得られます。(セマンティクスと構文の違いについては、サイドバーの構文とセマンティクスを参照してください。)

Javaは違います。Javaは、はるかに厳密なセマンティクスを提供し、実装者に任せません。CやC ++とは異なり、Javaはアトミック型のサイズとエンディアニズムを定義し、浮動小数点の動作も定義しています。

さらに、JavaはCおよびC ++よりも多くの動作を定義します。 Javaでは、メモリはアクセスできなくなるまで解放されず、言語には初期化されていない変数がありません。これらの機能はすべて、Javaプログラムの動作のバリエーションをプラットフォームごと、および実装ごとに狭めるのに役立ちます。 JVMがなくても、Java言語で記述されたプログラムは、同等のCまたはC ++プログラムよりもはるかに優れた方法で(再コンパイル後に)異なるCPUおよびオペレーティングシステムに移植されることが期待できます。

残念ながら、Javaを非常にポータブルにする機能には欠点があります。Javaは、8ビットバイトとIEEE754浮動小数点演算を備えた32ビットマシンを想定しています。8ビットマイクロコントローラーやCrayスーパーコンピューターなど、このモデルに適合しないマシンは、Javaを効率的に実行できません。このため、Java言語よりも多くのプラットフォームでCおよびC ++が使用されることを期待する必要があります。また、Javaプログラムは、両方をサポートするプラットフォーム間でCまたはC ++よりも簡単に移植できることを期待する必要があります。

仮想マシンとしてのJava:CPUの移植性

ほとんどのコンパイラは、CPUの1つのファミリ(たとえば、Intel x86ファミリ)で実行されるオブジェクトコードを生成します。複数の異なるCPUファミリ(x86、MIPS、SPARCなど)のオブジェクトコードを生成するコンパイラでさえ、一度に1つのCPUタイプのオブジェクトコードしか生成しません。3つの異なるCPUファミリのオブジェクトコードが必要な場合は、ソースコードを3回コンパイルする必要があります。

現在のJavaコンパイラは異なります。現在のJavaコンパイラは、Javaプログラムが実行される予定の異なるCPUファミリごとに出力を生成する代わりに、まだ存在しないCPUのオブジェクトコード(Jコードと呼ばれる)を生成します。

(SunJコードを直接実行するCPUを発表しましたが、Javaチップの最初のサンプルは今年の後半まで表示されないことを示しています。そのようなチップの完全な生産は来年開始されます。SunMicroelectronicsのpicoJavaIコアテクノロジーネットワークコンピュータをターゲットとするSun独自のmicroJavaプロセッサラインの中心となる予定です。LGSemicon、Toshiba Corp.、Rockwell Collins Inc.などのライセンシーも、picoJavaIコアに基づいてJavaチップを製造する予定です。)

Javaプログラムが実行される予定の実際のCPUごとに、Javaインタープリターまたは仮想マシンがJコードを「実行」します。この存在しないCPUにより、Javaインタープリターが存在する任意のCPUで同じオブジェクトコードを実行できます。

架空のCPUの出力を生成することは、Javaでは目新しいことではありません。UCSD(カリフォルニア大学サンディエゴ校)Pascalコンパイラは数年前にPコードを生成しました。 Lucent Technologiesで開発中の新しいプログラミング言語であるLimboは、架空のCPU用のオブジェクトコードを生成します。 Perlは、ネイティブの実行可能コードを作成する代わりに、中間プログラム表現を作成し、この中間表現を実行します。インターネットに精通したJVMは、安全でウイルスのないコードを生成できるように意図的に設計されているため、これらの他の仮想CPU実装とは異なります。インターネットが登場する前は、プログラムが安全でウイルスに感染していないことを証明するために仮想マシンは必要ありませんでした。この安全機能は、架空のCPUのプログラムをすばやく実行する方法をよりよく理解することと相まって、迅速なJVMの広範な受け入れ。今日、OS / 2、MacOS、Windows 95 / NT、Novell Netwareなど、ほとんどの主要なオペレーティングシステムには、Jコードプログラムのサポートが組み込まれているか、または搭載される予定です。

本質的に架空のCPUであるJVMは、ソースコード言語に依存しません。 Java言語はJコードを生成できます。しかし、Ada95もそうです。実際、Jコードでホストされるインタープリターは、BASIC、Forth、Lisp、Schemeなどのいくつかの言語用に作成されており、他の言語の実装が将来Jコードを発行することはほぼ確実です。ソースコードがJコードに変換されると、Javaインタープリターは、実行中のJコードを作成したプログラミング言語を知ることができません。結果:異なるCPU間の移植性。

プログラム(任意の言語)をJコードにコンパイルする利点は、同じコードが異なるCPUファミリーで実行されることです。欠点は、Jコードがネイティブコードほど高速に実行されないことです。ほとんどのアプリケーションでは、これは問題ではありませんが、最高のハイエンドプログラム(CPUの最後の1パーセントを必要とするプログラム)では、Jコードのパフォーマンスコストは許容できません。

仮想OSおよびGUIとしてのJava:OSの移植性

CまたはC ++で記述されたほとんどのMicrosoftWindowsプログラムは、再コンパイルした後でも、MacintoshまたはUnix環境に簡単に移植できません。プログラマーがCまたはC ++のセマンティックの弱点に対処するために特別な注意を払っていても、移植は困難です。この問題は、Windows以外のオペレーティングシステムへの移植がCPUを変更せずに行われた場合でも発生します。なぜ難しいのですか?

CおよびC ++のセマンティックの問題とCPU移植の問題を排除した後でも、プログラマーはさまざまなオペレーティングシステムとさまざまなGUIAPI呼び出しに対処する必要があります。

Windowsプログラムは、MacintoshおよびUnixプログラムとは非常に異なるオペレーティングシステムへの呼び出しを行います。これらの呼び出しは、重要なプログラムを作成するために重要であるため、この移植性の問題が解決されるまで、移植は困難なままです。

Javaは、(例えば、Javaに供給されるライブラリに含まれるライブラリ関数のセット提供することによって、この問題を解決しawtutil及びlang)仮想OS及び仮想GUIへの話。 JVMが仮想CPUを提供するのと同じように、Javaライブラリは仮想OS / GUIを提供します。すべてのJava実装は、この仮想OS / GUIを実装するライブラリを提供します。これらのライブラリを使用して、必要なOSおよびGUI機能の移植をかなり簡単に提供するJavaプログラム。

ネイティブOS / GUI呼び出しの代わりに移植性ライブラリを使用することは新しい考えではありません。 VisixSoftwareのGalaxyやProtoolsSoftwareのZincなどの製品は、CおよびC ++にこの機能を提供します。 Javaに従わない別のアプローチは、マスターとして単一のOS / GUIを選択し、移植先のすべてのマシンでこのマスターOS / GUIをサポートするラッパーライブラリを提供することです。マスターOS / GUIアプローチの問題は、移植されたアプリケーションが他のマシンでは異質に見えることが多いことです。たとえば、Macintoshユーザーは、MacintoshプログラムではなくWindowsプログラムのように見え、動作するため、最近のバージョンのMacintosh用MicrosoftWordについて不満を漏らしました。残念ながら、Javaが採用したアプローチにも問題があります。

Javaは、OS / GUIライブラリで最小公分母機能を提供しています。タブ付きダイアログボックスなど、1つのOS / GUIでのみ使用可能な機能は省略されました。このアプローチの利点は、共通機能をネイティブOS / GUIにマッピングするのが非常に簡単であり、注意して、ほとんどのOS / GUIで期待どおりに機能するアプリケーションを提供できることです。欠点は、Javaアプリケーションでは使用できないネイティブモードアプリケーションで使用できる機能があることです。開発者は、AWTを拡張することでこれを回避できる場合があります。他の時には彼らはしません。回避策で目的の機能を実現できない場合、開発者は移植性のないコードを作成することを選択する可能性があります。

誰が携帯性を気にしますか?

開発者、エンドユーザー、MIS部門の3つの主要な構成員が移植性に関心を持っています。

開発者:機会と脅威が迫っています

開発者は、ポータブルソフトウェアの作成に既得権を持っています。利点として、ポータブルソフトウェアを使用すると、より多くのプラットフォームをサポートできるため、潜在的な顧客の基盤が拡大します。ただし、開発者が新しい市場をターゲットにできるのと同じ移植性により、競合他社も自分の市場をターゲットにできます。

一言で言えば、Javaの移植性は、アプリケーションソフトウェア市場を、さまざまなOSとGUIに基づく分離された市場から、1つの大きな市場へと押し上げます。たとえば、現在のソフトウェア市場では、MicrosoftはWindowsおよびMacintoshアプリケーションソフトウェア市場で評価されるべき勢力ですが、OS / 2およびUnix市場ではほとんど存在していません。このパーティショニングにより、OS / 2およびUnix市場の企業はMicrosoftを競合他社として無視することができます。Javaを使用すると、これらの企業はWindows市場での競争が容易になりますが、MicrosoftはOS / 2およびUnix市場への参入も容易になります。

ユーザー:移植性の間接的な受益者

ユーザーは、移植性自体を気にしません。移植性が彼らの生活をより簡単でより快適にするなら、彼らはそれのためにすべてです。そうでない場合は、そうではありません。移植性はユーザーにいくつかのプラスの効果をもたらしますが、これらはやや間接的です。プラスの効果: