Java - эталонные реализации против сторонних поставщиков - PullRequest
1 голос
/ 28 августа 2009

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

Некоторые примеры - сервер Glassfish, который в основном является официальной эталонной реализацией Java EE. Тем не менее, я действительно редко вижу, чтобы люди этим пользовались. Jboss, несколько бесплатных проектов Apache (например, Apache ActiveMQ for JMS), WebLogic, WebSphere ...

Есть ли у кого-то свои правила (кроме чистой стоимости :)), что предпочтительнее?

Здесь я вижу 2 противоположные точки:

1) RI получает новые функции и новые версии спецификаций быстрее.

2) Решения сторонних поставщиков часто более «завершены» и ориентированы на конечного программиста, как и любые дополнительные используемые функции / утилиты (которые не являются частью спецификации).

Ответы [ 2 ]

1 голос
/ 29 августа 2009

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

Долгое время Tomcat был спецификацией сервлета RI. И долгое время EJB RI был шуткой - никто на самом деле не использовал его. И не было «эталонной реализации» для J2EE в целом.

Причина, по которой большинство людей используют другие серверы, заключается в том, что в течение долгого времени Weblogic и Websphere были только (реалистичными) реализациями, поэтому проектам / людям, которые начали с J2EE, будет удобнее с ними. JBoss был первым успешным сервером приложений J2EE с открытым исходным кодом - поэтому люди, которые предпочли открытый исходный код (или просто хотели бесплатный сервер приложений), были довольно ограничены этим вариантом - и снова - эти люди предпочтут то, что они знают.

Однако в настоящее время GlassFish в значительной степени сопоставим с другими открытыми / коммерческими серверами приложений Java EE. И он использует Tomcat для своего движка сервлета - и он довольно модульный, поэтому вы можете брать ненужные детали.

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

1 голос
/ 28 августа 2009

Еще несколько баллов:

3) интеграция с другими инструментами часто лучше для сторонних разработчиков (например, сервер Apache http и контейнер сервлетов tomcat)

4) RI содержит все функции, часто сторонние часто только полезные. Программное обеспечение является менее сложным, а иногда более удобным и имеет лучшую производительность.

5) RI является передним краем. Для производственного сервера более устаревшая реализация, когда не требуется последняя функция (большинство приложений "Java EE" работают на контейнере сервлетов Tomcat 5.5 - 2.4 - я в восторге)

ОБНОВЛЕНИЕ: для Java EE 6 и последующих 7 картина меняется. Существуют также полные стандартные реализации с открытым исходным кодом (такие как TomEE для Java EE6), а со Glassfish, похоже, имеется полезный RI для Java EE 7, единственный для ранних пользователей.

...