Názory k článku
Java 17 a OpenJDK 17 s hotovým Vector API a plánovaným koncem Applet API

To je přece cílem Oraclu i Apache.
Jenom věcná je to Eclipse Fundation. Spíš je zajímavé, jak to rozdrobili právě mezi Eclipse a Apache.
Java EE jako celek nikdy pořádně nefungovala. Stejně se vždycky aplikace přizpůsobovala konkrétnímu aplikačnímu serveru, který měl něco navíc proti Java EE.
Tohle není vůbec pravda hodněkrát jsem se setkal, že se vyvíjelo třeba na JBoss a pak se to provozovalo na WebSphere nebo WebLogic.

Kvůli Javě přeci SUN kupovali. Takže je logické, že se starají hlavně o Javu. Jinak dál funguje třeba MySQL a myslím, že technologicky to MySQL posunulo docela vpřed.
Proto vznikla právě MariaDB a spousta lidí raději používá PostgreSQL.
Oracle žije z toho, že prodává licence firmám, které třeba doteď provozují Javu 1.4 a Oracle jim ji supportuje. Tyhle firmy Oracle zajímají, ne vy, který používáte verzi zdarma.
Tak 1.4 asi těžko když už tak podporují 1.7 do July 2022. 1.6 podporuje jestě Azul, ale z toho určitě nic nemají. A nemůžou zpeněžit něco co nikdo nepoužívá. A nepoužívají to právě kvůli té jejich změněné licenci, kdy všichni přešli na OpenJDK. Ono je to stejně jedno, protože v budoucnu snad všichni budou používat containery a tam asi pro OracleJDK nebude místo. Navíc ve spoustě velkých firem a bankách se právě přechod na OpenJDK začal řešit ihned co Oracle přišel se změnou licence.

Co se týká GrallVM tak má před sebou ještě opravdu dlouhou cestu a čas ještě ukáže.
Otázkou co je všechno na Java zásluha Oracle, protože hodně to tlačí i RedHat a další. A zrovna Java se hodně nastartovala i za pomoci Google a Androidu, takže je otázka kolik na tom Oracle má vlastně zásluh.

Jenom věcná je to Eclipse Fundation.
Aha, měl jsem za to, že to souvisí se značkou Jakarta, kterou používal Apache pro javovské projekty.

Tohle není vůbec pravda hodněkrát jsem se setkal, že se vyvíjelo třeba na JBoss a pak se to provozovalo na WebSphere nebo WebLogic.
Jenže se to nepřenášelo as-is. Vývojová verze se lišila závislostmi od produkční verze.

Proto vznikla právě MariaDB a spousta lidí raději používá PostgreSQL.
PostgreSQL bych do toho netahal, to je úplně jiná databáze. MariaDB vznikla hned na začátku, dřív, než Oracle něco s MySQL udělal.

Tak 1.4 asi těžko
Když jsem psal verzi 1.4, myslím tím verzi 1.4. To, že nemají podporu napsanou veřejně na webu v ceníku, neznamená to, že to pro velké firmy v USA nepodporují.

Ono je to stejně jedno, protože v budoucnu snad všichni budou používat containery a tam asi pro OracleJDK nebude místo.
Oracle JDK je víc než jen OpenJDK se supportem. Jsou tam další nástroje, další optimalizace.

Otázkou co je všechno na Java zásluha Oracle, protože hodně to tlačí i RedHat a další.
Ovšem Oracle to rozhýbal, to nemohl udělat nikdo jiný. Samozřejmě, že to, aby byl projekt živý, zahrnuje i to, že do něj přispívají i ostatní.

A zrovna Java se hodně nastartovala i za pomoci Google a Androidu, takže je otázka kolik na tom Oracle má vlastně zásluh.
Tím myslíte to, že když vyšla Java 9, Android konečně začal podporovat Javu 8? Mně spíš připadalo, že byl Google dalším vývojem Javy po verzi 7 zaskočen…

Jenže se to nepřenášelo as-is. Vývojová verze se lišila závislostmi od produkční verze.
Ale přenášelo. Právě super na tom bylo, že se v aplikačním serveru vytvořil resource s nějakým názvem a člověk již nemusel nic v aplikaci řešit. V tomhle Java EE 7 byla velmi dobrá.

PostgreSQL bych do toho netahal, to je úplně jiná databáze. MariaDB vznikla hned na začátku, dřív, než Oracle něco s MySQL udělal.
No ale právě díky Oracle místo toho aby někdo uvažoval jestli PostgreSQL nebo MySQL rovnou šáhne po PostgreSQL. A MariaDB vznikla díky tomu, že se Oracle od MySQL distancoval.

Když jsem psal verzi 1.4, myslím tím verzi 1.4. To, že nemají podporu napsanou veřejně na webu v ceníku, neznamená to, že to pro velké firmy v USA nepodporují.
Tady se jedná o možná o jednotky a navíc tam kde běží Java 1.4 už nebude podpora i pro OS. Na tom nemohou nic velkého vydělat. Mimochodem 1.4 je 20let stará takže bych docela rád viděl kdo to ještě používá. U 1.5 bych tomu možná i věřil ale u 1.4 to můžou být maximálně jednotky.

Oracle JDK je víc než jen OpenJDK se supportem. Jsou tam další nástroje, další optimalizace
A co tam je navíc? Protože všechno co tam navíc dřív bylo je již v OpenJDK.

Ovšem Oracle to rozhýbal, to nemohl udělat nikdo jiný. Samozřejmě, že to, aby byl projekt živý, zahrnuje i to, že do něj přispívají i ostatní.
Tím si právě jistý nejsem Oracle právě trvalo hrozně dlouho, než se to začalo hýbat a to až od Java 9. Do té doby si s tím nevěděl rady a z velké části žil ještě z toho co vznikalo v SUNu.

Tím myslíte to, že když vyšla Java 9, Android konečně začal podporovat Javu 8? Mně spíš připadalo, že byl Google dalším vývojem Javy po verzi 7 zaskočen…
Jenže o to vůbec nejde/nešlo a když pominul, že se s nimi Oracle soudil a tím to totálně zastavil a Google přešel raději na Kotlin, tak jde o to, že přivedl nové vývojáře k Java

To, že nějak pojmenujete resource, je jenom detail. Aplikační server poskytuje spoustu dalších věcí – transakční manažer, knihovny pro SOAP a REST, XML parser, JSON parser, messaging atd. atd.

PostgreSQL a MySQL jsou úplně jiné databáze. Rozhodovat se mezi nimi nedávalo smysl ani dříve, Oracle na tom nic nezměnil.

Jak to mají vyřešení s podporou OS netuším, každopádně významní zákazníci Oraclu mají systémy i na Javě 1.4, možná i na starší.

Je tam navíc především GraalVM Enterprise, dál třeba Advanced Management Console.

Hýbat se to začalo tím, že vůbec vyšla Java 8. Nevěděl si s tím rady SUN, logicky pak nějakou dobu trvalo to dát do pořádku a vývoj znova nastartovat.

Tím, že Google začal používat i Kotlin, se Javy nijak nezbavil.

Je tam navíc především GraalVM Enterprise, dál třeba Advanced Management Console.
GraalVM není součástí Oracle JDK ale staví na něm. O AMC slyším poprvé a co tak koukám, tak to je zrovna věc kterou bych v JDK ani nechtěl.

Když si od Oraclu koupíte licenci na Javu (Java SE Subscription), získáte možnost používat Oracle JDK i GraalVM Enterprise.

Ale otázka nezněla na to co vám všechno přidá Oracle k licenci otázka zněla, co má navíc Oracle JDK oproti jiným OpenJDK.

Vy jste psal, že nevidíte důvod, proč používat něco jiného než otevřené buildy OpenJDK.

Ne tohle jsem nepsal. Psal jsem, že nevidím jediný důvod proč používat OracleJDK místo otevřených buildů.

Třeba kvůli podpoře. Jenže to zase budete tvrdit, že podpora není součástí Oracle JDK, že je to věc smlouvy…

Azul a RedHat jí nabízí taky, co tam máte dál?

Azul a RedHat nabízí podporu pro svoje produkty, ne na Oracle OpenJDK. Zkrátka když chcete něco s podporou, buildy OpenJDK zdarma vám nestačí.

Ne RedHat nabízí podporu pro jejich buildy OpenJDK tj. naprosto to samé co dělá Oracle s Oracle JDK. Azul nabízí podporu pro jejich Zulu OpenJDK a navíc
Support for Eclipse Temurin builds
A rozhodně raději budu řešit support s RedHatem nebo Azul než s Oraclem.

To, že vy máte nějaké preference, to je vaše věc. Kdybyste se ptal, jaká je výhoda RHELu oproti CentOSu, také je správná odpověď to, že RedHat poskytuje pro RHEL podporu – a vůbec nic na tom nemění fakt, Canonical poskytuje podporu pro Ubuntu.

Po roce 2010 přestávalo být jisté, zda Sun Javu 7 vůbec někdy vydá. Oracle vydal Javu 7 aby se už hotové změny vůbec dostaly ven a byl prostor vývoj Javy znovu nastartovat. A to se Oraclu povedlo.
A proč tedy ty věci z Project Coin nepřišly v Java 8.

Java EE umírá už dlouho, protože o to jako o celou specifikaci není zájem. Správně se to rozdělilo na samostatné projekty, kdo chce, použije některý z těch samostatných projektů. Takže třeba máte jedu dvě knihovny z Jakarta EE ve frameworku pro mikroslužby – což je do určité míry přesný opak Javy EE.
Zajímavé je, že RedHatu s Quarkus a i Springu se to celkem dobře daří. S tím mohl přijít Oracle již před 5lety a mohl si parádně prodávat support a licence, ale místo toho nedělal nic. Před 8 lety se klidně Java EE mohla dostat před Spring, ale Oracle si prostě nechal ujet vlak. Nikdo jim nebránil aby přišli s něčím jako je Eclipse MicroProfile a v té době by to měli celkem solidně nastartováné. Takže ano Oracle Java EE svojí hloupostí pohřbil a tím si pohřbil zlaté vejce, které by mu nyní s jeho cloudem velmi pomohlo.

A proč tedy ty věci z Project Coin nepřišly v Java 8.
Protože nebyly hotové.

Zajímavé je, že RedHatu s Quarkus a i Springu se to celkem dobře daří.
Ano, přesně, vezmou pár knihoven z Jakarta EE, které se jim hodí, a použijí je. Tak to má fungovat. Co vám na tom vadí?

S tím mohl přijít Oracle již před 5lety a mohl si parádně prodávat support a licence, ale místo toho nedělal nic.
Před pěti lety bylo Java EE považované za mrtvé, nikdo ho nechtěl dál rozvíjet. Bylo logické soustředit se na Javu, která už byla na cestě na JIP, než se vedle toho ještě pokoušet vzkřísit mrtvolu.

Co by na tom Oracle jako prodával a licencoval?

Před 8 lety se klidně Java EE mohla dostat před Spring, ale Oracle si prostě nechal ujet vlak.
Nemohla, ten vlak ujel už mnohem dřív. Tohle projel už Sun.

Takže ano Oracle Java EE svojí hloupostí pohřbil a tím si pohřbil zlaté vejce, které by mu nyní s jeho cloudem velmi pomohlo.
Do cloudu se hodí věci jako Micronaut, Helidon, Quarkus. A GraalVM. Těch pár věcí z Jakarta EE, které se pro to hodí, ty projekty využívají. Tak v čem je problém?

Myslel jsem rok 2015, takže sorry bylo to 6 let a to Java EE rozhodně mrtvá nebyla a bylo dost plánu na Java EE 8, které Oracle naprosto vykleštil svojí neschopností. Oracle to všechno naprosto pohnojil, protože Java EE byla zaháčkovaná v mnoha organizacích. Ty organizace v tu dobu řešili co s tím a Oracle jim nebyl schopný poskytnout nástupce místo toho sliboval hory doly a nic z toho. Mimochodem v roce 2014 vyšla Java 8, takže v té chvíli rozhodně už Java na JIP nebyla a Oracle se mohl soustředit na Java EE 8. Nyní mu to chybí a investuje do Micronaut. Jinak já v tom problém nevidím, ale rozhodně to Oracle z jejich pozice totálně pohnojil a stejně jako ostatní nabízejí podporu, tak on mohl nabízet podporu pro Java EE. A Quarkus staví na Java EE, takže tohle zadarmo mohl mít i Oracle kdyby nebyl totálně neschopný, navíc krásně zabalené s GraalVM.

Jenže doba, kdy byla šance Java EE zachránit, bylo vydání Java EE 5. Nebylo to úplně špatné, ale nestačilo to.

Co jiného z Java EE se podle vás mohlo použít pro mikroservisové frameworky než těch pár knihoven, které používá Helidon, Micronaut, Quarkus?

Ne právě, že ta zlomová verze byla Java EE 6 a CDI. Pár knihoven? Vždyť se z toho skoro všechno používá, snad jenom EJB, JSP, JSF (FE v Java je dnes mrtvý), JCA (to by se někomu možná mohlo hodit) a asi i JAX-WS (ale třeba pro integraci EET se hodí). Takže tu máme výborné CDI, JAX-RS a dále samozřejmě Servlet, JPA, JMS, Bean Validation. Takže vlastně spousta těch frameworku využívá skoro celou Java EE a jediný kdo k tomu vlastnil práva nebyl schopný to hezky zabalit a prodat.

CDI byl zajímavý pokus, ale tím, že přišel až v Java EE 6, bylo už pozdě.

To, že se nepoužívá Java EE jako celek, ale každý si z toho vytáhne pár knihoven, které s emu zrovna hodí, jsem psal dávno. Ono to jaksi plyne z principu mikroslužeb, že nechcete jeden velký server, který umí všechno, ale chcete malou službu, která potřebuje jen minimum závislostí.

Ale Java EE není o velkém serveru a to je asi co vám právě nedochází. Java EE je hlavně specifikace a to znamená, že když to napíšu podle specifikace tak to může (mělo) běžet jak na WebSphere tak JBoss i jako "Quarkus". Nikdo Oracle nebránil aby Java EE transformovali do Quarkus a Oracle s tím měl i takové plány ale zůstalo jenom o slibů.

Jenže když to napíšete podle specifikace EJB, Servlet, JPA a pak se to pokusíte spustit pod frameworkem, který z Java EE používá akorát JPA, zjistíte, že tam nemáte ani žádný server, protože ten framework ho má integrovaný. A i kdybyste to jen obalil tím frameworkem, pořád vám bude chybět EJB a Servlety.

Navíc jenom podle specifikace se to psalo málokdy, protože jste obvykle věděl, v jakém prostředí to poběží, takže se využily možnosti toho prostředí. Takže to třeba nebylo čisté JPA, ale Hibernate.

Jenže když to napíšete podle specifikace EJB, Servlet, JPA a pak se to pokusíte spustit pod frameworkem, který z Java EE používá akorát JPA, zjistíte, že tam nemáte ani žádný server, protože ten framework ho má integrovaný. A i kdybyste to jen obalil tím frameworkem, pořád vám bude chybět EJB a Servlety.
Tohle už je úplný nesmysl. Mimochodem Spring Boot používá obyčejný Tomcat a Quarkus Undertow což je servletová část z WildFly/JBoss.
Takže Oracle mohl vzít Glassfish, který mimochodem taky vlastnil a mohl ho rozsekat na moduly a vše se mohlo spouštět jako Quarkus. Tj. nějaký "stupidní initializer", který spustí servletový modul z Glassfish (v podstatě Tomcat/Undertow), pokud by byla dependency pro JMS tak natáhne modul s JMS atd. Úplně stejně jako to dělá Spring Boot a Quarkus. Klidně to mohl pojmenovat Java EE Microservice Edition. Ale ani tuhle věc, která by je nestála skoro nic, protože již všechno vyvinuté měli, neudělal. Proto vzniklo Eclipse Microprofile a Quarkus a obojí si troufám tvrdit je celkem úspěšné. Navíc díky tomu, že Oracle vyvíjí GrallVM, tak by vlastnil naprosto celou platformu od GrallVM až po poslední standardizovanou knihovnu.

Navíc jenom podle specifikace se to psalo málokdy, protože jste obvykle věděl, v jakém prostředí to poběží, takže se využily možnosti toho prostředí. Takže to třeba nebylo čisté JPA, ale Hibernate.
Párkrát jsem to taky zažil, ale u Java EE 6 to nebylo skoro potřeba a spíš to lidé dělali z neznalosti JPA. Zajímavé je, že v dnešní době se to již moc nedělá a píše se to oproti Spring Data a JPA a nikdo nemá potřebu z toho dostávat Hibernate. A jak již jsem psal normálně jsme vyvíjeli na JBoss/WildFly a aplikace pak běžela na WebSphere.

17. 9. 2021, 08:39 editováno autorem komentáře

Tohle už je úplný nesmysl.
Ne, to je realita. Když závisíte na nějaké technologii, kterou vám „aplikační server“ neposkytne, tak to fungovat nebude.

Mimochodem Spring Boot používá obyčejný Tomcat a Quarkus Undertow což je servletová část z WildFly/JBoss.
Spring Boot není plně dobrá technologie na mikroservisy. Ani nic jiného, co běží na Tomcatu.

Ale ani tuhle věc, která by je nestála skoro nic, protože již všechno vyvinuté měli, neudělal.
Otázka je, zda by jim to k něčemu bylo. To, o čem se bavíme, jsou nástroje pro tvorbu mikroslužeb. A na to technologie z Java EE nejsou vhodné. Dává smysl použít jednu dvě, ale když to postavíte jen na technologiích Java EE, nedostanete mikroslužbu. Má to možná smysl pro nějaké přechodné aplikace, když chce někdo směřovat k mikroslužbám, ale vlastně to chce dělat postaru. Je pravda, že zrovna mezi zákazníky Oraclu by se o něco takového zájemci našli – ale perspektiva v tom moc není, takže je zcela legitimní, že se tomu Oracle věnovat nechce a soustředí se na něco jiného.

Mimochodem, vyvinout Quarkus nějakou dobu trvalo, dávno hotové to tedy rozhodně nebylo.

Zajímavé je, že v dnešní době se to již moc nedělá a píše se to oproti Spring Data a JPA
Což je vhodné pro menší aplikace, kde zase nebudete mít žádnou výhodu z toho, že byste mohl použít všechny ostatní technologie z Java EE.

A jak již jsem psal normálně jsme vyvíjeli na JBoss/WildFly a aplikace pak běžela na WebSphere.
Ano, tak se to dělalo. Ale to neznamená, že jsou ty aplikační servery zaměnitelné. Také se vyvíjí pod Spring Bootem a pak se to nasadí na Weblogic. Což ale neznamená, že Spring má technologie, které jsou stejné, jako má Weblogic. API je z velké části stejné, ale implementace je jiná.

Ne, to je realita. Když závisíte na nějaké technologii, kterou vám „aplikační server“ neposkytne, tak to fungovat nebude.
Co do toho furt motáte aplikační server? To s tím nemá vůbec nic společného.

Spring Boot není plně dobrá technologie na mikroservisy. Ani nic jiného, co běží na Tomcatu.
To je sice pravda ale v dnešní době je to rozhodně nejpoužívanější technologie pro psaní microservice v Java.

Otázka je, zda by jim to k něčemu bylo. To, o čem se bavíme, jsou nástroje pro tvorbu mikroslužeb. A na to technologie z Java EE nejsou vhodné. Dává smysl použít jednu dvě, ale když to postavíte jen na technologiích Java EE, nedostanete mikroslužbu. Má to možná smysl pro nějaké přechodné aplikace, když chce někdo směřovat k mikroslužbám, ale vlastně to chce dělat postaru. Je pravda, že zrovna mezi zákazníky Oraclu by se o něco takového zájemci našli – ale perspektiva v tom moc není, takže je zcela legitimní, že se tomu Oracle věnovat nechce a soustředí se na něco jiného.
Zájem o to byl a jak ukazuje Quarkus zájem o to je. Nikde jsem netvrdil, že by se Java EE nemohla rozvíjet dál. Spring Boot se taky od první verze z roku 2004 velmi posunul. To samé se mohlo stát s Java EE. A že na to technologie z Java EE nejsou vhodné je úplný nesmysl, protože ty technologie se pořád používají ať již ve Springu nebo právě v Quarkusu. Pořád vidíte Java EE jenom jako aplikační server před 10 roky a opakujete stále to samé a diskuse s vámi nikam nevede (ne, že by někdy někde někam vedla).

Také se vyvíjí pod Spring Bootem a pak se to nasadí na Weblogic. Což ale neznamená, že Spring má technologie, které jsou stejné, jako má Weblogic.
Holinky jako hodinky obojí se natahuje.

API je z velké části stejné, ale implementace je jiná.
Ne API je dané, takže žádné z velké části stejné. Proto existovala i certifikace na servery a proto, když to bylo napsané jenom za použití API, tak to běželo na certifikovaném AS.

Co do toho furt motáte aplikační server? To s tím nemá vůbec nic společného.
Aplikační server ty technologie aplikaci poskytoval. Pokud postavíte aplikaci na Micronautu a použijete tam API EJB, opravdu vám to fungovat nebude.

To je sice pravda ale v dnešní době je to rozhodně nejpoužívanější technologie pro psaní microservice v Java.
Naštěstí se Oracle nerozhodl zabetonovat Javu na současných pozicích, ale vyvíjí ji pro budoucnost. Takže to, k čemu se používá technologie, která už je za zenitem, není moc zajímavé.

Zájem o to byl a jak ukazuje Quarkus zájem o to je.
A Quarkus ten zájem není schopen uspokojit? Nebo co by mělo být jinak?

Nikde jsem netvrdil, že by se Java EE nemohla rozvíjet dál. Spring Boot se taky od první verze z roku 2004 velmi posunul. To samé se mohlo stát s Java EE. A že na to technologie z Java EE nejsou vhodné je úplný nesmysl, protože ty technologie se pořád používají ať již ve Springu nebo právě v Quarkusu. Pořád vidíte Java EE jenom jako aplikační server před 10 roky a opakujete stále to samé a diskuse s vámi nikam nevede (ne, že by někdy někde někam vedla).
Diskuse se mnou by někam vedla, kdybyste diskutoval se mnou a ne s vašimi představami. Nikdy jsem netvrdil, že by se Java EE nemohla rozvíjet dál. Ale Java EE jako jeden velký technologický balík nemá perspektivu. Takže dál se může rozvíjet tak, že se vezmou jednotlivé její části a ty se budou používat samostatně tam, kde to dává smysl. A přesně to se děje. Třeba v Micronautu můžete použít JPA nebo JSR-330 (které je využívané i CDI). Ale je úplně jedno, že to má nějakou nálepku Java EE a že pod tou nálepkou jsou ještě další technologie. Důležité je jenom to, aby ty dílčí technologie byly plně nezávislé. Takže nálepka Java EE je tam úplně na nic a akorát hrozí, aby někoho nenapadlo začít ty technologie provazovat.

Pořád tedy nechápu, co se vám na tom nelíbí. Dílčí technologie se z toho používají. Dělat z toho balíky a certifikace, zda něco plně podporuje celý balík, nemá v dnešní době smysl – to jsou právě ty aplikační servery před 10 roky.

Holinky jako hodinky obojí se natahuje.
Uváděl jsem to jako další příklad toho, kdy se vyvíjí s jinou implementací technologií, než která se následně používá na produkci.

Ne API je dané, takže žádné z velké části stejné.
API je z velké části stejné, protože je v různých verzích a často se používají různá rozšíření API.

Proto existovala i certifikace na servery a proto, když to bylo napsané jenom za použití API, tak to běželo na certifikovaném AS.
Ano, to byla hezká teorie. Ale v praxi se to moc nepoužívalo, protože nenastávala ta situace, že byste jednu aplikaci chtěl provozovat na různých aplikačních serverech. Občas to někdo udělal, ale pak to obvykle bylo: „Tady máte bundle nebo specifikaci, že to nasadíte na tenhle AS v téhle verzi a s tou to konfigurací, pak na to od nás máte support. Nebo tady máte EAR, můžete ho nasadit, kam chcete, jsme přesvědčení, že to bude fungovat, ale support vám na to nedáme.“

Každopádně tohle jsou ty aplikační servery před deseti roky, nad kterými jste se ošklíbal. A pořád je to ten rozdíl, jestli máte platformu, programujete proti jejímu API a pak aplikaci nasadíte do nějaké implementace té platformy – což je původní Java EE. Nebo jestli máte nějaký framework, který přímo ve své aplikaci používáte a ta aplikace je s ním úzce provázaná – takže nemůžete tu aplikaci vzít a beze změny použít jiný framework. A takhle fungují frameworky jako Helidon, Micronaut, Quarkus, Vert.x. Ale i Spring a Spring Boot.

Abyste to pochopil, tak to zkusím naposled a opravdu jednoduše:
Java EE != aplikační server

Aplikační server ty technologie aplikaci poskytoval. Pokud postavíte aplikaci na Micronautu a použijete tam API EJB, opravdu vám to fungovat nebude.
Micronaut tu technologii poskytuje úplně stejně, jako ten aplikační server. Pořád je to jenom knihovna resp. framework. Jediný rozdíl je, že když použijete aplikační server, tak ta knihovna je tam a když Micronaut, tak ta knihovna je v JARu.

API je z velké části stejné, protože je v různých verzích a často se používají různá rozšíření API.
Ale pak není ten server certifikovaný nebo poskytuje něco z nové verze a stále na tom běží aplikace napsaná pro tu certifikovanou verzi. A ano tenhle bordel byl přesně ve WebSphere, ale pořád šlo používat Java EE 6 tj. že se nepoužívalo např. JPA 2.1 ale JPA 2.0.

A pořád je to ten rozdíl, jestli máte platformu, programujete proti jejímu API a pak aplikaci nasadíte do nějaké implementace té platformy – což je původní Java EE. Nebo jestli máte nějaký framework, který přímo ve své aplikaci používáte a ta aplikace je s ním úzce provázaná – takže nemůžete tu aplikaci vzít a beze změny použít jiný framework. A takhle fungují frameworky jako Helidon, Micronaut, Quarkus, Vert.x. Ale i Spring a Spring Boot.
Ale tohle se vám snažím od začátku vysvětlit, že to Oracle mohl udělat s Java EE sám. A mohla existovat Java EE od Oracle a Java EE/Quarkus od RedHatu.

Víte, jak vypadá Micronaut aplikace? Je to můj kód, který závisí na knihovnách Micronautu, případně na dalších knihovnách, které uvedu v závislostech. Klidně si to někdy zkuste, vytvořte si jednoduchou Micronaut aplikaci, dejte si do závislostí nějaké API z Java EE (jiné, než ke kterému Micronaut dodává) – třeba CDI. Až tu aplikaci zkusíte spustit, zjistíte, že nebude fungovat, protože tam bude chybět právě implementace CDI. Protože ji tam Micronaut nedodal, protože nic takového nedělá. Kdybyste to chtěl zprovoznit, budete muset do závislostí sám přidat implementaci CDI, nakonfigurovat ji… Když tohle uděláte, budete mít aplikaci závislou na Micronautu a zvolené implementaci CDI. Což je přesný opak toho, než o co se snažilo Java EE – abyste měl aplikaci závislou jen na API a mohl ji nasadit kamkoli.

Stále nechápete, že hodnota Java EE měla být právě v tom, že je to sada API (později několik sad API, kde větší sady v sobě zahrnovaly menší sady), které měli zabránit uzamčení na nějaké platformě. Prostě na vás nebude moci tlačit IBM, protože kdykoli můžete svou Java EE aplikaci vzít a přesunout ji na platformu od Oracle nebo RedHatu. Jenže za prvé tohle nikdy 100% nefungovalo, ale hlavně o to ve světě mikroslužeb není zájem. Protože když se vám ta mikroslužba přestane líbit, zahodíte ji a napíšete jinou, klidně v jiném jazyce nebo s jiným frameworkem. O takovouhle sjednocující platformu pro enterprise aplikace zkrátka už není zdaleka takový zájem, jako dříve, takže je logické, že do toho někdo nechce investovat.

Je zcela v pořádku, že dílčí knihovny z té platformy žijí dál. Kdo chce použít JPA, použije JPA – ale je mu úplně jedno, že JPA bylo kdysi především součástí Java EE. Tomu, kdo potřebuje použít jen JPA, je značka Java EE úplně ukradená. Přece když se rozhoduju, zda v aplikaci použiju pro práci s JSONem Jackson nebo JSR 374, neznamená to, že v prvním případě bude výsledkem non-Java EE aplikace a v druhém případě Java EE aplikace.

Quarkus nemá s Java EE nic společného. Jenom využívá některé standardy, které jsou shodnou okolností i součástí Java EE. Ale aplikace napsaná pomocí Quarkus není Java EE aplikace. Naopak můžete najít články jak od Javy EE přejít na Quarkus.

Takže pořád netuším, co měl podle vás Oracle s Java EE dělat. Pokud jste tím chtěl říct, že měl Oracle udělat něco takového, jako je Quarkus, pak to se stalo – za Helidonem, který jsem tu několikrát zmiňoval, je právě Oracle.

Víte, jak vypadá Micronaut aplikace? Je to můj kód, který závisí na knihovnách Micronautu, případně na dalších knihovnách, které uvedu v závislostech. Klidně si to někdy zkuste, vytvořte si jednoduchou Micronaut aplikaci, dejte si do závislostí nějaké API z Java EE (jiné, než ke kterému Micronaut dodává) – třeba CDI. Až tu aplikaci zkusíte spustit, zjistíte, že nebude fungovat, protože tam bude chybět právě implementace CDI. Protože ji tam Micronaut nedodal, protože nic takového nedělá. Kdybyste to chtěl zprovoznit, budete muset do závislostí sám přidat implementaci CDI, nakonfigurovat ji… Když tohle uděláte, budete mít aplikaci závislou na Micronautu a zvolené implementaci CDI. Což je přesný opak toho, než o co se snažilo Java EE – abyste měl aplikaci závislou jen na API a mohl ji nasadit kamkoli.
Tak asi je všem kromě vás jasné, že když přidáte dependency na api, tak tam nebude implementace.

o to ve světě mikroslužeb není zájem. Protože když se vám ta mikroslužba přestane líbit, zahodíte ji a napíšete jinou, klidně v jiném jazyce nebo s jiným frameworkem. O takovouhle sjednocující platformu pro enterprise aplikace zkrátka už není zdaleka takový zájem, jako dříve, takže je logické, že do toho někdo nechce investovat.
Právě, že o tohle by zájem byl a v dnešní době by to bylo velmi potřeba. Napíšete serverless podle API a spustíte to na Azure, AWS atp.

Takže pořád netuším, co měl podle vás Oracle s Java EE dělat. Pokud jste tím chtěl říct, že měl Oracle udělat něco takového, jako je Quarkus, pak to se stalo – za Helidonem, který jsem tu několikrát zmiňoval, je právě Oracle.
Jenže tohle měl udělat v roce 2015 a nazvat to Java EE Microservice. A o tom je celá tahle diskuze.

Právě, že o tohle by zájem byl a v dnešní době by to bylo velmi potřeba. Napíšete serverless podle API a spustíte to na Azure, AWS atp.
Jenže tohohle nedocílíte tak, že předepíšete, že aplikační server musí hostované aplikaci poskytnout implementaci synchronních servletů, CDI a JMS. A než se zase budete čertit nad tím aplikačním serverem, zkuste připustit, že aplikačním serverem je možné nazývat cokoli, do čeho se nasazuje vaše aplikace a co té aplikaci dodá implementaci něčeho, co ta aplikace sama v sobě nemá. Protože jak už jste zjistil, bez implementace to fungovat nebude.

Jenže tohle měl udělat v roce 2015 a nazvat to Java EE Microservice. A o tom je celá tahle diskuze.
Co „tohle“? Implementovat jeden framework a nazvat ho „Java EE Microservice“? Nebylo by poněkud matoucí, že předtím Java EE označovalo univerzální platformu, kterou může implementovat každý, a nově by to bylo označení pro jeden konkrétní framework? Mimochodem, Helidon se vyvíjí minimálně od roku 2018…

Jenže tohohle nedocílíte tak, že předepíšete, že aplikační server musí hostované aplikaci poskytnout implementaci synchronních servletů, CDI a JMS.
Nikdo nemluvil o tom že Java EE by v dnešní době byla stejná jako před 8lety. To jenom vy se stále koukáte na to koukate, jako by to v té době zamrzlo a už se to nijak nevyvíjelo. Pokud by ji Oracle nepohřbil svou nečinností a neschopností, tak by se vyvíjela stejně jako vše ostatní.

A než se zase budete čertit nad tím aplikačním serverem, zkuste připustit, že aplikačním serverem je možné nazývat cokoli, do čeho se nasazuje vaše aplikace a co té aplikaci dodá implementaci něčeho, co ta aplikace sama v sobě nemá. Protože jak už jste zjistil, bez implementace to fungovat nebude.
Tohle je totální nesmysl. Je to stále ten stejný přístup. Aplikační server je naprosto to samé jako framework. Ve skutečnosti všechny ty frameworky jsou akorát rozsekané aplikační servery přibalené přímo k aplikaci. Jak si myslíte, že ten aplikační server funguje? Poskytne aplikací právě ty knihovny a výsledek je naprosto stejný jako u těch ostatních frameworku.

Co „tohle“? Implementovat jeden framework a nazvat ho „Java EE Microservice“? Nebylo by poněkud matoucí, že předtím Java EE označovalo univerzální platformu, kterou může implementovat každý, a nově by to bylo označení pro jeden konkrétní framework?
Ne nebylo protože mohl vzniknout nový modul něco jako Java EE Initializer, který by moduly přibalil k té Java EE aplikaci (abyste to pochopil i vy byl by to framework který by měl implementace Java EE jako knihovny) a zároveň mohli stále existovat aplikační servery.

Mimochodem, Helidon se vyvíjí minimálně od roku 2018…

A mimochodem 2018 je rok kdy Oracle po nátlaku komunity předal Java EE. Takže to už bylo pro Oracle strašně pozdě a již v té době existoval Eclipse MicroProfile.

Vy nevíte, co chcete, ale nedáte pokoj, dokud to nemáte. Java EE z doby před osmi lety se vám pro dnešek nelíbí. OK. Tak jak podle vás měla dnešní Java EE vypadat? Já jsem jedno řešení navrhoval – vykašlat se na Java EE jako zastřešující standard a nechat jednotlivé technologie zvlášť, ať si každý používá takové technologie, které mu vyhovují. To se vám také nelíbí. Tak co tedy chcete?

Rozdíl mezi aplikačním serverem a frameworkem je v tom, že při vývoji aplikace pro aplikační server se teoreticky vůbec nestaráte o implementace toho, co vám poskytuje aplikační server. Napíšete jednu aplikaci, tu jednou spustíte pod Weblogicem, JPA bude implementovat Hibernate a data budou v Oracle SQL. A pak tu samou aplikaci, bez změny jediného bitu, nasadíte na JBoss, JPA bude implementováno EclipseLinkem a databáze bude PostgreSQL.

Když pro psaní aplikace použijete framework Spring, tak ho nevyměníte bez přepsání půlky souborů. Když budete psát Spring Boot aplikaci s embedded webovým serverem, musíte si do runtime závislostí přidat nějakou implementaci JPA. Když budete chtít implementaci JPA změnit, musíte přinejmenším znovu sestavit aplikaci s jinými závislostmi.

Vy nevíte, co chcete, ale nedáte pokoj, dokud to nemáte. Java EE z doby před osmi lety se vám pro dnešek nelíbí. OK. Tak jak podle vás měla dnešní Java EE vypadat? Já jsem jedno řešení navrhoval – vykašlat se na Java EE jako zastřešující standard a nechat jednotlivé technologie zvlášť, ať si každý používá takové technologie, které mu vyhovují. To se vám také nelíbí. Tak co tedy chcete?
Ne já stále tvrdím to samé, že Oracle zabil Java EE svojí neschopností a tvrdím to od začátku. Vy stále akorát mixujete minulost (Java EE před 8 lety) a současné moderní frameworky.
Rozdíl mezi aplikačním serverem a frameworkem je v tom, že při vývoji aplikace pro aplikační server se teoreticky vůbec nestaráte o implementace toho, co vám poskytuje aplikační server. Napíšete jednu aplikaci, tu jednou spustíte pod Weblogicem, JPA bude implementovat Hibernate a data budou v Oracle SQL. A pak tu samou aplikaci, bez změny jediného bitu, nasadíte na JBoss, JPA bude implementováno EclipseLinkem a databáze bude PostgreSQL.
Naprosto nepodstatný detail. Stejně tak to může udělat i ve Spring Bootu. Chcete Jetty dáte závislost na Jetty starter. Chcete EclipseLInk vyměníte Hibernate za EclipseLink atp. Chcete jiné JMS dáte jiný starter atp. A z velké části, že to jde udělat takto snadno můžeme všichni děkovat právě Java EE. A myslíte, že většina vývojářů ví na čem Spring Boot vevnitř běží, ani náhodou. Takže ani u frameworků se nestaráte na čem to ve skutečnosti běží.

Když pro psaní aplikace použijete framework Spring, tak ho nevyměníte bez přepsání půlky souborů. Když budete psát Spring Boot aplikaci s embedded webovým serverem, musíte si do runtime závislostí přidat nějakou implementaci JPA. Když budete chtít implementaci JPA změnit, musíte přinejmenším znovu sestavit aplikaci s jinými závislostmi.
Právě, že implementaci JPA přídávat nemusíte (tedy ne přímo) ale přidáváte Spring Data JPA. Co je za tím vás stejně jako u Java EE na AS nemusí zajímat. Máte API a to používáte. To že když to vyměníte za jinou implementaci to musíte přebuildit je daň za to, že jsou všechny závislosti zabalené ve FatJaru. I když i tohle by šlo obejít za runtime. Klidně může vzniknout Jirsák Boot, který bude v základu obsahovat Undertow, EclipseLink atp. a představte si, že by s tím mohli běžet i ostatní Spring Boot aplikace a nemusel v nich měnit skoro nic kromě pár změn v pom.xml.

Ne já stále tvrdím to samé, že Oracle zabil Java EE svojí neschopností a tvrdím to od začátku.
Vždyť jsem to psal – nevíte, co chcete, a nedáte pokoj, dokud to nemáte. Nevíte, co měl Oracle udělat jinak, ale víte, že to, co udělal, bylo špatně.

Vy stále akorát mixujete minulost (Java EE před 8 lety) a současné moderní frameworky.
Protože o ty moderní frameworky je evidentně zájem. Takže jsem se z vás stále snažil vypáčit, co měl Oracle udělat, aby se od té minulosti dostal k moderním frameworkům. Bláhově jsem si myslel, že když tvrdíte, že Oracle Javu EE zabil, že máte nějakou představu, co se s ní mělo stát.

Naprosto nepodstatný detail. Stejně tak to může udělat i ve Spring Bootu. Chcete Jetty dáte závislost na Jetty starter. Chcete EclipseLInk vyměníte Hibernate za EclipseLink atp. Chcete jiné JMS dáte jiný starter atp.
Jenže v tom je právě ten podstatný rozdíl. Jestli píšete univerzální aplikaci, kterou pak teprve konfigurací aplikačního serveru zprovozníte. Nebo jestli píšete aplikaci pomocí konkrétních technologií a jiné technologie vás nezajímají. Protože ta univerzálnost byla právě deviza Java EE, to byl důvod, proč vznikla. Myšlenka to byla zajímavá, ve své době měla své opodstatnění, ale postupem času se ukázalo, že není tak podstatná. (Všimněte si, že netvrdím, že neměla svůj vliv.)

Takže ani u frameworků se nestaráte na čem to ve skutečnosti běží.
Jenže to jsou dva různé pohledy, které jsou proti sobě otočené o 180 stupňů. Jeden pohled je „nestarám se, protože to běží pod čímkoli“, a proti tomu úplně opačný pohled „nestarám se, protože to pod ničím jiným běžet nemůže“.

Právě, že implementaci JPA přídávat nemusíte (tedy ne přímo) ale přidáváte Spring Data JPA.
To je jedno, že implementaci nepřidáváte přímo. Implementace je součástí vaší aplikace.

Již jsem vám to psal několikrát co Oracle měl udělat. Tj. Vytvořit nějaký Initializer modul, který by dodal všechny potřebné součásti z Java EE stejně jako to dělají ostatní frameworky jako Quarkus, Spring Boot atp. Jenže to měl udělat před rokem 2018 a ne se na to úplně vybodnout. Jestli nerozumíte psanému textu tak je problém u vás a ne u mě. Navíc vůbec nejde o to co já si myslím, že měl Oracle s Java EE udělat, ale co udělal a to všichni víme, že neudělal nic a pak se jí na nátlak komunity zbavil.

Rozdíl mezi Spring Data JPA s Hibernate, EclipseLink nebo OpenJPA a mezi Java EE a JPA vůbec nevidím. Pořád se používá JPA z Java EE a jestli implementaci dodá Spring, Quarkus nebo Java EE aplikační server je úplně jedno a pořád se jedná o to samé. Takže pokud udělám knihovnu s JPA API a pak jí dám do Java EE nebo Springu nebo do Quarkus, tak to pořád bude fungovat a vůbec mě nezajímá kdo mi dodá implemtaci JPA jestli framework nebo aplikační server je mi úplně jedno a z funkčního pohledu je to jedno úplně.

Stejně tak můžu říct, že implementace je součástí frameworku a moje aplikace běží na frameworku a pořád je to to samé jako když ta aplikace běží v aplikačním serveru. To, že si myslite, že dělat fatjar se všemi knihovnami v něm je jediná variantě je jenom váš problém, ale pořád si stejně jako u Java EE můžete framework dát jako provided závislost a knihovny dodat aplikaci jinak (přidáním na classpath). Mimochodem takhle by se to správně, pokud výsledkem vaší microsevice nějaký container, dělat mělo tj. dát library framework závislosti do jedné layer a do druhé samostatnou aplikaci (pokud potřebujete vědět proč to tak dělat nestyďte se zeptat). Potom už rozdíl mezi aplikačním serverem a layerem jenom s knihovnami není vůbec žádný. Na tu samou layer mužů nahrát novější verzi aplikace nebo, což bude pro vás bude naprostý šok, úplně jinou aplikaci.

Quarkus ani Spring Boot nedodávají všechny potřebné součásti Java EE. Umí dodat jenom některé. Ale dobře, dejme tomu, že by Oracle začal v roce 2018 vytvářet nějaký svůj Spring. K čemu by to bylo?

Ještě jednou vám zkusím vysvětlit rozdíl mezi Java EE aplikačním serverem a frameworkem. Když napíšete vzorovou Java EE aplikaci, spustíte ji na libovolném aplikačním serveru s podporou dané verze Java EE a profilu. Když napíšete aplikaci ve Springu, rozhodně nebude beze změny fungovat pod Micronautem nebo Helidonem.

O fatjar jsem já nic nepsal, s tím jste přišel vy.

Pokud je výsledkem mikroservice kontejner, možná to bude nativní kód přeložený GraalVM AoT, takže tam vám jarka v jiných vrstvách moc nepomohou. A i když to budete spouštět pod klasickým HotSpotem, pořád pro mikroslužby není úplně ideální nechat aplikaci teprve při startu zjišťovat, co je na classpath, a podle toho ji konfigurovat. Mikroservice nastartuje rychleji, pokud se tohle provede už v době buildu.

Tak si to přečte laskavě ještě jednou. Rok 2018 jste do toho začal motat vy s Helidonem, já jsem od začátku psal před pěti lety a ano omylem jsem myslel rok 2015. V tu dobu to smysl mělo a hlad by po tom byl.

Pokud napíšete aplikaci jenom za pomoci JPA a JAX-RS, tak vám s drobnou úpravou bude fungovat (nastavení frameworku) na většině těch frameworků, ale to je naprosto nepodstatné, protože kdyby existovala Java EE tak to tak mohlo fungovat. To co motáte do hromady je, že napíšete aplikaci přímo Hibernatem a budete se divit, že nepoběží na EclipseLink. Pořád motáte dohromady naprosto nesouvisející věci.

Pokud je výsledkem mikroservice kontejner, možná to bude nativní kód přeložený GraalVM AoT, takže tam vám jarka v jiných vrstvách moc nepomohou. A i když to budete spouštět pod klasickým HotSpotem, pořád pro mikroslužby není úplně ideální nechat aplikaci teprve při startu zjišťovat, co je na classpath, a podle toho ji konfigurovat. Mikroservice nastartuje rychleji, pokud se tohle provede už v době buildu.
To už se bavíme o něčem úplně jiném. A opět si diskuzi stačíte kam chcete.

Já jsem se ale ptal, k čemu by bylo, že by Oracle začal vyvíjet „Oracle Spring“.

Pokud napíšete aplikaci jenom za pomoci JPA a JAX-RS, tak vám s drobnou úpravou bude fungovat (nastavení frameworku) na většině těch frameworků
Nebude.

ale to je naprosto nepodstatné
To, že nerozumíte tomu, o čem diskutujete, bohužel nepodstatné není.

protože kdyby existovala Java EE tak to tak mohlo fungovat
Zdá se, že jste nepochopil princip, na kterém jsou ty frameworky postavené. Mimochodem, Spring vznikl s tím úmyslem, aby nebyl jako java EE.

To už se bavíme o něčem úplně jiném.
Bavíme se o tom, kam směřují moderní javové frameworky pro vývoj webových aplikací. Protože to je to, po čem je dnes poptávka – a Java EE umřela proto, že nabízí univerzálnost, po které ale poptávka není.

Já jsem se ale ptal, k čemu by bylo, že by Oracle začal vyvíjet „Oracle Spring“.
Tohle nikdo netvrdil. Psal jsem o tom, že měli Java EE modularizovat a udělat z ní v podstatě framework ale i s možností stále využívat aplikační servery. Byla by kontinuita a jsem si jistý, že by se to snadno prosadilo (speciálně pro vás museli by to udělat kolem roku 2015).

Pokud napíšete aplikaci jenom za pomoci JPA a JAX-RS, tak vám s drobnou úpravou bude fungovat (nastavení frameworku) na většině těch frameworků
Nebude.
Přídáme do toho toho JSR 330. Vytvořím Java EE aplikaci a nasadím na AS a funguje. Vyměním v pom.xml Java EE dependency resp. doplnim Spring Boot startery, application.pro­perties (s pár nastaveníma) a dodám main classu s inicializaci @SpringBootAp­plication a teď pro vás příjde šok ono to funguje. To samé udělám pro Quarkus a hele on to funguje. Ještě aby vás to víc šokovalo to udělám pro Helidon, Eclipse MicroProfile, Micronaut. A jediné co je potřeba změnit je initializer a konfigurace, což je naprosto to samé co konfigurace AS. Ale chápu, to nejste schopen pochopit.

Bavíme se o tom, kam směřují moderní javové frameworky pro vývoj webových aplikací. Protože to je to, po čem je dnes poptávka – a Java EE umřela proto, že nabízí univerzálnost, po které ale poptávka není.
Ne to se teda nebavíme a nikdy jsme se nabavili. Pak to možná vysvětlujete proč stále píšete naprosté nesmysly. Od začátku se bavíme o tom, že Oracle zabil Java EE. Je mi naprosto jasné, že jako vždy se snažíte stočit diskuzi někam úplně jinam, ale na to jsem si s vámi tady vyměnil už příliš mnoho komentářů abych neznal vaše typické chování. Po té univerzálnosti je stále hlad a proto 90% těch frameworků využívá spoustu API z Java EE. Ty frameworky zaplňují akorát díru, která tady po Oracle s Java EE zůstala.

Psal jsem o tom, že měli Java EE modularizovat a udělat z ní v podstatě framework ale i s možností stále využívat aplikační servery.
Jak jsem psal, nevíte, co chcete, ale nedáte pokoj, dokud to nemáte. Měli to udělat v podstatě bílé, ale aby to stále zůstalo černé.

Java EE byla modularizována ve verzi 6, kdy vznikly profily. Stále nechápete, k čemu Java EE sloužila. Byl to standard, proti kterému se dalo vyvíjet a následně bylo zaručena (resp. byl to cíl), že aplikaci vyvinutou pod Java EE (od Java EE 6 proti určitému profilu) bude možné spustit na libovolném aplikačním serveru podporujícím danou verzi Java EE (od verze Java EE 6 podporující daný nebo vyšší profil).

Celý ten princip spočívá v tom, že ten standard je jeden, nebo jich je několik málo. Asi vám stále nedošlo, že by byl nesmysl prohlásit za Java EE aplikační server cokoli, co podporuje alespoň jednu z technologií A, B, C, … W. Protože pak by jeden aplikační server podporoval technologie A, B, Q, S, další server technologie A, C, Q, W, další B, F. A kdybyste vyvinul aplikaci vyžadující D, E, M a L, nenašel byste žádný aplikační server, který by zrovna tuhle kombinaci podporoval. Takže byste nakonec stejně musel vyvíjet pro konkrétní aplikační server nebo framework, a žádný Java EE standard byste nepotřeboval. Přesně tak, jak se dnes vyvíjí s frameworky – prostě vyberete jeden a aplikaci vyvíjíte s ním.

Oracle mohl maximálně tak přijít s jedním v řadě těch frameworků, což se také stalo – za Helidonem stojí Oracle. A neřekl bych, že má proti Quarku nebo Micronautu nějaké zpoždění.

Vyměním v pom.xml Java EE dependency resp. doplnim Spring Boot startery, application.pro­perties (s pár nastaveníma) a dodám main classu s inicializaci @SpringBootAp­plication a teď pro vás příjde šok ono to funguje. To samé udělám pro Quarkus a hele on to funguje. Ještě aby vás to víc šokovalo to udělám pro Helidon, Eclipse MicroProfile, Micronaut. A jediné co je potřeba změnit je initializer a konfigurace, což je naprosto to samé co konfigurace AS. Ale chápu, to nejste schopen pochopit.
Já to chápu – vůbec netušíte, o čem je řeč. Až budete mít tu aplikaci napsanou pod Spring Boot frameworkem, s anotací @SpringBootAp­plication, odstraňte ze závislostí celý Spring a dejte do závislostí Quarkus nebo Micronaut. Vy tvrdíte, že to funguje – tak takový kód předveďte. Já tvrdím, že vám taková aplikace ani nepůjde přeložit.

Ne to se teda nebavíme a nikdy jsme se nabavili. Pak to možná vysvětlujete proč stále píšete naprosté nesmysly. Od začátku se bavíme o tom, že Oracle zabil Java EE.
Po Java EE nebyla poptávka, proto skončila. Oracle neměl co zabíjet, Java EE prostě umřela na nezájem.

Po té univerzálnosti je stále hlad
Není. Ta univerzálnost měla chránit před závislostí na jednom dodavateli. Typicky to bylo namířené proti Microsoftu – když budete vyvíjet v Microsoftích technologiích, jste vydáni na pospas Microsoftu. Napište aplikaci raději pomocí Java EE, pak můžete dodavatele aplikačního serveru snadno vyměnit.

Jenže o to u mikroslužeb není zájem, protože nemáte jednu obří aplikaci, jejíž výměna by byla drahá. Máte malé služby, které jsou různorodé, takže když budete potřebovat něco změnit, jednu službu zahodíte a místo ní dáte jinou.

Po té univerzálnosti je stále hlad a proto 90% těch frameworků využívá spoustu API z Java EE. Ty frameworky zaplňují akorát díru, která tady po Oracle s Java EE zůstala.
Nezaplňují žádnou díru, je to něco jiného. To, že se používají dílčí API z Java EE, je naprosto v pořádku – to je to jediné, co dává z Java EE smysl. Vy tvrdíte, že Oracle Javu EE zabil, ale ve skutečnosti to, co z Java EE dává smysl, pokračuje. Ale nepokračuje to jako jeden velký standard, protože o to není zájem. Akorát vy byste pořád chtěl, aby Oracle černou přemaloval na bílou, ale tak, aby zůstala pořád černá.

A skoro všichni Shenandoah poskytují kromě Oracle a asi SAPu. Shenandoah má jednu vlastnost, kterou žádný GC v Java 11 neumí a to vracet nepoužitou paměť zpět OS a nedržet jí navždy. G1 to umí až od Java 12.

No a co, že ho všichni poskytují? Pokud by poskytovali dva buildy, jeden se zapnutou podporou a druhý bez ní, bylo by to za mne v pořádku. Přidat bez důrazného varování do buildu novou vlastnost, to podle mne v pořádku není. Můžete argumentovat tím, že se ta podpora musí zapnout při startu aplikace a že to tedy nemůže nic negativně ovlivnit – jenže ono to problém způsobit může. Například pokud by si někdo nevšiml, že to není standardní vlastnost OpenJDK 11, počítal s tím – a pak to na jiném buildu nebude fungovat.

Všimněte si, že nijak nerozporuju užitečnost Shenandoah. Nerozporuju dokonce ani to, že může být součástí buildů OpenJDK. Ale měly by to být speciálně označené buildy, u kterých bude na první pohled jasné, že to není standardní OpenJDK.

Oracle JDK měl také věci co v OpenJDK nebyly, takže je to taky špatně?
Přidat bez důrazného varování do buildu novou vlastnost, to podle mne v pořádku není.
Všichni co to chtěli použít o tom věděli. Kdo to nepoužívá tak ho to neovlivnilo. GC se přidávali a odebírali od nepaměti. Maximálně vám to vypíše varování, že Shenandoah není přítomný. Tak co je tady vlastně za problém? Zjednodušeně, pokud nepoužíváte Oracle JDK nebo tři roky staré OpenJDK 11, tak tam Shenandoah je.

Oracle JDK není build OpenJDK.

Kdo to nepoužívá tak ho to neovlivnilo.
To by se hodilo na takový ten seznam posledních vět před smrtí. Vedle “to je bezpečná oprava, to nemůže nic rozbít“ atd.

Oracle JDK není build OpenJDK.
Je vám doufám jasné, že Oracle JDK vychází z OpenJDK a kdo ví jestli se to dnes vůbec něčím, než změnou nějakých stringů s copyrighty liší. Takže pokud někdo používá nějaký build OpenJDK tak by měl vědět od koho pochází. A pokud to neví, tak si to může snadno zjistit. Kdybyste nevěděl jak:

java -version

OpenJDK Runtime Environment AdoptOpenJDK

To by se hodilo na takový ten seznam posledních vět před smrtí. Vedle “to je bezpečná oprava, to nemůže nic rozbít“ atd.
A stalo se něco? Nestalo. Ovlivnilo to někoho? Neovlivnilo. Je ten kód izolovaný? Je. Je ho nutné aktivovat při buildu a při použití? Je. Je přidaná hodnota velká? Je. Používá se to? Ano.
Jinde bych s tím souhlasil, ale zrovna tady u přidání GC s tím nemám vůbec žádný problém a jak je vidět tak s tím kromě Oracle nemá problém skoro nikdo.

Je vám doufám jasné, že Oracle JDK vychází z OpenJDK
Ano, je mi to jasné. A vám je doufám jasné, že „distribuce“ něčeho je něco jiného, než „vychází z“ něčeho.

Takže pokud někdo používá nějaký build OpenJDK tak by měl vědět od koho pochází.
Proč?

A pokud to neví, tak si to může snadno zjistit. Kdybyste nevěděl jak:
Demagogu.

A stalo se něco? Nestalo. Ovlivnilo to někoho? Neovlivnilo.
Jak to víte? Ona existuje nějaká povinnost všechny problémy související s Javou vám hlásit?

Jinde bych s tím souhlasil, ale zrovna tady u přidání GC s tím nemám vůbec žádný problém
Kde uděláte tu tlustou čáru? Co takhle vylepšení nějakého GC, o kterém bude jeho autor tvrdit, že určitě nemůže mít negativní dopad na aplikaci? To by se také mohlo šoupnout do starých verzí, ne? A co přidání nové metody do třídy nebo do rozhraní? To přece starý kód nemůže volat, takže to také nevadí, ne?

Je vám doufám jasné, že Oracle JDK vychází z OpenJDK
Ano, je mi to jasné. A vám je doufám jasné, že „distribuce“ něčeho je něco jiného, než „vychází z“ něčeho.

Takže pokud někdo používá nějaký build OpenJDK tak by měl vědět od koho pochází.
Proč?
A proč by to měl znát když používá JDK? Třeba GraalVM, Oracle JDK nebo distribuci OpenJDK.

Jak to víte? Ona existuje nějaká povinnost všechny problémy související s Javou vám hlásit?
Máte nějaký důkaz, že se něco stalo? Nebo jenom plácáte?

Kde uděláte tu tlustou čáru? Co takhle vylepšení nějakého GC, o kterém bude jeho autor tvrdit, že určitě nemůže mít negativní dopad na aplikaci? To by se také mohlo šoupnout do starých verzí, ne? A co přidání nové metody do třídy nebo do rozhraní? To přece starý kód nemůže volat, takže to také nevadí, ne?
Tak pokud nechápe rozdíl mezi upravením stávajícího GC a přidáním nového GC, tak je mi vás skutečně líto. GC je součásti JVM a z pohledu aplikace je neviditelný. Změní se přidáním GC nějak výsledný bytecode aplikací? Asi těžko. Na rozdíl od Oracle JDK, kde se nedozvíte co se v update JDK změnilo, tak tady je to jasně deklarované a doložitelné.

A proč by to měl znát když používá JDK? Třeba GraalVM, Oracle JDK nebo distribuci OpenJDK.
Protože jsou to dvě různé věci. JDK je aplikace (a knihovny), a nikdo neočekává, že dvě různé aplikace budou dělat to samé. Aby něco mohlo používat názvy Java a JDK, musí to splnit nějaké standardy – ale pořád je to jen splnění standardů, které je možné splnit různě, a může tam být cokoli navíc. „Build“ znamená, že vezmu zdrojáky a přeložím je. Buildy se můžou lišit tím jaké patche zahrnu, jaký překladač použiju, jako nastavení překladače. Ale když je to build téže verze, mělo by se to lišit jenom zahrnutím bezpečnostních patchů, ničím dalším. Nebo to má být výrazně označeno, že je to pozměněný build.

Je to stejný rozdíl, jako když máte Chrome a Firefox – dvě různé aplikace, a naproti tomu máte dva různé buildy jedné verze Firefoxu.

Máte nějaký důkaz, že se něco stalo? Nebo jenom plácáte?
V IT je zvykem možným problémům předcházet. Třeba je normální zálohovat data. A zálohují se dříve, než se o nějaká data přijde. Váš přístup, kdy byste řekl „zatím se o žádná data nepřišlo, tak není potřeba zálohovat“ není považován za správný.

Tak pokud nechápe rozdíl mezi upravením stávajícího GC a přidáním nového GC, tak je mi vás skutečně líto.
Nic takového jsem nepsal.

GC je součásti JVM a z pohledu aplikace je neviditelný.
Zřejmě nechápete, co dělá GC. Například to, zda a na jak dlouho se kvůli GC zastavují jednotlivá vlákna, chování aplikace ovlivňuje, někdy dost podstatně. Asi byste nechtěl, aby v řídícím systému vašeho auta někdo jen tak vyměňoval GC a použil nějaký s nepredikovatelnou latencí s odůvodněním, že GC je přece z pohledu aplikace neviditelný.

Změní se přidáním GC nějak výsledný bytecode aplikací?
Pro vaši informaci, posloupnost je taková, že máte nejprve zdrojový kód v Javě, ten se pomocí kompilátoru přeloží do bajtkódu – GC se toho zatím nijak netýká. Přeložený bajtkód se pak spustí pod Java Virtual Machine, která bajtkód nijak neupravuje – jenom ho interpretuje nebo překládá na nativního kódu. A součástí prostředí, které běžící aplikaci poskytuje JVM, je i GC. JVM tedy opravdu bajtkód nemění, ale chování aplikace na JVM závisí. Proto se používají různé GC, protože mají vliv na to, jak aplikace funguje. Kdyby se aplikace se všemi GC chovaly stejně, není potřeba vytvářet další GC.