Что такое Java EE на самом деле? [закрыто]

Java EE окутывает эту «таинственную пелену» для молодых Java-разработчиков - ту, которую я пытался поднять довольно долго без особого успеха.

Путаница возникает из-за:

• Кажется, что Java EE является одновременно библиотекой и платформой - существует несколько способов «получить» библиотеку Java EE, обычно из чего-то вроде загрузки Oracle Java EE SDK. Однако библиотека Java EE не будет работать и компилироваться, если ваш код не выполняется или не имеет доступа к серверу приложений Java EE (например, JBoss, GlassFish, Tomcat и т. Д.). Зачем? Не могут ли библиотеки работать вне среды сервера приложений? Зачем мне нужно что-то масштабное, как JBoss, просто для компиляции простого кода для отправки электронной почты?

• Почему библиотеки Java EE не являются «стандартными» и включены в обычную загрузку JVM и / или SDK?

• Почему существует так много предложений Java EE, когда на самом деле существует только две основных разновидности стандартной Java (Oracle JVM / SDK | OpenJDK JVM / JDK)?

• Что можно сделать с Java EE, чего нельзя сделать со стандартной Java?

• Что можно сделать со стандартной Java, чего нельзя сделать с Java EE?

• Когда разработчик решает, что ему «нужна» Java EE?

• Когда разработчик решает, что Java EE им не нужен?

• Почему версия библиотеки Java EE не синхронизирована со стандартными выпусками библиотеки Java (Java EE 6 против Java 7)?

Спасибо, что помог мне очистить порку!

Почему библиотеки не могут работать вне среды сервера приложений?

На самом деле они могут. Большинство библиотек можно напрямую использовать отдельно (в Java SE) или включить в .war (практически всегда это Tomcat). Некоторые части Java EE, например JPA, содержат явные разделы в соответствующих спецификациях, в которых рассказывается, как они должны работать и использоваться в Java SE.

Во всяком случае, здесь речь идет не столько о среде сервера приложений как таковой, сколько о наличии всех других библиотек и кода интеграции, который их объединяет.

Из-за этого аннотации будут сканироваться только один раз для всех ваших классов, а не каждая библиотека (EJB, JPA и т.д.), выполняющая это сканирование снова и снова. Также из-за этого аннотации CDI могут применяться к EJB-компонентам, а менеджеры сущностей JPA могут быть добавлены в них.

Зачем мне нужно что-то масштабное, как JBoss, просто для компиляции простого кода для отправки электронной почты?

В этом вопросе есть несколько ошибок:

1. Для компиляции вам понадобится только API-файл jar, размер которого меньше 1 МБ для веб-профиля и чуть более 1 МБ для полного профиля.
2. Очевидно, что для запуска вам нужна реализация, но «массивность» - это слишком много. OpenJDK, например, составляет около 75 МБ, а TomEE (реализация веб-профиля, содержащая поддержку почты) - всего 25 МБ. Даже GlassFish (реализация полного профиля) занимает всего 53 МБ.
3. Почта отлично работает с Java SE (и, следовательно, с Tomcat), а также с использованием автономных mail.jar и activate.jar .

Почему библиотеки Java EE не являются «стандартными» и включены в обычную загрузку JVM и / или SDK?

Java EE в каком-то смысле была одной из первых попыток разбить и без того массивный JDK на части, которые легче управлять и загружать. Люди уже жалуются, что графические классы (AWT, Swing) и апплеты находятся внутри JRE, когда все, что они делают, - это запускают некоторые команды на безголовом сервере. И вы также хотите включить все библиотеки Java EE в стандартный JDK?

С окончательным выпуском поддержки модульности у нас будет только небольшая базовая JRE со многими вещами, которые можно установить отдельно в виде пакетов. Возможно, однажды многие или даже все классы, которые сейчас составляют Java EE, также станут таким пакетом. Время покажет.

Почему существует так много предложений Java EE, когда на самом деле существует только две основных разновидности стандартной Java (Oracle JVM / SDK | OpenJDK JVM / JDK)?

Java SE существует не только в двух вариантах. Существует как минимум IBM JDK, предыдущий BEA (JRocket, который объединяется с Oracle / Sun в связи с приобретением), различные другие реализации с открытым исходным кодом и множество реализаций для встроенного использования.

Причина того, что Java SE и EE являются спецификацией, заключается в том, что многие поставщики и организации могут их реализовать, и, таким образом, это поощряет конкуренцию и снижает риск привязки к поставщику.

На самом деле ничем не отличается компиляторы C и C ++, где у вас есть много конкурирующих предложений, и все они придерживаются стандарта C ++.

Почему версия библиотеки Java EE не синхронизирована со стандартными выпусками библиотеки Java (Java EE 6 против Java 7)

Java EE основан на Java SE, поэтому он отстает. Однако версии совпадают. Java EE 5 требует Java SE 5. Для Java EE 6 требуется Java SE 6 и так далее. Просто в основном, когда Java SE X актуальна, Java EE X-1 актуальна.

Вот несколько быстрых ответов на ваши вопросы ...

• Почему библиотеки JavaEE не могут работать без сервера приложений? Услуги, предоставляемые JavaEE (транзакции, управляемые контейнером, внедрение зависимостей, управляемое контейнером, служба таймера и т. Д.), По своей сути включают серверы приложений, совместимые с JavaEE (например: GlassFish, JBoss, WebSphere и т. Д.). Поэтому без такого контейнера библиотеки JavaEE бесполезны. « Зачем мне нужно что-то столь масштабное, как JBoss, просто чтобы скомпилировать простой код для отправки электронной почты? » Нет. Есть способы отправить электронное письмо без JavaEE ... Но если вы хотите сделать это способом JavaEE, вам понадобится контейнер JavaEE.

• Почему библиотеки JavaEE не включены в загрузку JavaSE? По той же причине, по которой многие библиотеки не включены: это было бы излишним. Поскольку вы даже не можете использовать библиотеки JavaEE без сервера приложений, зачем вообще их включать? JavaEE следует загружать, если и когда разработчик устанавливает сервер приложений и решает использовать JavaEE.

• Почему так много предложений JavaEE? Неужели предложений JavaEE « так много »? Если да, перечислите, пожалуйста, некоторые из них. Точнее, я считаю, что существует несколько реализаций одних и тех же API .

• Что можно сделать с JavaEE, чего нельзя сделать без стандартной Java? Много. Вы не можете полагаться на сервер приложений для управления транзакциями или контекстами сохранения без JavaEE. Вы не можете позволить серверу приложений управлять внедрением зависимостей EJB без JavaEE. Вы не можете использовать службу таймера, управляемую приложением, без JavaEE. Ответ на этот вопрос должен прояснить ответ на первый вопрос ... Для большинства услуг, предоставляемых JavaEE, требуется контейнер JavaEE.

• Что вы можете делать с JavaSE, чего не можете с JavaEE? Эм ... я не знаю.

• Когда разработчик решает, что ему нужна JavaEE? Этот вопрос полностью субъективен ... Но если вам нужна какая-либо из услуг, предоставляемых JavaEE, вы начинаете думать об этом. Если вы не знаете, что такое JavaEE ... вероятно, он вам не нужен.

• Когда разработчик решает, что JavaEE им не нужен? См. Предыдущий ответ.

• Почему версия библиотеки JavaEE не синхронизируется с версией JavaSE? Хороший вопрос. Я не буду делать вид, что знаю, как на него ответить ... Но я предполагаю, что ответ таков: «потому что они не синхронизированы».

С высоты птичьего полета Java EE - это платформа, то есть то, на чем мы можем строить.

С технической точки зрения стандарт Java Enterprise Edition определяет набор API-интерфейсов, обычно используемых для создания корпоративных приложений. Эти API-интерфейсы реализуются серверами приложений - и да, разные серверы приложений могут использовать разные реализации API-интерфейсов Java EE.

Однако библиотека java ee не будет работать и компилироваться, если ваш код не выполняется на сервере приложений Java EE или не имеет доступа к нему (например, JBoss, GlassFish, Tomcat и т. Д.).

Вы компилируете с использованием API Java EE, поэтому вам нужны только эти API во время компиляции. Во время выполнения вам также понадобится реализация этих API, то есть сервер приложений.

Зачем мне нужно что-то масштабное, как JBoss, просто для компиляции простого кода для отправки электронной почты?

Вы этого не сделаете. Однако, если вы хотите использовать Java EE API для отправки почты, вам потребуется реализация этого API во время выполнения. Это может быть предоставлено сервером приложений или предоставлено отдельной библиотекой, которую вы добавляете в свой путь к классам.

Почему библиотеки Java EE не являются «стандартными» и включены в обычную загрузку JVM и / или SDK?

Потому что стандартизированы только API, но не реализации.

Почему так много предложений Java EE

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

Что можно сделать с Java EE, чего нельзя сделать со стандартной Java?

Поскольку реализации Java EE построены на «стандартной Java»: ничего. Однако использование существующих библиотек может значительно сэкономить усилия, если вы решаете типичные корпоративные проблемы, а использование стандартизированного API может предотвратить привязку к поставщику.

Что можно сделать со стандартной Java, чего нельзя сделать с Java EE?

Ничего, поскольку Java EE включает Java SE.

Когда разработчик решает, что ему «нужна» Java EE? Когда разработчик решает, что Java EE им не нужен?

Вообще говоря, API Java EE решают типичные повторяющиеся проблемы в корпоративных вычислениях. Если у вас есть такие проблемы, обычно имеет смысл использовать стандартные решения, но если у вас другие проблемы, могут потребоваться разные решения. Например, если вам нужно поговорить с реляционной базой данных, вам следует рассмотреть возможность использования JPA. Но если вам не нужна реляционная база данных, JPA вам не поможет.

Что такое Java EE?

Начнем с определения каноничности в вики:

Java Platform, Enterprise Edition или Java EE - это корпоративная вычислительная платформа Java от Oracle. Платформа предоставляет API и среду выполнения для разработки и запуска корпоративного программного обеспечения, включая сетевые и веб-сервисы, а также другие крупномасштабные, многоуровневые, масштабируемые, надежные и безопасные сетевые приложения.

Главное здесь то, что Java EE - это платформа, предоставляющая API, а не какая-то конкретная библиотека.

Зачем нужна Java EE?

Основная область применения Java EE - сетевые приложения, в отличие от Java SE, ориентированного на разработку настольных приложений с простой сетевой поддержкой. Это главное различие между ними. Масштабируемость, обмен сообщениями, транзакции, поддержка БД для каждого приложения ... потребность во всем этом возросла с развитием сети. Конечно, многие готовые решения, которые предоставляет Java SE, полезны для разработки сетей, поэтому Java EE расширяет Java SE.

Зачем нам нужны серверы приложений для запуска нашего кода?

Зачем нужны операционные системы? Поскольку есть много болезненной работы с оборудованием, нам нужно сделать даже самое простое приложение. А без ОС нужно делать это снова и снова. Упрощенная ОС - это просто программный контейнер, который предоставляет нам глобальный контекст для запуска наших приложений.

А это и есть серверы приложений. Они позволяют нам запускать наши приложения в их контексте и предоставляют множество функций высокого уровня, необходимых для корпоративных высоконагруженных сетевых приложений. И мы не хотим писать свои собственные велосипеды для решения этих проблем, мы хотим написать код, который удовлетворит потребности нашего бизнеса.

Другим примером здесь может быть JVM для Java.

Почему Java EE не содержит встроенного сервера приложений?

Мне сложно сказать. Думаю, это было сделано для большей гибкости. Java EE говорит, что им следует делать, они решают, как это делать.

Почему JVM не включает Java EE?

Потому что они направлены в разные секторы рынка. Java EE имеет набор функций, которые не нужны для обычных настольных компьютеров.

Почему так много предложений Java EE?

Потому что Java EE описывает только поведение. Это может реализовать каждый.

Что можно сделать с Java EE, чего нельзя сделать с Java SE?

Чтобы покорить Интернет. Это действительно сложно сделать с апплетами и сокетами Java SE :)

Что можно сделать с Java SE, чего нельзя сделать с Java EE?

Как упоминалось выше, Java EE расширяет Java SE, поэтому с Java EE вы сможете делать все, что доступно для Java SE.

Когда разработчик решает, что ему «нужна» Java EE?

Когда им нужна мощь Java EE. Все, что написано выше.

Когда разработчик решает, что Java EE им не нужен?

Когда пишут обычное консольное или настольное приложение.

Почему версии Java SE и Java EE не синхронизированы?

У Java всегда были проблемы с именованием технологий и версией. Так что эта ситуация не исключение.

Java EE - это концепция контейнера.
Контейнер - это контекст выполнения, в котором будет запускаться ваше приложение и который предоставляет последний набор услуг. Каждый вид сервиса определяется спецификацией JSR. Например, JSR 907, JTA (Java-транзакция Api), которые предоставляют стандартный способ управления распределенной транзакцией для различных ресурсов.
Как правило, существует множество различных реализаций для данного JSR, реализация, которую вы будете использовать, зависит от поставщика контейнера, но вы действительно не возражаете, так как вы уверены, что поведение соответствует предопределенному контракту: JSR API.
Итак, чтобы воспользоваться преимуществами Java EE, вам необходимо запустить приложение внутри контейнера. Двумя основными из них являются EJB и контейнер сервлетов, которые присутствуют на любом сертифицированном сервере приложений Java EE.

Целью всего этого является определение стандартной среды выполнения, позволяющей упаковать ваше приложение только с помощью самого необходимого, id.est. Ваш бизнес. Это позволяет избежать зависимости от неизвестного и разнообразного набора сторонних библиотек, которые вам пришлось бы упаковать и предоставить вместе с вашим приложением в противном случае, и которые могут быть источниками конфликта с другими приложениями на сервере. В Java EE вы знаете, что все стандартные нефункциональные требования, такие как безопасность, транзакция, масштабируемость, удаленный вызов и многие другие, будут обеспечиваться контейнером (факторизованным для всех приложений, работающих внутри него), и вам просто нужно основывать свою работу на нем.