1. Въведение
Чували ли сте някога за Java EE? Какво ще кажете за Java 2EE, J2EE или сега Джакарта EE? Всъщност това са различни имена за едно и също нещо: набор от корпоративни спецификации, които разширяват Java SE.
В тази кратка статия ще опишем развитието на Java EE.
2. История
В първата версия на Java корпоративните разширения на Java бяха просто част от основния JDK.
След това, като част от Java 2 през 1999 г., тези разширения бяха извадени от стандартните двоични файлове и се роди J2EE или Java 2 Platform Enterprise Edition. Ще запази това име до 2006 г.
За Java 5 през 2006 г. J2EE е преименуван на Java EE или Java Platform Enterprise Edition. Това име щеше да остане чак до септември 2017 г., когато се случи нещо голямо .
Вижте, през септември 2017 г. Oracle реши да предостави правата за Java EE на Eclipse Foundation (езикът все още е собственост на Oracle) .
3. В преход
Всъщност фондацията Eclipse законно трябваше да преименува Java EE. Това е така, защото Oracle има правата върху марката „Java“.
Така че, за да изберете новото име, общността гласува и избра: Джакарта EE. По определен начин все още е J EE.
* Обявено е ново име
Това все още е развиваща се история и прахът не се е уталожил напълно.
Например, докато Oracle е с отворен код, те не са отворили цялата документация. Все още има много дискусии по този въпрос поради правни проблеми, които правят сложно създаването на документация с отворен код, свързана например с JMS и EJB.
Все още не е ясно дали новата документация на Eclipse Foundation ще може да се позовава на оригиналите.
Също така, любопитно е, че Eclipse Foundation не може да създава никакви нови Java пакети, използвайки пространството от имена на javax , но може да създава нови класове и подкласове под съществуващите.
Преходът също така означава нов процес за добавяне на спецификации към Джакарта EE. За да го разберем по-добре, нека да разгледаме какъв е бил този процес при Oracle и как се променя в рамките на Eclipse Foundation.
4. Бъдещето
В исторически план, за да може дадена функция да се превърне в „EE“, се нуждаехме от три неща: спецификация, референтна реализация и тестове. Тези три неща могат да бъдат предоставени от всеки в общността и изпълнителен комитет ще реши кога те са готови да добавят към езика.
За да разберем по-добре миналия процес, нека разгледаме по-отблизо какво представляват JSRs, Glassfish и TCK и как те въплъщават новите EE функции .
Ще разберем и какво да очакваме в бъдеще.
4.1. JCP и сега, EFSP
В миналото процесът, чрез който се ражда нова функция на EE, се наричаше Java Community Process (JCP).
Java SE все още използва JCP днес. Но тъй като EE е променила собствеността си, от Oracle на Eclipse Foundation, имаме нов и отделен процес за това. Това е процесът за спецификация на Eclipse Foundation (EFSP) и е продължение на процеса на разработка на Eclipse.
Има обаче някои важни разлики, най-вече около „Прозрачност, откритост, споделена тежест и неутралност на доставчика“. Организаторите на EFSP например предвиждат съвместни работни групи, които са неутрални към доставчика, процес на сертифициране, който се самообслужва, и организация, която работи и управлява като меритокрация.
4.2. JSRs
В JCP първата стъпка за добавяне на функция към EE беше създаването на JSR или заявка за спецификация на Java. JSR беше малко като интерфейс за EE функция. Изпълнителният комитет на JCP прегледа и одобри завършен JSR, а след това сътрудниците на JSR го кодират и предоставят на общността.
Добър пример за това беше JSR-339 - или JAX-RS - който първоначално беше предложен през 2011 г., одобрен от JCP през 2012 г. и накрая пуснат през 2013 г.
И докато общността винаги можеше да претегли, докато дадена спецификация беше в процес на обсъждане, времето показа, че подходът, който е първи за изпълнение - както в случая с JSR 310, java.time и Joda Time - има тенденция да създава по-широко приети функции и API .
И така, EFSP отразява този първи изглед на кода в заявената му цел: „EFSP ще се основава първо на практически експерименти и кодиране, тъй като начин да се докаже, че нещо е достойно за документиране в спецификация.“
4.3. Стъклена рибка
Тогава, като част от JCP, JSR се нуждае от референтно изпълнение. Това е малко като класа, който реализира интерфейса . Референтната реализация помага на разработчиците на съвместими библиотеки или други организации, които искат да създадат свое собствено изпълнение на спецификацията.
За функциите на Java EE JCP използва Glassfish за своите референтни реализации.
И докато тази централизация на Glassfish опрости процеса на откриване за изпълнителите, тази централизация също изискваше повече управление и имаше тенденция да облагодетелства един доставчик пред друг.
Следователно EFSP не изисква референтно изпълнение, а вместо това само съвместимо изпълнение. Просто казано, тази фина промяна прави така, че внедряванията вътре в централна архитектура, като Glassfish, няма да бъдат неволно предпочетени от фондацията.
4.4. TCK
И накрая, JCP изисква функциите на EE да бъдат тествани чрез набора за технологична съвместимост или TCK.
TCK беше набор от тестове за валидиране на специфичен EE JSR. Просто казано, за да се съобрази с Java EE, сървърът на приложения трябва да внедри всичките си JSR и да премине всички тестове на определения TCK.
Тук няма много промени. Oracle с отворен код TCK, както и EE JSRs. Разбира се, всички бъдещи документи и TCK ще бъдат с отворен код.
5. Заключение
Java EE със сигурност се е развила много през тези години. Приятно е да видим, че продължава да се променя и подобрява.
Предстоят много предизвикателства, така че нека се надяваме на плавен преход.