移植性とは何ですか？ Javaは他の言語よりも移植性が高いですか？
JavaはC、C++ 、. NETおよびその他の言語よりも移植性が高いのではないかと思います。Javaインタプリタにより移植性があることについて何度も読みましたとJVMですが、JVMはハードウェアのアーキテクチャの違いを隠すだけです。それでも、異なるマシンアーキテクチャには異なるJVMが必要です。ここで何が欠けているのでしょうか？それで、最も一般的なアーキテクチャのCの抽象化レイヤーを誰かが作成した場合、 CVMとしましょう。CVMがインストールされると、これらのアーキテクチャでCプログラムが実行されますよね。
この移植性は正確には何ですか？ .NETはポータブルと呼ぶことができますか？
可搬性は白黒ではありません。移植性とは、プログラムを取得して、関心のあるすべてのプラットフォーム上で実行することがいかに簡単かということです。
これに影響することがいくつかあります。 1つは言語自体です。 Java言語仕様では、通常、「実装」まではほとんどありません。たとえば、「i = i ++」はCおよびC++では未定義ですが、Javaでは定義されています。より実際的には、 "int"のような型は、Java（たとえば、intは常に32ビット）で特定のサイズを持ちますが、CおよびC++では、サイズはプラットフォームとコンパイラによって異なります。これらの違いだけでは、 CおよびC++で移植可能なコードを書くことを妨げるものではありませんが、はるかに勤勉である必要があります。
もう1つはライブラリです。 Javaには、CおよびC++にはない標準ライブラリがたくさんあります。たとえば、スレッド、ネットワーキング、GUIライブラリなどです。これらの種類のライブラリはCおよびC++に存在しますが、そうではありません利用可能な標準ライブラリと対応するライブラリの一部は、プラットフォームごとに大きく異なります。
最後に、実行可能ファイルを取得して他のプラットフォームにドロップし、そこで動作させることができるかどうかという問題がすべてあります。これは通常、ターゲットプラットフォームにJVMがあることを前提として、Javaで機能します。 （そして、人々が気にする多くの/ほとんどのプラットフォーム用のJVMがあります）これは一般的にCとC++には当てはまりません。通常はleastで再コンパイルする必要がありますが、これは前の2つのポイントをすでに処理していることを前提としています。
はい、「CVM」が複数のプラットフォームに存在する場合、CおよびC++の移植性が向上します。あなたはまだCコードを移植可能な方法で書く必要があります（例えば：標準が言うこと以外はintのサイズについて何も仮定していない）、またはCVMに書く必要があります（それがのための統一された決定をしたと仮定します）これらすべての種類のすべてのターゲットプラットフォームでの処理）また、非標準ライブラリ（ネットワーキング、スレッド化、GUIなし）の使用をやめるか、それらの目的のためにCVM固有のライブラリに書き込む必要があります。つまり、CとC++をより移植性の高いものにすることではなく、移植性のある特別なCVM-C/C++について話しています。
繰り返しになりますが、移植性は白黒のものではありません。 Javaを使用しても、非互換性が存在する可能性があります。GUIライブラリ（特にAWT）は、一貫性のない動作があることで悪名高く、スレッドが関係するものは、ずさんになると異なる動作をする可能性があります。ただし、一般に、 、ある重要なJavaプログラムを1つのプラットフォームで作成して別のプラットフォームで実行するのは、CまたはC++で作成したプログラムで同じことを行うよりもはるかに簡単です。
他の人がすでに述べたように、移植性はややあいまいな概念です。特定の観点から見ると、Cは実際にはJavaよりもmore移植可能です。 Cは、基盤となるハードウェアについてほとんど仮定していません。 1バイトが8ビットであると仮定したり、負の数を2の補数で表現したりすることも想定していません。理論的には、フォンノイマンベースのマシンとコンパイラがあれば、Cを使用してもかまいません。
実際、Cで書かれた「Hello world」プログラムは、Javaで書かれた「Hello world」プログラムよりも多くのプラットフォームで動作します。おそらく同じ "hello world"プログラムを PDP-11 とiPhoneで動作させることができます。
ただし、実際には、ほとんどのreal-worldプログラムは「Hello world」を出力するだけではありません。 Javaは、実際にはのため、Cよりも移植性が高いという評判があります。実際のCプログラムを別のCプログラムに移植するには、かなりの労力が必要です。実際のプラットフォームよりもプラットフォームJavaプログラム。
これは、C言語が実際にはANSI-Cであり、非常に汎用的な最小限の言語であるためです。ネットワークプログラミング、スレッド化、またはGUI開発はサポートされていません。したがって、これらのいずれかを含むプログラムを作成したらすぐに、Win32やPOSIXなど、移植性の低い拡張子をCにフォールバックする必要があります。
しかし、Javaでは、ネットワークプログラミング、スレッド化、およびGUIツールは言語によって定義され、各VM実装に組み込まれています。
とはいえ、最近のC/C++の移植性に関して、多くのプログラマーも過小評価していると思います。 POSIXはクロスプラットフォームスレッドの提供に大いに役立ちます。C++に関しては、Boostは基本的にJavaと同じように移植可能なネットワークライブラリとスレッドライブラリを提供します。これらのライブラリには、プラットフォーム固有の癖がありますが、Javaにもあります。
基本的に、Javaは、予測可能な方法でバイトコードを解釈するVM実装を持つ各プラットフォームに依存し、C/C++は、プラットフォーム固有のライブラリを使用します。プリプロセッサ（#ifdefs）。どちらの戦略でも、クロスプラットフォームのスレッド化、ネットワーキング、およびGUI開発が可能です。移植性に関しては、JavaがC/C++よりも速く進んだことです。Java言語仕様には、スレッド化、ネットワーキング、およびGUI開発がほぼ毎日行われていました一方、Boostネットワーキングライブラリは2005年頃に登場し、2011年にC++ 11で標準のポータブルスレッドがC++に含まれるようになりました。
Javaプログラムを作成すると、Windows、Linux、MacOSなど、JVMが記述されたすべてのプラットフォームで実行されます。
C++プログラムを作成する場合は、プラットフォームごとに具体的にコンパイルする必要があります。
Java "一度書くとどこでも実行できる"というモットーは神話だと言われています。多くのネイティブリソースとの対話を必要とするデスクトップアプリケーションでは、JavaEEアプリケーションごとに現在、私はWindowsで作業しており、他の同僚はLinuxで作業しています-何の問題もありません。
（移植性に関連するもう1つのことは、JavaEE（エンタープライズ版）です。JavaEEテクノロジーで作成されたアプリケーションは、JavaEE認定のアプリケーションサーバーで実行されると言われています。ただし、これは少なくともJavaEE6までは当てはまりません。（ こちらを参照） ））
移植性は、プログラムを元の場所とは別の環境で実行するための労力の尺度です。
これで、LinuxのJVMがWindowsの環境とは異なる環境であるかどうかについて議論することができます（そうですね）。
あなたが話しているCVMは、POSIXライブラリとランタイムライブラリが提供しようとしているものですが、実装の大きな違いにより、ハードルが高くなります。確かにMicrosoftとAppleの場合、これらはおそらく開発者が競合するプラットフォームに製品を持ち出さないようにするために意図的にそうしたものです。
.netの前面では、monoが提供するもの、つまりオープンソースの.Net実装に固執できれば、Javaとほぼ同じ種類の移植性を享受できますが、monoはWindowsバージョンよりも大幅に遅れているため、これは一般的な選択肢ではありません。 。これがサーバーベースの開発でどれほど人気があるかはわかりませんが、問題は少ないと思います。
Javaは開発者の観点から移植可能です。Javaで記述されたコードは、再コンパイルする必要なく、どの環境でも実行できます。Cは特定のOSに関連付けられているだけでなく、移植性がありません多くの場合、コンパイル後は常に特定のハードウェアアーキテクチャに関連付けられます。C++の場合も同様です。Netは仮想マシンにも依存しているため、C/C++よりも移植性が高く、コンパイル時の特定のハードウェアアーキテクチャ。ただし、公式にはWindowsマシンに限定されます。
あなたは正しい、JVMはプラットフォーム固有です（そうでなければなりません！）しかし、Javaは移植可能であるということは、開発者の立場と標準Java開発者はJVMを記述せず、使用します:-)。
編集 @ Raze2Dust質問に対処します。はい、できます。実際、バイトコードではなくマシンコードを生成するコンパイラを作成することで、Javaプラットフォーム固有にすることができます。しかし、他のコメントの一部が示唆しているように、なぜそうするのでしょうか？コンパイルされたコードを、JVMが機能するのと同じ方法で操作にマップするインタープリターを作成する必要があるので、その長短は間違いなく可能ですが、なぜそうするのでしょうか。
Javaは3異なるタイプの移植性を提供します。
ソースコードの移植性：特定のJavaプログラムは、基盤となるCPU、オペレーティングシステム、またはJavaコンパイラ。
CPUアーキテクチャの移植性：現在のJavaコンパイラは、まだ存在しないCPU用のオブジェクトコード（バイトコードと呼ばれる）を生成します。 Javaプログラムを実行する予定の実際のCPUごとに、Javaインタープリターまたは仮想マシンがJコードを「実行」します。この存在しないCPUにより、Javaインタープリターが存在するすべてのCPUで同じオブジェクトコードを実行できます。
OS/GUIの移植性：Javaは、一連のライブラリ関数（awtなどのJava提供のライブラリに含まれる）を提供することでこの問題を解決します、util、およびlang）は、架空のOSおよび架空のGUIと通信します。 JVMが仮想CPUを提供するのと同じように、Javaライブラリは仮想OS/GUIを提供します。すべてのJava実装は、この仮想OS/GUIを実装するライブラリを提供します。これらのライブラリを使用して必要なOSとGUI機能を提供するJavaプログラムは、かなり簡単に移植できます。
これを見てください リンク
「C VM」を書けるか尋ねます。ではない正確に。 「Java」は、プログラミング言語と仮想マシンの両方を含む多くのことを意味するためにSunが使用する大きな用語です。 "C"はプログラミング言語にすぎません。結果のバイナリの形式を決定するのはコンパイラとOSおよびCPUです。
Cは移植性があると言われることもある理由ランタイムを指定しない。コンパイラーを作成した人は、そのプラットフォームに適したものを選ぶことができました。欠点は、Cは十分に低レベルであり、プラットフォームは十分に異なるため、Cプログラムが1つのシステムで正常に機能し、別のシステムではまったく機能しないことはよくあることです。
C言語を特定のABIと組み合わせる場合は、JVMに類似したVMを定義できます。たとえば、次のようなものはすでにいくつかあります。
- 「インテルバイナリ互換性仕様」は、そのようなABIの例です（現在、ほとんど誰も使用していません）。
- 「Microsoft Windows」は、このようなABI（巨大で仕様が不十分なもの）である可能性もあります。そのため、Wineは1つですVMそれのために書かれたプログラムを実行します
- 「MS-DOS」、dosemuは1つのVM
- "Linux"は今日最も人気のあるものの1つであり、そのプログラムはLinux自体で実行できます NetBSD 、または FreeBSD
- "PA-RISC" -- HPのDynamo はJITのようなVMでした
これらすべてのC VMは、実際には実際のマシンです-AFAIKは、C VMこれは純粋に仮想的なものでした。これは驚くべきことではありません。 HPが示したように、JITを作成して、同じプラットフォーム上でもコードをより効率的に実行できます。
移植性、またはWikipediaで記述されている Software Portability は、複数の環境（OS）で同じソフトウェア（コード）を再利用する機能です。 Java JVMは、JVMであり、Windows、Linux、Mac OSなどのために設計された任意のオペレーティングシステムで実行できます。
.NETでは、ソフトウェアをさまざまなプラットフォームに移植できます。 Wikipedia から：
.NET Frameworkの設計により、理論的にはプラットフォームに依存しないため、クロスプラットフォーム互換性があります。つまり、フレームワークを使用するように作成されたプログラムは、フレームワークが実装されているシステムのタイプを変更せずに実行する必要があります。
また、Microsoftは.NETフレームワークをWindowsの外部に実装したことがなく、.NETがプラットフォームに依存しないことを確認したため、 Mono は.NETアプリケーションを実行し、コードをコンパイルしてLinuxで実行できるようにしました。
C++、Pascalなどの言語の場合、そのプラットフォームで実行するには、各OSにアクセスして、そのプラットフォームでビルドする必要があります。 WindowsのEXEファイルは、Linux（マシンコード）の.soとは異なります。これは、どちらも異なるライブラリを使用してカーネルと通信し、各OSには独自のカーネルがあるためです。
さまざまなアーキテクチャのJVMが必要ですが、もちろんJavaプログラムはそのJVMで）実行されますです。したがって、アーキテクチャのJVMを取得したら、Javaプログラムはそのアーキテクチャで利用できます。
Javaプログラムを記述し、Javaバイトコード（アーキテクチャに依存しない）にコンパイルして）できるので、どのJVMでも実行できますJVMは基盤となるアーキテクチャを抽象化し、私のプログラムは仮想マシン上で実行されます。
Java languageは移植可能です（より正確には、コンパイルされたバイトコードは移植可能です）。それぞれのVMは、特定のハードウェアプロファイルに特定の実装が必要です。ただし、その努力がなされると、all Javaバイトコードがそのプラットフォームで実行されます。 Java /バイトコードを1回使用すると、任意のJVMで実行されます。
.NETは非常によく似ていますが、原則はそれほど重視されていません。 CLRはJVMに類似しており、独自のバイトコードを持っています。 Monoは* nixに存在しますが、「公式」ではないことは間違いありません。
WORE-どこでも一度実行すると書き込み
実際には、これはJVMを備えたプラットフォームに限定されますが、これはデプロイしたいプラットフォームの大部分をカバーします。インタプリタ言語とコンパイル済み言語のほぼ中間にあり、両方の利点を享受しています。