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

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

1. dipende dalla JVM e
2. 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 anche più fortemente 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é i lambda in Java 8 non sono oggetti (vedere ad esempio qui ), Scala e Clojure potrebbero dover gestire valori Java che non sono oggetti. questo sarebbe un problema?

Posso pensare ai seguenti scenari:

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

Riassumendo: possiamo aspettarci che il futuro sviluppo di Java avrà un impatto su linguaggi come Scala e Clojure per mantenere l'interoperabilità con Java? Sono già in corso (link a) discussioni su questo argomento?

Nota

Posso immaginare che Scala, Clojure e altri linguaggi basati su JVM non avranno grossi problemi nell'aggiornamento della loro implementazione a versioni più recenti di JVM (e che le nuove funzionalità di JVM renderanno questa implementazione ancora più semplice). La mia domanda si concentra sulle funzionalità di Java come linguaggio e se / come altri linguaggi JVM saranno in grado di "vedere" / utilizzare queste nuove funzionalità, non se i linguaggi basati su JVM verranno eseguiti sugli ultimi JVM.

In realtà Java 8 non introduce molto che sarà dannoso per altri linguaggi JVM che interagiscono con Java. Il lavoro svolto su Lambdas ha aiutato a risolvere una serie di piccoli problemi relativi a invokedynamic, MethodHandles, MethodReferences ecc. - A parte questo, continua come al solito. Detto questo, c'è un intero nuovo gruppo di API che le altre lingue JVM potrebbero potenzialmente chiamare ora. Quelli che useranno di default o no dipende da loro.

Il più grande cambiamento che ha influito sull'interoperabilità è effettivamente arrivato con Java 7 - con il bytecode invokedynamic che consente chiamate di associazione dinamica / tardiva all'interno della JVM - qualcosa che inizialmente era progettato per le altre lingue sulla JVM. Da allora è stato utilmente adattato per Lamdbas, quindi a partire da Java 8, Java inizierà effettivamente a emettere questi bytecode.

Alcuni linguaggi (ad esempio JRuby) stanno già usando pesantemente l'invocinodinamica, mentre altri (Scala, Groovy et al) stanno ancora studiando il suo uso o sono nelle prime fasi di patch in. In teoria rende le loro chiamate dinamiche quasi performanti come quelle esistenti Chiamate invokestatic di Java, al contrario della miriade di soluzioni più lente che sono state costrette a utilizzare in passato.

Java 9 porterà ulteriori sfide per i linguaggi JVM con il progetto Jigsaw che entrerà nella piattaforma che sarà l'inizio della fine per il caricamento e i percorsi di classe tradizionalmente per la JVM. Le persone del linguaggio JVM ne sono abbastanza consapevoli e mi aspetto che avvenga una collaborazione sensata.

Scala sta per essere lasciata indietro quando Java aggiunge lambda perché a Java lambda viene assegnato un tipo in base al contesto in cui vengono utilizzati, mentre Scala lambda viene assegnato un tipo in base alle loro arità, tipi di parametro e tipi di ritorno, quindi 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 tu non usi / scriva dei wrapper che convertono Scala () => Unit in Runnable.