In che modo il nuovo sviluppo di Java influenzerà la sua interoperabilità con linguaggi come Scala e Clojure?

Question

In che modo il nuovo sviluppo di Java influenzerà la sua interoperabilità con linguaggi come Scala e Clojure?

#1 da (15 voti)
#2 da (2 voti)

11

Per quanto ho capito, sia Scala che Clojure sono stati progettati come nuove lingue che

dipende dalla JVM e
si integrano facilmente con il codice Java, nel senso che consentono di utilizzare le classi Java all'interno del codice Scala e Clojure.

A partire da Java 8 (e forse ancora più strongmente con le versioni successive di Java), ci saranno cambiamenti nella semantica del linguaggio Java.

Volevo chiedere come questi cambiamenti avranno un impatto sull'interoperabilità tra Java e Scala / Clojure e quali saranno le conseguenze. Ad esempio, poiché lambdas in Java 8 non sono oggetti (vedi ad esempio qui ), Scala e Clojure potrebbero avere a che fare con valori Java che non sono oggetti. Questo sarebbe un problema?

Posso pensare ai seguenti scenari:

Il linguaggio Scala o Clojure verrà esteso per adattarsi alla nuova semantica Java (per gestire i nuovi valori non object) e supportare l'interoperabilità con Java.
La lingua di Scala o Clojure sarà non estesa. Ciò sarebbe possibile solo se le nuove funzionalità di Java come i valori di funzione possono essere mappate a concetti esistenti. Ad esempio, in Scala anche una funzione è un oggetto, quindi suppongo che le funzioni Java saranno nuovamente avvolte in una sorta di oggetti quando diventano visibili a Scala.
Il linguaggio Scala o Clojure continuerà a supportare l'interoperabilità fino a Java 6 o 7, senza seguire lo sviluppo di Java più recente. Ciò richiederebbe che le versioni precedenti di Java siano ancora supportate (almeno da OpenJDK o un altro progetto), in modo che questi linguaggi possano essere basati su un ramo più conservatore / stabile di Java.

Riassumendo: possiamo aspettarci che il futuro sviluppo di Java avrà un impatto su linguaggi come Scala e Clojure per mantenere l'interoperabilità con Java? Esiste già una discussione (collegamento a) su questo argomento?

Nota

Posso immaginare che Scala, Clojure e altri linguaggi basati su JVM non presentino problemi significativi nell'aggiornare la loro implementazione a versioni più recenti della JVM (e che le nuove funzionalità di JVM renderanno questa implementazione ancora più semplice). La mia domanda si concentra sulle funzionalità di Java come lingua e se / come l'altro linguaggio JVM sarà in grado di "vedere" / utilizzare queste nuove funzionalità, non sul fatto che i linguaggi basati su JVM funzioneranno sulle ultime JVM.

java scala clojure

posta Giorgio 08.01.2013 - 10:51

fonte

2 risposte

2

Scala sta per essere lasciata indietro quando Java aggiunge lambda perché a Java lambdas viene assegnato un tipo in base al contesto in cui sono utilizzati, mentre a Scala lambdas viene assegnato un tipo in base alle loro origini, tipi di parametri e tipi di ritorno, ad esempio ,

executor.execute(() -> { System.out.println("hello world"); });

da Java 8 può essere scritto in Scala come:

executor execute new Runnable {
    override def run() { println("hello world") }
}

a meno che non usi / scrivi alcuni wrapper che convertono Scala's () = > Unità da eseguire.

risposta data 09.01.2013 - 20:41

fonte

Leggi altre domande sui tag java scala clojure

algoritmo di elevatore e implementazione [chiuso] Come scrivere costruttori che potrebbero fallire nel creare un'istanza appropriata di un oggetto

score 15 · Accepted Answer

In realtà Java 8 non introduce molto che andrà a scapito di altri linguaggi JVM che interagiscono con Java. Il lavoro svolto su Lambdas ha contribuito a risolvere una serie di piccoli problemi relativi a invokedynamic, MethodHandles, MethodReferences, ecc. Ma, a parte ciò, continua normalmente. Detto questo, c'è un nuovo gruppo di API che le altre lingue JVM potrebbero potenzialmente chiamare ora. Quelli che useranno per impostazione predefinita o meno dipende da loro.

Il più grande cambiamento che ha avuto impatto con l'interoperabilità è arrivato in realtà con Java 7 - con il bytecode invocato che consente chiamate di binding dinamici / tardivi all'interno della JVM - qualcosa inizialmente progettato per le altre lingue sulla JVM. Da allora è stato adattato molto bene per Lamdbas, così da Java 8, Java inizierà effettivamente a emettere questi bytecode.

Alcune lingue (JRuby per esempio) stanno già utilizzando intensamente invokedynamic, mentre altre (Scala, Groovy et al) stanno ancora studiando il suo uso o sono nelle prime fasi di applicazione di patch in. In teoria fa le loro chiamate dinamiche quasi come performante come chiamate invokestatic Java esistenti, in contrasto con la miriade di soluzioni alternative più lente che sono state costrette a utilizzare in passato.

Java 9 porterà più sfide per i linguaggi JVM con il progetto Jigsaw che entrerà nella piattaforma che sarà l'inizio della fine per i tradizionali percorsi di classe e classpath per la JVM. I linguisti della JVM sono piuttosto consapevoli di ciò e mi aspetto che abbia luogo una collaborazione sensata.