Compatibilidad entre los cierres de Scala y los cierres de Java 8 - java, scala, cierres, scala-java-interop

Después de leer algunas entradas de la lista de correo OpenJDK,Parece que los desarrolladores de Oracle actualmente están eliminando más cosas de la propuesta de cierre, porque los errores de diseño anteriores en el lenguaje Java complican la introducción de los cierres de Java.

Teniendo en cuenta que los cierres de Scala son mucho más.Más potente que los cierres planeados para Java 8, me pregunto si será posible e. sol. llamar a un método Java tomando un cierre de Scala, definiendo un cierre en Java y dándole una función de Scala, etc.

Entonces, ¿los cierres de Java se representarán como sus homólogos de Scala en el bytecode o de manera diferente? ¿Será posible cerrar la brecha de funcionalidad entre los cierres de Java / Scala?

Respuestas

Nota: 5 años después, SCALA 2.12.0-M3 (octubre de 2015) incluyó esta mejora:

Scala 2.12 emite cierres en el mismo estilo que Java 8.

Para cada lambda, el compilador genera un método que contiene el cuerpo lambda.
En tiempo de ejecución, este método se pasa como un argumento a la LambdaMetaFactory proporcionado por el JDK, que crea un objeto de cierre.

Comparado con Scala 2.11, el nuevo esquema tiene la ventaja de que el compilador ya no genera una clase anónima para cada lambda. Esto conduce a archivos JAR significativamente más pequeños.

Creo que es más complicado que asumir que hay dos grupos de partes interesadas aquí. los Proyecto lambda La gente parece estar trabajando mayormente independientemente de la gente de Oracle. de vez en cuando tirar algo por la pared Que la gente del Proyecto Lambda se entera indirectamente. (Scala, es por supuesto el tercer actor.)

Desde el última propuesta del proyecto Lambda es eliminar todos los tipos de funciones, y simplemente crear algún tipo de inferencia sofisticada para implementar interfaces que tengan un solo método abstracto (SAM tipos), preveo lo siguiente:

• Llamar al código de Scala que requiere un cierre de Scala dependerá completamente de la implementación del Function* rasgos (y la implementación de rasgos engeneral): si el compilador de Java parece un SAM (que está en Scala-land) o si los métodos no abstractos también aparecen abstractos para la JVM. (Creo que actualmente parece que son abstractos, ya que los rasgos se implementan como interfaces, pero no conozco casi nada acerca de la implementación de Scala. Esto podría ser un gran obstáculo para la interperabilidad).

  Complicaciones con los genéricos de Java (en particular, cómo expresarInt/int/Integer, o Unit/Nothing/void en una interfaz genérica) también puede complicar las cosas.

• El uso de las funciones de Scala para implementar los SAM de Java no será diferente de lo que es ahora, debe crear un implicit conversión para la interfaz específica que desea implementar.

Si la JVM obtiene tipos de funciones (y Oracle pareceno haber eliminado esa posibilidad), puede depender de cómo se implemente. Si son objetos de primera clase que implementan una interfaz particular, entonces todo lo que Scala debe hacer para ser compatible es Function* Implementar la nueva interfaz. Si se implementa un nuevo tipo de tipo en la JVM por completo, esto podría ser difícil: los desarrolladores de Scala pueden envolverlos usando la magia como lo hacen actualmente para Arrays, o pueden crear crear implicit conversiones (Un nuevo concepto de lenguaje parece un poco exagerado.)

Espero que uno de los resultados de toda esta discusión sea que todas de los diversos idiomas de JVM acordaremos alguna forma estándar de representar cierres, de modo que Scala, Groovy, JRuby, etc. puedan pasar los cierres de un lado a otro con un mínimo de molestia.

Lo que más me interesa son las propuestas para métodos de extensión virtual Eso permitirá que la Java Collections API uselambdas. Dependiendo de cómo se implementen, pueden simplificar en gran medida algunos de los problemas de compatibilidad binaria con los que hemos tenido que lidiar al cambiar el código Scala, y pueden ayudar a implementar rasgos de manera más fácil y eficiente.

Espero que algunos de los desarrolladores de Scala seanme involucré y ofrecí su aporte, pero en realidad no he visto ninguna discusión de Scala en las listas del Proyecto Lambda, ni ningún participante que salte a mí como desarrollador de Scala.

Es probable que puedas hacer esto extremadamente fácilmente usando conversiones implícitas a la collection.JavaConversions Ya sea que salgan o no de la caja.

Por supuesto, esto es obviamente no tan, porque puede ocurrir que los cierres de Java se conviertan en tipos generados por la JVM. en tiempo de ejecución - Me parece recordar una presentación de Neal Gafter diciendo algo en este sentido