Миграция Java в Scala

Question

Какие важные моменты следует знать и какие обходные пути следует предпринимать при постепенной миграции существующей базы Java-кода в Scala? С (потенциально очень длительной) промежуточной фазой, где используются оба языка.

Вот о чем я думаю:

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

Answer 1

Scala не нравится:

• внутренние классы Java
• статические методы и переменные (особенно в суперклассах)
• необработанные типы

Java не любит:

• Черты объектов Scala
• замыкания
• актеры (кроме Скарлетт Йоханссон и Актеры Akka, поскольку они имеют Java API)
• подразумевает, особенно Манифесты
• конструкции продвинутого типа (типы с более высоким типом, типы структур, переменные типа)

Answer 2

Хорошая презентация, которую может дать некоторое представление о предмете, - Скрытность Скала в вашу организацию Дэвид Коупленд.

Answer 3

Изначально (т. Е. На первом этапе миграции) я бы сказал, что вы не хотите экспортировать API (интерфейс / публичный метод и т. Д.) С трудной в использовании конструкцией скалы из Java.

На практике я бы ограничил это экспортом чего-либо специфичного для scala (опять же, я говорю о первом этапе миграции здесь):

• библиотечные классы scala (типы функций, коллекциии т. д.)
• сигнатуры генерических типов высшего рода
• имплициты

Так что же остается?Что ж, внутренние компоненты классов (частные методы, поля и т. Д.) Можно преобразовать для использования конструкций scala и библиотечных классов.

Если у вас есть какие-либо API-интерфейсы (особенно API-интерфейсы, ориентированные на клиента, которые вы собираетесь перенести), я бы сказал,спроектировать их заново с нуля в Scala;изначально используя Java-бэкэндТогда я бы медленно поел в коде между ними.

Из пунктов, которые вы подчеркнули, я бы согласился, что неизменная парадигма Scala и изменяемая парадигмаЯва не смешивается хорошо.Другие пункты, которые я нашел менее проблематичными.

Другой основной момент несоответствия парадигмы - как преобразовать любой параллельный код, который у вас есть (то есть тот, который использует java.util.concurrent).Это, конечно, может быть преобразовано как , но вопрос заключается в том, следует ли заменить модель параллелизма, основанную на блокировке, моделью, основанной на актерах или STM .В любом случае это также может быть полная модернизация, в отличие от преобразования как такового .

Answer 4

Один прием, который мне нравится использовать, я определю объект, используя идиоматические свойства Scala (vals и vars), затем добавлю аннотацию @BeanProperty, чтобы затем представлять ее как свойства JavaBean.Таким образом, каждый язык может использовать нативные идиомы.

Аннотация @BeanInfo может также использоваться на уровне класса для аналогичной цели, но вы должны быть осторожны - при использовании @BeanInfo любые методычто вы дополнительно определяете пользовательское как setXXX или getXXX, не будут подвергаться самоанализу бина.Это важно, поскольку вы должны вручную писать методы получения / установки для типов коллекций, если вы также хотите обрабатывать перевод между, например, списками Scala и списками Java.

Answer 5

Я добавлю к тому, что сказали другие, так как они правильные и значимые. Больше, чем просто код, вам нужно перенести свои модульные тесты. Это не кажется сложным, пока вы не начнете изменять изменяемость и многопоточность, и при этом пытаться заставить все работать так же, как и раньше. Во время перехода очень важно помнить все пограничные случаи при обнаружении дополнительных пограничных случаев, которые вы можете ввести во время миграции.

Если вы перенесете свои модульные тесты в хорошую среду тестирования Scala, такую ​​как ScalaTest, с прямым переводом, вы можете обнаружить, что то, что вы тестируете, не то, что вы тестировали раньше. При выполнении миграции важно, чтобы вы сохраняли смысл кода вместе с тестами, а не допускали фрагментацию мысли.