Що таке насправді Java EE? [зачинено]

У Java EE є ця "таємнича кожуха" навколо неї для молодших розробників Java - таку, яку я досить довго намагаюся підняти з невеликим успіхом.

Плутанина виникає через:

• Здається, Java EE є і бібліотекою, і платформою - існує кілька способів "отримати" бібліотеку Java EE, як правило, із чогось типу завантаження SDK Java EE SDK Oracle. Однак бібліотека 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, яка нижче 1 Мб для веб-профілю, і трохи більше 1 МБ для повного профілю.
2. Для запуску вам очевидно потрібна реалізація, але "масовий" - це завищення речей. Наприклад, OpenJDK становить близько 75 Мб, а TomEE (реалізація веб-профілю, що підтримує пошту) становить лише 25 Мб. Навіть GlassFish (реалізація повного профілю) становить лише 53 Мб.
3. Пошта відмінно працює від Java SE (і, отже, Tomcat), а також використовуючи окремий mail.jar та activation.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 - це платформа, тобто те, на чому ми можемо спиратися.

Приймаючи більш технічну перспективу, стандарт Enterprise Enterprise Edition визначає набір API, які зазвичай використовуються для побудови корпоративних програм. Ці API реалізовані серверами прикладних програм, і так, різні сервери додатків можуть використовувати різні реалізації API Java EE.

Однак бібліотека java ee не працюватиме і не буде компілюватися, якщо тільки ваш код не працює або має доступ до сервера додатків Java EE (наприклад, JBoss, GlassFish, Tomcat тощо).

Ви компілюєте з Java EE API, тому вам потрібні ці API лише під час компіляції. Під час виконання вам також знадобиться реалізація цих API, тобто сервер додатків.

Чому мені потрібно щось масове, як JBoss, просто для складання простого коду для надсилання електронного листа?

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

Чому бібліотеки Java EE не є "стандартними" і не включаються до регулярного завантаження JVM та / або SDK?

Оскільки стандартизовані лише API, а не реалізації.

Чому існує так багато пропозицій Java EE?

Тому що люди не згодні з правильним способом реалізації певних функцій. Тому що різні постачальники змагаються за частку ринку.

Що можна зробити з Java EE, що вони не можуть зробити зі стандартною Java?

Оскільки реалізації EE Java побудовані за допомогою "стандартної Java": Нічого. Однак використання існуючих бібліотек може заощадити багато зусиль, якщо ви вирішуєте типові проблеми для підприємства, а використання стандартизованого API може запобігти блокуванню постачальника.

Що можна зробити зі стандартною Java, яку вони не можуть зробити з Java EE?

Нічого, оскільки Java EE включає Java SE.

Коли розробник вирішує, що їм "потрібна" Java EE? Коли розробник вирішує, що Java EE не потребує?

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

Що таке Java EE?

Почнемо з визначення канонічності на wiki:

Платформа Java, 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), які забезпечують стандартний спосіб управління розподіленою транзакцією на різних ресурсах. Отже, щоб скористатися Java EE, потрібно запустити додаток всередині контейнера. Два основних з них - EJB і контейнер сервлетів, які присутні на будь-якому сервері додатків, сертифікованих Java EE.
Загалом існує багато різних реалізацій для даного JSR, реалізація, яку ви будете використовувати, залежить від постачальника контейнерів, але ви цього не дуже заперечуєте, оскільки ви впевнені, що поведінка поважає попередньо визначений контракт: API JSR.

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