Quali sono i vantaggi dell'utilizzo della compilazione della macchina virtuale (ad esempio JVM) sulle lingue nativamente compilate?

Question

Ho sentito che il vantaggio di Java è che le persone possono scrivere il codice, compilarlo per il JVM, ed eseguirlo ovunque. Ogni persona ha solo bisogno di un'app JVM per la loro piattaforma.

Certo, sembra simile alla situazione attuale, dove tutti hanno un compilatore specifico per la loro piattaforma. Quindi il vantaggio non è spiegato da quello. Ma penso di vedere la spiegazione .. La questione deve essere che nella situazione Java, non è possibile o non doveva accedere alla macchina reale direttamente in un modo specifico del sistema operativo.

Suppongo che significhi che in altre lingue, il codice stesso deve essere modificato a seconda di quale computer è in esecuzione.

Qualcuno può fornire brevi esempi di questo come un programma Hello World che lo dimostra? Senza dubbio essere in non-java ad es. C

Dal momento che non è qualcosa che non accada - accadere in un programma Hello World o la maggior parte che ho visto dai libri che ho usato su Java, purtroppo sono stati "come programmare" libri stile, e tutte le cose in loro Non lo ha dimostrato (forse "perché non potevano o non volevano usare Java per dimostrarlo!). Sebbene lo trombavano come un grande vantaggio. Mi piacerebbe vedere gli esempi di esso.

Answer 1

Ho messo insieme alcune delle risposte ..

Mentre non gli ho testato .. Vedo alcuni esempi che hanno senso per me, dall'interno delle risposte, di

Bruno ha fornito un esempio in C

#include <win32.h> (una linea specifica del sistema operativo e il codice dovrebbero essere riscritti per un sistema operativo diverso) Tutto ciò che è limitato all'utilizzo delle chiamate in stdio.h e pochi altri (sono portatili)

Gary, ha parlato di un caso con int. Quello in c, "un int è a 32 bit su una scatola a 32 bit. 64-bit su una scatola a 64 bit" "Il modo portatile è quello di usare INT32_T" e un punto sul linguaggio C e del linguaggio di assemblaggio. intorno e ha scoperto che se ritieni il limite, torni a 0. Quindi, sarebbe un caso di codice avente un effetto diverso su un diverso sistema e compilazione, ma forse non funziona come previsto e dover essere riscritto.

Thorbjørn ha fornito un collegamento agli esempi di linguaggio di assemblaggio su diverse CPU. Win32 ASM per CPU a 32 bit e Win64 per 64 bit. Ha un esempio di Hello World in ciascuno, e dice che non è facile convertirli, poiché "In Win32, tutti i parametri vengono passati tramite la pila, tuttavia in Win64 sono passati tramite i registri". Ha detto che usa diverse istruzioni .. Immagino tu forse è più di quello, nel senso che se è un linguaggio di assemblaggio diverso .. e il linguaggio di assemblaggio è un caso ovvio di non portabilità .. Quindi non l'ho detto nella domanda, ma è bello vedere gli esempi in quel link. Ed è buona conoscenza avere. Buono a vedere alcuni lingue di montaggio contemporanea non oscurando macchine ..

Answer 2

.

... dove ognuno ha un compilatore specifico per la loro piattaforma. Quindi il vantaggio non è spiegato da quello.

Codice di porting scritto per esempio C o C ++ è quasi sempre MOLTO più coinvolto rispetto al semplice ricompilazione del codice. Non è certamente qualcosa che un utente medio di computer non sviluppatore può fare facilmente. Il codice scritto nelle lingue compilato è molto spesso scritto contro l'API di un sistema operativo specifico (l'API Win32, ad esempio) e quindi non può essere facilmente compilato su altri sistemi operativi.

Java Bytecode viene eseguito su qualsiasi piattaforma in cui è disponibile un ambiente di runtime Java. Il codice non deve essere ricompilato. Foourse È possibile scrivere il codice specifico del sistema operativo in Java, ma la libreria standard di Java e le numerose librerie gratuite disponibili sul Web, forniscono un ambiente a piattaforma multipiattaforma molto ricco.

Oltre alla portabilità, in esecuzione su una macchina virtuale ha altri vantaggi. Java utilizza un jit compiler per compilare Bytecode Java al codice della macchina nativo in runtime. Il compilatore JIT può fare ottimizzazioni sofisticate per la CPU specifica che il programma è in esecuzione e può utilizzare le informazioni di profilazione che non sarebbero disponibili per un compilatore in anticipo - in linea di principio, un compilatore JIT può quindi produrre un codice più ottimale di un compilatore "normale".

Oltre alla Java VM, ci sono altre macchine virtuali. Ad esempio, Microsoft .net contiene il CLR (Runtime della lingua comune) E c'è anche llvm , che ha front-end per molte lingue diverse tra cui C e C ++ (e che dovrebbe portare i vantaggi di Compilazione JIT anche a C e C ++).

Answer 3

Oltre ai vantaggi del JVM che ti consentirà di eseguire il codice indipendentemente dall'architettura della CPU con prestazioni ragionevoli grazie al jit-compiler, un vantaggio fondamentale di Java è che non è solo un linguaggio di programmazione, ma un ambiente di runtime con Un API comune a tutte le piattaforme sottostanti su cui può essere eseguita (ci sono alcune differenze occasionalmente, ma tendono ad essere insetti).

GeneracodictagCode (GNU Cross Compiler), ad esempio, ti consente di compilare il codice C per più o meno qualsiasi piattaforma. Va bene in linea di principio per tutto ciò che è limitato all'utilizzo delle chiamate in gcc e alcuni altri. Tuttavia, ti imbatterai nei guai abbastanza rapidamente non appena si tenta di usare qualcosa di un po 'più specifico del sistema operativo, il che tende a appare abbastanza rapidamente: GUI, alcuni I / O, filettatura, processi, networking.

Non appena si ottiene un stdio.h o simile nel codice C, dovrai riscrivere parti del codice per portarlo a una piattaforma Linux / OSX, alcuni di questi lavori potrebbero non essere ovvi o direttamente possibili. < / P >.

Il vantaggio di Java non è solo la sua macchina virtuale e la capacità di leggere ed eseguire lo stesso bytecode su qualsiasi piattaforma, è anche la disponibilità di una biblioteca piuttosto ampia come parte del JRE (ad esempio J2SE) e un comune filettatura e modello di rete.

Answer 4

Penso che il punto sia quello su Java puoi fare cose utili anche che sono portatili.In C e C ++, a volte si finisce per dover fare il puntatore aritmetico e preoccuparti quali sono le dimensioni degli intercetti (variano da sistema operativo e CPU) e tali.Ci sono correzioni negli standard per affrontare quello in modo portatile, ma Java è stato progettato in mente fin dall'inizio.C'è un altro vantaggio del JVM, penso.Cose come Jython e Scala sono in grado di utilizzare le vaste librerie Java (e qualsiasi altra classe Java disponibile) come se fossero parte della loro lingua.Nella maggior parte delle altre lingue, il modo di interfacciarsi con diverse lingue è usando il C ABI, che è in qualche modo limitativo in un mondo oop.In questo senso, Java è la nuova C. Inoltre, il JVM offre la raccolta e la riflessione della spazzatura e le cose così belle.

Answer 5

.

certo, sembra simile al situazione attuale, dove tutti hanno un compilatore specifico per loro Piattaforma.

La cosa che devi capire è che anche se c'è un compilatore specifico per ogni piattaforma, le lingue sono leggermente diverse (a meno che non sia esattamente lo stesso compilatore, che è raro per gli altri rispetto al compilatore GCC) e Piattaforma I programmi vedi sono molto diversi. "Oh, abbiamo numeri interi a 64 bit qui, e devi usare x11 per fare grafici ecc. Ecc.". Devi gestire queste cose nel codice, e solo il fatto che esiste un progetto GNU piuttosto grande solo per gestire la configurazione di specificare queste differenze ai programmi (Automake) dovrebbe indicare che questa non è una questione banale.

La piattaforma fornita da un JVM è specificata molto più rigidamente, e i tuoi programmi comportano stesso su tutti loro. I numeri interi traboccanti? Oh, questo significa farlo e ignoralo. ecc. Questo è così ben fatto che è previsto che le cose funzionano allo stesso modo su tutti i JVM e che i guasti non sono dovuti alle differenze di piattaforma tra macchine per lo sviluppo e la distribuzione. Guardi sempre prima per qualche motivo esterno e solo nei casi più rari trovi un bug nel JVM. Un pezzo di lavoro molto ben progettato.

Answer 6

Il vantaggio principale, per me, è la portabilità della biblioteca.Le biblioteche potrebbero avere dipendenze di versione tra loro, ma, a parte questo, un barattolo funziona solo.

là è il cosiddetto Classloader Hell, ma non è così comune.

Nella maggior parte delle altre lingue, devi trovare la corretta biblioteca binary, oppure devi scaricare le fonti per installarla.

Answer 7

Indovina che stai parlando di problemi di porting.Infatti JVM è ciò di cui è parlato nella letteratura popolare, che Java elimina la necessità che il porting del codice sia un'ombra più sottile.

Non devi sembrare troppo lontano.Una piccola industria di Windows per gli sviluppatori di porting del codice UNIX [e viceversa] esistono per questa precisa ragione.Vuoi esempi?Che ne dici di cose come quelle vicine, lunghe puntatori in c?Oppure usando __declspec (DLLEXPORT) per creare una DLL specifica di Windows mentre GCC non avrà nulla e hai bisogno di fare l'opzione?

Uno degli scenari più difficili è stato con la GUI basata su C ++ in particolare prima che il QT sia nato in esistenza.I carichi di GUI sono ancora fatti su .NET, il codice legacy è su MFC e per Linux / UNIX un sacco di codice legacy è in XWindows.Java è un Godsend in tali casi: la maggior parte delle cose funzionerà senza reinventare la ruota su piattaforme.

Answer 8

Portabilità principalmente.Lo stesso java binario può funzionare su Linux / Mac / Windows.Plus SPARC / PPC / X86 / X86-64 / Braccio / MIPS ecc. Leggi: stesso binario.Nessuna ricompilazione necessaria.:)