использовать внутри скаловского кода скаловские же структуры данных и только при передаче их фреймворкам (jackson, freemarker) конвертировать в явовские или использовать напрямую те-же явовские List, Map, Set внутри алгоритмов?

Зачем же тогда Одерский рожал свою ацкую библиотеку коллекций, если не использовать все ее плюшки на практике? Первый вариант, конечно.

freemarker

http://circumflex.ru/projects/freemarker/index.html - возможно, пригодится.

По бину имхо если использовать спринг, то и писать как будто на джаве, ничего плохого в этом нет. Опять же имхо, но к скале лучше переходить постепенно, писать на джаве++, приобретая плюсы скалы, но не залазя в дебри.

Насчет коллекций однозначно не скажу, библиотека коллекций в скале это по-моему единственная концепция, которую я не осилил на приемлемом уровне (понимать как оно работает, расширять, свободно читать код) и лично считаю слишком переусложненной. Но вряд ли это изменится, поэтому видимо придется с этим жить.

Если нужно сделать Stateless bean - так и делайте его. На скале это неплохо получается, т.е. интеграция с джавой вполне работает. Есть специфика, но основные рецепты вы выясните в первую неделю работы. Вообще scala это все-таки больше язык, и в плане архитектуры мало что нового предлагает. Т.е. модули, зависимости, конфигурация, логирование и т.п. остаются такими же, как и до скалы. Другой путь, состоящий в полном переписывании проекта на каком-нибудь скала-специфичном фреймворке, вряд ли подойдет. По коллекциям - используйте в коде коллекции скалы. Некоторые разработчики используют коллекции гугла или апача, потому как стандартные из java.utils не очень удобны. Вы сможете в пару строк написать алгоритм решения задачи с помощью комбинации map, filter, groupBy, zip, reduce и прочих конструкций, вместо огорода из десятков-сотен строк с малозначимыми временными переменными, многоэтажными циклами и прочим.

Зачем же тогда Одерский рожал свою ацкую библиотеку коллекций, если не использовать все ее плюшки на практике? Первый вариант, конечно.

В том-то и проблема, что библиотека получилась довольно таки «аццкой» раз (но это еще пол беды, вкурить можно) и не очень кошерно интегрируящаяся с явовскими коллекциями - два. Что мешало заимплементить в ней явовские интерфейсы я до сих пор не понимаю.

А за ссылку спасибо, обязательно завтра посмотрю.

По бину имхо если использовать спринг, то и писать как будто на джаве, ничего плохого в этом нет.

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

Если нужно сделать Stateless bean - так и делайте его. На скале это неплохо получается, т.е. интеграция с джавой вполне работает.

Да, что все работает было еще давно выяснено. Я даже ради фана несколько EJB в свое время на скале написал, что конечно извращение редкостное, но выглядело забавно.

Другой путь, состоящий в полном переписывании проекта на каком-нибудь скала-специфичном фреймворке, вряд ли подойдет.

Да, не особо подойдет, да и смысла отказываться от спринга я не вижу. Больно уж в нем много плюшек, делающих жизнь приятной, а волосы - мягкими и шелковистыми ;) И собирать солянку из кучи велосипедов и кусков для замены spring ioc+aop+mvc+security+jmx exposure+jms template - очень не хочется.

У нас в системе используется Spring + Scala + Java. Полет нормальный.

Правда исторически так получилось, что все бины у нас на Java, а на Scala написаны всякие фоновые процессы на основе actors. Внутри Scala кода используются родные коллекции, иначе профита мало, а там где нужно, используется scala.collection.JavaConversions.

А зачем на Scala переписывать? Чем обоснован такой переход?

Ну у нас получилось меньше кода, особенно при составлении сложных xml запросов к системе, для API которой нет xsd, соответственно нельзя задействовать JAXB объекты. Кода меньше и он гораздо читабельней. Ну это если фичи scala без фанатизма пользовать :-)

А зачем на Scala переписывать? Чем обоснован такой переход?

Тем, что в данном проекте ее можно погонять и понять - надо оно нам или нет :)

Я скалу не первый раз в глаза вижу, но у меня сложилось мнение что для production оно слишком переусложненное. У коллег мнение другое. Вот и решили один проект на ней продолжить делать, благо его не особо жалко.

По-моему вы пытаетесь применить Scala к задаче, которая не очень подходит для языка.

А для чего она тогда подходит, если не для написания +- нагруженной системы с разлапистой бизнес-логикой? Для очередного hello world || вычисления факториала?

Откуда такая ирония? Если бы не было готовых библиотек для bignum, то задача вычисления факториала была бы нетривиальной. Кстати, олимпиадного уровня задача.

На мой взгляд Scala хороша для написания сложной бизнес-логики. Еще хороша для конкурентных задач, где можно применить акторы, и где функциональная парадигма показывает свою мощь.

Мой личный опыт состоял в применении Scala для написания десктопного приложения. Проект временно заморозил, но Scala показала себя очень хорошо (или мое умение ее использовать).

В вашем же случае мне показалось, что вы хотите использовать Scala просто как Java непосредственно внутри Java Framework. Может быть и получится. Кто знает? Тем более, если я правильно понял, коллекции можно использовать из Scala, а они весьма удобны, хотя и выглядят запутанно (implicits как класс типов даже в методе map). Только имейте в виду, что при переходе из Java в Scala и обратно передаваемые коллекции могут преобразовываться, а это накладные расходы. Ну, тут будет, как спланируете.

На мой взгляд Scala хороша для написания сложной бизнес-логики.

Вот ее то мы и собираемся на скале писать. Частично новую, частично - переписывать ту, что есть, когда требуется переделка.

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

Согласен. Для таких вещей в скале много чего есть «из коробки», в отличие от той-же явы, где нужны велосипеды и/или сторонние библиотеки.

В вашем же случае мне показалось, что вы хотите использовать Scala просто как Java непосредственно внутри Java Framework. Может быть и получится. Кто знает?

Оно точно получится, вопрос в том - будет ли это продуктивно и эффективно. Что собственно мы и собираемся проверить.

На самом деле, будь моя воля - я бы использовал что-то попроще скалы, не столь академичное и не служащее больше полигоном для обкатки новых фич языков. Но на данный момент я так и не нашел ничего production ready, удовлетворяющего необходимым критериям (обязательная строгая типизация, работа на jvm и 100% совместимость с имеюшимися явовскими библиотеками, наличие приятных языковых конструкций типа first class functions, closures, pattern matching, перегрузка операторов или что-то на нее похожее, как в скале, функционального подхода к обработке коллеций: foreach, map, filter, и так далее). Довольно интересно в этом плане выглядят kotlin от jetbrains и ceylon от redhat, но они пока-что в стадии глудокой беты.

А что в скале кажется слишком академичным и лишним?

Имхо переусложнены коллекции, т.е. осилить хороший спец их может, если напряжется, а вот среднячку уже сложно.

Система типов тоже далеко не с одного взгляда вкуривается.

Implicits довольно таки запутывают код и периодически делают его разбор сложным.

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

Это из того, что вспомнили сразу.

Implicits и маскирование функций под операнды очевидно не для программистов-пользователей сделано и в любом проекте должно быть запрещено, только для четко выделенных библиотек, и то надо в каждом случае хорошо думать. Но бывают же места, где эти штуки реально к месту и без них никак (например вырубает всякие b.add(new BigInteger(«12345»)).multiple(BigInteger.valueOf(6789)) вместо простого и читаемого кода с перегрузкой операций и implicit conversions). К имитации английского языка (scalatest) я лично отношусь со скепсисом, но кому то наверное нравится...

С коллекциями согласен, и никуда они уже не денутся. Хотя в принципе простые случаи, коих большинство, особого понимания не требуют, простые задачи там вроде решаются просто. Разве что mutable vs immutable им стоило бы сделать одномуквенным префиксом или похожим соглашением, из куска кода без импортов его семантика банально непонятна или может быть неверно понята.

Про систему типов не очень понял, может я её сам не вкурил, но вроде там ничего сложного. Отличия от джавы только в том, что в интерфейсах (трейтах) можно писать реализацию методов. Вроде в 8 джаве это тоже будет.

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

Ну да, что ведет к куче затрат на code review, проверку выдерживания программистами coding style и риски того, что при отсутствии вышеназванного - кто-то особо умный таки запутает код :) Т.е. да, я согласен что в некоторых случаях применение оправдано, но мы же не в идеальном мире. А если инструмент позволяет выстрелить себе в ногу - кто-то обязательно это сделает в итоге.

К имитации английского языка (scalatest) я лично отношусь со скепсисом, но кому то наверное нравится...

Поддерживаю. Опять же с оговоркой про ружье и ногу.

Про систему типов не очень понял, может я её сам не вкурил, но вроде там ничего сложного. Отличия от джавы только в том, что в интерфейсах (трейтах) можно писать реализацию методов. Вроде в 8 джаве это тоже будет.

Я имел ввиду все эти upper|lower bounds, covariance, contravariance итд. Въехать во все это можно и писать какие-то обобщенные библиотечные функции и классы вполне реально, но не сказал бы что легко и просто. Достаточно посмотреть на сигнатуры тех-же методов коллекций чтобы поначалу мозг начал закипать.

Проблема психологическая. Это на форуме можно звиздеть что «на скале можно писать как на java». Можно, только сердце кровью обливается обмазать код аннотациями, джавовскими коллекциями и склеивать все спрингом вместо cake pattern.

Мой совет, пишите большие модули на одном языке. И их можно склеить спрингом. Если у вас хватит маны пользоваться джавовскими коллекциями в Scala, то можете в Scala клеить классы поменьше.

И да, используйте class. object полезен как замена простой фабрике. Вместо двух невнятных конструкторов new Point(int,int), new Point(string) можно использовать Point.fromXY(int, int) и Point.parse(string). При этом в самом классе оставить один конструктор и провести валидацию в одной точке через require. Еще полезен object в алгебраических типах данных когда один из типов без параметров. Как None в Option.

Что мешало заимплементить в ней явовские интерфейсы я до сих пор не понимаю.

Имплисит конвертор просто проксирует чаще всего

Приятный язык очень. Только позволяет писать то что ты думаешь непосредственно, почти без адаптации к хм... нормальным практикам программирования. Потом разгребаешь порыв творчества.

что вы хотите использовать Scala просто как Java непосредственно внутри Java Framework.

А что им терпеть муки работы с XML, XPath, отсутствие банальных кратких map и filter

все эти upper|lower bounds, covariance, contravariance

прямо как в Java. <? super X> или <? extens M> не видели?

Имплицит конвертор не всегда спасает. Он например (что совершенно естественно) не спасает когда мы передаем куда-то параметры внутри Map, как например в случае Spring MVC, когда у нас есть Model, куда надо положить данные. Или когда например метод контроллера возвращает json с помощью @ResponseBody аннотации и jackson, используемый спрингом в качестве сериализатора затыкается на скаловских типах. приходится делать:

import java.util.{Map => JMap}

@ResponseBody def blahBlahBlah(): JMap[String, AnyRef] = {...}

Там еще есть штуки типо toJava и toScala

прямо как в Java. <? super X> или <? extens M> не видели?

Видел :) Но таки в скале все слегка сложнее явы и разбираться в этом хорошим программерам дольше, а плохим - вообще нереально.

Там просто еще пару надстроек есть, но вообщем то же самое. Просто в Java обычно их вообще не пишут, просто лень. Скажу больше, мне архитектор из Java кода их убрал во время review )))

Ну архитектора такого надо-бы железной линейкой по пальчикам за такие шутки :)

Он начинал на Cobol )

Ну архитектора такого надо-бы железной линейкой по пальчикам за такие шутки :)

А какого фига он тогда занимается review явовского кода, а не имеет должности минимум главы департамента, не сидит в личном кабинете попивая вискарь и приставая к секретарше? По возрасту положено уже =)))

Внезапно сошел с трона и решил погонять простых смертных

Там просто еще пару надстроек есть, но вообщем то же самое.

Наткнулся сейчас в скаловской стандартной библиотеке на конструкцию: def toMap[T, U](implicit ev: A <:< (T, U)): immutable.Map[T, U] = {...} И без гугла не смог вкурить, какого-же типа должен быть имплицитный параметр. Так что про «вообщем то же самое» бы не стал говорить.

Внедрения скала в ява проэкт

Подскажите пожалуйста, как внедрить скалу в ява проэкт!

Большое спасибо!