Perché abbiamo bisogno di altre lingue JVM

Question

Vedo here che ci sono un carico di lingue oltre a Java eseguito sulla JVM. Sono un po 'confuso sull'intero concetto di altre lingue in esecuzione nella JVM. Quindi:

Qual è il vantaggio di avere altre lingue per JVM?

Cosa è richiesto (in termini di alto livello) per scrivere un linguaggio/compilatore per JVM?

Come scrivere/compilare/eseguire codice in una lingua (diversa da Java) nella JVM?

---

EDIT: C'erano 3 follow-up domande (originariamente commenti) che hanno ricevuto risposta nella risposta accettata. Sono qui ristampati per la leggibilità:

Come un'app scritta in, per esempio, JPython, interagisce con un'app Java?

Inoltre, l'applicazione JPython può utilizzare una qualsiasi delle funzioni/oggetti JDK ??

E se fosse il codice Jaskell, il fatto che sia un linguaggio funzionale non lo rende incompatibile con il JDK?

Answer 1

Per affrontare le vostre tre domande a parte:

Qual è il vantaggio di avere altre lingue per la JVM?

Ci sono due fattori qui. (1) Perché una lingua diversa da Java per JVM e (2) perché sulla JVM è in esecuzione un'altra lingua, invece di un runtime diverso?

1. Altre lingue possono soddisfare altre esigenze. Ad esempio, Java non ha il supporto integrato per closures, una funzione che è spesso molto utile.
2. Un linguaggio eseguito su JVM è codecode compatibile con qualsiasi altro linguaggio eseguito sulla JVM, il che significa che il codice scritto in una lingua può interagire con una libreria scritta in un'altra lingua.

Ciò che è richiesto (in termini di alto livello) di scrivere un linguaggio/compilatore per la JVM?

La JVM legge i file bytecode (.class) per ottenere le istruzioni necessarie. Pertanto, qualsiasi linguaggio che deve essere eseguito sulla JVM deve essere compilato in bytecode attenendosi allo Sun specification. Questo processo è simile alla compilazione in codice nativo, tranne per il fatto che invece di compilare per istruzioni comprese dalla CPU, il codice viene compilato per istruzioni che vengono interpretate dalla JVM.

Come scrivere/compilare/eseguire codice in una lingua (diversa da Java) nella JVM?

Molto simile allo stesso modo in cui si scrive/compila/esegui codice in Java. Per bagnarti i piedi, ti consiglio di guardare allo Scala, che funziona perfettamente sulla JVM.

rispondere alle vostre domande di follow-up:

Come sarebbe un app scritte, per esempio, JPython, interagire con un'applicazione Java?

Questo dipende dalla scelta dell'implementazione di colmare il divario linguistico. Nel tuo esempio, Jython project ha un mezzo diretto per farlo (see here):

from java.net import URL 
u = URL('http://jython.org') 

Inoltre, possibile utilizzare tale applicazione JPython una delle funzioni JDK/oggetti?

Sì, vedere sopra.

E se fosse il codice Jaskell, il fatto che sia un linguaggio funzionale non lo rende incompatibile con il JDK?

No. Scala (collegamento sopra) ad esempio implementa funzionalità funzionali mantenendo la compatibilità con Java. Per esempio:

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) 
    } 
} 

Answer 2

Lo fanno per stare al passo con .Net. .Net consente C#, VB, J # (in precedenza), F #, Python, Ruby (presto disponibile) e C++. Probabilmente mi mancano alcuni. Probabilmente il più grande lì dentro è Python, per gli scripting people.

Answer 3

Ciò che la JVM può fare è definito dal bytecode della JVM (ciò che si trova nei file .class) piuttosto che nella lingua di partenza. Quindi cambiare il linguaggio del codice sorgente di alto livello non avrà un impatto sostanziale sulle funzionalità disponibili.

Per quanto riguarda ciò che è richiesto per scrivere un compilatore per JVM, tutto ciò che è veramente necessario è generare file bytecode/.class corretti. Il modo in cui scrivi/compili il codice con un tipo di compilatore alternativo dipende dal compilatore in questione, ma una volta che il compilatore emette file .class, eseguirli non è diverso dall'esecuzione dei file .class generati da javac.

Answer 4

io risponderei, “perché Java sucks”, ma poi di nuovo, forse è too obvious ... ;-)

Answer 5

avete bisogno di altre lingue sulla JVM per lo stesso motivo è necessario più linguaggi di programmazione in generale: Lingue diverse sono migliori come risolvere problemi diversi ... tipizzazione statica vs. tipizzazione dinamica, rigida contro pigro ... dichiarativo, imperativo, orientato agli oggetti ... ecc.

In generale, scrivere un "compilatore" per un'altra lingua da eseguire su la JVM (o CLR .Net) è essenzialmente una questione di compilazione di quella lingua in bytecode java (o nel caso di .Net, IL) anziché in linguaggio assembly/macchina.

Detto questo, un sacco di lingue aggiuntive che vengono scritti per JVM non vengono compilati, ma piuttosto interpretare linguaggi di scripting ...

Answer 6

Java è un linguaggio di programmazione piuttosto verboso che sta ottenendo molto rapidamente superata con tutti i nuovi linguaggi/strutture fantasiosi che emergono negli ultimi 5 anni. Per supportare tutta la sintassi di fantasia che le persone vogliono in una lingua E preservare la retrocompatibilità, ha più senso aggiungere altre lingue al runtime.

Un altro vantaggio è che permette di eseguire alcuni framework web scritto in Ruby ala JRuby (aka Rails), o Grails (Groovy su Railys essenzialmente), ecc su una piattaforma di hosting provato che probabilmente è già in produzione presso molte aziende, piuttosto che dover utilizzare ambienti di hosting Ruby non così provati e testati.

Per compilare le altre lingue si sta semplicemente convertendo in codice byte Java.

Answer 7

Il vantaggio di avere altre lingue per la JVM è quasi lo stesso del vantaggio di avere altre lingue per il computer in generale: mentre tutte le lingue complete di turing possono eseguire tecnicamente le stesse attività, alcune lingue rendono alcune attività più semplici di altre mentre altre lingue semplificano altri compiti. Dal momento che la JVM è qualcosa che abbiamo già la possibilità di eseguire su tutti (beh, quasi tutti) i computer, e molti computer, in effetti già ce l'hanno, possiamo ottenere il vantaggio "scrivi una volta, vai ovunque", ma senza richiedere quello usa Java.

Scrivere una lingua/compilatore per la JVM non è molto diverso da quello di scrittura per una macchina reale. La vera differenza è che devi compilare il bytecode della JVM anziché il codice eseguibile della macchina, ma questa è davvero una piccola differenza nel grande schema delle cose.

Il codice di scrittura per una lingua diversa da Java nella JVM in realtà non è diverso dalla scrittura di Java eccetto, ovviamente, che si utilizzerà una lingua diversa. Compilerai usando il compilatore che qualcuno scrive per esso (ancora, non molto diverso da un compilatore C, fondamentalmente, e praticamente diverso da un compilatore Java), e finirai per essere in grado di eseguirlo solo come se avessi compilato il codice Java dato che una volta che è in bytecode, la JVM non può dire da quale lingua proviene.

Answer 8

Il vantaggio per queste altre lingue è che ottengono accesso relativamente facile a molte librerie java.

Il vantaggio per le persone Java varia in base alla lingua: ognuno ha una storia che dice ai programmatori Java cosa fanno meglio. Alcuni metteranno in risalto il modo in cui possono essere utilizzati per aggiungere script dinamici alle app basate su JVM, altri parleranno semplicemente di come la loro lingua è più facile da usare, ha una sintassi migliore o così via.

Ciò che è necessario è lo stesso per scrivere qualsiasi altro compilatore di linguaggio: analizzando un AST, quindi trasformandolo in istruzioni per l'architettura di destinazione (codice byte) e archiviandolo nel formato corretto (file .class).

Dal punto di vista degli utenti, basta scrivere il codice ed eseguire i binari del compilatore, e fuori vengono i file .class che è possibile combinare con quelli che produce il compilatore java.

Answer 9

Lingue diverse sono adattate a compiti diversi. Mentre alcuni domini problematici si adattano perfettamente al linguaggio Java, alcuni sono molto più facili da esprimere in linguaggi alternativi. Inoltre, per un utente abituato a Ruby, Python, ecc., La possibilità di generare bytecode Java e sfruttare le classi JDK e il compilatore JIT ha vantaggi evidenti.

Answer 10

In una certa misura è probabilmente una "corsa agli armamenti" contro .NET CLR.

Ma penso che ci sono anche ragioni autentiche per l'introduzione di nuovi linguaggi per la JVM, in particolare quando essi saranno eseguiti 'in parallelo', è possibile utilizzare il linguaggio giusto per il lavoro giusto, un linguaggio di scripting come Groovy può essere esattamente quello che ti serve per la presentazione della tua pagina, mentre il vecchio e vecchio Java è migliore per la tua logica aziendale.

Ho intenzione di lasciare qualcuno più qualificato per parlare di ciò che è necessario per scrivere un nuovo linguaggio/compilatore.

Per quanto riguarda la modalità di scrittura del codice, lo si fa nel blocco note/vi come al solito! (o utilizzare uno strumento di sviluppo che supporti il ​​linguaggio se si vuole farlo nel modo più semplice.) La compilazione richiederà un compilatore speciale per il linguaggio che lo interpreterà e lo compilerà in bytecode.

Poiché java produce anche tecnodecode tecnicamente, non è necessario eseguire operazioni speciali per eseguirlo.

Answer 11

I linguaggi .NET sono più per lo spettacolo che l'utilità reale. Ogni lingua è stata così macellata, che sono tutti C# con una nuova faccia.

ci sono una serie di motivi per fornire lingue alternative per la Java VM:

• La JVM è multipiattaforma. Qualsiasi lingua convertita in JVM lo ottiene come bonus gratuito.
• C'è un bel po 'di codice legacy là fuori. I motori antiquati come ColdFusion offrono prestazioni migliori offrendo ai clienti la possibilità di passare gradualmente le loro applicazioni dalla soluzione legacy alla soluzione moderna.
• Alcune forme di script sono più adatte allo sviluppo rapido. JavaFX, ad esempio, è stato progettato con un rapido sviluppo grafico in mente. In questo modo compete con motori come DarkBasic. (L'elaborazione è un altro giocatore in questo spazio.)
• Gli ambienti di scripting possono offrire controllo. Ad esempio, un'applicazione potrebbe desiderare di esporre un ambiente simile a VBA all'utente senza esporre le API Java sottostanti. L'utilizzo di un motore come Rhino può fornire un ambiente che supporta la codifica rapida e sporca in una sandbox accuratamente controllata.
• Gli script interpretati indicano che non è necessario ricompilare nulla. Nessuna necessità di ricompilare si traduce in un ambiente più dinamico. per esempio. Nonostante l'uso di Java come "linguaggio di scripting" da parte di OpenOffice, Java fa schifo per quell'uso. L'utente deve passare attraverso tutti i tipi di giga di ricompilazione/ricarica non necessari in un ambiente di scripting dinamico come Javascript.
• Che mi porta ad un altro punto. I motori di scripting possono essere più facilmente fermati e ricaricati senza fermarsi e ricaricare l'intera JVM. Ciò aumenta l'utilità del linguaggio di scripting in quanto l'ambiente può essere ripristinato in qualsiasi momento.

Answer 12

Rispondere solo la tua seconda domanda:

La JVM è solo una macchina e l'esecuzione del modello astratto. Quindi indirizzarlo con un compilatore è lo stesso di qualsiasi altra macchina e modello di esecuzione che un compilatore potrebbe bersagliare, sia implementato in hardware (x86, CELL, ecc.) O software (pappagallo, .NET). La JVM è abbastanza semplice, quindi è in realtà un obiettivo abbastanza facile per i compilatori. Inoltre, le implementazioni tendono ad avere compilatori JIT piuttosto buoni (per gestire il pessimo codice prodotto da javac), in modo da ottenere buone prestazioni senza doversi preoccupare di molte ottimizzazioni.

Si applicano un paio di avvertimenti. Innanzitutto, la JVM incarna direttamente il modulo di java e il suo sistema di ereditarietà, quindi provare a fare qualcos'altro (ereditarietà multipla, dispacciamento multiplo) rischia di essere complicato e richiedere un codice contorto. Secondo, le JVM sono ottimizzate per gestire il tipo di bytecode prodotto da javac. Produrre bytecode che è molto diverso da questo è probabile che entri in angoli dispari del compilatore JIT/JVM che sarà probabilmente inefficiente nella peggiore delle ipotesi (nel peggiore dei casi, possono mandare in crash la JVM o almeno fornire spurie di VirtualMachineError spurie).

Answer 13

È molto più semplice per un produttore di compilatori generare codici byte JVM o CLR. Sono un'astrazione molto più pulita e di livello superiore rispetto a qualsiasi linguaggio macchina.Per questo motivo, è molto più fattibile sperimentare con la creazione di nuovi linguaggi che mai, perché tutto ciò che devi fare è scegliere una di queste architetture VM e avrai una serie di strumenti e librerie già disponibili per la tua lingua. Consentono ai progettisti di linguaggi di concentrarsi maggiormente sulla lingua rispetto a tutta l'infrastruttura di supporto necessaria.

Answer 14

Se si pensa che si desidera progettare una nuova lingua e si desidera eseguirla in un runtime gestito con JIT e GC. Quindi considera che è possibile:

(a) scrivere il proprio runtime gestito (VM) e affrontare tutti i tipi di problemi tecnicamente difficili che porteranno senza dubbio a molti bug, cattive prestazioni, threading improprio e una grande quantità di sforzo di portabilità

o

(b) compilare il linguaggio in bytecode che può essere eseguito sulla macchina virtuale Java, che è già abbastanza maturo, veloce e sostenuta da un certo numero di piattaforme (a volte con più di una scelta dei vendor impementation).

Dato che il codice byte JavaVM non è strettamente legato al linguaggio Java da limitare indebitamente il tipo di linguaggio che è possibile implementare, è stato un ambiente di destinazione popolare per le lingue che si desidera eseguire in una VM.

Answer 15

Poiché il processo di JSR sta rendendo Java sempre più morti: http://www.infoq.com/news/2009/01/java7-updated

E 'un peccato che le aggiunte anche essenziali e lungo conosciute come chiusure non vengono aggiunti solo perché i membri non sono d'accordo su un implementazione.

Answer 16

Il motivo è che la piattaforma JVM offre molti vantaggi.

• serie gigante di librerie
• più ampia grado di piattaforma implementazioni
• matura framework
• codice legacy che è già parte della vostra infrastruttura

Le lingue Sun sta cercando di sostenere con le loro specifiche Scripting (ad esempio Python, Ruby) sono attive e sono in gran parte dovute ai miglioramenti percepiti della produttività. L'esecuzione di Jython consente, in teoria, di essere più produttivi e sfruttare le capacità di Python per risolvere un problema più adatto a Python, ma essere comunque in grado di integrarsi, a livello di runtime, con la base di codice esistente. Le classiche implementazioni di Python e Ruby hanno la stessa capacità per le librerie C.

Inoltre, è spesso più semplice esprimere alcune cose in un linguaggio dinamico rispetto a Java. Se questo è il caso, puoi andare dall'altra parte; consumare Python/Ruby librerie da Java.

C'è un problema di prestazioni, ma molti sono disposti ad accettarlo in cambio di un codice meno dettagliato e più chiaro.

Answer 17

Java ha accumulato una vasta base di utenti su sette versioni principali (da 1.0 a 1.6). La sua capacità di evolversi è limitata dalla necessità di preservare la retrocompatibilità per le innumerevoli milioni di righe di codice Java in esecuzione nella produzione.

Questo è un problema perché Java ha bisogno di evolvere per:

• competere con i nuovi linguaggi di programmazione che hanno imparato dai successi e fallimenti di Java.
• incorporare nuovi progressi nella progettazione del linguaggio di programmazione.
• consente agli utenti di sfruttare appieno i vantaggi dell'hardware - ad es. processori multi-core.
• correggere alcune idee all'avanguardia che hanno introdotto problemi imprevisti (ad esempio eccezioni controllate, generici).

Il requisito della retrocompatibilità è un ostacolo al mantenimento della competitività.

Se si confronta Java con C#, Java presenta il vantaggio in librerie e framework maturi, pronti per la produzione e uno svantaggio in termini di funzionalità del linguaggio e velocità di aumento della quota di mercato. Questo è ciò che ci si aspetterebbe dal confronto di due linguaggi di successo distanti tra una generazione e l'altra.

Qualsiasi nuova lingua ha lo stesso vantaggio e lo svantaggio che C# ha rispetto a Java in misura estrema. Un modo per massimizzare il vantaggio in termini di funzionalità linguistiche e minimizzare lo svantaggio in termini di librerie e framework maturi è quello di creare il linguaggio per una macchina virtuale esistente e renderlo interoperabile con il codice scritto per quella macchina virtuale. Questa è la ragione del modesto successo di Groovy e Clojure; e l'eccitazione intorno a Scala. Senza la JVM queste lingue avrebbero potuto occupare solo una piccola nicchia in un segmento di mercato molto specializzato, mentre con la JVM occupano una nicchia significativa nel mainstream.