Jakarta EE 9. Дорогою сліз і страждань
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Передмова
Я не планував писати окрему статтю на цю тематику. Але коли почав писати четверту частину своєї книги «Розробка Java додатків» (it-simulator.com/#/article/608 ), то зрозумів, що в світі Enterprise Java зараз відбуваються цікаві, часом революційні зміни, про які і хочеться написати.
Java EE. Боротьба за виживання
Enterprise Java (то що ми зазвичай називаємо Java EE) в останні роки переживає не найкращі часи. Починаючи з середини
• Реактивне програмування
• Мікросервісная архітектура
Все, що вдалося в неї впихнути з новинок — JSON-B (Json Binding) 1.1 і Java EE Security 1.0. Критиці піддавали і тривалий
Але закривати її не стали. Замість цього в 2017 році Java EE пересіла з ораклових рейок на нові та перейшла під крило Eclipse Foundation, незалежної організації з досить серйозними учасниками. Все це було покликане реанімувати Java EE і збільшити її популярність. Eclipse Foundation навіть погодився з претензіями Oracle на Java як торгову марку і перейменував своє нове дітище спочатку в Eclipse Enterprise for Java, а потім в Jakarta EE. Були перейменовані всі специфікації, наприклад Java Persistence API (JPA) став просто Jakarta Persistence.
Але процес переходу (перенесення коду і специфікацій) виявився не менш бюрократизованим, ніж сама розробка Java EE. Тільки у вересні 2019 року було випущено Jakarta EE 8, яка була точною копією Java EE 8. Але тут її розробники зіткнулися з дійсно великою проблемою. Oracle заборонила додавати нові пакети в кореневому пакеті javax. *, щоправда дозволивши додавати нові типи (класи і інтерфейси).
При такому розкладі розробка ускладнювалася неймовірно, тому було прийнято болісне рішення перейменувати всі javax. * пакети в jakarta. *, порушивши для клієнтських додатків зворотну сумісність. І ось в листопаді 2020 року було випущено Jakarta EE 9 з переімованнимі пакетами, а також дрібними змінами в вигляді видалення застарілих специфікацій (Corba).
Ніяких нових специфікацій в Jakarta EE 9 додано не було (просто версії існуючих збільшилися на 1), що додало деякого скептицизму. Але більшість головних Jakarta EE вендорів випустило оновлення для реалізації її специфікацій, наприклад:
• Tomcat 10, Jetty 11, GlassFish 6, WildFly 21 (Servlet API)
• Jersey 3 (JAX-RS)
• Hibernate Validator 7 (Bean Validation)
• Weld 4 (CDI)
• EclipseLink 3 (JPA)
Але і тут виникли свої фундаментальні складності. Справа в тому, що ще в 2016 році на конференції Java One виникла пропозиція створити розширення (тоді ще для Java EE 7), яке дозволяло б додавати специфікації для найбільш популярних напрямків в сучасній (читайте мікросервісной) архітектурі. Назвали цей проект Eclipse Microprofile. Його перша версія вийшла в 2017 році і містила існуючі специфікації з Java EE 7 — JAX-RS, CDI і JSON-P.
Але вже у вересні 2017 року з’явилася версія 1.2, куди були додані специфікації:
• Config 1.1
• Fault Tolerance 1.0
• Metrics 1.0
• Health 1.0
• JWT Auth 1.0
З тих пір аж до сьогоднішнього дня вийшло вже 12 головних версій Microprofile, і в версії 4.0 можна знайти і Open API, і Open Tracing і навіть Microprofile Config. Ці специфікації реалізують найбільші сервера додатків — Open Liberty, Wildfly, Payara, Thorntail і Kumuluz EE. І новий веб-фреймворк Quarkus до речі теж. Все це виглядає дуже позитивно, якби не одне лихо — Microprofile 4.0 (і все його реалізації) все ще використовує Jakarta EE 8. Це виглядає досить дивно, враховуючи, що версія 4.0 вийшла через місяць після релізу Jakarta EE 9.
Таким чином, якщо ви використовуєте Microprofile в своєму проекті, то використовувати Jakarta EE 9 ви не можете. І не зрозуміло, коли зможете, тому що немає ніяких планів про підтримку нової версії. Ходять навіть чутки, що Microprofile і Jakarta EE можуть об’єднатися в один проект, але це на рівні чуток.
Що з іншими Java фреймворками? Spring планує підтримку
github.com/...ng-framework/issues/26224
Hibernate, завжди достатньо інертний в своїх планах, запланував перехід в версії 5.5, яка буде теж невідомо коли:
hibernate.atlassian.net/browse/HHH-13946
Що робити іншим проектам/бібліотекам, які з якихось причин не планують такий перехід? Є проекти, наприклад, PrimeFaces, які будуть підтримувати дві версії свого продукту (для Jakarta EE 8 і Jakarta EE 9). Як наприклад, деякі бібліотеки (Guava) випускають дистрибутиви і для JDK, і для Android. Але це не саме простий вихід, тому виник такий новий проект як Eclipse Transformer:
projects.eclipse.org/...ts/technology.transformer
Це по своїй суті утиліта, яка вміє при завантаженні програми динамічно замінювати пакети в class-файлах (в JAR або WAR архівах) при старті програми. Її можна налаштувати так, що вона буде здійснювати міграцію javax. * -> jakarta. *. Така утиліта спростить життя розробникам серверiв додатків, які повинні підтримувати якусь одну версію Jakarta EE. І позбавить від необхідності термінової переробки legacy проектів.
Висновки
В цілому у Enterprise Java і її шанувальників були непрості останні
70 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів