Compatibilità tra chiusure Scala e chiusure Java 8 - java, scala, chiusure, scala-java-interop

Dopo aver letto alcune voci della mailing list di OpenJDK,sembra che gli sviluppatori Oracle stiano attualmente rimuovendo ulteriormente le cose dalla proposta di chiusura, perché i precedenti errori di progettazione nel linguaggio Java complicano l'introduzione delle chiusure Java.

Considerando che le chiusure della Scala sono molto di piùpotente rispetto alle chiusure previste per Java 8, mi chiedo se sarà possibile e. g. chiamare un metodo Java prendendo una chiusura da Scala, definendo una chiusura in Java e dandola a una funzione Scala ecc.?

Quindi le chiusure Java saranno rappresentate come le loro controparti Scala in bytecode o diversamente? Sarà possibile colmare il divario di funzionalità tra le chiusure Java / Scala?

risposte:

Nota: 5 anni dopo, SCALA 2.12.0-M3 (ottobre 2015) ha incluso questo miglioramento:

Scala 2.12 emette chiusure nello stesso stile di Java 8.

Per ogni lambda il compilatore genera un metodo contenente il corpo lambda.
In fase di esecuzione, questo metodo viene passato come argomento a LambdaMetaFactory fornito da JDK, che crea un oggetto di chiusura.

Rispetto a Scala 2.11, il nuovo schema ha il vantaggio che il compilatore non genera più una classe anonima per ogni lambda. Ciò porta a file JAR significativamente più piccoli.

Penso che sia più complicato che supporre che ci siano due gruppi di parti interessate qui. Il Progetto Lambda le persone sembrano lavorare principalmente indipendentemente dalle persone Oracle, ogni tanto lanciando qualcosa oltre il muro che la gente del Progetto Lambda scopre indirettamente. (Scala, è ovviamente il terzo stakeholder.)

Dal momento che il ultima proposta di Progetto Lambda è eliminare tutti i tipi di funzione insieme e creare semplicemente una sorta di inferenza fantasiosa per l'implementazione di interfacce che hanno un unico metodo astract (SAM tipi), prevedo quanto segue:

• La chiamata del codice Scala che richiede una chiusura di Scala dipenderà interamente dall'implementazione di Function* tratti (e implementazione dei tratti ingenerale) - se appare al compilatore Java come SAM (che è in Scala-land) o se i metodi non astratti appaiono astratti anche nella JVM. (Penserei che al momento sembrano astratti poiché i tratti sono implementati come interfacce, ma non so quasi nulla dell'implementazione di Scala. Questo potrebbe essere un grosso ostacolo all'interoperabilità.)

  Complicazioni con generici Java (in particolare come esprimereInt/int/Integer, o Unit/Nothing/void in un'interfaccia generica) può anche complicare le cose.

• L'uso delle funzioni Scala per implementare i SAM Java non sarà diverso da quello attuale - devi crearne uno implicit conversione per l'interfaccia specifica che desideri implementare.

Se la JVM ottiene tipi di funzione (e Oracle sembranon aver eliminato questa possibilità), può dipendere da come è implementata. Se sono oggetti di prima classe che implementano una particolare interfaccia, allora tutto ciò che Scala deve fare per essere compatibile è rendere Function* implementare la nuova interfaccia. Se un nuovo tipo di tipo è implementato interamente nella JVM, allora questo potrebbe essere difficile: gli sviluppatori Scala possono avvolgerli usando la magia come fanno attualmente per Arrays, o possono creare creare implicit conversioni. (Un nuovo concetto di lingua sembra un po 'inverosimile.)

Spero che uno dei risultati di tutta questa discussione sia quello tutti delle varie lingue JVM si accorderanno su un modo standard per rappresentare le chiusure - in modo che Scala, Groovy, JRuby, ecc ... possano passare tutte le chiusure avanti e indietro con un minimo di seccatura.

Ciò che è più interessante per me sono le proposte per metodi di estensione virtuale che consentirà l'utilizzo dell'API Java Collectionslambda. A seconda di come questi vengono implementati, possono semplificare notevolmente alcuni dei problemi di compatibilità binaria che abbiamo dovuto affrontare quando si modifica il codice Scala e possono aiutare a implementare i tratti in modo più semplice ed efficiente.

Spero che alcuni degli sviluppatori di Scala lo sianoessere coinvolto e offrire il loro contributo, ma in realtà non ho visto alcuna discussione su Scala nelle liste del Progetto Lambda, né alcun partecipante che salta fuori da me come sviluppatore di Scala.

Probabilmente potresti farlo facilmente usando conversioni implicite a la collection.JavaConversions indipendentemente dal fatto che vengano fuori dalla scatola.

Certo che lo è ovviamente no, perché potrebbe essere il caso che le chiusure Java vengano trasformate in tipi generati da JVM in fase di esecuzione - Mi sembra di ricordare una presentazione di Neal Gafter che dice qualcosa in questo senso