Comment le nouveau développement de Java influencera-t-il son interopérabilité avec des langages comme Scala et Clojure?

Autant que je sache, Scala et Clojure ont été conçus comme de nouvelles langues

1. dépendent de la JVM, et
2. s'intègre facilement au code Java, dans le sens où ils permettent d'utiliser des classes Java dans le code Scala et Clojure.

À partir de Java 8 (et peut-être encore plus fortement avec les versions ultérieures de Java), il y aura des changements dans la sémantique du langage Java.

Je voulais demander comment ces changements affecteront l'interopérabilité entre Java et Scala / Clojure et quelles en seront les conséquences. Par exemple, étant donné que les lambdas de Java 8 ne sont pas des objets (voir par exemple ici ), Scala et Clojure peuvent avoir à gérer des valeurs Java qui ne sont pas des objets. Serait-ce un problème?

Je peux penser aux scénarios suivants:

1. Le langage Scala ou Clojure sera étendu pour s'adapter à la nouvelle sémantique Java (pour gérer les nouvelles valeurs non-objet) et prendre en charge l'interopérabilité avec Java.
2. La langue Scala ou Clojure ne sera pas étendue. Cela ne serait possible que si les nouvelles fonctionnalités Java telles que les valeurs de fonction peuvent être mappées à des concepts existants. Par exemple, dans Scala même une fonction est un objet, donc je suppose que les fonctions Java seraient à nouveau enveloppées dans une sorte d'objets lorsqu'elles deviendront visibles pour Scala.
3. Le langage Scala ou Clojure continuera de prendre en charge l'interopérabilité jusqu'à Java 6 ou 7, sans suivre le dernier développement de Java. Cela nécessiterait que les anciennes versions de Java soient toujours prises en charge (au moins par OpenJDK ou un autre projet), afin que ces langages puissent être basés sur une branche plus conservatrice / stable de Java.

En résumé: peut-on s'attendre à ce que le développement futur de Java ait un impact sur des langages comme Scala et Clojure pour maintenir l'interopérabilité avec Java? Y a-t-il déjà (lien vers) une discussion en cours sur ce sujet?

Remarque

Je peux imaginer que Scala, Clojure et d'autres langages basés sur JVM n'auront pas de problèmes majeurs à mettre à jour leur implémentation vers des versions plus récentes de la JVM (et que les nouvelles fonctionnalités JVM rendront cette implémentation encore plus facile). Ma question se concentre sur les fonctionnalités de Java en tant que langage et si / comment d'autres langages JVM pourront "voir" / utiliser ces nouvelles fonctionnalités, pas si les langages basés sur JVM fonctionneront sur les dernières JVM.

En fait, Java 8 n'introduit pas grand-chose qui sera préjudiciable aux autres langages JVM qui interagissent avec Java. Le travail effectué sur Lambdas a aidé à résoudre un certain nombre de petits problèmes concernant la dynamique invoquée, les poignées de méthode, les références de méthode, etc. - mais en dehors de cela, il se poursuit normalement. Cela dit, il existe un tout nouveau tas d'API que les autres langages JVM pourraient potentiellement appeler maintenant. Le choix de ceux qu'ils utiliseront par défaut ou non.

Le plus grand changement impactant l'interopérabilité est en fait intervenu avec Java 7 - avec le bytecode dynamique invoqué qui permet les appels de liaison dynamique / tardive au sein de la JVM - quelque chose qui a été initialement conçu pour les autres langages de la JVM. Il a depuis été très utilement adapté pour Lamdbas, donc à partir de Java 8, Java commencera réellement à émettre ces bytecodes.

Certaines langues (JRuby par exemple) utilisent déjà massivement la dynamique invoquée, tandis que d'autres (Scala, Groovy et al) étudient toujours son utilisation ou en sont aux premiers stades de la mise à jour. En théorie, leurs appels dynamiques sont presque aussi performants que ceux existants. Appels invokestatiques Java, par opposition à la myriade de solutions de contournement plus lentes qu'ils ont été contraints d'utiliser dans le passé.

Java 9 posera plus de défis pour les langages JVM avec le projet Jigsaw qui entrera dans la plate-forme qui sera le début de la fin pour le chargement de classe et les chemins de classe traditionnellement pour la JVM. Les gens du langage JVM en sont assez conscients et je m'attends à une collaboration sensée.

Scala est sur le point d'être laissé de côté lorsque Java ajoute des lambdas, car les lambdas Java reçoivent un type en fonction du contexte dans lequel ils sont utilisés, tandis que les lambdas Scala se voient attribuer un type en fonction de leurs arités, types de paramètres et types de retour, par exemple,

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

de Java 8 peut être écrit en Scala comme:

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

sauf si vous utilisez / écrivez des wrappers convertissant Scala's () => Unit en Runnable.