Настолько сырая что линкдин и еще кое кто из очень известный компаний (официальную информацию вы можете узнать позже) изучают возможность перейти в очень коротком будущем на play 2.0. «Фитча» — упаковка в war, скорее бремя чем аватаж. Так же очень важный фактор в пользу второй версии это акка а не доморощенный асинхроно-событийный модуль который понимает Quartz.
А вы попробуйте реализовать похожий тест на последней версии томката и уверен ваши цифры вас удивят. Насколько я понимаю автор запускал приложение без определенных jvm параметров (server или увеличение permGen итд)?
Вы ведь знакомы с play, с принципапи работы netty, mina, grizly и вы должны понимать что если в вашем приложении вы хотите использовать к примеру WebSocket или хотите что написать банальный чат способный выдерживать десятки тысяч одновременных подключений или же ищете асанхронизма то не о каком развертывании play приложения в j2ee контейнере не может быть и речи. Цитируя создателя play, которого всегда передергивает от упоминания про j2ee — «не вижу ни малейшего смысла использовать play с j2ee, актуальная поддержка (речь шла о 1.1) имеется как вынужденная временная мера, но я вам не советую использовать play с j2ee». Конец цитаты, было сказанно почти на всех jug на которых я присутствовал с господином Bort. Но не будем отдалятся от сути и развязывать святых войн. Создатели play не рекомендуют вам использовать онный с j2ee, но если у вас действительно нет другого выбора то используйте.
Так же по мудлям можно использовать и старые добрые jars :) При условии если у вас не бует конфликтов имен.
Ну тут наверное воля большинства взяла свое, хотя про полное желание искоренить поддержку j2ee я слышу от господина Bort уже с версии 1.1 наверное, вот думал наконец то порадовал, аль нет.
А я вам про что говорю, модули на потом, но вот честно никто мне пока точного ответа как они будут выглядеть не дал, т.е. гдать пока на эту тему не вижу смысла
Тут не совсем проблема просто разработчки ранее не тестировали под jvm x64. Насколько мне известно сейчас есть люди которые этим занимаются, неудобства могут наверное возникать (хотя я давно об этом не слышал) во время разработки.
Да я и не обижаюсь, и не оправдываю, стараюсь объяснить как есть. Пока поддержка Java7 не может чисто физически быть в приоритетах так как почти вся команда разработчиков брошена на play 2. А поддержкой (именно поддержкой) веток 1.* занимается всего пара человек. Но я бы не стал говорить что вторая версия вообще непригодна для реальных проектов, использовать можно но на больших проектах могут возникнуть неудобства.
Про java7 это не проблема play а скорее tools которые фреймворк использует, а как вам известно он использует компилятор от eclipse для динамической компиляции изменения и javasist (что коллатерально) для некоторых фич. Я даже не знаю есть ли уже стабильная версия эклипс компилятора для версии 7. А теперь представте работу которую нужно проделать что бы все это интегрировать, хотите помогите сообществу будем только рады. Лично я предпочитаю видеть как play эволюционирует в сторону scala чем в сторону java 7, пора кончать с java :).
Согласен но раньше были и минусы такого подхода, я думаю что модули вернутся но вот в каком виде? Не знаю конечно что из себя представляет данный проект но вот например урезанная версия play 2.0 для rest. А так то верно что они поспешили с выходом 2.0.
Сыровато то он сыровато, но вот невозможность генерирования war это не недароботка а скорее наведение порядка, все хватить деплоить в j2ee, а не нравится пользуйте спринг роу или что то вроде этого. War в play! это пережиток того времени когда сам фреймворк был эмбрионом и использовался в банке в купе с вебсферой. Все хватить вводить людей в заблуждение и лелеять их пустыми надеждами, приложения для netty и j2ee несовместимы!..
Плюс ebean в том что он легче hibernate так как не имеет например сессий (я правда им давно не пользовался с 2010).
А насчет поддержи модулей обождите оно еще вернется, но вот такие модули как поддержка мувена я бы самолично в печь отправлял.
Согласен с вами по поводу движка шаблонов, я сам не понял зачем нужно было это делать, тем более вокруг столько всего уже есть, scalate например (взяли бы его за основу). Тоже самое anorm я так и не понял зачем он понадобился, меня уверяли что это достойная замена орм но для языков с функциональной парадигмой но думаю что эта цель не была достигнута в реализации. По мне так ScalaQuery подходит лучше как замена jpa.
Про развертывание в продакшене тоже постараюсь написать как только закончу очередной проект и на его примере представлю все. Может даже с интеграцией в шеф если интерестно.
Не совсем обратно несовместим, код каторый вы пишете будет несовместим т.к как вы видели очень много поменялось, например теперь метод-экшен должен возвращать результат, редирект более не делается прямым вызовом экшена итд. Остались кирпичики из версии 1.* которые просто перекочевали в версию 2.0, но для финального пользователя наступили координальные изменения. Все это ради достижения принципа java == scala (пропорциональность частей).
С моей точки зрения для такого языка как scala использование jpa не совсем приемлемо. Я не говорю что это невозможно просто подумайте чего стоит достижение immutability в сущнастях jpa, это возможно (сам этого достигал) но какой ценой? Так же одна из основных причин это тяжеловесность jpa и его несовместимость с ActiveRecord à la RoR. Вообще разговоры о «выкидывании» jpa из play core идут уже с версии 1.1.
А вы попробуйте реализовать похожий тест на последней версии томката и уверен ваши цифры вас удивят. Насколько я понимаю автор запускал приложение без определенных jvm параметров (server или увеличение permGen итд)?
Сами понимаете вторая версия вышла недавно так что пока свежих сравнительный работ нет. Вот если хотите несколько ссылок с версией 1.1:
Сранение с кучей других фреймворков
Сравнение с нодом
Не может версия 2 быть более медленней чем 1.1, поверьте мне на слово, а если не хотите то сравните реализацию фитч из версии 1.1 и 2.
Вы ведь знакомы с play, с принципапи работы netty, mina, grizly и вы должны понимать что если в вашем приложении вы хотите использовать к примеру WebSocket или хотите что написать банальный чат способный выдерживать десятки тысяч одновременных подключений или же ищете асанхронизма то не о каком развертывании play приложения в j2ee контейнере не может быть и речи. Цитируя создателя play, которого всегда передергивает от упоминания про j2ee — «не вижу ни малейшего смысла использовать play с j2ee, актуальная поддержка (речь шла о 1.1) имеется как вынужденная временная мера, но я вам не советую использовать play с j2ee». Конец цитаты, было сказанно почти на всех jug на которых я присутствовал с господином Bort. Но не будем отдалятся от сути и развязывать святых войн. Создатели play не рекомендуют вам использовать онный с j2ee, но если у вас действительно нет другого выбора то используйте.
Так же по мудлям можно использовать и старые добрые jars :) При условии если у вас не бует конфликтов имен.
Ну тут наверное воля большинства взяла свое, хотя про полное желание искоренить поддержку j2ee я слышу от господина Bort уже с версии 1.1 наверное, вот думал наконец то порадовал, аль нет.
А я вам про что говорю, модули на потом, но вот честно никто мне пока точного ответа как они будут выглядеть не дал, т.е. гдать пока на эту тему не вижу смысла
Да я и не обижаюсь, и не оправдываю, стараюсь объяснить как есть. Пока поддержка Java7 не может чисто физически быть в приоритетах так как почти вся команда разработчиков брошена на play 2. А поддержкой (именно поддержкой) веток 1.* занимается всего пара человек. Но я бы не стал говорить что вторая версия вообще непригодна для реальных проектов, использовать можно но на больших проектах могут возникнуть неудобства.
Согласен но раньше были и минусы такого подхода, я думаю что модули вернутся но вот в каком виде? Не знаю конечно что из себя представляет данный проект но вот например урезанная версия play 2.0 для rest. А так то верно что они поспешили с выходом 2.0.
Сыровато то он сыровато, но вот невозможность генерирования war это не недароботка а скорее наведение порядка, все хватить деплоить в j2ee, а не нравится пользуйте спринг роу или что то вроде этого. War в play! это пережиток того времени когда сам фреймворк был эмбрионом и использовался в банке в купе с вебсферой. Все хватить вводить людей в заблуждение и лелеять их пустыми надеждами, приложения для netty и j2ee несовместимы!..
Плюс ebean в том что он легче hibernate так как не имеет например сессий (я правда им давно не пользовался с 2010).
А насчет поддержи модулей обождите оно еще вернется, но вот такие модули как поддержка мувена я бы самолично в печь отправлял.
Согласен с вами по поводу движка шаблонов, я сам не понял зачем нужно было это делать, тем более вокруг столько всего уже есть, scalate например (взяли бы его за основу). Тоже самое anorm я так и не понял зачем он понадобился, меня уверяли что это достойная замена орм но для языков с функциональной парадигмой но думаю что эта цель не была достигнута в реализации. По мне так ScalaQuery подходит лучше как замена jpa.