Sto imparando sulla conversione del codice sorgente in codice macchina tramite i quadri .NET e JRE. Per iniziare ho fatto qualche ricerca confrontando i due processi e creato this diagram. Ho bisogno di aiuto per criticare la sua correttezza e, soprattutto, aggiungere le cose serie che ho perso per capire meglio il percorso di compilazione.In che modo Java Runtime Environment si confronta con il framework .NET in termini di processo di compilazione?
Sia .NET e Java compilare fino a bytecode, che è un linguaggio intermedio, che contiene le istruzioni per una macchina virtuale. Non è un codice macchina perché non può essere eseguito direttamente su una macchina fisica. Cosa succede invece (almeno oggi, Java ha una storia più oscura a questo riguardo) è che in fase di esecuzione viene eseguito un compilatore just-in-time che traduce le istruzioni della VM in codice nativo che viene poi eseguito direttamente. Questo ha un grande vantaggio nella performance solo interpretandolo.
Si differenziano un po 'in questo senso. Su ^H^H L'implementazione Java di Oracle utilizza un intelligente mix di interpretazione, misurazione e JIT che compila solo le parti che sono pesantemente utilizzate e interpretano diversamente. Ciò serve a ridurre l'impatto iniziale del compilatore JIT (che deve essere eseguito in anticipo altrimenti, allungando il tempo di avvio del processo) pur consentendo buone prestazioni laddove necessario. .NET d'altra parte sempre JIT-compila tutto il codice che viene usato (il codice non utilizzato non è compilato, però).
Come per una domanda che hai citato nei tuoi commenti: Sì, il CLR e la JVM sono le piattaforme su cui tali programmi sono eseguiti. Anche una macchina virtuale è una macchina, solo meno hardware-y. Entrambi sono strettamente integrati con un framework corrispondente, la Base Class Library per .NET e la libreria di classi Java per Java. Quelli sono quadri.
Potresti spiegare cosa intendi "In .NET un assembly è l'unità di compilazione"? – jesterII
Quello che vedi in Visual Studio in un singolo progetto viene compilato in un unico file '.exe' o' .dll' - l'assembly risultante. L'unità di compilazione si riferisce alla più piccola unità compilabile che diventa rilevante se si desidera eseguire la ricompilazione parziale, ad esempio. In Java dovresti semplicemente ricompilare le classi che sono cambiate, in .NET dovresti ricompilare un intero progetto. Intendiamoci, la differenza è trascurabile per la maggior parte dei casi - i compilatori per entrambe le piattaforme sono incredibilmente veloci, specialmente rispetto a C++. – Joey
+1 per la ricompilazione di .class Java. Non l'ho mai realizzato, ma dopo aver guardato la cartella obj, apparentemente .NET non separa il risultato dell'oggetto per ogni classe. Si possono separare le classi in librerie per ridurre la ricompilazione, ma Java separa esplicitamente ogni classe. – Martheen
Cosa intendi con "assemblatore" lì? Come sembra ora, non è sbagliato: CLR/JVM non genera assembly ma invece dirige il codice macchina. Almeno la JVM (non credo che CLR) possa generare assembly come sottoprodotto, ma questo è appena necessario. – Voo
@Voo, per assemblatore intendo un programma che converte l'assembly leggibile da un utente in codice macchina che l'architettura della cpu può comprendere. Vedo che questo potrebbe essere completamente ridondante nel processo. – jesterII
@EJP, Voo sta dicendo che JVM crea codice macchina, non il compilatore Java che genera codice byte. – jesterII