21

Javaの利点は、人々がコードを記述し、JVM用にコンパイルして、どこでも実行できることだと聞いています。各人が必要とするのは、プラットフォーム用のJVMアプリだけです。

もちろん、それは現在の状況に似ており、誰もが自分のプラットフォームに固有のコンパイラを持っています。したがって、その利点はそれによって説明されません。しかし、私は説明を見ていると思います。問題は、Javaの状況では、OS固有の方法で実際のマシンに直接アクセスすることはできない、または意図されていないということであるに違いありません。

他の言語では、実行しているコンピューターに応じてコード自体を修正する必要があることを意味していると思います。

これを示すHelloWorldプログラムのように、誰かがこれの短い例を提供できますか？間違いなくそれは非Java、例えばCにあるでしょう

これは、Hello Worldプログラムで通常発生することではないため、またはJavaで使用した本以降に見たほとんどの場合、残念ながら「プログラミング方法」スタイルの本であり、その中のすべてのものはそうではありませんでした。それをデモンストレーションします（おそらく、Javaを使用してデモンストレーションすることができなかったか、または使用したくなかったのです！）。彼らはそれを大きなアドバンテージとして打ち負かしましたが。その例を見てみたいです。

4

8 に答える 8

10

...誰もが自分のプラットフォームに固有のコンパイラを持っています。したがって、その利点はそれによって説明されません。

たとえばCまたはC++で記述されたコードの移植は、ほとんどの場合、単にコードを再コンパイルするよりもはるかに複雑です。それは確かに、平均的な非開発者のコ​​ンピューターユーザーが簡単にできることではありません。コンパイルされた言語で記述されたコードは、特定のオペレーティングシステム（Win32 APIなど）のAPIに対して記述されることが多いため、他のオペレーティングシステムで簡単にコンパイルすることはできません。

Javaバイトコードは、Javaランタイム環境が利用可能なすべてのプラットフォームで実行されます。コードを再コンパイルする必要はありません。もちろん、オペレーティングシステム固有のコードをJavaで記述できますが、Javaの標準ライブラリ、およびWebで利用可能な多くの無料ライブラリは、非常に豊富なクロスプラットフォーム環境を提供します。

移植性に加えて、仮想マシンでの実行には他の利点があります。Javaは、JITコンパイラを使用して、実行時にJavaバイトコードをネイティブマシンコードにコンパイルします。JITコンパイラーは、プログラムが実行されている特定のCPUに対して高度な最適化を行うことができ、事前コンパイラーでは利用できないプロファイリング情報を使用できます。したがって、原則として、JITコンパイラーはより最適なコードを生成できます。 「通常の」コンパイラよりも。

Java VMの他に、他の仮想マシンがあります。たとえば、Microsoft .NETにはCLR（共通言語ランタイム）が含まれており、 LLVMもあります。LLVMには、CやC ++を含むさまざまな言語のフロントエンドがあります（JITコンパイルの利点をCやC ++にももたらすはずです）。 。

于 2010-07-11T19:42:34.307 に答える
3

重要なのは、Javaでは移植性のある便利なこともできるということです。CおよびC++では、ポインタ演算を実行し、intのサイズ（OSおよびCPUによって異なります）などを心配する必要がある場合があります。これを移植可能な方法で処理するための標準には修正がありますが、Javaは最初からこれを念頭に置いて設計されています。JVMには別の利点があると思います。jythonやscalaのようなものは、それらが独自の言語の一部であるかのように、広大なJavaライブラリ（およびその他の利用可能なJavaクラス）を使用できます。他のほとんどの言語では、さまざまな言語とインターフェイスする方法はC ABIを使用することですが、これはOOPの世界では多少制限があります。この意味で、javaは新しいCです。また、jvmは、ガベージコレクションとリフレクションなどの優れた機能を提供します。

于 2010-07-11T19:58:34.277 に答える
3

JITコンパイラのおかげでCPUアーキテクチャに依存せずにコードを実行できるJVMの利点に加えて、Javaの基本的な利点の1つは、プログラミング言語だけでなく、API共通のランタイム環境であるということです。それを実行できるすべての基盤となるプラットフォームに（時々いくつかの違いがありますが、それらはバグになる傾向があります）。

gcc（GNUクロスコンパイラ）たとえば、多かれ少なかれ任意のプラットフォーム用にCコードをコンパイルできます。原則として、通話の使用に限定されているものstdio.hやその他のいくつかの場合は問題ありません。ただし、もう少しOS固有のものを使用しようとすると、すぐに問題が発生します。これは、GUI、一部のI / O、スレッド、プロセス、ネットワークなど、非常に速く表示される傾向があります。

Cコードにまたは類似のものを取得したらすぐに#include <win32.h>、コードの一部を書き直してLinux / OSXプラットフォームに移植する必要があります。この作業の一部は、明白でないか、直接不可能な場合があります。

Javaの利点は、仮想マシンと、任意のプラットフォームで同じバイトコードを読み取って実行できることだけでなく、JRE（J2SEなど）の一部としてのかなり大きなライブラリと、共通のスレッド化およびネットワーキングの可用性でもあります。モデル。

于 2010-07-11T20:03:02.710 に答える
3

もちろん、それは現在の状況に似ており、誰もが自分のプラットフォームに固有のコンパイラを持っています。

理解する必要があるのは、プラットフォームごとに固有のコンパイラがある場合でも、言語がわずかに異なること（gccコンパイラ以外ではまれなまったく同じコンパイラでない限り）、およびプラットフォームがプログラムであることです。 seeは大きく異なります。「ああ、ここには64ビット整数があるので、グラフィックスなどを行うにはX11を使用する必要があります」。これらをコードで処理する必要があります。プログラムにこれらの違いを指定する構成（automake）を処理するためだけにかなり大きなGNUプロジェクトが存在するという事実は、これが些細なことではないことを示しているはずです。

JVMによって提供されるプラットフォームははるかに厳密に指定されており、プログラムはそれらすべてで同じように動作します。整数があふれていますか？ああ、それはこれを行うことを意味し、それを無視します。これは非常によく行われているため、すべてのJVMで同じように機能することが期待され、障害は開発マシンとデプロイメントマシンのプラットフォームの違いによるものではありません。常に外部の理由を最初に探しますが、JVMにバグが見つかったのはごくまれなケースです。非常によく設計された作品。

于 2010-07-11T20:31:08.670 に答える
2

私にとっての主な利点は、ライブラリの移植性です。ライブラリ間でバージョンの依存関係がある場合がありますが、それ以外は、JARが機能します。

いわゆるクラスローダー地獄がありますが、それはそれほど一般的ではありません。

他のほとんどの言語では、正しいライブラリバイナリを見つけるか、ソースをダウンロードしてインストールする必要があります。

于 2010-07-11T21:45:14.513 に答える
1

あなたが移植の問題について話していると思います。実際、JVMは人気のある文献で話されていることであり、Javaがコードの移植の必要性を排除することは少し微妙です。

遠くを見る必要はありません。この正確な理由から、WindowsからUNIXへのコード移植開発者（およびその逆）の小さな業界が存在します。例が欲しいですか？Cの近く、遠くのポインターのようなものはどうですか？または、__ declspec（dllexport）を使用してWindows固有のdllを作成しますが、gccにはこれがなく、-sharedオプションが必要ですか？

最も困難なシナリオの1つは、特にQTが登場する前にC++ベースのGUIを実行することでした。GUIのロードは引き続き.NETで実行され、レガシーコードはMFCで実行され、Linux/UNIXの場合は多くのレガシーコードがXWindowsで実行されます。このような場合、Javaは天の恵みです。ほとんどのものは、プラットフォーム間で車輪の再発明をしなくても機能します。

于 2010-07-11T19:17:44.057 に答える
0

主に携帯性。同じJavaバイナリをLinux/Mac/Windowsで実行できます。さらに、SPARC / PPC / x86 / x86-64 / ARM / MIPSなど。読み取り：同じバイナリ。再コンパイルは必要ありません。:)

于 2010-07-11T21:48:32.857 に答える
0

私はいくつかの答えをまとめました。

私はそれらをテストしていませんが..私は答えの中から、私にとって意味のある素晴らしい例を見ます

ブルーノはCで例を提供しました

#include <win32.h>（OS固有の行とコードは別のOS用に書き直す必要があります）stdio.hおよびその他のいくつかの呼び出しの使用に制限されているもの（移植可能）

ゲイリー、intのケースについて話しました。Cでは、「intは32ビットボックスでは32ビットです。64ビットボックスでは64ビットです」「移植可能な方法はint32_tを使用することです」と、Cとアセンブリ言語についてのポイントです。周りを見て、制限を超えると0に戻ることがわかりました。したがって、コードが別のシステムに別の影響を及ぼし、コンパイルしているが、おそらく意図したとおりに機能していない場合であり、書き直しました。

Thorbjørnは、さまざまなCPUでのアセンブリ言語の例へのリンクを提供しました。32ビットCPUの場合はWin32ASM、64ビットの場合はWin64。それぞれにhelloworldの例があり、「Win32ではすべてのパラメーターがスタックを介して渡されますが、Win64ではレジスターを介して渡されるため、変換するのは簡単ではありません」と述べています。彼はそれが異なる命令を使用していると言いました..それが異なるアセンブリ言語である場合、アセンブリ言語が移植性のない明らかなケースであるという意味で、おそらくそれ以上だと思います..したがって、私はそれについて言及しませんでした質問ですが、そのリンクで例を見るのは良いことです。そして、持っていることは良い知識です。機械を曖昧にしない現代のアセンブリ言語を見るのは良いことです。

于 2010-07-17T19:03:18.177 に答える