ここで、JVM で実行される Java 以外の言語が多数あることがわかります。私は、JVM で実行される他の言語の概念全体について少し混乱しています。そう：
JVM に他の言語を使用する利点は何ですか?
JVM 用の言語/コンパイラを作成するには、(大まかに言えば) 何が必要ですか?
JVM で (Java 以外の) 言語でコードをどのように記述/コンパイル/実行しますか?
編集:承認された回答で回答された 3 つのフォローアップの質問 (元のコメント) がありました。読みやすくするために、ここに転載します。
たとえば、JPython で作成されたアプリは、Java アプリとどのようにやり取りするのでしょうか?
また、その JPython アプリケーションは JDK 関数/オブジェクトのいずれかを使用できますか??
Jaskell コードの場合、それが関数型言語であるという事実は、JDK との互換性を失わないのでしょうか?
3 つの質問に個別に対処するには:
JVM に他の言語を使用する利点は何ですか?
ここには2つの要因があります。(1) JVM に Java 以外の言語を使用する理由、および (2) JVM で別のランタイムではなく別の言語を実行する理由
JVM 用の言語/コンパイラを作成するには、(大まかに言えば) 何が必要ですか?
JVM は、バイトコード (.class) ファイルを読み取って、実行する必要のある命令を取得します。したがって、JVM で実行する言語はすべて、 Sun の仕様に準拠したバイトコードにコンパイルする必要があります。このプロセスは、ネイティブ コードへのコンパイルと似ていますが、CPU が理解する命令にコンパイルするのではなく、JVM が解釈する命令にコードをコンパイルする点が異なります。
JVM で (Java 以外の) 言語でコードをどのように記述/コンパイル/実行しますか?
Java でコードを記述/コンパイル/実行する方法とほとんど同じです。足を濡らすには、JVM 上で問題なく動作するScalaを調べることをお勧めします。
フォローアップの質問に答える:
たとえば、JPython で作成されたアプリは、Java アプリとどのようにやり取りするのでしょうか?
これは、言語のギャップを埋めるという実装の選択に依存します。あなたの例では、Jython プロジェクトにはこれを行うための簡単な手段があります (こちらを参照)。
from java.net import URL
u = URL('http://jython.org')
また、その JPython アプリケーションは JDK 関数/オブジェクトのいずれかを使用できますか?
はい、上記を参照してください。
それが Jaskell コードである場合、それが関数型言語であるという事実は、JDK との互換性を失わないでしょうか?
いいえ。たとえば、Scala (上記のリンク) は、Java との互換性を維持しながら機能的な機能を実装します。例えば：
object Timer {
def oncePerSecond(callback: () => unit) {
while (true) { callback(); Thread sleep 1000 }
}
def timeFlies() {
println("time flies like an arrow...")
}
def main(args: Array[String]) {
oncePerSecond(timeFlies)
}
}
一般に複数のプログラミング言語が必要なのと同じ理由で、JVMには他の言語が必要です。さまざまな問題を解決するには、さまざまな言語の方が適しています...静的型付けと動的型付け、厳密と怠惰...宣言型、必須、オブジェクト指向...など。
一般に、JVM（または.Net CLR）で実行する別の言語の「コンパイラ」を作成することは、基本的に、アセンブリではなく、その言語をJavaバイトコード（または.Net、ILの場合）にコンパイルすることです。 /machine言語。
とはいえ、JVM用に作成されている追加の言語の多くはコンパイルされておらず、スクリプト言語として解釈されています...
これをひっくり返して、新しい言語を設計し、それを JIT と GC を使用してマネージド ランタイムで実行したいとします。次に、次のことができると考えてください。
(a) 独自のマネージド ランタイム (VM) を作成し、多くのバグ、パフォーマンスの低下、不適切なスレッド化、多大な移植作業につながる可能性のあるあらゆる種類の技術的に困難な問題に取り組む
また
(b) 言語をコンパイルして、Java VM で実行できるバイトコードを作成します。このバイトコードは、すでに成熟しており、高速で、多くのプラットフォームでサポートされています (複数のベンダー実装の選択肢がある場合もあります)。
JavaVM バイトコードは、実装できる言語の種類を過度に制限するほど Java 言語と密接に結びついていないため、VM で実行する言語のターゲット環境として人気があります。
Java は非常に冗長なプログラミング言語であり、過去 5 年間に登場した新しいファンシーな言語/フレームワークのすべてで非常に急速に時代遅れになっています。人々が言語で必要とするすべての高度な構文をサポートし、下位互換性を維持するには、ランタイムに言語を追加する方が理にかなっています。
もう 1 つの利点は、Ruby、JRuby (別名 Rails)、または Grails (Groovy on Railys) などで記述された Web フレームワークを、多くの企業で既に運用されている可能性が高い実証済みのホスティング プラットフォームで実行できることです。それを使用して、試行錯誤されたRubyホスティング環境とはほど遠いものです。
他の言語をコンパイルするには、Java バイトコードに変換するだけです。
私は「 Javaはダメだから」と答えますが、それでも、おそらくそれはあまりにも明白です…;-)
JVM に他の言語を使用する利点は、コンピューターに一般的に他の言語を使用する利点とまったく同じです。すべてのチューリング完全言語は技術的に同じタスクを達成できますが、一部の言語は他の言語よりも簡単なタスクを実行し、他の言語は他の言語よりも簡単に実行できます。他のタスクをより簡単に。JVM はすでにすべての (ほぼすべての) コンピュータで実行できる機能を備えているため、多くのコンピュータで実際に既に使用されているため、「一度書けばどこでも実行できる」というメリットを得ることができますが、必要な要件はありません。それはJavaを使用しています。
JVM 用の言語/コンパイラを作成することは、実際のマシン用に作成することと実際には違いはありません。本当の違いは、マシンの実行可能コードではなく、JVM のバイトコードにコンパイルする必要があることですが、それは物事の全体的なスキームにおける小さな違いです。
JVM で Java 以外の言語のコードを作成することは、Java を作成することと実際には違いはありませんが、もちろん、別の言語を使用することになります。誰かが書いたコンパイラを使ってコンパイルし (繰り返しますが、基本的には C コンパイラとあまり変わらず、Java コンパイラとほとんど変わりません)、最終的にはそれを実行するだけで済みます。 Javaコードをコンパイルするのと同じように、バイトコードになると、JVMはそれがどの言語から来たのかを知ることができません.
さまざまな言語がさまざまなタスクに合わせて調整されています。一部の問題ドメインは Java 言語に完全に適合しますが、別の言語で表現する方がはるかに簡単なドメインもあります。また、Ruby や Python などに慣れているユーザーにとっては、Java バイトコードを生成し、JDK クラスと JIT コンパイラを利用できることには明らかな利点があります。
2番目の質問に答える：
JVM は単なる抽象的なマシンであり、実行モデルです。したがって、コンパイラでターゲットにすることは、ハードウェア (x86、CELL など) またはソフトウェア (オウム、.NET) で実装されている場合でも、コンパイラがターゲットにする可能性のある他のマシンおよび実行モデルとまったく同じです。JVM は非常に単純なので、実際にはコンパイラーにとって非常に簡単なターゲットです。また、実装にはかなり優れた JIT コンパイラ (javac が生成するお粗末なコードを処理するため) が含まれている傾向があるため、多くの最適化について心配する必要なく、優れたパフォーマンスを得ることができます。
いくつかの注意事項が適用されます。まず、JVM は Java のモジュールと継承システムを直接具現化するため、他のこと (複数の継承、複数のディスパッチ) を実行しようとすると、扱いにくく、複雑なコードが必要になる可能性があります。次に、JVM は、javac が生成する種類のバイトコードを処理するように最適化されています。これとは非常に異なるバイトコードを生成すると、JIT コンパイラ/JVM の奇妙なコーナーに入る可能性が高く、せいぜい非効率的です (最悪の場合、JVM をクラッシュさせるか、少なくとも誤った VirtualMachineError 例外を与える可能性があります)。
JVMが実行できることは、ソース言語ではなく、JVMのバイトコード（.classファイルにあるもの）によって定義されます。したがって、高レベルのソースコード言語を変更しても、使用可能な機能に大きな影響はありません。
JVM用のコンパイラを作成するために必要なことに関しては、実際に行う必要があるのは、正しいバイトコード/.classファイルを生成することだけです。代替コンパイラの種類を使用してコードを記述/コンパイルする方法は、問題のコンパイラによって異なりますが、コンパイラが.classファイルを出力した後、それらを実行することは、javacによって生成された.classファイルを実行することと同じです。
これらの他の言語の利点は、多くの Java ライブラリに比較的簡単にアクセスできることです。
Java ユーザーにとってのメリットは、言語によって異なります。それぞれの言語には、Java コーダーに優れている点を伝えるストーリーがあります。JVM ベースのアプリに動的スクリプトを追加するために使用する方法を強調する人もいれば、言語が使いやすく、構文が優れているなどについて話す人もいます。
必要なのは、他の言語コンパイラを作成する場合と同じことです。解析して AST を作成し、それをターゲット アーキテクチャの命令 (バイト コード) に変換し、正しい形式 (.class ファイル) で保存します。
ユーザーの観点からは、コードを記述してコンパイラ バイナリを実行するだけで、Java コンパイラが生成するファイルと混合できる .class ファイルが生成されます。
.NET 言語は、実際の有用性というよりも見せびらかすためのものです。各言語は非常に解体されているため、すべて C# であり、新しい顔をしています。
Java VM に代替言語を提供する理由はさまざまです。
JSR プロセスが Java をますます死んでレンダリングしているため: http://www.infoq.com/news/2009/01/java7-updated
メンバーが実装について合意できないという理由だけで、Closures のような本質的で長く知られている追加でさえ追加されないのは残念です。
Java は、7 つのメジャー バージョン (1.0 から 1.6) にわたって膨大なユーザー ベースを蓄積してきました。本番環境で実行される無数の数百万行の Java コードの下位互換性を維持する必要があるため、その進化能力は制限されています。
Java は次のように進化する必要があるため、これは問題です。
下位互換性の要件は、競争力を維持するための障壁です。
Java と C# を比較すると、Java は、成熟した本番環境に対応したライブラリとフレームワークで有利ですが、言語機能と市場シェアの増加率の点で不利です。これは、1 世代離れた 2 つの成功した言語を比較した場合に期待されることです。
どの新しい言語にも、Java と比較して C# と同じ長所と短所があります。言語機能の利点を最大化し、成熟したライブラリとフレームワークの欠点を最小限に抑える 1 つの方法は、既存の仮想マシン用の言語を構築し、その仮想マシン用に記述されたコードと相互運用できるようにすることです。これが、Groovy と Clojure のささやかな成功の背後にある理由です。そしてScalaの興奮。JVM がなければ、これらの言語は非常に専門化された市場セグメントで小さなニッチを占めることしかできなかったでしょうが、JVM があれば、主流のかなりのニッチを占めることになります。
コンパイラ作成者が JVM または CLR バイトコードを生成する方がはるかに簡単です。それらは、どの機械語よりもはるかにクリーンで高レベルの抽象化です。このため、これらの VM アーキテクチャの 1 つをターゲットにするだけで、その言語で使用できる一連のツールとライブラリが既に用意されているため、新しい言語の作成を実験することがこれまで以上に実現可能になります。これにより、言語設計者は必要なサポート インフラストラクチャよりも言語に集中できます。
彼らは.Netに遅れずについていくためにそれをします。.Net では、C#、VB、J# (以前)、F#、Python、Ruby (近日公開予定)、および c++ を使用できます。私はおそらくいくつかを逃しています。スクリプト作成者にとっては、おそらくその中の大きなものは Python です。
その理由は、JVM プラットフォームには多くの利点があるからです。
Sun が Scripting 仕様でサポートしようとしている言語 (Python、Ruby など) は、主に生産性が向上していると認識されているため、次々と登場しています。Jython を実行すると、理論的には生産性が向上し、Python の機能を活用してPythonに適した問題を解決できますが、ランタイム レベルで既存のコードベースと統合することもできます。PythonとRubyの従来の実装は、 Cライブラリに対して同じ機能をもたらします。
さらに、Java よりも動的言語で表現する方が簡単な場合がよくあります。この場合は、別の方法を使用できます。JavaからPython/Rubyライブラリを使用します。
パフォーマンス ヒットはありますが、多くの人は、コードベースがより簡潔で明確になるのと引き換えに、それを喜んで受け入れます。
ある程度、それはおそらく .NET CLR に対する「軍拡競争」です。
しかし、JVM に新しい言語を導入する真の理由もあると思います。特に、それらが「並列」で実行される場合は、適切な言語を適切な仕事に使用できます。Groovy のようなスクリプト言語は、まさにあなたが必要としているものかもしれません。通常の古い Java はビジネス ロジックに適しています。
新しい言語/コンパイラを書くために何が必要かについて話すために、より資格のある人を残すつもりです.
コードの書き方はいつものようにnotepad/viで！(または、簡単な方法で実行したい場合は、その言語をサポートする開発ツールを使用してください。) コンパイルには、言語を解釈してバイトコードにコンパイルする特別なコンパイラが必要です。
Java も技術的にバイトコードを生成するため、それを実行するために特別なことをする必要はありません。