Компания Oracle выпустила (https://blogs.oracle.com/java/entry/glassfish_server_open_so...)
открытый сервер приложений GlassFish Server Open Source Edition 4.1 (https://glassfish.java.net), предоставляющий полную реализацию спецификации Java EE 7 (http://www.oracle.com/technetwork/java/javaee/overview/index...) (Java Platform, Enterprise Edition 7), как в форме web профиля (Java EE 7 Web Profile), так и полного профиля (Java EE 7 Full Platform). Включение выражения "Open Source Edition" в название продукта сигнализирует о прекращении его коммерческой поддержки, о чём было заявлено Oracle в ноябре прошлого года. Пользователям, которым требуется коммерческая поддержка, рекомендовано использовать продукт Oracle WebLogic Server. Код GlassFish распространяется под двумя лицензиями: CDDL v1.0 и GPL v2.
Особенности (https://glassfish.java.net/docs/4.1/release-notes.pdf) выпуска:
- Добавлена поддержка Java 8 (http://www.opennet.me/opennews/art.shtml?num=39334), CDI 1.2 (https://jcp.org/aboutJava/communityprocess/mrel/jsr346/index...) и WebSocket 1.1 (https://www.websocket.org/). Обеспечена полная совместимость со свежими спецификациями Java EE;
- Закрыто более тысячи отчётов об ошибках. Сообщается, что несмотря на прекращение предоставления коммерческой поддержки, подход к поддержанию качества не изменился;
- Добавлен компонент Tyrus (https://tyrus.java.net/) с реализацией Java API для использования WebSocket 1.1. Кроме элементов спецификации WebSocket в Tyrus также реализованы дополнительные возможности, такие как средства регулирования числа открытых сеансов, доступ к метрикам через JMX, поддержка пересоединений клиента, поддержка прокси, оптимизированная широковещательная передача сообщений для всех открытых сокетов;
- Включён новый выпуск Jersey (https://jersey.java.net/) с реализацией JAX-RS 2.0 для создания RESTful web-сервисов на Java. В новом выпуске добавлена поддержка нового клиентского API для использования OAuth 1 и OAuth 2, улучшены средства диагностики проблем, предоставлен доступ к метрикам через JMX, обеспечена возможности сохранения в лог трассировки на уровне отдельных запросов, добавлена поддержка инициирования пересоединения клиента со стороны сервера;- В OpenMQ (https://mq.java.net/) с поддержкой JMS 2.0 добавлена возможность создания каналов связи при помощи протокола WebSocket. Для использования доступно два типа клиентов WebSocket: mqstomp c поддержкой протокола STOMP 1.2 и mqjsonstomp, который отличается передачей сообщений поверх STOMP 1.2 в формате JSON;
- Обновлён Java EE 7 SDK, который теперь распространяется в форме zip-архива и отличается простым процессом установки.
URL: https://blogs.oracle.com/java/entry/glassfish_server_open_so...
Новость: http://www.opennet.me/opennews/art.shtml?num=40554
смотрю WebSocket уже почти во всех ява-приложения встраивают...
не удивительно, java очень часто в веб применяется. сам хочу попробовать поработать с этой технологией да времени не хватает
Просто любопытно. А зачем вам Java в Web?Видел всякие ужасы, сделанные на базе tomcat. Приемники по проекту отказываются с ними работать.
Видел ужасы под названием UCS-ы и iLO. Лучше бы делали GUI-клиенты работающие со штатным cli (по ssh), если уж нужно помочь людям, способным работать только с мышкой. А GUI-шки эти делать лучше на чём угодно, но только не на Java.
Не знаю, может у меня опыт не удачный, но по моему, Java как и server-side, так и client-side себя не оправдывает. Поэтому, собственно, и интересуюсь. Зачем нужен Java в Web?
RESTful web-сервисы на Java как раз и позволяют писать клиентские приложения на любом языке программирования и использовать любую технологию для Web-взаимодействия клиента с сервером.
> RESTful web-сервисы на Java как раз и позволяют писать клиентские приложения на
> любом языке программирования и использовать любую технологию для Web-взаимодействия клиента
> с сервером.А причём тут Java? RESTful сервисы, например, очень любят делать на Ruby. И я не вижу никакой проблемы делать RESTful сервисы на любом популярном языке в данной области.
>> RESTful web-сервисы на Java как раз и позволяют писать клиентские приложения на
>> любом языке программирования и использовать любую технологию для Web-взаимодействия клиента
>> с сервером.
> А причём тут Java? RESTful сервисы, например, очень любят делать на Ruby.
> И я не вижу никакой проблемы делать RESTful сервисы на любом
> популярном языке в данной области.Потому что в Java наиболее стандартизирован подход к управлению жизненным циклом ПО. Причём это не завязано на какую-то определённую операционную систему. Всё везде достигается однообразными методами: ставим JRE/JDK, JEE-сервер, на клиенте работает браузер или толстый Java Web Start-клиент. Серверные приложения самоконфигурятся дескрипторами развёртывания, главное: чтобы ресурсы были в наличии.
Вы так говорите как быдто на любом другом языГе/фреймворке оно по другому...
У жабы только одно реальное преимущество - оно позволяет малоквалифиуированным прогерам создавать хоть как то работающий код. И в следствие этого - в штатах например заявили что не будут продлевать рабочие визы для 1 млн жабберов - надо было видеть штурм канадской границы после этого :)PS: Справедливости ради - это был самый крузис, после того как отпустило штаты этом миллион жабобыдлкодящих индусов утилизировали, трудятся на пользу капиталистического хозяйства [не их] Родины :)
>>> RESTful web-сервисы на Java как раз и позволяют писать клиентские приложения на
>>> любом языке программирования и использовать любую технологию для Web-взаимодействия клиента
>>> с сервером.
>> А причём тут Java? RESTful сервисы, например, очень любят делать на Ruby.
>> И я не вижу никакой проблемы делать RESTful сервисы на любом
>> популярном языке в данной области.
> Потому что в Java наиболее стандартизирован подход к управлению жизненным циклом ПО.
> Причём это не завязано на какую-то определённую операционную систему. Всё везде
> достигается однообразными методамиМне кажется, что вам очень понравится Ruby on Rails, например… Хотя бы горазде менее монструозно-костылявое. IMHO, комментатор выше прав, утверждая, что данное свойство можно наблюдать для любого популярного языка программирования в данной области.
>: ставим JRE/JDK, JEE-сервер, на клиенте работает браузер
> или толстый Java Web Start-клиентВот тут уже начинается огромное количество проблем. Я не знаю почему так, может потому что программисты допускают тонну UB или ещё что, но почему-то конкретный Java Web сервис нужно запускать используя конкретную версию JRE (или что там ещё). Иначе нас приветствует куча глюков, а то и вообще не работает. И очень часто делают завязку именно на реализации от Oracle (Sun), которые не очень-то свободные.
А вообще, Java-хрени — это, грубо говоря, единственные приложения, выполняемые на моих компьютерах, где я не могу поменять размер шрифта (от чего приходится голову пододвигать к монитору, либо использовать «экранную лупу»), посмотреть исходный код или вообще понять почему возник тот или иной глюк. Вероятно, я просто слишком безграмотен.
> Серверные приложения самоконфигурятся дескрипторами
> развёртывания, главное: чтобы ресурсы были в наличии.Кстати о ресурсах, я хренею сколько ОЗУ и ЦП утилизируется теми Java-приложениями, с которыми сталкивался я. Возможно мне просто не повезло.
> Причём это не завязано на какую-то определённую операционную систему. Всё везде достигается однообразными методами
Нам приходилось использовать целую виртуалку Windows и с Sun Java конкретной версии на ней, чтобы подсоединиться к iLO (старому) или UCS. При попытках использовать другую комбинацию хватали те или иные глюки внутри Java-приложения (либо в некоторых случаях просто очень сильные тормоза).
Вообще, почитав комментарии, у меня сложилось впечатление, что Java-программисты видели в жизни только два языка: PHP и Java. Притом первый изучали поверхностно и вообще не интересовались всякими Akelos-ами (если говорить про разработку web-сервисов) и т.п. Грубо говоря, это обожатели больших framework-ов, которые решили не смотреть на framework-и для других ЯП.
> Мне кажется, что вам очень понравится Ruby on Rails, например…Я вообще не понимаю Ruby. Это хипстерский язык.
> Вот тут уже начинается огромное количество проблем. Я не знаю почему так, может потому что программисты допускают тонну UB или ещё что, но почему-то конкретный Java Web сервис нужно запускать используя конкретную версию JRE (или что там ещё). Иначе нас приветствует куча глюков, а то и вообще не работает. И очень часто делают завязку именно на реализации от Oracle (Sun), которые не очень-то свободные.
Если управление жизненным циклом не внедрено в процесс и не используется, то глюки в сломанной "цепочке" не заставят себя долго ждать.
> А вообще, Java-хрени — это, грубо говоря, единственные приложения, выполняемые на моих компьютерах, где я не могу поменять размер шрифта (от чего приходится голову пододвигать к монитору, либо использовать «экранную лупу»), посмотреть исходный код или вообще понять почему возник тот или иной глюк. Вероятно, я просто слишком безграмотен.
Вероятно. Может быть всё захардкожено по самое не могу.
> Кстати о ресурсах, я хренею сколько ОЗУ и ЦП утилизируется теми Java-приложениями, с которыми сталкивался я. Возможно мне просто не повезло.
Возможно вам не повезло с людьми, которые производили такие неэффективные продукты, либо элементарное скупердяйство на приобретение подходящего железа сыграло шутку с жадиной — кто вас знает.
> Грубо говоря, это обожатели больших framework-ов, которые решили не смотреть на framework-и для других ЯП.
Мультиязычность до добра не доводит. Вон, .NET проповедовали поддержку множества языков. И где они теперь?
Вернее будет: Java-разразботчики — это обожатели чётких спецификаций. А фреймворки, которые реализуют эти спецификации, можно-нужно смотреть и сравнивать.
>> Кстати о ресурсах, я хренею сколько ОЗУ и ЦП утилизируется теми Java-приложениями, с которыми сталкивался яПоддерживаю, так же вижу и сравниваю проекты с которыми работали коллеги Явисты, web приложения довольно много берут, учитывая малую нагрузку.
Т.е. если для Явы требуется отдельное/настраиваемое управление памятью, то зачем это нужно? когда есть в разы быстрее C/C++
>>> Кстати о ресурсах, я хренею сколько ОЗУ и ЦП утилизируется теми Java-приложениями, с которыми сталкивался я
> Поддерживаю, так же вижу и сравниваю проекты с которыми работали коллеги Явисты,
> web приложения довольно много берут, учитывая малую нагрузку.Там просто стартовый порог, на развёртывание инфраструктуры, но вас же не волнует что mysql по умолчанию 40% оперативки отъедает ( просто 40% в настройках по умолчанию, насколько помню ), а для работы БД ( любой большой ) рекомендуется выделять почти всю свободную память, но это не для тех БД что key-value хранят ( хотя тонкой настройкой тех просто не интересовался ).
> Т.е. если для Явы требуется отдельное/настраиваемое управление памятью, то зачем это нужно?
> когда есть в разы быстрее C/C++потому что на С разрабатывать большой портал можно будет до конца жизни ( особенно чтобы производительность в большом приложении была сравнима с JEE ), а потом ещё в гробу отлаживать, и после этого после коллапса вселенной переписывать если вдруг в компании не очень сильно поменяется бизнес процесс. JIT вообще достаточно хитрая штука.
P.s. как то слышал забавную фразу, о том что программисты на больших проектах в 90% случаях не правильно указывают узкие места, просто анализирую код и структуру проекта.
Там Оракл, на отдельных серверах, речь шла только о серверах приложений Ява, которые крутятся на сервере отдельно.-
К тому же питону можно прикручивать расширения на C/C++ в критичных местах. Меньшее потребление памяти и прилич скорость.В фейсбуке, бэкенд за php на C++, поддерживают, никто и не говорит что всё от идо надо писать на С/C++ c нуля.
> Там Оракл, на отдельных серверах, речь шла только о серверах приложений Ява,
> которые крутятся на сервере отдельно.
> -
> К тому же питону можно прикручивать расширения на C/C++ в критичных местах.
> Меньшее потребление памяти и прилич скорость.
> В фейсбуке, бэкенд за php на C++, поддерживают, никто и не говорит
> что всё от идо надо писать на С/C++ c нуля.facebook очень большая компания, они сейчас и на асм-е переписать могут, и свою кафедру в институте открыть, что бы своему языку обучать, давайте с чем то поближе к массовой реальности.
p.s. у того же FB проблемы с PHP и возникли, да и бизнес у них "специфичный" им при добавлении функционала гораздо важней скорость добавления а не производительность.
> facebook очень большая компанияОк, яндекс, рамблер - поменьше, и то же С++
>> facebook очень большая компания
> Ок, яндекс, рамблер - поменьше, и то же С++Да давайте банк с 3-мя отделениями возьмём, или автосалон с 10 салонами, что вы всё на компании работающие только в сети смотрите?
Сколько процентов программистов всего в них работает, из общего количества?
а зачем тогда Ява? если нагрузка никакая.
> а зачем тогда Ява? если нагрузка никакая.что-бы время не тратить, особенно в случае роста.
тогда на Python будет и проще и быстрей писать и сотрудников ещё и дешевле нанимать!
> тогда на Python будет и проще и быстрей писать и сотрудников ещё
> и дешевле нанимать!Это большое заблуждение ИМХО.
Java в web сама по себе не интересна - дешевле использовать толпу PHP-студентов.Java в web применяется когда само основная часть это не UI и эта части написана на java.
К примеру всякие системы документооборота, интеграции и прочие специализированные системы.И web идет в придачу =)
PS есть системы написанные на java чисто для web. Но в этом случае уже вопрос вкуса ... и умений команды разработчиков (дешевле написать на том, что знают, чем перетянуть команду на другой язык).
... и возможность поддержки в будущем.
Java вряд-ли настолько эволюционирует чтобы код Java5 был непонятен разрабом на Java15, а вот с PHP может разное приключиться.
> Java вряд-ли настолько эволюционирует чтобы код Java5 был непонятен разрабом на Java15,
> а вот с PHP может разное приключиться.Да что вы так к этому PHP уцепились? На свете только два языка — PHP и Java?
>> Java вряд-ли настолько эволюционирует чтобы код Java5 был непонятен разрабом на Java15,
>> а вот с PHP может разное приключиться.
> Да что вы так к этому PHP уцепились? На свете только два
> языка — PHP и Java?там было
" дешевле использовать толпу PHP-студентов."Да предложите распространённые альтернативы со схожими/лучшими перспективами для ПО которе должно прожить хотя-бы 10-к лет ( без глобальных переписываний )
Тем кому дешевле использовать php программистов их и используют. На java вы можете написать точно такой же сайт что и на php, зря вы считаете что это какой-то избранный язык на котором пишутся специализированные системы. Вся фишка в том что на php подобные системы написать крайне проблематично и затратно по ресурсам и времени. И поскольку в данной нише рынка альтернатив java нет, то это и воспринимается как основная ниша для java программистов.
Вот обычный пример как человек написал на java простенький интернет магазин буквально на коленках http://programador.ru/simple-jsp-servlet-based-shop/
Мда, прочитал, итого:Самое начало - хостинг дороже.
Далее - автор сообщает что 21 первый век на дворе, поэтому используйте Яваскрипт-библиотеки. (не говоря уже что за 4 года с момента написания статьи Яваскрипт полез в серверную часть, заметно ускорился и оброс огромным количеством фреймворков)Так и в чем тогда преимущество Явы?
Преимущество зависит от того что вы хотите сделать. К примеру вам нужно ускорить работу с базой данных - используете JNDI. Нужно удобно хранить объекты - используете Hibernate, это значительно ускоряет разработку и снижает количество ошибок. Вот для сравнения код который я сейчас пишу для сохранения или обновления объекта с использованием google фреймворка Guice:private Provider<EmtityManager> entityManagerProvider;
@Transactional
@Override
public void saveOrUpdate(Entity entity) {
entityManagerTransaction.merge(entity);
}а вот удаления
@Transactional
@Override
public void remove(Entity entity) {
entitiManagerProvider.remove(entity);
}
Обратите внимание что в этим кодом я могу и сохранить объект и обновить те поля объекта которые надо обновить и имею при этом транзакционность на уровне приложения и там же идёт обработка Ecxeption. Для того чтобы написать такой же код на PHP потребуется полтора экрана текста. Сравните это с другими языками и если не сочтёте преимуществом то просто продолжайте использовать тот другой язык что уже используете.
По делу мне сейчас лень беседовать, поэтому просто «приебусь к орфографии». :)IMHO, у вас очепятки:
> private Provider<EmtityManager> entityManagerProvider;
> entitiManagerProvider.remove(entity);—
> EmtityManager
> entitiManagerProvider
Думаю так делать не разумно, если сказать нечего глупо искать к чему бы придраться
> Думаю так делать не разумно, если сказать нечего глупо искать к чему
> бы придратьсяЭто было что-то вроде шутки. На самом деле я просто заметил опечатки и хотел помочь вам улучшить свой код (если это copy&paste из реального кода).
спасибо за помощь, но то не копипаст. я этот код прямо в окне и напечатал, на опечатку не обратил внимание. Eclipse бы мне выдал ошибку, тут опечатка осталась не замечена.
> Сравните это с другими языками и если не сочтёте преимуществом
> то просто продолжайте использовать тот другой язык что уже используете.Не буду приводить код с ОРМ-реализацими Python-фреймворков (SqlAlchemy, Django-ORM), но код не больше, с текущим функционалом. Советую посмотреть, мне кажется тебе лаконичность Python понравиться.
почему не будете? напишите пусть люди заценят, будет возможность сравнить
По сути Python ORMы действует так же как и Хибернейт, все доки с примерами доступны, сравни:
http://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html/ch...http://docs.sqlalchemy.org/en/latest/orm/session.html#merging
https://docs.djangoproject.com/en/dev/ref/models/instances/#...
да, действительно ORM очень похожи. но вот connection pooling я сомневаюсь что в том же питоне есть
есть
чтож, тогда действительно можно порадоваться за Python программистов, у них есть все инструменты чтобы делать всё тоже что можно делать на Java )
>> Сравните это с другими языками и если не сочтёте преимуществом
>> то просто продолжайте использовать тот другой язык что уже используете.
> Не буду приводить код с ОРМ-реализацими Python-фреймворков (SqlAlchemy, Django-ORM),
> но код не больше, с текущим функционалом. Советую посмотреть, мне кажется
> тебе лаконичность Python понравиться.Осталось быть уверенным что через 10 лет можно будет найти человека со знанием текущей ( на 2014 год )версии "питона" что-бы поправить кусочек кода, а то ph10000 может стать сильно несовместимым.
>>> Сравните это с другими языками и если не сочтёте преимуществом
>>> то просто продолжайте использовать тот другой язык что уже используете.
>> Не буду приводить код с ОРМ-реализацими Python-фреймворков (SqlAlchemy, Django-ORM),
>> но код не больше, с текущим функционалом. Советую посмотреть, мне кажется
>> тебе лаконичность Python понравиться.
> Осталось быть уверенным что через 10 лет можно будет найти человека со
> знанием текущей ( на 2014 год )версии "питона" что-бы поправить кусочек
> кода, а то ph10000 может стать сильно несовместимым.Это байки в стиле "падающей плазмы KDE на ФриБСД2"? от 2 да 2.7 - более 10 лет - не было кардинальных сломов и код очень хорошо читается.
Ну 3й, согласен, резко поменяли ряд вещей, но это вполне тот же язык, и его любой знающий ранние версии сможет использовать. Кто пишет на питон, тот знает что писать/читать 2 и 3 версии никаких проблем нет.
Что касается Явы я видел как свежий программист рылся в старых доках явы, при работе с проектом на древней версии Явы, т.к. всплывали всякие особенности для него не знакомые.
> Ну 3й, согласен, резко поменяли ряд вещей, но это вполне тот же
> язык, и его любой знающий ранние версии сможет использовать. Кто пишет
> на питон, тот знает что писать/читать 2 и 3 версии никаких
> проблем нет.так 10000 намёк на Phyton 3000
> Что касается Явы я видел как свежий программист рылся в старых доках
> явы, при работе с проектом на древней версии Явы, т.к. всплывали
> всякие особенности для него не знакомые.Не ну если он использовал особенности J7 то код J5 может просто казаться непонятным ( просто привыкли к упрощённым конструкциям ) или просто библиотеки поменялись ( по функционалу), а вот так чтобы конструкция J5 не заработала, не знаю может и возможно но "не верится" что-то...
Мне кажется, что особенность Java в том, что можно легко воссоздать среду конфигурацию использовавшуюся во время разработки, взять код и перенести его на новую платформу, на счёт питона не знаю ( но по сути он вроде похожий на Java, просто среди его "разрабов" не хватает людей не любящих сильных перемен ).
потому что в java есть целый стек технологий EE. К примеру для ORM данных используется Hibernate, DataNucleus или можно по простому с использованием JDBC коннектора к базе данных. При этом можно использовать JNDI интерфейс, это значительно ускоряет работу поскольку используется пул соединений с базой данных. При этом имеем транзакционность на уровне приложения или можно задействовать транзакции даже более глобально, между распределёнными системами используя JTA. И это только часть готового к применению разработчиком стека технологий "javax.persistence." и "javax.transaction.".
То что вы перечислили мне не знакомо, я с этим не работал. Технологий много, помимо стандартного стека Java EE есть ещё всякие фреймворки.
Если вам страшно от ужасов которые вы видели то в этом тоже есть плюс, ведь теперь вы знаете как делать не нужно )
Мда, сразу видно что других языков вы не знаете. Всё что вы перечислили есть и в Python, плюс для скорости выполнения там есть своя реализация JIT.Особенно меня доставляет зацикленность ява программистов на технологиях, которые уже начинают увядать и на смену которым приходят более легковесные решения. Тот же SOAP как пример.
> Мда, сразу видно что других языков вы не знаете. Всё что вы
> перечислили есть и в Python, плюс для скорости выполнения там есть
> своя реализация JIT.
> Особенно меня доставляет зацикленность ява программистов на технологиях, которые уже начинают
> увядать и на смену которым приходят более легковесные решения. Тот же
> SOAP как пример.Я поверхностно знаю PHP и Perl, есть с чем сравнивать, Python я не знаю и сравнивать возможность действительно нет. Вы можете продолжать использовать Python я тут не ставлю себе задачи отговорить вас от его использования.
По поводу SOAP вы сейчас сказали глупость, SOAP более тежеловесное решение сериализации чем JSON и об этом даже в википедии написано:
"Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки. В системах, где скорость важна, чаще используется пересылка XML-документов через HTTP напрямую, где параметры запроса передаются как обычные HTTP-параметры."
Судя по такому вашему высказываю я думаю вы очень поверхностно разбираетесь в том о чём пишите.
Ты не понял, я и писал что СОАП - это г.мамонта, которое юзают явисты очень активно, работал с разными людьми. (Ибо сериализация в объекты идет искаропки, но то что при больших данных идет оверхеад с дополнит. данными все забывают.)
> не удивительно, java очень часто в веб применяется. сам хочу попробовать поработать
> с этой технологией да времени не хватаетпосмотрев на Яву имея другой бэграунд, у неё просто следующие фичи, благодаря которым она не умирает:
1)В целом стабильное, без резких сломов между релизами развитие. Хотя чувствуется фрагментарность в поддержке определенными библиотеками, определенных версий, это уже минус, т.к. уже не скажешь что все 100500 библиотек работают с такой-то версией (или есть подвохи в работе оных).
2)Поддержка и участие в развитии крупной компании за спиной.
3)Популярность Андроида, и соотв. написание под него приложений на яве.
Если даже последний пункт сойдет на нет, я думаю, ява будет по немногу становится нишевым языком для легаси-систем, ибо сейчас на ней в WEB генерировать "яваскрипт" (JSON) для браузера можно и без неё, и написать это можно быстрее. Будет меньше молодежи, и соответственно новых опенсоурс проектов задающих новые векторы развития или помогающие массивно отловить баги.
> Если даже последний пункт сойдет на нет, я думаю, ява будет по
> немногу становится нишевым языком для легаси-систем, ибо сейчас на ней в
> WEB генерировать "яваскрипт" (JSON) для браузера можно и без неё, и
> написать это можно быстрее."слышал" там в последнее время вообще для "этого" ничего писать не нужно, если "для работы" а не "для красоты".
Всё делается в библиотеках, разработчик же конечного продукта просто дописывает бизнес-логику, да и можно даже на на Java собственно говоря ( JEE это набор спецификаций (интерфейсов), на которых основаны реализации, этот подход добавляет немного уверенности в будущем Java )
Долго пытался уйти на geronimo, но это какой-то "не юниксвей". В итоге из серьезных плюсов для маленьких самописных и неизвестно кем написанных проектов могу отметить то, что у джеронимо очень забавно реализована абстракция от связи с базой данных. Остальное - сплошные боль и мучения.А что касается больших проектов, то там наверное да, с голым томкэтом не полезешь.
Надо будет глянуть. Может сделали по-нормальному, наконец, локализацию в JSF, а не череззаборногузадирищенски.
кстати, как глассфиш в сравнении с красношапкинским Wildfly, кто теперь лучше?
> кстати, как глассфиш в сравнении с красношапкинским Wildfly, кто теперь лучше?Wildfly вроде как лучше по скорости. GlassFish лучше по стабильности и стандартизации. Вообще, нужно тестировать приложения на разных JEE-серверах, чтобы понять, чего упустили.
> Вообще, нужно тестировать приложения на разных JEE-серверах, чтобы понять, чего упустили.Oh, yA -Ya!
Добавь что ещё на разных jvm, на разных ОЗЪ ..."Write once, run everywhere!" во всей красе :)
На Ruby и PHP такого раздолья нет, правда ведь? ;)
"everywhere" вообще то в данном случае речь идёт о разных операционных системах, а не о разных реализациях технологий. Java EE стек один, но его реализация его у каждого разная.
> "everywhere" вообще то в данном случае речь идёт о разных операционных системах,
> а не о разных реализациях технологий.На яве можно написать код, который будет рабочим на определенной ОС и на других нет.
Можно, если требуется скажем получить доступ к файлу то приходится работать с файловой системой реализация которой зависит конечно от конкретной ОС. Но вы вынесете работу с реализацией файловой системы за пределы Java языка, задействуйте JNDI и настраивайте пути доступу в зависимости от типа OC за пределами Java. http://forum.vingrad.ru/faq/topic-45382.html
При такой реализации у вас работа с файлами будет одинакова для всех ОС. И я могу поспорить что вы даже не знали о такой возможности.
Golang: syscall.Setrlimit(syscall.RLIMIT_NOFILE, &new)Это работает в Linux, FreeBSD, MacOS X. Под Win, понятно, нет.
Вопрос к знатокам: как это же решить в Java? Я знаю ответ. О какой write once run everywhere вообще речь, если я не могу написать один код для сисколла под два разных юникса?
> На яве можно написать код, который будет рабочим на определенной ОС и
> на других нет.- действительно есть чудики которые в пути к файлу пишут "C:\Temp\file", но никто не мешает им немного лучше изучить Java и узнать что такое File.separator, как вообще пользоваться классом File, как определить путь к временной директории и т. п. Короче в Java достаточно средств для того чтобы писать кроссплатформенный код, все остальное зависит от программиста.