Совместимость между закрытиями Scala и Java 8 закрытий

Скорее всего, вы сможете сделать это очень легко, используя неявные преобразования а-ля collection.JavaConversions, независимо от того, поставляются они из коробки или нет.

Конечно, это не очевидно, потому что может быть так, что Java-закрытия превращаются в типы, которые генерируются JVM во время выполнения - я припоминаю презентацию Нила Гафтера, в которой говорилось что-то в этом роде

Я думаю, что это сложнее, чем предположить, что здесь есть две группы заинтересованных сторон. Люди из Project Lambda, похоже, работают в основном независимо от людей из Oracle, изредка бросая что-то через стену, о чем люди из Project Lambda узнают косвенно. (Scala, конечно, является третьей заинтересованной стороной. )

Поскольку последнее предложение Project Lambda состоит в том, чтобы полностью отказаться от функциональных типов и просто создать некий причудливый вывод для реализации интерфейсов, имеющих один абстрактный метод (типы SAM), я предвижу следующее:

• Вызов кода Scala, требующего закрытия Scala, будет полностью зависеть от реализации Function* трейтов (и реализации трейтов в целом) - будет ли он выглядеть для компилятора Java как SAM (что и происходит в Scala-land) или неабстрактные методы также будут выглядеть абстрактными для JVM. (Я думаю, что в настоящее время они выглядят абстрактными, поскольку трейты реализованы как интерфейсы, но я почти ничего не знаю о реализации в Scala. Это может стать большим препятствием для совместимости.)

  Сложности с Java generics (в частности, как выразить Int/int/Integer, или Unit/Nothing/void в generic интерфейсе) также могут усложнить ситуацию.

• Использование функций Scala для реализации Java SAMs не будет отличаться от того, что происходит сейчас - вам нужно будет создать неявное преобразование для конкретного интерфейса, который вы хотите реализовать.

Если JVM получит типы функций (а Oracle, похоже, не исключила такую возможность), то это может зависеть от того, как они будут реализованы. Если это объекты первого класса, реализующие определенный интерфейс, то все, что нужно сделать Scala для совместимости, это заставить Function* реализовать новый интерфейс. Если новый тип будет реализован в JVM целиком, то это может быть сложно - разработчики Scala могут обернуть их с помощью магии, как они сейчас делают для Array, или создать неявные преобразования. (Концепция нового языка кажется несколько надуманной.)

Я надеюсь, что одним из результатов всего этого обсуждения станет то, что все различные языки JVM согласуют некий стандартный способ представления замыканий - так, чтобы Scala, Groovy, JRuby и т.д. могли передавать замыкания туда и обратно с минимальными трудностями.

Что мне более интересно, так это предложения по виртуальным методам расширения, которые позволят Java Collections API использовать лямбды. В зависимости от того, как они будут реализованы, они могут значительно упростить некоторые проблемы бинарной совместимости, с которыми нам приходилось сталкиваться при изменении кода Scala, и они могут помочь более легко и эффективно реализовать трейты.

Я надеюсь, что некоторые разработчики Scala принимают участие и предлагают свой вклад, но я не видел ни обсуждения Scala в списках Project Lambda, ни участников, которые показались бы мне разработчиками Scala.