Perché abbiamo bisogno di altri linguaggi JVM

StackOverflow https://stackoverflow.com/questions/85058

  •  01-07-2019
  •  | 
  •  

Domanda

Vedo Qui che ci sono un sacco di linguaggi oltre a Java che vengono eseguiti sulla JVM.Sono un po' confuso sull'intero concetto di altri linguaggi in esecuzione nella JVM.COSÌ:

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

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

Come si scrive/compila/esegui codice in un linguaggio (diverso da Java) nella JVM?

MODIFICARE: C'erano 3 domande di follow-up (originariamente commenti) a cui è stata data risposta nella risposta accettata.Sono ristampati qui per leggibilità:

Come potrebbe un'app scritta, ad esempio, JPython, interagire con un'app Java?

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

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

È stato utile?

Soluzione

Per rispondere alle tue tre domande separatamente:

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

Ci sono due fattori qui.(1) Perché avere un linguaggio diverso da Java per la JVM e (2) perché avere un altro linguaggio in esecuzione sulla JVM, invece di un runtime diverso?

  1. Altre lingue possono soddisfare altri bisogni.Ad esempio, Java non ha il supporto integrato per chiusure, una funzionalità che spesso risulta molto utile.
  2. Un linguaggio eseguito sulla JVM è bytecode 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.

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

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

Come si scrive/compila/esegui codice in un linguaggio (diverso da Java) nella JVM?

Più o meno nello stesso modo in cui scrivi/compili/esegui codice in Java.Per bagnarti i piedi, consiglierei di guardarlo Scala, che funziona perfettamente sulla JVM.

Rispondendo alle tue domande di follow-up:

Come potrebbe un'app scritta, ad esempio, JPython, interagire con un'app Java?

Ciò dipende dalla scelta dell'implementazione di colmare il divario linguistico.Nel tuo esempio, Progetto Jython ha un mezzo semplice per farlo (Vedere qui):

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

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

Sì, vedi sopra.

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

NO.Scala (link sopra) ad esempio implementa caratteristiche 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)
  }
}

Altri suggerimenti

Hai bisogno di altri linguaggi sulla JVM per lo stesso motivo per cui hai bisogno di più linguaggi di programmazione in generale:Lingue diverse sono migliori perché risolvono problemi diversi...tipizzazione statica vs.tipizzazione dinamica, rigorosa vs.Pigro ...Dichiarativo, imperativo, orientato agli oggetti...eccetera.

In generale, scrivere un "compilatore" per un altro linguaggio da eseguire sulla JVM (o su .Net CLR) è essenzialmente una questione di compilare quel linguaggio in bytecode Java (o, nel caso di .Net, IL) invece che in assembly /linguaggio macchina.

Detto questo, molti dei linguaggi extra scritti per JVM non sono compilati, ma piuttosto linguaggi di scripting interpretati...

Capovolgendo questo concetto, considera di voler progettare un nuovo linguaggio e di volerlo eseguire in un runtime gestito con JIT e GC.Allora considera che potresti:

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

O

(b) compila il tuo linguaggio in bytecode che può essere eseguito sulla Java VM che è già abbastanza matura, veloce e supportata su un numero di piattaforme (a volte con più di una scelta di impementazione del fornitore).

Dato che il bytecode JavaVM non è legato così strettamente al linguaggio Java da limitare indebitamente il tipo di linguaggio che è possibile implementare, è stato un ambiente di destinazione popolare per i linguaggi che desiderano essere eseguiti in una VM.

Java è un linguaggio di programmazione abbastanza dettagliato che sta diventando obsoleto molto rapidamente con tutti i nuovi linguaggi/framework fantasiosi usciti negli ultimi 5 anni.Per supportare tutta la sintassi elaborata che le persone desiderano in una lingua E preservare la compatibilità con le versioni precedenti, ha più senso aggiungere più lingue al runtime.

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

Per compilare le altre lingue stai semplicemente convertendo in byte code Java.

Risponderei: “perché Java fa schifo” ma forse è proprio così troppo ovvio … ;-)

Il vantaggio di avere altri linguaggi per la JVM è più o meno lo stesso del vantaggio di avere altri linguaggi per il computer in generale:mentre tutti i linguaggi turing-complete possono tecnicamente svolgere gli stessi compiti, alcuni linguaggi rendono alcuni compiti più facili di altri mentre altri linguaggi rendono più facili altri compiti.Poiché 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, esegui ovunque", ma senza richiedere quello usa Java.

Scrivere un linguaggio/compilatore per la JVM non è molto diverso da scriverne uno per una macchina reale.La vera differenza è che devi compilare il bytecode della JVM invece che il codice eseguibile della macchina, ma questa è davvero una piccola differenza nel grande schema delle cose.

Scrivere codice per un linguaggio diverso da Java nella JVM non è in realtà diverso dallo scrivere Java, tranne, ovviamente, per il fatto che utilizzerai un linguaggio diverso.Compilerai utilizzando il compilatore che qualcuno ha scritto per esso (di nuovo, non molto diverso da un compilatore C, fondamentalmente, e praticamente non diverso per niente da un compilatore Java), e alla fine sarai in grado di eseguirlo semplicemente come se compilassi il codice Java poiché una volta che è in bytecode, la JVM non può dire da quale lingua proviene.

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

Rispondendo solo alla tua seconda domanda:

La JVM è solo una macchina astratta e un modello di esecuzione.Quindi sceglierlo come target con un compilatore è esattamente come qualsiasi altra macchina e modello di esecuzione che un compilatore potrebbe prendere di mira, sia esso implementato nell'hardware (x86, CELL, ecc.) o nel software (parrot, .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 codice scadente prodotto da Javac), quindi puoi ottenere buone prestazioni senza doverti preoccupare di molte ottimizzazioni.

Si applicano un paio di avvertenze.Innanzitutto, la JVM incorpora direttamente il modulo Java e il sistema di ereditarietà, quindi provare a fare qualsiasi altra cosa (ereditarietà multipla, invio multiplo) è probabile che sia complicato e richieda un codice contorto.In secondo luogo, le JVM sono ottimizzate per gestire il tipo di bytecode prodotto da Javac.La produzione di bytecode molto diverso da questo rischia di entrare in angoli strani del compilatore JIT/JVM che probabilmente saranno inefficienti nella migliore delle ipotesi (nel peggiore dei casi, possono arrestare in modo anomalo la JVM o almeno fornire eccezioni VirtualMachineError spurie).

Ciò che la JVM può fare è definito dal bytecode della JVM (quello che trovi nei file .class) anziché dalla lingua di origine.Pertanto, la modifica del linguaggio del codice sorgente di alto livello non avrà un impatto sostanziale sulle funzionalità disponibili.

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

Il vantaggio per questi altri linguaggi è che ottengono un accesso relativamente facile a molte librerie Java.

Il vantaggio per gli utenti Java varia a seconda della lingua: ognuno ha una storia che racconta ai programmatori Java cosa sanno fare meglio.Alcuni sottolineeranno come possono essere utilizzati per aggiungere script dinamici alle app basate su JVM, altri parleranno semplicemente di come il loro linguaggio sia più facile da usare, abbia una sintassi migliore e così via.

Ciò che è richiesto sono le stesse cose per scrivere qualsiasi altro compilatore di linguaggio:analizzandolo in un AST, quindi trasformandolo in istruzioni per l'architettura di destinazione (codice byte) e memorizzandolo nel formato corretto (file .class).

Dal punto di vista dell'utente, basta scrivere il codice ed eseguire i binari del compilatore e vengono fuori file .class che puoi mescolare con quelli prodotti dal tuo compilatore Java.

I linguaggi .NET sono più per spettacolo che per effettiva utilità.Ogni linguaggio è stato così massacrato che sono tutti C# con un nuovo volto.

Esistono diversi motivi per fornire linguaggi alternativi per Java VM:

  • La JVM è multipiattaforma.Qualsiasi linguaggio portato su 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 lentamente le loro applicazioni dalla soluzione legacy a quella moderna.
  • Alcune forme di scripting sono più adatte allo sviluppo rapido.JavaFX, ad esempio, è progettato pensando al rapido sviluppo grafico.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 voler esporre all'utente un ambiente simile a VBA 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 un sandbox attentamente controllato.
  • Gli script interpretati significano che non è necessario ricompilare nulla.Nessuna necessità di ricompilare si traduce in un ambiente più dinamico.per esempio.Nonostante l'uso di Java da parte di OpenOffice come "linguaggio di scripting", Java fa schifo per quell'uso.L'utente deve sottoporsi a tutti i tipi di operazioni di ricompilazione/ricaricamento che non sono necessarie in un ambiente di scripting dinamico come Javascript.
  • Che mi porta ad un altro punto.I motori di scripting possono essere arrestati e ricaricati più facilmente senza arrestare e ricaricare l'intera JVM.Ciò aumenta l'utilità del linguaggio di scripting poiché l'ambiente può essere ripristinato in qualsiasi momento.

È molto più semplice per uno scrittore di compilatori generare codici byte JVM o CLR.Sono un'astrazione di livello molto più pulito e superiore rispetto a qualsiasi linguaggio macchina.Per questo motivo, è molto più fattibile che mai sperimentare la creazione di nuovi linguaggi, 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.Permettono ai progettisti linguistici di concentrarsi più sulla lingua che su tutta l'infrastruttura di supporto necessaria.

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

È un peccato che anche le aggiunte essenziali e note da tempo come Closures non vengano aggiunte solo perché i membri non riescono a concordare un'implementazione.

Java ha accumulato un'enorme base di utenti in sette versioni principali (dalla 1.0 alla 1.6).La sua capacità di evolversi è limitata dalla necessità di preservare la compatibilità con le versioni precedenti per gli innumerevoli milioni di righe di codice Java in esecuzione in produzione.

Questo è un problema perché Java deve evolversi per:

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

Il requisito della compatibilità con le versioni precedenti rappresenta un ostacolo per rimanere competitivi.

Se si confronta Java con C#, Java presenta il vantaggio di librerie e framework maturi e pronti per la produzione, e uno svantaggio in termini di funzionalità del linguaggio e tasso di aumento della quota di mercato.Questo è ciò che ti aspetteresti confrontando due lingue di successo distanti una generazione.

Qualsiasi nuovo linguaggio presenta gli stessi vantaggi e svantaggi di C# rispetto a Java in misura estrema.Un modo per massimizzare il vantaggio in termini di funzionalità del linguaggio e ridurre al minimo lo svantaggio in termini di librerie e framework maturi è creare il linguaggio per una macchina virtuale esistente e renderlo interoperabile con il codice scritto per quella macchina virtuale.Questo è il motivo del modesto successo di Groovy e Clojure;e il fermento intorno a Scala.Senza la JVM questi linguaggi avrebbero potuto occupare solo una piccola nicchia in un segmento di mercato molto specializzato, mentre con la JVM occupano una nicchia significativa nel mainstream.

Lo fanno per stare al passo con .Net..Net consente C#, VB, J# (in precedenza), F#, Python, Ruby (disponibile a breve) e C++.Probabilmente me ne mancano alcuni.Probabilmente il più importante è Python, per gli sviluppatori di script.

In una certa misura si tratta probabilmente di una "corsa agli armamenti" contro .NET CLR.

Ma penso che ci siano anche ragioni reali per introdurre nuovi linguaggi nella JVM, in particolare quando verranno eseguiti "in parallelo", puoi usare il linguaggio giusto per il lavoro giusto, un linguaggio di scripting come Groovy potrebbe essere esattamente ciò di cui hai bisogno la presentazione della tua pagina, mentre il vecchio Java normale è migliore per la tua logica aziendale.

Lascerò che qualcuno più qualificato parli di ciò che è necessario per scrivere un nuovo linguaggio/compilatore.

Per quanto riguarda come scrivere il codice, lo fai in notepad/vi come al solito!(o utilizza uno strumento di sviluppo che supporti il ​​linguaggio se vuoi farlo nel modo più semplice.) La compilazione richiederà un compilatore speciale per il linguaggio che lo interpreterà e compilerà in bytecode.

Poiché Java produce tecnicamente anche bytecode, non è necessario fare nulla di speciale per eseguirlo.

Il motivo è che la piattaforma JVM offre molti vantaggi.

  • Numero enorme di biblioteche
  • Più ampio grado di implementazioni della piattaforma
  • Quadri maturi
  • Codice legacy che è già parte della tua infrastruttura

I linguaggi che Sun sta cercando di supportare con le proprie specifiche di scripting (ad es.Python, Ruby) sono emergenti in gran parte grazie ai miglioramenti della produttività percepiti.Gestire Jython ti consente, in teoria, di essere più produttivo e sfruttare le capacità di Pitone 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 Pitone E Rubino effettuare la stessa abilità per C biblioteche.

Inoltre, spesso è più semplice esprimere alcune cose in un linguaggio dinamico che in Java.Se questo è il caso, puoi andare dall'altra parte;consumare Pitone/Rubino biblioteche da Giava.

C'è un calo in termini di prestazioni, ma molti sono disposti ad accettarlo in cambio di una base di codice meno dettagliata e più chiara.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top