Váltás java 8-ról 9-re vagy újabbra

Fórumok

Anélkül, hogy közvetlenül bármi közöm lenne a témához, pusztán külsős érdeklődőként: van itt olyan, aki akár üzemeltetőként, akár fejlesztőként már váltott vagy legalább megpróbált váltani 8-ról 9-re?
Mik a tapasztalatok?
Mivel lehet megelőzni a nagyobb szívásokat?
Esetleg jobb elfelejteni az egészet? Elvileg ugye a 8-as még sokáig támogatott, csak jövő évtől fizetős (Oracle JDK8 extended support 2025-ben ér véget, az OpenJDK8-ról meg nem találtam ilyen infót)

Érdekes, hogy a 9-es a jelek szerint nem kompatibilis felülről a 8-assal - ennek nem néztem utána, de ha 9-es JRE volt telepítve a gépemre, akkor pl. az IntelliJ IDEA és a PyCharm nem működtek. (el sem indultak) Mindkettő javaban íródott. Visszatérva az OpenJDK8-ra már működnek.

Hozzászólások

Röviden:
Java8-ról álltunk át Java9-re (kliens oldalon). Volt vele meló, akarni kellett és részben néhány dolgot átcsavarni, pl. a buidelést (javapackager). Szerintem nem volt túl sok szívás. Egyelőre a Java10-re átállás nincs tervben de próba jelleggel elvégeztem és 9 -> 10 az csak annyi volt, hogy kicseréltem egy fileban a 9-t 10-re. :)

Ha oracle jre-t használnak, és nem openjdk-t, akkor volt, amennyiben nem akarnak support-ért fizetni.

A nagy váltás most 8->9 irányába van, egyrészt ha a saját alkalmazás használ olyan API-t, amit az Oracle bezárt
a modulok miatt (és igen, elmondták korábban, hogy nem kéne), illetve ha használ valami olyan KÖNYVTÁRAT, ami
használt olyan api-t, amit bezártak.

Oracle Java SE support:
9 - már nincs publikus update.
10 - idén szeptemberig
11 - idén szeptemberben szándékoznak kiadni

Forrás: http://www.oracle.com/technetwork/java/eol-135779.html
Csak ezért kérdeztem.

Ez a modulos izé, ez mi? Tegnap nézelődtem, de csak a jdk forrás modularizálásáról találtam infót.
Azért nekifutok újra a keresésnek.

"Strong encapsulation—The packages in a module are accessible to other modules only if the module explicitly exports them. Even then, another module cannot use those packages unless it explicitly states that it requires the other module’s capabilities. This improves platform security because fewer classes are accessible to potential attackers. You may find that considering modularity helps you come up with cleaner, more logical designs."

Az egyik legfontosabb pontja a történetnek. Csak ugye ehhez végül is az egész JDK-t át kellett hegeszteniük, aminek meg következményei vannak.

https://labs.consol.de/development/2017/02/13/getting-started-with-java…

Röviden: a könyvtár fejlesztők számára ad egy lehetőséget, hogy mi az, amit kipublikál a könyvtárából,
és mi az, ami belsős kód marad. Eddig erre ugye nem igazán volt lehetőség, most már van. Az ötlet
egyébként teljesen jó, csak ennek vannak bizonyos következményei.

A másik kérdéshez: a történet egyszerű. Vagy használod az Oracle legújabb JVM-ét, mert az mindig
elérhető lesz, vagy maradsz egy régebbi verziónál, amihez egy ideig kapsz supportot, utána meg csak
pénzért. Vagy ha nem akarsz fizetni, akkor ott az OpenJDK.

Ez így elsőre furcsa, de ha megnézzük, baromi sok cég ezt csinálja, sőt, a legtöbbször
azt mondják, hogy X verziónál régebbit nem is támogatnak, és kész. Itt van rá lehetőség, egyszerűen
fizetni kell érte.

Mondjuk ha szerver alkalmazást fejleszt valaki, simán lehet, hogy megéri fizetni egy licensz-t, és
hozzácsapja a terméke árához.

A motiváció az volt, hogy később ne legyen még nagyobb a szívás mondjuk java8ról ugrani Java akármennyire. Pár apróság is jól jött a 9ből (Compact Strings, G1GC), bár ezek inkább csak érzésre segítettek. Volt egy komolyabb technológia/stack váltás is még tavaly évvége felé és így rögtön ezt is megléptük és innentől már 9->10, 10->11 vagy épp 9->11 kevésbé szívás.

Ha nagyon rövid akarok lenni: inkább lépünk verziónként gyakran kisebbeket mint ritkán egy nagyot.

Érdemes áttekinteni mire álltok át, mielőtt beleugrotok. Megváltozott a Java verziózása és licenszelése is!

http://www.oracle.com/technetwork/java/javase/documentation/eol-135779…

https://medium.com/codefx-weekly/no-free-java-lts-version-b850192745fb

Az LTS verziókra érdemes átállni, mert éles környezetben általában ezt preferálják.
Az átállás során a Java ökoszisztémában lesz több probléma, például: adott maven plugin nem fog futni - és ez baj, mert meg kell várnod hogy kijöjjön a frissítés belőle. De vannak olyan sajátosságok is mint például a Java9-ig 1.9 formában kell az adott pluginban hivatkozni a java verzióra, de felette már 10, 11, stb formában.

Szerintem kipróbálgatni ki lehet ezeket a köztes verziókat, de csak a technológia követésének céljából. Az LTS verzió bevezetése előtt meg kell bizonyosodni hogy az ökoszisztémád tamogatja azt: maven pluginok, CI szerver, IDE, teszteszközök, monitoring rendszer, APM, stb.

Ha ezek rendben vannak, akkor lehet végre a kóddal is foglalkozni.

"Csak a változás állandó." - Herakleitos

Hát, több kolléga is hasonló véleményt fogalmazott meg, 18-20 éves Java tapasztalattal a háta mögött. De ezt majd a piac eldönti. Az OpenJDK menekülési útvonal lehet, de abba ugye visszaportolja az Oracle a javításokat KORLÁTOZOTT ideig (4 hónapig) utána meg nem. Ennek az lesz a következménye, hogy divergálni fog az OpenJDK és az Oracle JDK működése, amelyet tovább erősít az, ha az OpenJDK sok patchet kap mondjuk egy Red Hat-től.

"Csak a változás állandó." - Herakleitos

"Ennek az lesz a következménye, hogy divergálni fog az OpenJDK és az Oracle JDK működése"
Vagy nem.
https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-…
"While we know there will initially be differences, our intent is that within a few releases there should be no technical differences between OpenJDK builds and Oracle JDK binaries. To achieve this, Oracle will work with other OpenJDK contributors on an open build-and-test infrastructure with the potential to support additional ports."
"Oracle JDK will contribute previously commercial features such as Java Flight Recorder to OpenJDK"
"The Oracle JDK will continue as a commercial long term support offering
The Oracle JDK will primarily be for commercial and support customers once OpenJDK binaries are interchangeable with the Oracle JDK (target late 2018)
Oracle will continue to enhance the packaging and distributing of complete ready-to-run applications"

Az egésznek a lényege, hogy a normál kiadás lesz az OpenJDK, aminek a fizetős supportált változata az Oracle JDK.
Mindennek az oka a .NET Core megnyitása volt szerintem.

Miért zárnák be? A default Java a GPL licences OpenJDK lesz. Ha meg kereskedelmi támogatást akarsz, akkor Oracle JDK.

Nem tudom, ki az, aki használ élesben Javat közületek, és használ kereskedelmi támogatást (ami most is elérhető az Oracle-től).

Ami most a támogatás nélküli Oracle JDK (azaz a sima Oracle JDK), az lesz az OpenJDK. Kódminőségben, tartalomban, mindenben.

Ami meg a mostani kereskedelmi támogatásos Oracle JDK, az lesz az Oracle JDK.

(Egyszer régen az egyik patinás szofvergyáros egyik mw-ének tanfolyamán a tanfolyami oktató azzal kezdte, hogy a termék neve volt ez, volt az, és most megint változni fog, mert a "B"RD, a "Bigswcompany" Renaming Divison döntése ez volt. Simán leírtam (és nem csak én) ezt a Bigswcompany Renaming Divisont, hogy figyelemmel kísérjem a tevékenységüket, mert egy ideje tele volt már a hócipőm azzal, hogy a cég termékei és azok dokumentációi soha nem azon a néven találhatóak, mint amelyen az öreg rókák emlegetik őket.

oktató: Ezt a "B"RD-t le ne írjátok! Az ujjamból szoptam, hogy színezzem a sztorit.
mi: Ja... pedig teljesen hihető volt, hogy van ilyen osztály.
oktató: Hát ez az...

Úgy látszik, fertőző.)

Umm, pont az van a cikkben hogy közelíteni fog egymáshoz a kettő...

Én nem látom a közelgő katasztrófát amitől zengenek ezek a topic-ok. A kényszerített update fejlesztőként örvendetes, tapasztalatom szerint indokolatlanul sok 1.6-os cucc van a piacon (jelenleg is van a kezem alatt). Örülnék ha már írhatnék egy lamba kifejezést...

A fizetős Oracle JDK érdekes lépés, nem hiszem hogy akinek az OpenJDK nem jó annak ketté törné az üzletét ez a lépés.

Látom hogy rövid távon fog ez bukkanókat okozni, de közép távon jobb az irány, szerintem.

Kényszerített update: nagyobb céges környezetben még nem dolgoztál? Utolsó munkahelyemen még élnek olyan rendszerek, amiket még a XX. században építettünk és működnek. Egyszerűen nincs idő, kapacitás stb., hogy minden egyes rendszert állandóan átírjanak az adott eszköz fejlesztőinek újabb és még újabb kitalációinak megfelelően. Lásd java8->újabb átállás.

Csak nagyobb környezetben dolgozom, nemzetközi bank szférában kódolok.

Tudom hogy ez a nincs kapacitás duma a fő indok, találkoztam vele eleget. Most éri utol a sok jól menedzselt céget a technical debt, mindenki szépen túl fogja élni.

Ahogy írtam igen, a java8->9 döcögés lesz, de utána nem, ami szerintem elfogadható trade-off.

Nem duma... miközben írod az új rendszer új kódját, mennyi időd van rá, hogy egy korábbi rendszeredet átírd az új fejlesztőeszköz igényeinek megfelelően? És ez csak egy darab fejlesztő. Kell még üzemeltetés, esetleg a szakterületekről tesztelők, akiket a napi munkájukból kell kivenni a tesztek idejére stb.

A sun.misc.Unsafe volt szerintük az egyetlen módja anno, hogy direktben memóriát foglaljál, és magadd menedzseld (meg még sok minden mást is tud ez az implementation-detail osztály).

Persze lett volna más megoldás (például JNI-vel), de mindenki kényelmes volt: ha már más is használja az Unsafe-t, nekem is lehet, hiszen nem lesz a Sun/Oracle olyan hülye, hogy bedöntse a projekteket. Nem, nem hülyék, csak kényelmesek.

Emiatt a sun.misc.Unsafe whitelisten van, az kilátszik még a csomagokból. Szar megoldás.
Érdemes elolvasni ezt: https://blog.takipi.com/still-unsafe-the-major-bug-in-java-6-that-turne…

És nem véletlenül dolgoznak alternatívákon.

Azert kivancsi lennek, hogy irsz meg mondjuk egy Mockito-t a sun.misc.Unsafe nelkul... :)

Szerintem a fo problema az, hogy a Java alapvetoen az egysegsugaru programozonak lett kitalalva: csak semmi izgalom, csak semmi extravagancia, minden a leheto legegyszerubb, hogy a huje is megertse (es tudjon benne kodolni) - uzleti szoftverek fejlesztesehez ez a helyes hozzaallas. Ez viszont kifejezetten megneheziti azoknak az eletet, akik power toolokat fejlesztenek, amelyek egy szinttel melyebb hozzaferest es hozzaertest igenyelnek (jellemzo pelda: a private field/method azert private, hogy az egysegsugaru programozo ne hivja meg veletlenul. Viszont a teszteleshez es ugy altalaban a kodon operalo / kodot manipulalo tooloknak ez csak egy "flag").

Talan a legjobb megoldas egy kulon Java fordito es JVM lenne, ami kifejezetten tamogatna ezt a fajta hasznalatot (pl. ki lehetne kapcsolni a visibility checkeket). Persze akkor meg minden marha raszabadulna, akar szuksege lenne ra akar nem, es elszabadulna a kaosz...

Elolvastam, nagyon tanulsagos. Lenyegeben arra lukad ki, amire en is (pl. java agent hasznalata aka "specialis JVM / compiler uzemmod"), illetve "... Test libraries like Mockito can only be used in a testing scope."

Azert nem egy trivialis feladat, le a kalappal az ipse elott. Remelem kap erte fizetest :)

"Ez viszont kifejezetten megneheziti azoknak az eletet, akik power toolokat fejlesztenek, amelyek egy szinttel melyebb hozzaferest es hozzaertest igenyelnek"

nekem régen az jött le a javaval kapcsolatban, hogy a buzi cések pointerekkel baszakodnak alacsony szinten, nekünk meg itt van a szuper high level java, ahol ilyenekkel nem kell törődni, mert lazán eltekintünk fölötte. gondolom erre találták ki. az nem lehet, hogy ilyen powertool esetén nem java kellene, hanem mondjuk c? ahogy gondolom machine/deep learninget sem assemblyben írnak/használnak.

"I'd rather be hated for who I am, than loved for who I am not."

elképzelhető, javaban nem programozok, így lehet mások az elképzeléseim a powertoolról. gondolom a leírtakat nem lehet alacsonyabb szintű nyelven megírni, mert annak meg ott nem lenne értelme, vagy nehézkes lenne.

"I'd rather be hated for who I am, than loved for who I am not."

Semennyi, mert a cég és a menedzsment így tervezik meg a munkát. Akár hány helyen dolgoztam, mindenhol említették a szakemberek felfelé, hogy van technical debt a kódbázisban, kéne vele foglalzkoni, de ahogy írod a XX. század óta tologatják és tesznek rá, minek ez alapon.

Ahol ez most is így van, igen, ott drágulni fog bezony a dolog a kedves cégnek. Maguknak köszönhetik csak, de ismét, senkinek a biznisze nem fog csődbe menni emiatt, csak lesz egy jó adag manager fluktuáció.

A problémát nem technikai oldalról látom hanem szervezeti oldalról. Fejlesztőként szerintem 1 sprint, rossz esetben 2 sprint elég az átállásra. Nagyon-nagyon unlucky esetben 3 sprint, ha mondjuk valamelyik maven plugin helyett alternatíva kell. Üzemeltetői/infra oldlaról nem tudom mekkora munka, aki jártas ebben jelezze.

A gond ott lesz, hogy a jelenlegi szervezeti felépítés - azaz a szemellenző ami rád van téve, a fejlesztő/üzemeltető teljes elválasztása sőt egymás szervezetileg támogatott utálása, inkompetens menedzsment, a hatékonytól teljesen távol álló céges folyamatok és 4 rétegnyi menedzseren átfutó kommunikáció az átállási folyamatot fájdalmassá fogja tenni. Tekintsük ezt most egy Darwin-i közbeavatkozásnak, főleg ahogy 2020-tól elkezdenek jönni a pénzügyi startup-ok, ezek a túlhízott multik ahol semmire nincs pénz és idő a $2 milliárd-os árbevétel mellett, kénytelenek lesznek kompetetívvé válni.

Ami pedig annyira régi hogy esélytelen vagy nincs értelme esetleg, file menü -> new project.

Üzemeltetői oldalról mekkora? 10+ évvel ezelőtti info is releváns? Mert akkor nagy lehet. Egy ilyen verzió ugrás nem sima patch, amin átfuttatjuk a szokásos gyors teszteket. És akkor azért komolyabb teszthez kell a leendő felhasználóktól teszt, terhelés teszt, ami apróbb javításoknál ha megy is, nem olyan mértékű, mint egy ilyen váltásnál stb.
És ha valami borul, akkor vissza az elejére.

Te a kódodban hiába nem használtál soha semmit a "tiltott gyümölcsökből", külső libekkel már bőven lehetnek gondok. Átlag enterspájz alkalmazásszerver meg azon lennék meglepődve, ha OOB működne az új, áttúrt Java verzión (az újabb verzióra átállás pedig szintén nem feltétlenül triviális).

És akkor még jól jársz, ha el sem indul a cucc, mert akkor rögtön kiderül a gond. Nem pedig ad-hoc random hibákat kapsz az éles rendszerben, mert 6 láb mélyen valami indiai reflectionös tákolás elszáll, a hibát meg útközben elnyeli egy "absztrakciós réteg" és teljesen más exceptiont dob tovább, hogy lehessen utána hetekig full vakvágányon nyomozni a probléma okát.

A becslésed szerint benne lenne csak a fejlesztés része maga 1-3 sprintben normál esetben, az átállás pedig koránt sem kockázatmentes. Security oldalról annyira azért nem sürgős az átállás, főleg, ha OpenJDK alapon fut a történet. A bekerülő új nyelvi elemek a további fejlesztések esetén lényegi költségcsökkenést nem hoznának. Egy belső, ritkán piszkált n+1. rendszer esetén akkor mégis minek?

Startupoknál lehet ilyen szempontból általában jobban mennek a dolgok, de azért ott sem fenékig tejfel az élet. Illetve jó kérdés, hogy ha nem 1-2 év után, hanem 8-10 évnyi folyamatos fejlesztés után vizsgálnánk egy átlag startupos rendszert, mekkora minőségbeli különbség lenne.

Ezzel óvatosan, mert te is le leszel hülyézve...
Mikor valamelyik, kissé politizálós topic-ban merészeltem felhozni, hogy akármilyen jól összerakott tesztekkel is adódhatnak, komoly, nem várt gondok... khm... :D

Egyébként +nagyon sok, csak nem tudtam így megfogalmazni.

Ez a technical debt egy nagyon menőn hangzó fogalom, én értem is a mögöttes tartalmat, de amíg a szakma nem tudja ezt rendesen "forintosítani" (lásd fizikai eszközöknél az amortizációt), addig nem biztos, hogy az adott xy managert kellene inkompetensezni...

>Csináltam tavaly év végén egy legacy rendszer 1.7 -> 1.8 migrációját egy regionális banknál, tudom milyen móka.
Ha 3-4 éve, amikor a Java 8 kijött álltak volna át, mennyivel lett volna jobb? Azt értem, hogy láttál egy ilyen átállást, ami szívás volt, de magára a technical debtre nem látom hogyan illik a példa.

Az amortizáció sincs rendesen forintosítva (mármint valóban, pontosan, mérhetően, a valóságnak megfelelően), csak egy tudományos rekeszizommal (aka hasracsapás) meghatározott érték, ami jogszabályban van lefektetve.

Hasonló mértékben lehetne a technical debtet is forintosítani: elnagyoltan, általánosítottan, valamely külső szabályzóra bízva magad. A Sonar például ad időbecslést 1-1 code smell kijavítására, a code smell típusától függően.

Tegyük hozzá, hogy az indiai buborékképződés nem különbözik az egyéb buborékoktól, csak nekünk jobban fáj.

Megvolt a bázis, a minta, amelyik tudta azt, amit el kellett végeznie. Híre ment, hogy "még a májkroszoft is indiaiakkal fejleszt/felügyel", senki se akart lemaradni a hajóról... India pedig nem tökölt, szállította nekik a "szakembereket" a cégekhez, amelyek pókerarccal _bármit_ elvállaltak a telefonfelkapkodástól a remote agysebészetig.

Aztán 10-15 éven át a vezetői szintek felső harmada (amelyik egyébként a negyedéveket papíron pozitívan érintő döntéseket meghozta) nem volt hajlandó meghallani a számukra kritikát jelentő hangokat az alsó kétharmad felől, hogy "az India által elvégzendő munkát lappangó vagy ki is fizetett túlórákban ITT végezzük el úgy, hogy még korrigálnunk is kell azt, amit ott elcsesztek".
Ezt a képet tovább homályosította az is, hogy ha munkában vagy szakfórumon laikusok előtt véleményezte az ember az indiai (átlag)teljesítményt, azt a korábbi, a tényleg potens bázisról szóló hírektől megkábultak hajlamosak voltak a szalonrasszizmus számlájára írni.

Tavaly pedig pukkant egyet a lufi, ami még így is termetes.

Ott látom, hogy nincs egyetlen "meglepetésre", vagy "szemben az eddigi tévhittel" vagy bármi hasonló. Úgy sorolja, hogy hány szakmai analfabétát küldtek a piacra annak létszámigényei szerint, mintha a tegnapi időjárást írná.
Miközben tavalyig a média az indiai ájtí csodájára járt: elhitték egymásnak a meséket, a saját háztáji fórumaikon író-olvasó szakmabeliek véleménye pedig nem tükröződött (pedig egyébként toleránsnak tartott országokból származó véleményekkel rezonált) az írásokban, elvégre nehogy már a tapasztalat cáfolja a "köztudomású gazdasági sikert".

Tegyuk meg hozza kiegesziteskent, hogy az atlag management egy akarmilyen nagyobb cegnel erosen bonusz-vezerelt, amely altalaban negyedeves-eves teljesitmenyen alapul (teljesitmeny = tervezett koltseg - jelentett koltseg > 0 => PROFIT!), ebbe siman belefer, hogy egy 5 eves projektben az elso ket evben nem tortenik semmi, a projektvezetes jelenti, hogy minden oke, sot, meg elorebb is van a project a tervnel, minden f*sza. Mire kiderul, hogy sz*r van a palacsintaban, a management elelmesebb resze mar regen egy masik cegnel kezdi az uj projektet. A "lerabolt" eredeti projektnek meg lottek, innentol veszuzemmod, "huje IT" nem ert a szakmajahoz, indiaiak meg meg annyira sem.

Egyebkent ez kis cegnel is mukodik, egy angol etteremlancnal volt egy ismerosom boltvezeto, o pontosan ugyanezt meselte, hogy az elodje minden kiadast visszavagott, az nem erdekelte, hogy kozben a konyhai gepek allapota leromlott, a stabil emberek felmondtak, stb., a felsovezetesnek csak egy szam volt a kiadas/koltseg a papiron, amit erosen csokkentett, igy felmarkolta a bonuszt, es utana lelepett, rahagyva a sz*rkupacot a gagyi kelet-europainak, aki azt hitte, milyen jo allast kapott (pedig kb. minimalberre volt bejelentve, a tobbit jutalom formajaban kapta - volna)...

Igy megy ez.

Ui. a multkor veletlenul figyeltem fel a polcomon porosodo szakirodalomra, amely a "The Dilbert Principle" cimet viseli, ebbol reszletesen tajekozodhatunk a nagyvallalatok mukodesi elveirol es a gyakorlatrol. Minden 18 even felulinek erosen ajanlott.

A reális megoldás az volna, ha egy "menedzsernek" nem lehetne arra utaznia, hogy 2-3-4 évig nyugodtan kierőszakolhat olyan megoldásokat, amelyek időzített bombák, arra alapozva, hogy mire robbannak, már más lesz a pozíciója ill. a helyi szüret után máshol: neki csak a szüret fog jutni a LÁTSZÓLAG faszán lezárt péjétékből.

Reális, de elképzelhetetlen.

Kompatibilisek a publikus API szintjén.
Az, hogy sokan használtak Sun-os, nem a publikus API, hanem az implementáció részét képező osztályokat direktben (pedig erről 25 éve tudjuk, hogy nem szabad), azoknak a kódjai nem fognak futni. Nem tudom sajnálni őket.

létezik valami program arra, hogy java forrásból vagy jarból megállapítsa, hogy csak publikus API-t használ-e az a program, vagy mást is? én nem programozok javaban, csak vannak itt főként jar formátumú programok, amiket ha lehet megnéznék mekkora szopacs lesz/lehet később velük.

"I'd rather be hated for who I am, than loved for who I am not."

Persze.
Forrásból:
Sonar például szól érte, ha nem publikus API-t használsz:
https://rules.sonarsource.com/java/tag/lock-in/RSPEC-1191

Ha JAR-t akarsz nézni:
http://mcs.une.edu.au/doc/jdepend/docs/JDepend.html
Ez scanneli a class file-okat is, és megmondja a csomagfüggőségeket.

köszi, megnézem. nem programozok javaban, nekem az (is) kell, hogy megmondja publikus vagy nem az API amit használ a program. ha nekem kiír egy raklap függőséget az semmit sem mond, hogy rendben van-e vagy sem. lehet tudja ez is, hogy egyértelműen jelzi a publikus és direkt hívásokat, csak jeleztem. :)

"I'd rather be hated for who I am, than loved for who I am not."

Application szerverek hogy állnak?:)

Bocs, kicsit későn ébredtem, segítenétek megtalálni a hivatalos indokát, hogy miért vették ki [majdnem] a jaxb-t az SE-ből? Olyasmiket véltem találni, hogy pl. 'Hát mert a jaxb-t EE-ben is lehet használni', de ezt nem érzem nagyon frappáns érvnek.

Az egyébként igen dicséretes, hogy elkezdtek dolgokat kidobálni a JDK-ból, lásd még CORBA, aminek már akkor sem volt semmi keresnivalója benne, amikor betették kb. 20 éve...
A JDK-nak a lehető legkisebbnek kellene lennie, úgyis az a jó a Java platformban, hogy nagyon könnyen lehet dependencyket hozzáadni a projektedhez.