Я думаю, что это сложнее, чем предполагать, что здесь есть две группы заинтересованных сторон. Люди Project Lambda , кажется, работают в основном независимо от людей Oracle, время от времени бросают что-то через стену , что люди Project Lambda обнаруживают косвенно. (Scala, конечно, третий участник.)
Так как последнее предложение Project Lambda состоит в том, чтобы полностью исключить типы функций и просто создать какой-то причудливый вывод для реализации интерфейсов, которые имеют единственный метод astract ( SAM типы) Я предвижу следующее:
Вызов кода Scala, который требует закрытия Scala, будет полностью зависеть от реализации признаков Function* (и реализации признаков в целом) - будет ли он представлен компилятору Java как SAM (который он находится в Scala-land) или неабстрактные методы также кажутся абстрактными для JVM. (Я думаю, что в настоящее время они выглядят абстрактно, поскольку черты реализованы в виде интерфейсов, но я почти ничего не знаю о реализации Scala. Это может стать серьезным препятствием для взаимодействия.)
Осложнения с помощью универсальных Java-выражений (в частности, как выразить Int / int / Integer или Unit / Nothing / void в универсальном интерфейсе) также могут усложнять ситуацию.
Использование функций Scala для реализации Java SAM не будет отличаться от того, что есть сейчас - вам нужно создать implicit преобразование для конкретного интерфейса, который вы хотите реализовать.
Если JVM получает типы функций (а Oracle, похоже, не исключил эту возможность), это может зависеть от того, как она реализована. Если они являются объектами первого класса, реализующими определенный интерфейс, то все, что нужно Scala для совместимости, - это заставить Function* реализовать новый интерфейс. Если новый тип типа полностью реализован в JVM, это может быть сложно - разработчики Scala могут обернуть их, используя магию, как они это делают в настоящее время для Array с, или они могут создавать преобразования implicit. (Новая концепция языка кажется немного надуманной.)
Я надеюсь, что одним из результатов всего этого обсуждения будет то, что все различных языков JVM согласятся на какой-то стандартный способ представления замыканий - так что Scala, Groovy, JRuby и т. Д. ... все могут проходить замыкания назад и вперед с минимальными трудностями.
Что меня интересует, так это предложения виртуальных методов расширения , которые позволят API-интерфейсам Java Collections использовать лямбды-выражения. В зависимости от того, как они реализованы, они могут значительно упростить некоторые проблемы двоичной совместимости, с которыми нам приходилось сталкиваться при изменении кода Scala, и могут помочь более легко и эффективно реализовать черты.
Я надеюсь, что некоторые разработчики Scala будут вовлечены и предложат свой вклад, но на самом деле я не видел ни обсуждения Scala в списках Project Lambda, ни каких-либо участников, которые бы говорили о мне как о разработчиках Scala.