Javaの移植性について混乱しています。Java 言語が移植可能である場合、なぜenumJ2ME では不明なのですか?
C++ では、どのプラットフォームやライブラリが使用されているかは重要ではありません。「C++ 言語」は、すべてのプラットフォームで変わるわけではありません。
int私の目的は、 、String、またはArray( のライブラリのようなもの) などのプリミティブ型を使用する Java ライブラリを開発することですGenetic algorithms。このライブラリをモバイルおよびデスクトップ アプリケーションで使用したいと考えています。しかし、enum他のいくつかのキーワードは、すべてのプラットフォームに存在しないようです。
ですから、「Java の移植性」の意味を誤解していたと思います。どういう意味ですか？
Java には、モバイル向けの ME、デスクトップ向けの SE、エンタープライズ向けの EE の 3 つの種類があります。
「Java は移植可能」とは、SE バージョンを指します。これは、準拠する JVM を備えた任意のハードウェアでJavaバイトコードを実行できることを意味します。
ME が SE と同じであり、EE が同じであるという意味ではありません。EE には EJB がありますが、SE と ME にはありません。移植性が低下するわけではありません。
C++ 言語は、すべてのプラットフォームで変わるわけではありません。
このステートメントは厳密には正しくありません。Microsoft は、他の場所では実行できない拡張機能を C++ に追加します。
プラットフォーム固有の拡張機能を使用しない限り、ANSI C++ はポータブルソース コードを意味する場合があります。移植可能なバイトコードという意味ではありません。再コンパイルと再リンクが必要になる場合があります。
電話で遺伝的アルゴリズムを実行したいですか? モバイル デバイスが非常に強力になったことは知っていますが、GA はサーバー側の機能になると考えています。モバイル デバイスは、私にとってビューのように感じます。
すべてのハードウェア アーキテクチャには独自の独自の命令セット (ax、bx を追加) があり、C++ コードをビルドすると、コンパイラはそれを、作業中のシステム/アーキテクチャに固有のマシン コードに変換します。したがって、さまざまなアーキテクチャで動作するように、コードをカスタマイズしてビルドする必要があります。
しかし、Java で何が起こるかというと、それをビルドすると、(マシン コードではなく) バイト コードにコンパイルされます。また、Java 仮想マシン (JVM) は、バイト コードを、プログラムが実行されている特定のアーキテクチャで理解できる命令に解釈します。すべての主要なアーキテクチャとオペレーティング システムに対応する JVM があるため、Windows で記述したコードは解釈され、ソース レベルの変更なしで MAC-OS または Linux で実行されます。それが Java が移植可能である理由であり、それがWrite Once Run Everywhereのモットーの由来です。
Java コードはすべての主要なプラットフォームで実行できるため、Java は「移植可能な言語」として知られています。さらに、Java ソースを「バイトコード」.class にコンパイルすると、プラットフォームごとに「マシンコード」をコンパイルする必要がある他の多くの言語とは異なり、これらのファイルを変更せずに Java 対応プラットフォームで使用できます。たとえば、32 ビット環境と 64 ビット環境で個別の「.exe」。
主に Windows 環境で使用される「ポータブル」の別の意味は、Java ランタイム環境をファイルシステムの任意の場所から実行でき、「インストール」する必要がないことを意味します。つまり、重要な情報をWindows レジストリ。これはほとんどの Java アプリケーションにも当てはまり、最初にアプリケーションをインストールしなくても、任意のコンピューターから USB フラッシュ ドライブなどの外部ストレージ デバイスを介して、さまざまなドライブ文字からアプリケーションを実行できます。
Java は、次の 3 種類の移植性を提供します。
ソース コードの移植性: 特定の Java プログラムは、基盤となる CPU、オペレーティング システム、または Java コンパイラに関係なく、同じ結果を生成する必要があります。
CPU アーキテクチャの移植性: 現在の Java コンパイラは、まだ存在しない CPU 用のオブジェクト コード (バイトコードと呼ばれる) を生成します。Java プログラムが実行される実際の CPU ごとに、Java インタープリターまたは仮想マシンが J コードを「実行」します。この存在しない CPU により、Java インタープリターが存在する任意の CPU 上で同じオブジェクト コードを実行できます。
OS/GUI の移植性: Java は、架空の OS および架空の GUI と対話する一連のライブラリ関数 (awt、util、lang などの Java 提供のライブラリに含まれる) を提供することで、この問題を解決します。JVM が仮想 CPU を提供するように、Java ライブラリは仮想 OS/GUI を提供します。すべての Java 実装は、この仮想 OS/GUI を実装するライブラリを提供します。これらのライブラリを使用して必要な OS と GUI 機能を提供する Java プログラムは、かなり簡単に移植できます。
C および C++ 言語の構文とセマンティックは標準化されていますが、非常に基本的なアプリケーションに限定しない限り、真のクロスプラットフォーム アプリケーションを作成することは非常に困難です。
これには、エンディアンから基本的なオペレーティング システムとの対話方法 (ウィンドウを開くなど) まで、高レベルおよび低レベルの理由がいくつかあります。
さらに、コンパイルの結果ではなく、C/C++ ソース コードのみが移植可能と見なすことができます。結果の実行可能コードとライブラリは、システム アーキテクチャ (たとえば、異なる CPU) とオペレーティング システムとの間に大きな違いがあるため、移植できません。
Java は、これらの問題の両方を解決する試みとしてかなり成功しています。
Java はコードをアセンブリにコンパイルするのではなく、より抽象的な「バイトコード」にコンパイルします。仮想マシン (JVM) によってアセンブリに「解釈」または「オンザフライで再コンパイル」される疑似アセンブリ言語です。バイトコードはほとんどが非常に低レベルの言語であるため、この変換は通常かなり効率的です。ARM プロセッサの一部のバージョンでは、バイトコードをネイティブに実行することさえできます。したがって、Java アプリケーションがコンパイルされると、その結果は「任意の」アーキテクチャで実行できます (そのマシンで JVM が使用できる場合)。
Java には、最も一般的なデータ構造 (特定のアーキテクチャに対して最も効率的な方法で JVM に実装されている) の広範な実装を提供するだけでなく、「ハードウェアおよびソフトウェアの抽象化レイヤー」も提供する非常に大きなランタイム ライブラリがバンドルされています。コーディング中に標準的な方法でシステムと対話できます。それを適切なアーキテクチャと OS 呼び出しに変換するのは JVM の仕事です。例として、Java は Swing フレームワークを提供します。これにより、システムに依存しない方法で GUI を作成できます。つまり、ウィンドウを開くと、Windows では Win32/MFC 呼び出しに、Linux では XWin 呼び出しに変換されます。
Javaにはさまざまな「タイプ」があると述べました。
ただし、Java アーキテクチャは相互運用性を可能にするように設計されていることに注意してください。特に、異なるバージョンや異なる「タイプ」用に構築されたライブラリを混在させることができるようになっています。
これは、マシンに JVM があれば、あるマシンで作成された Java プログラムが他のマシンで実行されることを意味します。
このリンクを参照してください。
移植性とは、異なるマシンでプログラムを実行できることを指します。特定のプログラムを異なるマシンで実行すると、さまざまな量の作業が必要になる場合があります (たとえば、まったく作業を行わない、再コンパイルする、ソース コードに小さな変更を加えるなど)。Java アプリケーションとアプレットを移植可能と呼ぶとき、それらは通常、アプリケーションとアプレットが変更 (再コンパイルやソース コードの微調整など) なしでさまざまな種類のマシンで実行されることを意味します。