Впечатления от работы с Play! Framework 2.1 + Java

[sha1dy]

Отличная статья!
Как человек, первый раз попробовавший play! еще в дремучей версии 1.0 (там и близко scala не было), версия 2.x и дальше — это чисто scala framework, и если хочется остаться в рамках java (попробуйте найти программистов с опытом scala), то play! 1.2 и только.

За что создателей play! сейчас нещадно критикуют.

[vba]

Немного о политике. Если версия 2.0 курировалась и писалась в zenexity людьми очарованными haskell, f# и scala и которые не могли смотреть на java без рвотных позывов, то версия 2.1 дорабатывалась typesafe так как zenexity не выполнила своих прямых обязательств в срок. Сложно сказать будет ли в play 2.* нормальная поддержка java как в 1.*. Насколько мне известно typesafe определили на проект play именно scala разработчиков, да компания продвигает именно scala на рынке. Скорее всего поддержка java будет болтаться в проруби и в последующих версиях. С другой стороны что сегодня можно сделать с java, который безнадежно склеивает ласты.

[nile1]

С другой стороны что сегодня можно сделать с java, который безнадежно склеивает ласты.

Да ну? Прямо таки склеивает ласты, причем безнадежно?
«А мужики-то не знают...»

[vba]

Да сравнинте хотя бы фичи по датам выпуска в c# и java, там разница в несколько световых лет. Например если говорить про консервативный с++ до даже в его последнем стандарте есть поддержка closure а в java такая фича еще до сих пор под вопросом. Да это сугубо мое личное мение, может от части схожее с авторским. Если вы хотите тут развести троллоло то не советую.

[btd]

Не спора ради: замыкания в с++ и java примерно одинаково реализуются (в с++ это просто объект с перегруженным оператором скобки).
А по делу: пока есть enterprise будет ява!

[vba]

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

[Kipriz]

У меня такое же впечатление. Поэтому надо изучать и что-то отличное от Java, чтобы не просто не потерять работу, но и иметь удовольствие писать на чём-то современном и красивом.

[btd]

Я с такими же мыслями изучал scala =)

[btd]

Насчет cobol'а я бы даже сказал больше — такие АБСки до сих пор продаются (типичный пример accenture alnova).

[nile1]

Я согласен, что Java сильно отстает по синтаксису от C#, и многие фичи (например, generics, annotations) реализованы немного странно и часто в угоду обратной совместимости. Однако говорить, что Java склеивает ласты, мягко говоря, преждевременно.

Весь enterpise сидит на Java, есть куча фреймворков, реализованных на этой платформе. Да взять хотя бы тот же Hadoop, который используется все чаще. Да и в Google, Amazon и других гигантах, использующих opensource, Java используется вовсю.

[vba]

Дык на кобыле (cobol) тоже вон сколько всего написанно. А что собственно вам мешает Hadoop, Lucene итд портировать на c# получится гороздо лучше. Склеивание ласт начинается с забрасывания обогащения фич языка. А то что весь энтерпрайз сидит то заслуги прошлых лет и только sun и если ничего не предринять то будет поздно.

[nile1]

Развитие C# намертво привязано к проприетарному и некроссплатформенному .NET (да, есть Mono, но уровень поддержки не тот, и по возможностям отстает от .NET). Скорее Scala или что-то подобное заменит, но еще не скоро. Ценность Java как раз не в языке, а в самой платформе и ее экосистеме. А под JVM можно писать и на других языках, на той же Scala.

[vba]

Насчет фич в моно есть все необходимое и за ним стоит солидная контора а уровень поддержки нисколько не отличается от j2se. Когда я говорю про склеивание ласт я имею ввиду только java как язык. Одерский как то сказал в одной из своих заметок что java который мы знаем уже давно исчерпал свои возможности а вот jvm нет и именно с ней и стоит работать и развивать ее. Например еклипс как всегда обгадился делая ставку на язык поверх java вместо jvm.

[antonarhipov]

еклипс как всегда обгадился делая ставку на язык поверх java вместо jvm

это про Xtend?

[vba]

Да да он самый, хотя это наверное к этому топику никак не относится

[Googolplex]

в java такая фича еще до сих пор под вопросом

Неправда. Java 8 даёт возможность использования замыканий вполне себе официально: jdk8.java.net/lambda/
По небольшому опыту использования JDK8 могу сразу сказать, что джава очень много приобрела с поддержкой лямбд.

[vba]

Спасибо за информацию, но согласитесь что до последнего момента не было уверености что замыкания войдут в состав 8 версии и х как то уж усиленно двигали в сторону 9. Кстати не замыкания ли виноваты в сдвиге даты выхода 8 версии по сравнению с объявленными датами сразу после покупки java ораклом?

[antonarhipov]

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

[vba]

Ну насколько я помну там вопрос стоял ребром, в 7рку не включили а восмерку планировали через год макс и поползли слухи что в связи с плотным графиком возможно… И тогда видимо народ взбунтовался и решили дату выхода 8 версии сдвинуть. Может я конечно ошибаюсь и это только слухи но изменение даты выхода имело место.

[Googolplex]

Про перенос даты не могу не согласиться, хотя, наверное, я имею в виду немного другое. Я следил за JDK8 внимательно только с конца прошлого года, и там в списке майлстоунов было написано, что релиз (General Availability) будет в мае-июне. Однако около конца февраля-начала марта дата релиза сдвинулась на сентябрь…
И ещё странно, что в самом JDK8 лямбды есть уже давно, но нет библиотеки потоков для работы с коллекциями. Зато есть отдельная сборка, в которой эти библиотеки есть.

[orionll]

Вы не путаете closure с function literals (они же lambda expressions)? Замыкания были в Java чуть-ли не с самого начала

[senia]

Учитывая требование на final (ослабленное с приходом лямбд до effectively final), эти замыкания — не совсем то, что под «замыканиями» подразумевают в других языках.

[orionll]

Ну, функциональные языки как раз поощряют использовать immutable стиль программирования. Так что final, ИМХО, — это даже хорошо

[senia]

Это было бы хорошо, если бы были требуемые инструменты.

Если судить по stackoverflow, то далеко не все так просто могут перейти на чистый функциональный стиль. Для некоторых foldLeft в качестве замены итерирования с сайд-эффектом кажется магией.

Но забудем об этом. Считаем, что мы гуру ФП.
Допустим вам надо за 1 проход по циклу собрать несколько агрегаторов.
В scala это foldLeft с использованием кортежей и pattern metching, в C# это Aggregate с их вариацией на тему анонимных классов.
А вот в java это только итерирование с сайд-эффектами. Ибо кортежи без сопоставления с образцом не читаемы, а анонимные классы такого не позволят.

[norguhtar]

Я в свое время смотрел на Play! но остался на Spring Framework. Причины более мощные и обширные инструментальные средства.

[Kipriz]

Я вас понимаю.
В своё время не смог убедить руководство использовать Play 1.2.x в новом проекте: нужны были расширенные возможности по авторизации и аутентификации не только через web, но и через ldap. Поэтому пришлось остаться на Spring Framework и использовать Spring Security.

[sphinks]

Интересная статья, порадовали ремарки к каждому пункту.:)
Для себя решил вопрос, который давно волновал: попробовать Play 2.1 для маленьких проектов, как что-то более легкое чем Spring, но как понял рановато, лучше видимо еще проще брать что-то аля Spark или тогда уж с Spring не слазить.

[Kipriz]

Как что-то более лёгкое, чем Spring, я бы рекомендовал попробовать Grails. Потом сможете и большие проекты на нём писать :) Groovy не так уж и труден для изучения и понимания, а Grails уже давно вырос и готов для реального применения.

[vba]

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

[sinnus]

В Play! есть засада с транзакциями. Если включить DAO поддержку, то на каждый HTTP запрос будет стартовать транзакция вне зависимости от того, используется ли DAO в течении запроса или нет. Покрайней мере так было в версии 1.2.

[vba]

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

[sinnus]

Это поведение из коробки. О каких доморощеных умельцах речь?

[vba]

В play 1.* нет никакой поддержки dao весь автоматизм реализован для поддержки activerecord паттерна. Далее вы говорите про включение поддержки дао, я не знаю каким способом вы ее включаете но изначально play не предусматривает ничего такого. Вам приходися или все делать руками или же использовать готовый модуль.

[sinnus]

Действительно, DAO нет. Но поведение из коробки с транзакциями есть. О них речь. Activerecord или DAO — тут не принципиально.

[voronaam]

По поводу двойных кавычек в JSON: так ведь стандарт такой! А то, что всякие парсеры позволяют писать без кавычек как раз плохо, потом разработчики удивляются что их JSON не проходит валидацию.

[antonarhipov]

По сравнению с 1.x у Play 2 значительно улучшилось управление зависимостями. В Play 1.x есть плагины для maven и ivy но это всё какие то костыли и нормально настроить проект на раз-два всё равно довольно сложно.
А вот с SBT (как бы ужастен он не был) в Play 2 всё стало заводиться как раз с пол-пинка — выкачал проект, открыл в IDE — можно работать. Соответственно и релизы стало делать как то проще и логичней.

[Kipriz]

Верно подмечено. В Play 2 работать с зависимостями стало легче.

[GapCoder]

Play2.* неплохо интегрируется в maven-проекты
cescoffier.github.io/maven-play2-plugin/maven/release/usage.html

При желании его можно тем-же мавеном подсобрать в war, чтобы не менять деплоймент, например.
Но тогда надо быть аккуратным и помнить про nio и подконфигуривать ваш servlet-container на его поддержку.

[Akela_wolf]

Пробовал Play!, но не устроило несколько вещей, которые упомянуты автором статьи и которые оказались для меня наиболее существенными недостатками: скорость компиляции, отсустствие встроенное защиты от CSFR, отсутствие нормальной документации. До работы с БД даже не дошел.

Результат: сейчас использую Lift. При изменении шаблонов перекомпиляция не требуется, документация есть (хотя тоже не без проблем, но в Google groups обсуждалось множество вопросов и можно воспользоваться коллективным опытом), защита от распространненных уязвимостей (включая XSS и CSFR) «из коробки», интеграция с squeryl. В общем, после Play! я считаю Lift намного более дружественным к разработчику фреймворком.

[k0sh]

Используем play 2.1 в текущем проекте. Так же боремся (почти успешно) с перечисленными трудностями. Из плюсов по сравнению со стандартным JEE — простота разработки и развертывания проекта (особенно радуются этому фронтендеры). Основной недостаток — время (пере)компиляции.