Itt a Java 16!

Java

Linkek:

( zdesigner | 2021. 03. 17., sze – 13:30 )

Jó, jó, de lesz idén Java-Mikulás? :) 

( nagy_peter v | 2021. 03. 17., sze – 14:15 )

Van már olyan desktop program, ami 8-asnál újabb Java-t igényel? 
Én folyton csak olyanba futok bele, ami 8-asnál újabb java alatt nem indul el.

Nagy Péter

( hunludvig v | 2021. 03. 18., cs – 09:53 )

Majd egy napja kint a hír és még senki nem posztolta be, hogy döglött platform?

Azért ne hasonitsuk össze egy totálisan döglött nyelvvel/technológiával az őskorból.

Bár részben igazad van, most hogy a Java EE app serverestül a sirban végezte, elég sok legacy rendszert lehet még megszokásból toszogatni, de maga a nyelv azért tovább él és fejlődik.

A Jakarta is? Ismerősömnél még tolják az EE-t ezerrel.

Amúgy maga a pőre Java sokat fejlődött, és igazából azt sem értem, hogy miért törik el olyan sok régi program új JRE/JDK mellett, mikor pl az én (igaz nem túl bonyolult/összetett) projektjeim vígan szaladnak 1x JDK-kon is is, valamint miért nem lehet hozzácsopni a futtatókörnyezetet az alkalmazásokhoz? Sok embernek az vette el a kedvét a Java-tól, amit a sün/orákulum Java SE telepítő műveltek, de egy pőre csak kizippelt OpenJDK pl marhára nem nyúl semmihez, nem okoz semmi galibát és nyugodtan lehetne minden alkalmazáshoz saját futtatókörnyezetet csomagolni. Vígan elfut egy újabb OpenJDK és egy régebbi JRE javaw.exe ugyanazon a gépen több példányban, mindenféle konténer/homokozó/virtualizáció nélkül.

Látom amúgy a trendet, tényleg egyre népszerütlenebb, de azért nem egy teljesen elavult romhalmaz, csak a .net nyitása is betett neki.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Én nem láttam új projektet ~5 éve amit ebben csináltak, ellenben mindenhol Spring-Bootot igen. Te láttál?

Én csak ilyeneken dolgozom. Olyanon is, aminél Spring-ből kell átírni ezt-azt, mert elértek a határokig és kemény a fal, a körbetákolás meg összeomlott, a JavaEE-ben pedig out-of-the-box benne van, ami hiányzott. 

Alapvetően az van, hogy nincs új ember JavaEE-re, mert nem igazán tanulja senki, mindenki tolja a divatos 0 perces keretrendszereket, mert a Hello World projektek izgalmasak és egyszerűek, aztán amikor elérnek a keretrendszeri falakhoz, akkor jön az, hogy szopás van.

https://iotguru.cloud

Nem is állitom hogy csettintésre eltűnt az EE, csak hogy ahol létezik még az legacy. Új projekt sehol. De ezek szerint kevés rálátásom van a piacra. Egy-két magyar bankot tudnék mondani ahol még tartja magát. És egyéb nehezen mozgó dinoszaurusz-szervezetek.

0 perces alatt gondolom nem a Springre vagy a Spring Bootra gondolsz (2002 és talán 2013, ha összeadom a korukat években akkor majdnem 30 (!!!!) évnél járunk).

Egy kicsit mesélj hogy mi az a fal amit a Spring-Boot nem tud átugrani, a Java EE az app servereivel meg igen.

Új projekt sehol. De ezek szerint kevés rálátásom van a piacra.

Miért gondolod, hogy téged találnának meg JavaEE munkával, ha nem értesz hozzá? Tipikus survivorship bias. :)

0 perces alatt gondolom nem a Springre vagy a Spring Bootra gondolsz

Nem, hanem például a https://ktor.io/ sokak új játékszere, mert fancy és syntactic sugar meg lófasz tejszínhabbal. És amint elértek a határáig, jönnek a szopáshegyek.

Egy kicsit mesélj hogy mi az a fal amit a Spring-Boot nem tud átugrani, a Java EE az app servereivel meg igen.

Például horizontálisan és/vagy vertikálisan elosztott tranzakciók kényelmes támogatása, idéznék a doksiból: "Last but not least, EJB has an advantage over RMI in that it supports standard role-based authentication and authorization and remote transaction propagation. It is possible to get RMI invokers or HTTP invokers to support security context propagation as well, although this is not provided by core Spring: There are just appropriate hooks for plugging in third-party or custom solutions here."

De van még sok apróság, amire a core Spring nem ad egységes támogatást, vagy 3rd party tool kell hozzá vagy custom körbetákolás. Leginkább custom körbetákolással szoktam találkozni.

https://iotguru.cloud

Amit itt olvasok (RMI, elosztott tranzakció) nekem olyasminek tűnik aminek eleve ott se kéne lennie a rendszerben, DE nem is vagyok architect 20 év tapasztalattal, elhiszem hogy bizonyos rendszerekben szükség van rá. Nem is tudok rá nagyon mit mondani, én főleg microservice -eket vagy ahhoz hasonló alkamazásokat gyártok, és nem jellemző hogy tranzakcionálisan kellene kezelnünk alkalmazásokon átivelő folyamatokat.

Amit itt olvasok (RMI, elosztott tranzakció) nekem olyasminek tűnik aminek eleve ott se kéne lennie a rendszerben, DE nem is vagyok architect 20 év tapasztalattal, elhiszem hogy bizonyos rendszerekben szükség van rá.

Hát pedig sok-sok-sok esetben fontos dolog, hogy semmiképp ne legyen adatvesztés és integritása legyen a rendszernek. Értem, hogy nem találkozol ilyenekkel, de ez nem jelenti azt, hogy ezekre nincs igény.

Nem is tudok rá nagyon mit mondani, én főleg microservice -eket vagy ahhoz hasonló alkamazásokat gyártok, és nem jellemző hogy tranzakcionálisan kellene kezelnünk alkalmazásokon átivelő folyamatokat.

Ja, úgy könnyű...

-

Ez kicsit olyan, mintha futár lennél egy 50 köbcentis robogóval és egyszerűen nem értenéd, hogy minek vannak még mindig nagy tehergépkocsik, biztos ki fognak halni, mert az utóbbi években mindig csak olyan dolgokat kellett vinned, ami elfért a motoron, nem találkoztál olyan kiszállítandó termékkel, amihez teherautó kellene. Pedig egyszerűen csak olyan feladattal bíztak meg, amihez elég a robogó, nem kerestek meg azzal, hogy ki kellene vinni 10 darab 250 kilós kazánt.

https://iotguru.cloud

Nem is azt mondtam hogy szabad adatot veszteni, hanem azt mondtam hogy minden alkalmazás a saját tranzakciójáért felel :)

Ami nagyon sok esetben egyszerűen kevés és ilyenkor jön a Spring esetén a mindenféle custom dirty hack, különben könnyen inkonzisztens lehet a rendszer egésze.

De rendben, ebben maradhatunk.

Emlékeim szerint ezen már többször is átmentünk, pont ebben maradva, aztán mindig újra előhozod.

https://iotguru.cloud

És például Wildfly Swarm használatával egészen jól is használható, ha külön akarjuk futtatni a kis szolgáltatásainkat, OpenShift használatával meg on premise is meglesz a felhő élmény. Ha meg JavaEE konténerben akarjuk futtatni, akkor ott tudjuk futtatni. Ha meg szeretnénk tranzakciókat és security propagációt a szolgáltatásokon keresztül, akkor nem kell vért hugyozni. :)

Szoktam mondani, hogy a konténereket és a microservice architektúrát a Java EE hozta be, csak ez a legtöbb helyen nem ment át és zsíros seggű mamutokat építettek.

https://iotguru.cloud

> nem igazán tanulja senki

Hogyan lehet rendesen megtanulni? Én is Spring/Tomcat világból jövök és napi szinten tákolunk. Sejtem, hogy érdemes lenne jobban belemélyedni az EE-be, de vagy ezer éves doksikat találok vagy a legújabb trendi cuccokat. Hol lehetne belekezdenem?

"napi szinten tákolunk"

Az a Java EE-nél is úgy lesz, ne aggódj :) Egy kicsit én is EE-ztem régebben, és volt olyan hogy hiába volt feketén fehéren megkövetelve valami az EE doksiban, az egyik konténer igy csinálta, a másik meg úgy.

Egy kicsit én is EE-ztem régebben, és volt olyan hogy hiába volt feketén fehéren megkövetelve valami az EE doksiban, az egyik konténer igy csinálta, a másik meg úgy.

Ezek szerintem nem megkövetelt dolgok voltak, hanem opcionális dolgok, eléggé szigorú a Java EE specifikáció abban, amit megkövetel. Mondanál példát?

https://iotguru.cloud

a Java EE app serverestül a sirban végezte

Van olyan friss projektem, amin a távoli országban székelő ügyfél az AS/400-on futó, kb. 20+ éves IBM dokumentumkezelőjét immáron Linuxon futó IBM dokumentumkezelőre cseréli - alatta a jólszituált 8-as IBM Java + WebSphere 9... és ezt most vezetik be!