私は.NETとJREフレームワークを介して、ソースコードからマシンコードへの変換について学んでいます。まず、2つのプロセスを比較していくつかの調査を行い、this diagramを作成しました。その正しさを批判する上で助けが必要であり、さらに重要なことは、編集経路をより良く理解するために忘れた深刻な事柄を追加することです。Javaランタイム環境と.NETフレームワークの比較は、コンパイルプロセスの面でどのように行われますか？
.NETとJavaの両方がバイトコードにコンパイルダウン、それは仮想マシンのための手順が記載されていた中間言語です。物理マシン上では直接実行できないため、マシンコードではありません。その代わりに何が起きるか（今日では、Javaはこれに関してより暗い歴史を持っています）は、実行時にジャストインタイムコンパイラが実行され、VM命令をネイティブコードに変換して直接実行します。これはそれを解釈するだけではなく、大きなパフォーマンス上の利点があります。
この点で少し違います。 Su ^H^H OracleのJava実装では、使用頻度の高い部分とそれ以外の場合に解釈する部分だけを解釈、測定、およびJITコンパイルするという巧妙な組み合わせが使用されています。これは、JITコンパイラによる初期の影響を軽減するため（必要に応じて先行して実行する必要があるため、プロセスの起動時間を長くする必要があります）、パフォーマンスを向上させるためです。一方、.NETは常に使用されているすべてのコードをJITコンパイルします（使用されていないコードはコンパイルされません）。
あなたのコメントであなたが言ったように：はい、CLRとJVM はです。このようなプログラムは実行されます。仮想マシンもマシンであり、ハードウェアはほんの少ししかありません。どちらも、対応するフレームワークである.NET用のBase Class LibraryとJava用のJavaクラスライブラリと緊密に統合されています。それらはフレームワークです。
".NETではアセンブリはコンパイル単位です"という意味を教えてください。 – jesterII
Visual Studioで単一のプロジェクトに表示される内容は、結果のアセンブリである '.exe'または' .dll'にコンパイルされます。コンパイル単位とは、最小のコンパイル可能な単位を指します。たとえば、部分的な再コンパイルを実行する場合は、関連性があります。 Javaでは、変更されたクラスを再コンパイルするだけで済みます。.NETでは、プロジェクト全体を再コンパイルする必要があります。ほとんどの場合、その違いはごくわずかです。両方のプラットフォームのコンパイラは、特にC++に比べて、非常に高速です。 – Joey
Java .class再コンパイルの場合+1。私はそれを実現することはありませんでしたが、objフォルダを見た後、明らかに.NETは各クラスのオブジェクト結果を分離しません。再コンパイルを減らすためにクラスをライブラリに分けることができますが、Javaは明示的に各クラスを分離します。 – Martheen
「アセンブラ」とはどういう意味ですか？ CLR/JVMはアセンブリを生成せず、代わりにマシンコードを直接指示します。少なくともJVM（私はCLRとは思えません）は副産物としてアセンブリを生成することができますが、それはほとんど必要ありません。 – Voo
アセンブラによる@Vooとは、人が読めるアセンブリを、CPUアーキテクチャが理解できるマシンコードに変換するプログラムを意味します。私は、これがプロセス中で完全に冗長であるかもしれないことが分かります。 – jesterII
@EJP、Vooは、JVMがバイトコードを生成するJavaコンパイラではなくマシンコードを作成すると言っています。 – jesterII