Java SE и Scala Standard Library - случаи, когда один из них предпочтителен

Question

Мы все знаем, что можно использовать библиотеки Java из Scala и наоборот. Но даже глядя на поверхность Java SE и стандартной библиотеки Scala, мы можем заметить, что в них много частей, которые решают идентичные или, по крайней мере, похожие проблемы. Тривиальными примерами являются коллекции, параллелизм и IO. Я не являюсь экспертом ни в одном из двух, но я подозреваю, что в целом Java SE шире по размеру, в то время как Scala SL содержит более концептуально расширенные функции (например, актеры). Вопрос в том, если у нас есть доступ к обеим библиотекам и есть возможность использовать оба языка, есть ли рекомендации, когда мы должны выбирать функции Java SE вместо Scala SL?

Answer 1

В общем, при написании на Scala я бы советовал всегда использовать библиотеки Scala вместо библиотек Java.Мой совет по конкретным областям:

• Коллекции - Scala намного лучше, и я всегда предпочел бы их по сравнению с эквивалентами Java.Однако в Scala отсутствует изменяемый TreeMap, поэтому, если вам нужна такая структура, вам придется вернуться к Java.
• Параллелизм - функции параллелизма в Scala обертывают Java и являются более продвинутыми.Я бы всегда выбирал их.
• IO - я думаю, что это одна из областей, где Scala более узкая в том, что она поддерживает.Я бы обычно использовал Scala Source, когда это возможно, но могут быть более необычные ситуации, когда вам придется вернуться к Java IO (или, возможно, использовать стороннюю библиотеку).
• Swing - Последний разЯ посмотрел, что свинг-свинг Scala не был завершен, поэтому, если вы делаете много вещей, связанных с Swing, вы можете принять решение использовать повсеместно компоненты свинг-кода Java для согласованности.

Answer 2

Библиотеки Scala подразделяются на две основные категории:

1. Оригинальные библиотеки Scala. Они полностью (или почти полностью) написаны на Scala. Обычно люди будут писать библиотеки с нуля по уважительным причинам. Возможно, в Java нет подобной библиотеки, или, возможно, тот, кто написал Scala, считает, что эквивалент Java имеет серьезные ограничения.

Коллекции - один из таких примеров.

1. Scala Wrappers над библиотеками Java. В этих случаях Scala использует шаблон адаптера (или один из других аналогичных шаблонов) для обеспечения Scala-friendly API. Эти API более гибки, хорошо интегрируются с важными классами Scala (такими как коллекции и Option) и часто используют мощные функции Scala, такие как черты, для уменьшения шаблонов.

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

Отличным примером этого является Scala Swing.

В конкретном случае scala.io это не столько библиотека, сколько грубая обертка, просто для выполнения простых общих задач сценариев с идиоматическим Scala API. Это достаточно для этого - и, конечно, намного добрее на моих глазах, чем java.io, - но не для каких-либо серьезных операций ввода-вывода. Существует реальная библиотека ввода / вывода для Scala, которая в настоящее время проходит оценку для принятия.

Еще один пример, который мне очень нравится, если scala.sys.process. Он охватывает Java Process и ProcessBuilder, предоставляя почти все функциональные возможности и добавляя некоторые. Кроме того, при необходимости вы можете использовать большинство внутренних компонентов Java (единственное исключение составляет Process, что не очень полезно).

Я советую использовать библиотеки Scala, если они существуют и соответствуют вашим потребностям, расширять их, если они в основном адекватны, но в противном случае обращаться к библиотекам Java без колебаний. В конце концов, высокая степень взаимодействия с Java является ключевой особенностью Scala.