Hlavní navigace

Názor ke zprávičce Java 17 a OpenJDK 17 s hotovým Vector API a plánovaným koncem Applet API od Filip Jirsák - Co do toho furt motáte aplikační server? To...

  • 17. 9. 2021 10:51

    Filip Jirsák

    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.