Comments 40
Отличная статья!
Как человек, первый раз попробовавший play! еще в дремучей версии 1.0 (там и близко scala не было), версия 2.x и дальше — это чисто scala framework, и если хочется остаться в рамках java (попробуйте найти программистов с опытом scala), то play! 1.2 и только.
За что создателей play! сейчас нещадно критикуют.
Как человек, первый раз попробовавший play! еще в дремучей версии 1.0 (там и близко scala не было), версия 2.x и дальше — это чисто scala framework, и если хочется остаться в рамках java (попробуйте найти программистов с опытом scala), то play! 1.2 и только.
За что создателей play! сейчас нещадно критикуют.
Немного о политике. Если версия 2.0 курировалась и писалась в zenexity людьми очарованными haskell, f# и scala и которые не могли смотреть на java без рвотных позывов, то версия 2.1 дорабатывалась typesafe так как zenexity не выполнила своих прямых обязательств в срок. Сложно сказать будет ли в play 2.* нормальная поддержка java как в 1.*. Насколько мне известно typesafe определили на проект play именно scala разработчиков, да компания продвигает именно scala на рынке. Скорее всего поддержка java будет болтаться в проруби и в последующих версиях. С другой стороны что сегодня можно сделать с java, который безнадежно склеивает ласты.
С другой стороны что сегодня можно сделать с java, который безнадежно склеивает ласты.
Да ну? Прямо таки склеивает ласты, причем безнадежно?
«А мужики-то не знают...»
Да сравнинте хотя бы фичи по датам выпуска в c# и java, там разница в несколько световых лет. Например если говорить про консервативный с++ до даже в его последнем стандарте есть поддержка closure а в java такая фича еще до сих пор под вопросом. Да это сугубо мое личное мение, может от части схожее с авторским. Если вы хотите тут развести троллоло то не советую.
Не спора ради: замыкания в с++ и java примерно одинаково реализуются (в с++ это просто объект с перегруженным оператором скобки).
А по делу: пока есть enterprise будет ява!
А по делу: пока есть enterprise будет ява!
Согласен с вами, на мой взгляд с java дела обстоят точно так же как с cobol который до сих пор можно встретить во многих организациях например в крупных банках Люксембурга. Платформа будет существовать еще достаточно долго, наверное столько сколько будет спрос даже если большенство разработчиков будут отдавать предпочтения другим языкам.
Я согласен, что Java сильно отстает по синтаксису от C#, и многие фичи (например, generics, annotations) реализованы немного странно и часто в угоду обратной совместимости. Однако говорить, что Java склеивает ласты, мягко говоря, преждевременно.
Весь enterpise сидит на Java, есть куча фреймворков, реализованных на этой платформе. Да взять хотя бы тот же Hadoop, который используется все чаще. Да и в Google, Amazon и других гигантах, использующих opensource, Java используется вовсю.
Весь enterpise сидит на Java, есть куча фреймворков, реализованных на этой платформе. Да взять хотя бы тот же Hadoop, который используется все чаще. Да и в Google, Amazon и других гигантах, использующих opensource, Java используется вовсю.
Дык на кобыле (cobol) тоже вон сколько всего написанно. А что собственно вам мешает Hadoop, Lucene итд портировать на c# получится гороздо лучше. Склеивание ласт начинается с забрасывания обогащения фич языка. А то что весь энтерпрайз сидит то заслуги прошлых лет и только sun и если ничего не предринять то будет поздно.
Развитие C# намертво привязано к проприетарному и некроссплатформенному .NET (да, есть Mono, но уровень поддержки не тот, и по возможностям отстает от .NET). Скорее Scala или что-то подобное заменит, но еще не скоро. Ценность Java как раз не в языке, а в самой платформе и ее экосистеме. А под JVM можно писать и на других языках, на той же Scala.
Насчет фич в моно есть все необходимое и за ним стоит солидная контора а уровень поддержки нисколько не отличается от j2se. Когда я говорю про склеивание ласт я имею ввиду только java как язык. Одерский как то сказал в одной из своих заметок что java который мы знаем уже давно исчерпал свои возможности а вот jvm нет и именно с ней и стоит работать и развивать ее. Например еклипс как всегда обгадился делая ставку на язык поверх java вместо jvm.
в java такая фича еще до сих пор под вопросом
Неправда. Java 8 даёт возможность использования замыканий вполне себе официально: jdk8.java.net/lambda/
По небольшому опыту использования JDK8 могу сразу сказать, что джава очень много приобрела с поддержкой лямбд.
Спасибо за информацию, но согласитесь что до последнего момента не было уверености что замыкания войдут в состав 8 версии и х как то уж усиленно двигали в сторону 9. Кстати не замыкания ли виноваты в сдвиге даты выхода 8 версии по сравнению с объявленными датами сразу после покупки java ораклом?
Вы немного с версиями вроде напутали. Непонятно, какие могут быть сомнения, что лямбды могут не войти в 8ку.
Ну насколько я помну там вопрос стоял ребром, в 7рку не включили а восмерку планировали через год макс и поползли слухи что в связи с плотным графиком возможно… И тогда видимо народ взбунтовался и решили дату выхода 8 версии сдвинуть. Может я конечно ошибаюсь и это только слухи но изменение даты выхода имело место.
Про перенос даты не могу не согласиться, хотя, наверное, я имею в виду немного другое. Я следил за JDK8 внимательно только с конца прошлого года, и там в списке майлстоунов было написано, что релиз (General Availability) будет в мае-июне. Однако около конца февраля-начала марта дата релиза сдвинулась на сентябрь…
И ещё странно, что в самом JDK8 лямбды есть уже давно, но нет библиотеки потоков для работы с коллекциями. Зато есть отдельная сборка, в которой эти библиотеки есть.
И ещё странно, что в самом JDK8 лямбды есть уже давно, но нет библиотеки потоков для работы с коллекциями. Зато есть отдельная сборка, в которой эти библиотеки есть.
Вы не путаете closure с function literals (они же lambda expressions)? Замыкания были в Java чуть-ли не с самого начала
Учитывая требование на final (ослабленное с приходом лямбд до effectively final), эти замыкания — не совсем то, что под «замыканиями» подразумевают в других языках.
Ну, функциональные языки как раз поощряют использовать immutable стиль программирования. Так что final, ИМХО, — это даже хорошо
Это было бы хорошо, если бы были требуемые инструменты.
Если судить по stackoverflow, то далеко не все так просто могут перейти на чистый функциональный стиль. Для некоторых foldLeft в качестве замены итерирования с сайд-эффектом кажется магией.
Но забудем об этом. Считаем, что мы гуру ФП.
Допустим вам надо за 1 проход по циклу собрать несколько агрегаторов.
В scala это foldLeft с использованием кортежей и pattern metching, в C# это Aggregate с их вариацией на тему анонимных классов.
А вот в java это только итерирование с сайд-эффектами. Ибо кортежи без сопоставления с образцом не читаемы, а анонимные классы такого не позволят.
Если судить по stackoverflow, то далеко не все так просто могут перейти на чистый функциональный стиль. Для некоторых foldLeft в качестве замены итерирования с сайд-эффектом кажется магией.
Но забудем об этом. Считаем, что мы гуру ФП.
Допустим вам надо за 1 проход по циклу собрать несколько агрегаторов.
В scala это foldLeft с использованием кортежей и pattern metching, в C# это Aggregate с их вариацией на тему анонимных классов.
А вот в java это только итерирование с сайд-эффектами. Ибо кортежи без сопоставления с образцом не читаемы, а анонимные классы такого не позволят.
Я в свое время смотрел на Play! но остался на Spring Framework. Причины более мощные и обширные инструментальные средства.
Интересная статья, порадовали ремарки к каждому пункту.:)
Для себя решил вопрос, который давно волновал: попробовать Play 2.1 для маленьких проектов, как что-то более легкое чем Spring, но как понял рановато, лучше видимо еще проще брать что-то аля Spark или тогда уж с Spring не слазить.
Для себя решил вопрос, который давно волновал: попробовать Play 2.1 для маленьких проектов, как что-то более легкое чем Spring, но как понял рановато, лучше видимо еще проще брать что-то аля Spark или тогда уж с Spring не слазить.
В Play! есть засада с транзакциями. Если включить DAO поддержку, то на каждый HTTP запрос будет стартовать транзакция вне зависимости от того, используется ли DAO в течении запроса или нет. Покрайней мере так было в версии 1.2.
Плей как раз и не был задуман для работы с dao он предусматривал работу а ля рор с актив рекордом, а уш что там всякие доморощенные умелцы накрутили своими кривыми руками с dao то это на их и собственно ваш страх и риск.
Это поведение из коробки. О каких доморощеных умельцах речь?
В play 1.* нет никакой поддержки dao весь автоматизм реализован для поддержки activerecord паттерна. Далее вы говорите про включение поддержки дао, я не знаю каким способом вы ее включаете но изначально play не предусматривает ничего такого. Вам приходися или все делать руками или же использовать готовый модуль.
По поводу двойных кавычек в JSON: так ведь стандарт такой! А то, что всякие парсеры позволяют писать без кавычек как раз плохо, потом разработчики удивляются что их JSON не проходит валидацию.
По сравнению с 1.x у Play 2 значительно улучшилось управление зависимостями. В Play 1.x есть плагины для maven и ivy но это всё какие то костыли и нормально настроить проект на раз-два всё равно довольно сложно.
А вот с SBT (как бы ужастен он не был) в Play 2 всё стало заводиться как раз с пол-пинка — выкачал проект, открыл в IDE — можно работать. Соответственно и релизы стало делать как то проще и логичней.
А вот с SBT (как бы ужастен он не был) в Play 2 всё стало заводиться как раз с пол-пинка — выкачал проект, открыл в IDE — можно работать. Соответственно и релизы стало делать как то проще и логичней.
Верно подмечено. В Play 2 работать с зависимостями стало легче.
Play2.* неплохо интегрируется в maven-проекты
cescoffier.github.io/maven-play2-plugin/maven/release/usage.html
При желании его можно тем-же мавеном подсобрать в war, чтобы не менять деплоймент, например.
Но тогда надо быть аккуратным и помнить про nio и подконфигуривать ваш servlet-container на его поддержку.
cescoffier.github.io/maven-play2-plugin/maven/release/usage.html
При желании его можно тем-же мавеном подсобрать в war, чтобы не менять деплоймент, например.
Но тогда надо быть аккуратным и помнить про nio и подконфигуривать ваш servlet-container на его поддержку.
Пробовал Play!, но не устроило несколько вещей, которые упомянуты автором статьи и которые оказались для меня наиболее существенными недостатками: скорость компиляции, отсустствие встроенное защиты от CSFR, отсутствие нормальной документации. До работы с БД даже не дошел.
Результат: сейчас использую Lift. При изменении шаблонов перекомпиляция не требуется, документация есть (хотя тоже не без проблем, но в Google groups обсуждалось множество вопросов и можно воспользоваться коллективным опытом), защита от распространненных уязвимостей (включая XSS и CSFR) «из коробки», интеграция с squeryl. В общем, после Play! я считаю Lift намного более дружественным к разработчику фреймворком.
Результат: сейчас использую Lift. При изменении шаблонов перекомпиляция не требуется, документация есть (хотя тоже не без проблем, но в Google groups обсуждалось множество вопросов и можно воспользоваться коллективным опытом), защита от распространненных уязвимостей (включая XSS и CSFR) «из коробки», интеграция с squeryl. В общем, после Play! я считаю Lift намного более дружественным к разработчику фреймворком.
Используем play 2.1 в текущем проекте. Так же боремся (почти успешно) с перечисленными трудностями. Из плюсов по сравнению со стандартным JEE — простота разработки и развертывания проекта (особенно радуются этому фронтендеры). Основной недостаток — время (пере)компиляции.
Sign up to leave a comment.
Впечатления от работы с Play! Framework 2.1 + Java