Oracle wants your money for the commercial use of Java

HUP cikkturkáló

Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license.

via https://java.com/en/download/release_notice.jsp

( uid_7086 | 2018. 04. 21., szo – 15:13 )

Már majdnem elkezdtem Javat tanulni... :D
Őszintén remélem, hogy az összes fejlesztő kedvét elveszik tőle egy életre. :(
(kiemelném az "... or production use" kitételt: ergo az összes open source projekt is mehet a kukába, ha nem akarnak fizetni érte)

Vajon mi a helyzet az olyanokkal, mint pl. az openjdk?
Vagy például a scala, aminek a futtatásához úgy rémlik, JRE kell, plusz a saját cuccai?

Gondolom, az egész arra megy ki, hogy az androidos bevételekből ők is kaszáljanak. Tévednék?

A java 8 addigra 5 éves lesz, aki akar áttér java 9-re, 10-re. Amúgy nem ez a történelemben az első, hogy egy kifutó verzió frissitésére ugy vesznek rá cégeket, hogy fizetni kell a supportért már.
2020 ban mellesleg a personal support is megszűnik. Ha jól emlékszem a Windosoknak is ilyen a supportja, hogy egy idő után az előző verzióknak fizetőssé válik...

Uh szerintem nem kell ezt a dolgot túlreagálni...

Ja, hogy ez csak a régiről szól? Akkor bocs, ezt kivételesen nem szándékosan kapkodtam el/reagáltam túl...

A téma nyitójától nem vagyok hozzászokva a manipulatív hírekhez. Az meg nem jött át, hogy a 8-as voltaképp réginek számít.

Persze még mindig kérdéses, hogy mit is akarnak ezzel oracle-ék így, ilyen formában. Mert valahogy nagyon olyan érzést kelt, mintha az egész java-t be akarnák zárni és fizetőssé tenni

ui: sorry... most, hogy téged olvastalak, a nyitót még mindig háromszor kellet átfutnom, hogy meglássam az SE mögött a 8-at :((((
(leszarom, akkor se megyek szemészetre)

Pardon? Mi az a Np? Bocs, ennyire lassú vagyok mostanában. :(

Végeredményben, ha ez a cél, lehet némi igazságuk, bár sajnos a saját bőrömön tapasztaltam, hogy milyen szopás lehet átállni egyik javaról a másikra, pedig én csak üzemeltettem, a fejlesztő szentségelt igazán. :D

"a fejlesztő szentségelt igazán."

Ez az a nyelv, ami azért került a fókuszba, mert a platformfüggetlenség nyelve. Aztán annyit fejlődött, hogy ugyanaz más platformok között sem és ugyanazon platformon verzióváltás után sem feltétlenül megy gondok nélkül.

Itt a közelmúltig ugyanabból az appból volt egy maces, egy wines, és egy 8-as - most ért össze a 3 (értsd: kódszinten ki lett védve, ahol lyukra futott).
És készül a 9-es...

Azért nem ilyen egyszerű a helyzet: A java 9 és 10 nincs igazán elterjedve (Android 7-esnél jár) és supportja idén megszűnik (március/szeptember) egyedül a Java SE 7 és 8 lesz támogatott ezentúl (2022 és 2024-ig), illetve majd az idén szeptemberre tervezett 11-es verzió, de az még sok kérdést vet fel. (via)

Nem, rosszul értelmezed. Csak a hivatalos Oracle Java kiadásnál lehet szó fizetős kiadásról. Az OpenJDK GPL licenc alatt áll, ami természetesen nem zárja ki fizetős support lehetőségét, de erre sincs monopóliuma az Oracle-nek. Itt tényleg csak az update forceolása a lényeg. Nem kell többet belelátni.
Az Android Dalvik ART jogilag már egyáltalán nem azonos az Oracle Java nevű termékével. Semmilyen kereskedelmi licencet nem követelhet az Oracle utána amolyan SCO módra. Java 7 API verzióval sem 100% kompatibilis. A Google és Oracle között zajló perek semmilyen szinten nem érintik a végfelhasználókat, akár céges felhasználók, akár magánszemélyek.

Normális HUP-ot használok!

A Java nyelv egy specifikáció teljesen leírja, bárki implementálhatja.
A JVM virtuális gépet is leírja egy specifikáció, bárki implementálhatja.
Az egyes Java API-kat specifikálják a JCP-ben, bárki implementálhatja.

Ez maga a Java: egy specifikációhalmaz, aminek vannak implementációi.
Mint ahogy a C nyelv meg a standard library is egy specifikációhalmaz, aminek vannak implementációi.

Az egész most az Oracle Java implementációról szól.
Nem az OpenJDK-ról, nem az IBM J9-ről, nem a többi alternatív Java implementációról.

Erről van valami link? Mert nekem úgy tűnt nem erről.

Egyrészt vigyáztak arra, hogy a Dalvikot (se az ART-ot) ne hívják Java-nak, viszont a Java API-t felhasználták. És a Google úgy gondolta, hogy egy API clean room újraimplementálása fair use, míg most a bíróság azt mondja, hogy nem. Illetve ezzel kapcsolatban próbálkoznak most a legfelső bíróságnál, hogy hátha mégis.

És emiatt OpenJDK-ra építeni már nem gáz, ha megfelelsz a GPLv2+Classpath licencnek, mert az abban levő API-kra értelemszerűen vonatkozik a szoftver licence.

Cleanroom volt az, mert az Apache Harmony-ra épül, az meg cleanroom :)

Ha jól emlékszem anno a Harmonyba elég sok garázscég beszállt, mint pl. az IBM, de aztán megfeneklett a dolog mert a Sun nem volt hajlandó eladni TCK licencet a projektnek. Akkoriban még akadt releváns más kereskedelmi JDK implementáció, akiknek viszont volt TCK licencük.

Viszont hivatalosan én nem láttam olyan írást, hogy azért állították le a Harmony fejlesztését, mert licencgondok lettek volna vele. Lehet, hogy volt ilyen, és már nem emlékszem, vagy a fejlesztőknek a Sun informálisan fejezte ki nemtetszését, és ők meg nem akarták erőltetni.

A Google-t meg most pont a Harmony kód felhasználása miatt perelte be az Oracle.

Jogilag nem egyértelmű az ügy, én is meg tudom indokolni, hogy ez miért nem fair use és miért az Oracle-nek van igaza. Ahogy az ellenkezőjét is. :)

Amit mi fejlesztők ebből az ügyből tanulhatunk, az az, hogy az API licencét is figyelni kell, nem csak az implementációét, és ha olyan API-t kell használnunk, ami proprietary, akkor azt lehetőség szerint válasszuk el a saját kódunktól minél jobban.

Ez egyébként is best practice (vagy annak kéne lennie), gondoljunk csak arra, hogy a kódunkat jó lenne több platformon használni, akkor a proprietary platformfüggő API-kat mindenképpen jó minta, ha kiszervezzük külön modulba.

Egyfelől dicséretes, hogy a Java9 fiaskó után (több éves csúszás) próbálnak javítani a folyamaton, és time based release-re váltanak.
Viszont sikerült a lehető legrosszabb megoldást megtalálni, és lesz egy csomó nem LTS változat, meg pár évente kijelölnek egy LTS-t. Na ezzel megint ugyanott vagyunk, hogy van JDK10, de senki sem használja az OpenJDK fejlesztőkön kívül...

Az Android 7.0 óta OpenJDK 8 forkot használ. Ez jelenleg a platform felhasználóinak kb. 35%-a. A többiek a kb. Java 7-nek megfelelő Apache Harmony forkot.
Sokszor látom azt, hogy megbízók azt mondják, hogy "fusson az összes létező Androidon" - ez lényegében 4.4 (API level 19) minimum támogatást jelent. Ennek szerintem nem minden esetben van értelme üzletileg, hiszen kérdés, hogy a sok éves telefont használó emberek hány %-a tartozik a célcsoportjába az appnak.

Ui: nem ellentmondani akartam a hozzászólásodnak, inkább alátámasztani. A Java platform szempontjából egyáltalán nem mindegy, hogy az Androidon mi fut.

A történet ott meg arról szólt, hogy az API az másolható, vagy sem. Eddig az volt a szabály, hogy az API-t
bármikor lehet másolni (ez minden API-ra vonatkozik) de most egy bírósági határozat szerint nem. Ami elég
kellemetlen, mondjuk pl. a Wine tekintetében, ezért is az USA legfelsőbb bírósága elé viszik az ügyet.

Előbb vagy utóbb, a saját újtát járva, mindenki eljut odáig, hogy belátja: Minél nagyobbra nő egy IT vállalat, annál kevésbé képes és hajlandó valós innovációk és hosszú távon fenntartható fejlesztések mentén kialakítani a termékpalettáját.

Helyette egyre inkább előtérbe kerül az újra és újra kifizettetése az újra feltalált keréknek, a régi termékek legacy-nak kikiáltása és frissítgettetése az ügyfélközönséggel. Ha ez nem megy észérvek mentén (mert általában nem megy, hiszen minek javíts meg valamit, ha nem romlott el?!), illetve nem megy az új verzióhoz köthető látszatinnovációkkal és félszakmai idealizmusokkal (pl. az új verzsönben van ilyen-olyan beépített funkció, ami jobban kinyalja a segged, így még nagyobbra nőhet az e-péniszed a főnököd/projektvezetőd előtt), akkor megy majd félelemkeltéssel (nincsenekfrissítéseknemvagybiztonságban, JUJJ!), pszichológiai hadviseléssel (nemfrissítesznemvagymenő, JUJJ!) és arroganciával (fizess kétszer annyit, hogy támogassuk neked a régi, jól beváltat). Mindezért, nagy vonalakban kimondhatjuk, hogy az IT nagyvállalatok növekedése és profitéhsége a valódi innoviációk ellensége. A termékportfóliók technológiai értéke pedig egyre inkább csak marketingérték lesz (értsd: üres, felfújt, értéktelen lufi).

Szóval, lehet itt engem, meg néhány szkeptikusan gondolkodót lehülyézni és pszichiáterhez zavarni, igazán akkor kapsz majd észbe, merre tart a mi kis informatikánk, amikor a saját bőrödön érzed, hogy kihúzzák alólad a talajt, ha nem minden tekintetben állsz éppen az ominózus nagyvállalat érdekében. Mint például most.

Ha van pár forintnyi, nem a párnacihában elhelyezett megtakarításod, jó eséllyel a "nagyvállalatok" részben te magad vagy: egyszerre rabszolga és rabszolgatartó; egyszerre imperialista és proletár.

Nem annyira egyszerű, nem olyan könnyen kommunikálható és a legkevésvbé sem olyan népszerű gondolat, mint ahogyan komonistázni vagy globalistázni lehet egy hegyeset, de jobban közelíti a tyúkszarosunk viszonyait.

Nem kell kommunistázni, sem globalistázni.

Azt kell csak látni, hogy ha egy nagyvállalat (vagy egy mögötte álló tőzsdecápa befektető) +1% haszonért cserébe (miközben van neki 6%-os növekedése) képes egy legacy eldobós üzleti döntést meghozni, miközben ezzel kollektíve sokkal nagyobb veszteséget és szopórollert hoz az ügyfélközönségre, akkor ő egy öncélú, arrogáns döntést hozott meg, szembeköpve azokat, akik bíztak benne és odaadták nekik a pénzüket korábbi termékért cserébe, meg esetlegesen azokat az az értékeket, melyek alapján korábban őt választották. Ez a viselkedés üzletileg etikátlan, függetlenül attól, hogy nekem vagy bármely proletárnak mi van a párnacihájában. Lehet, hogy még így is megéri nekik, de ettől még etikátlan. Vannak ilyen szituációk, csak fősodratúék nem igazán hajlandóak meglátni, mivel a pénz és a profit az Isten, az szent. Ha valaki X pénzből nem akar minden áron, minden eszközzel 2X-et csinálni, csak 1,5X-et, az már életképtelen lúzer, vagy szentségtörő.

Mondjuk ha valaki 2018-ban azt hitte, hogy egy szoftverre tovább kap supportot, mint amit a termék megvásárlásakor a szerződésben rögzítettek, akkor a fizetős support felajánlása nem átverés, hanem egy extra szolgáltatás, vagy legrosszabb esetben hülyeségi adó.
(Nem azt mondom, hogy szentségtörő, aki tovább támogat egy terméket, mint amit vállalt, de nem értem, milyen alapon várod el. Ugyanennyire elvárhatnám tőled is, hogy fogd az opensource változatot, implementáld bele a különbségeket, és támogassad. Őt sem kötelezi a szerződés, téged sem. Sőt, te legalább hiszel benne, hogy valakinek csinálnia kellene.)

Ezt megjegyzem, jó érv lesz lejárt garanciák érvényesítésekor.

(Egyébként az LG tévém 3 héttel a garancia lejárta után dobta fel a talpát. Jött a szaki, elvitte, mért, felhívott, mondta, hogy pechem van: a táp feküdt ki, de csak azután, hogy minden panelt megpirított, gyakorlatilag van egy műanyag keretem, amit meg kell tölteni tévéalkatrészekkel, kicsit drágább lesz, mintha a keretet is kidobom, és veszek egy úgy tévét... de ha nem bánom, előbb ír egy levélkét a gyárnak azzal, hogy legyenek jófejek és tekintsenek el a két évet meghaladó 3 héttől.
Úgy tettek.

Az emberarcú szocializmus gelkájánál a garanciaidő alatt is meg kellett volna kenni a munkafelvevőt, hogy ne hajtson el tévéstül.)

(A történelmi ismereteid elég hiányosak lehetnek, ha azt hiszed, hogy most van a vadkapitalizmus fénykora (esetleg az ipari forradalomnak olvass utána, vagy a 1900-as, 1910-es évek Amerikájának, ha jó szépirodalmi korleírást akarsz, akkor Sinclair: A tragacskirálya sem rossz.)

Továbbra sem értelek: veszel egy terméket, megmondják, mit kapsz. Nem mondom, hogy nem lenne rendicsek dolog adni hozzá ajándékot, de nem kötelező, és nem is feltétlen etikátlan nem adni. Te akarsz kapni ajándékba még 150 év supportot? Vagy 15 elég?

Lehet, hogy a te világképedben az már önmagában bűn, ha valakinek befektetésen haszna van, de ezt elég sokan nem osztják, és a világot sem viszi előre (vö: van két zsömlém, melyik a jobb rendszer: amikor megegyezhetek veled, hogy az egyiket neked adom, de akkor holnap másfelet kérek vissza, vagy az, amelyikben választhatok, hogy neked adom ajándékba, vagy elteszem, és ha holnap már nem finom, akkor kidobom?). Itt tudtad, hogy meddig lesz support, még időd is lett volna portolni a cuccaidat, meg nem is lett volna muszáj használni eleve (ha eleve mindent fortranban írtál volna, az ma is backwards compatible, hozzá sem kellene nyúlni, csak több meló).

( kisg v | 2018. 04. 21., szo – 15:12 )

OpenJDK-t forkolni nem kell félnetek jó lesz

( Hevi v | 2018. 04. 21., szo – 15:21 )

Par hete mikor eszrevettem, hogy az archiv letoltesekhez regisztralni kell, kulonben nem engedi letolteni, felig viccesen megjegyeztem, hogy ideje atallni .Net-re.

A vegen meg kiderul, hogy nem csak felig volt vicc...

( b | 2018. 04. 21., szo – 16:04 )

hát akkor ennyi volt a java.

--
GPLv3-as hozzászólás.

( uid_395 v | 2018. 04. 21., szo – 17:32 )

ez jót fog ez tenni a CStinfo / ETDR / KIRA rendszereknek remélem :) Hogy végre nem kell a -Dsunjava.compatible.*.lofasz.1.5* -ot beírni envként :)

( NevemTeve | 2018. 04. 21., szo – 18:19 )

Hát, aki ezt nem érti úgy, hogy 'süllyedő hajót elhagyni', azt nem is tekintem paranoiásnak...

Már csak az a kérdés, hogy mit is tekintsünk süllyedő hajónak: csak az Oracle-s Java8-at, vagy az összes Oracle-s Java-féleséget, vagy az összes Java-féleséget?

(Szerk: Bár a Google esete Tóth Marival azért elég világos útmutatás.)

A Google ügy alapvetően a Harmony alapú implementáció miatt született, ezért is álltak át OpenJDK-ra Android 7-től.

Én azt remélem, hogy OpenOffice -> LibreOffice mintára lesz egy LibreJDK fork, ami végre új egységet hozhat a platformba (pl. az Android is ezt használhatja).

Gyerekek, itt baromi nagy képzavar van. Az OpenJDK az GPL-es kód, plusz classpath exception.

Ezt tessék végigolvasni:

https://softwareengineering.stackexchange.com/questions/119436/what-doe…

Tehát nem lesz tőle a kódod GPL-es, azért, mert összelinkeled, tehát nyugodtan lehet használni, mi is átálltunk.

Viszont az OpenJDK-ra nincs céges support. Ha hiba van, ha security probléma van, akkor meg kell várni, amíg valaki
kijavítja (vagy nem).

A másik, hogy az Oracle JRE-nél ha jól tudom, van ilyen msi installeres cucc, amivel sok száz-ezer gépre könnyen fel
tudod rakni, ezért az üzemeltetők most harapófogóba kerülnek. Az egyik oldalról kell nekik az Oracle JRE, mert ugye azzal
tudják ezt megtenni, a másik oldalról meg a gépeken futó java-s alkalmazásokat vagy mindig updatelik, hogy menjen legújabb
jre-vel is (igazából kellene), vagy ha akarnak security update-et, de nem akarják a legújabb verziókat használni, akkor kénytelenek
lesznek fizetni érte.

Az üzemeltetők (értsd: semmirekellő, lusta, papucsos, pizzazabáló rendszergazdák) jobban teszik, ha felkötik a (kecsappal lezabált) gagyátjukat és összescriptelik az installt, mintsem megint egy szoftveres, ultrahiper, innovatív szolúsöntől várják majd a seggük fényesre nyalását. Nem olyan nehéz feladat szerintem. Persze, napjaink out-of-the-box megoldásainak káoszában könnyű ezzel ellentétes véleményt formálni.

Azt meg ne felejtsd el, amit Frankó Mérnök Úr lejjebb már megjegyzett, hogy az openjdk az enterprise linux-okban támogatott marad. Ahogy pl. a szélsőségesen idealista, Firefox fejlesztők átálltak a csiligány, instabil, ocsmány és bloated GTK3-ra, illetve a kvantum szarjukra, a RedHat átvette a firefox-esr támogatását RHEL 6 alatt. Mai napig kap patch-eket és maradt GTK2. Ahogy történt ez a 2.6.32-es kernellel és fog történni az openjdk-val is.

Aki lusta megírni egy install scriptet, ami lefut jól 1000-100000 gépen, azt nem tudom másként jellemezni, csak a zárójeles résszel. Akkor sem, ha ez HZ Mérnök Úrnak nem tetszik, frusztrációját pedig seggfejezésben és anyázásban éli ki. Bár nem ma volt, de volt szerencsém IT részlegen lehúzni 2 évet. A Pokoli Operátor Sztahanov lehetne azokhoz képest, amiket ott leműveltek egyesek. És pont ehhez hasonló kifogásokkal jöttek, hogy "nincs hozzá automatikus ezmegaz".

Persze lehet RHEL 7.X is... csak az meg bűnösen innovatíve systemd-only.

Lentebb már írtam.

Persze, a systemd-t és a pulseaudio-t ettől még nem bocsájtom meg nekik, de azzal főként csak RedHat-on kívül volt probléma és utóbbi sokkal inkább köszönhető a corporate-idealista projektvezetőknek más Linux-oknál (Ubuntu, Debian stb.), mintsem személy szerint Poettering-nek.

Nem az a baj, hogy a RHEL 7 systemd-only. Az a baj, hogy minden más mainstream Linux systemd-only, holott nem kéne annak lennie. Ja és, az a baj (de ez nem a Red Hat baja nyilván), hogy miután lejár a Debain Wheezy támogatása (jövő hónap végén), ironikusan a RHEL 6, illetve rajta keresztül a CentOS 6 lesz az egyetlen, szabadon elérhető, még hivatalosan támogatott, mainstream systemd nélküli disztró. Utóbbi, amellett, hogy a Red Hat érdeme, a rajtuk kívüli Linux világ szégyene.

Jó is az a RHEL 6.X... kivéve, ha SAMBA share-re kell rálátni.

yum install samba4-client

Persze, gondolom neked is az OS-frissítés az első, ami eszedbe jut, ha nem tudsz magasabbra erőltetett SMB szabványú kiszolgálóra csatlakozni.

Hogy te mit gondolsz, azzal inkább nem számolnék, de annyit elárulok, hogy az új szerelmed a cifs-utilst (FIXME... please, please FIXME, anybody!) nem gyártotta le 4-es sambához, ezért az a 3-ast követeli vissza a függőségi fájában, amint feltennéd a 4-es feltelepítése után, amit úgy tudsz megtenni, hogy leszedted a 3-ast, a cifs-utilsszal együtt.

"cifs-utils package can not be installed when samba4* packages are installed as it requires samba* version 3 packages as dependencies."

Szóval egyrészt igazad van, lehet játszani smbclienttel, másrészt a cifs mount felejtős.
Ez otthon, onánia közben nem probléma, legfeljebb kezet váltasz, de...

Hogy te mit gondolsz, azzal inkább nem számolnék

http://a.te.ervelesi.hibad.hu/szemelyeskedes

az új szerelmed

Nincs új szerelmem. Hűséges társam még mindig a régóta szeretett Windows XP.

Aki nem az OS-től várja a megváltást és a minden azonnal működjön idealizmusát, az elfogadja, hogy minden OS-nek vannak limitációi. Nem kivétel ezalól a RHEL 6 sem. Ez természetesen nem azt jelenti, hogy az adott operációs rendszer alkalmatlan lenne valamire, vagy szimplán rosszabb egy másiknál, bármennyire is igyekszel ezt éreztetni.

A cifs-ből valóban nem készült külön olyan verzió, ami samba4-libekre dependálna. A jó hír viszont az, hogy amire a korábbi samba csomagokból dependál libwbclient.so.0, azt ugyanúgy szállítja a samba4-libs. Tehát, az alábbi módon megoldható, hogy tudj mount-olni SMB share-t RHEL 6 alól.

  1. Felteszed a dependenciáit, leszámítva a samba-winbind-clients-t, ami ugye Samba 3.
    
yum install keyutils libcap-ng krb5-libs libtalloc samba4-libs samba4-common
  2. Beszerzed a cifs-utils RPM-jét Red Hat Customer Portal-ról, vagy ha CentOS, akkor valamelyik mirror-ról (alábbi példában a wget az utóbbi esetre vonatkozik), aztán felteszed kézzel a cifs-utils-t, a dependenciák ignorálásával.
    
wget http://mirror.met.hu/centos/6.9/os/x86_64/Packages/cifs-utils-4.8.1-20.el6.x86_64.rpm
rpm -i --nodeps cifs-utils-4.8.1-20.el6.x86_64.rpm
  3. Kipróbálod.
    
mkdir /mnt/test
mount -t cifs -o vers=2.1 '//upgrade.idealizmus.lx/share' /mnt/test
mount -t cifs -o vers=3.0 '//upgrade.idealizmus.lx/share' /mnt/test

_Saját_ gépemen nagyon-nagyon-nagyon sok ilyet játszottam, amikor újratelepítés nélkül vándorolgattam folyamatosan RH 7.3-ból Fedora tizenegykettőig, amikor elhagytam.
RHEL szerveren NEM cigánykodunk, mert az ügyfeleit hosszútávon is komolyan vevő RH az első "not the recommended method" momentumnál pont úgy elhajt a fenébe problémás esetben, mint ahogy a M$ vagy egyéb rutinos szoftveriparos tenné.
Arra képes, hogy a hw-re hivatkozzon, mígnem hónapos levelezés után kiderül (nem ők árulják el: te találod meg), hogy a problémát olyan ismert bugjuk okozza, amelynek ticketjét handabandázással zárták le, de amúgy ismerik a hibát.

Az Oracle JavaXY nem fizetős. A fizetős support fizetős.
Mivel már a Java 10 (11-re átnevezve) a GA, a Java 8-hoz (mivel EOL) csak fizetős support keretében kapsz fixeket.

ÉS!

Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license.

2019 január még egy év.
Egy év átállni Java 9/10/11/18.9-re.
Binárisan is kompatibilis.
Mi kell még?

Tudom, megint ősi dolgokra hivatkozom, de egy év, ha közben még aktív fejlesztés is megy, kurva kevés egy ilyen jellegű verzióváltáshoz - már ha jól értem és azért ez nem csak annyi, hogy felrakok egy java11-et és minden megy tovább.
A 9/10-nek már az említése is érdekes itten...
http://www.oracle.com/technetwork/java/eol-135779.html
Keress rá az "Oracle Java SE Support Roadmap" szövegre!
Ott láthatod, hogy a 9-es és a 10-es supportja még idén lejár.

A 11-est még nem néztem meg, különösen, hogy már a 8-ast sem ismerem, de ismerve az oracle korábbi ténykedését, gyanítom, ez is sok dolgot megváltoztat, ráadásul még sehol sincs. Na egy ilyenre átállni már nem is egy év, csak kilenc hónap alatt... Én nem vállalnám be.

sokkal kisebb szopás lesz.

Egyrészt eddig ~3 évente volt _nagy_ release, néhány undocumented (s így ne is építs rá, de mégis építenek rá) dolog változással [1]. A 9 behozott egy teljesen új koncepciót, ami ezeket az undocumented feature-ket nagyrészt lezárja. S mostantól nem 3 évente nagy, hanem 6 havonta kisebb release-k vannak. Így egyrészt talán nem lesz annyi undocumented breaking change, másrészt ami lesz-is, kisebb adagban jön.

tl;dr: a modulrendszer volt nagyonnagy törés, innentől nem lesz ekkora szopás.

[1]: pl. ilyen volt
- a 

sun.*

csomagok használata, ami miatt a Sun 20 éve küzdött, hogyplsne, de néhány szoftver (pl.: AbevJava) mégiscsak
- vagy ilyenek, hogy a HashMap iterátora által visszaadott elemek sorrendjére ne támaszkodj, egyeseknek mégis sikerült
- etc.

Igen, ad.
Van egy JAR-od, mondjuk com.foo.
Ebben van ket csomagod, mert el akarod szeparalni a kodokat:
com.foo.domain1 es com.foo.domain2
A domain1 es domain2 csomagokban levo osztalyok implementacio (ami ugye reszletkerdes, nem az API resze az implementacio mikentje) is hasznalnak olyan osztalyt, amely kozos (pl. utility classok, belso osztalyok).

Ezt csak ugy tudjak megtenni, ha az a kozos osztaly public eleressel rendelkezik (es nem package private).

Viszont a fejleszto azt szeretne, hogy ez az osztaly ne legyen elerheto kivulrol (implementation detail, nem az API resze, amelyet tobb csomag is hasznal).

Na, ezt eddig nem tudta megtenni, erre 25 evvel ezelott a Java tervezoi nem gondoltak.
Mostantol kezdve viszont meg lehet tenni, berakod egy com.foo.common vagy com.foo.util csomagba, amelyet nem exportalsz a JAR-bol.

plusz, ha akarom, akkor én kézzel lemésolom a lib 

com.foo.VeryFeatureSuchImplementation

osztályát, előre rakom a classpathen az általam írtat, s innentől beleturkálok abba, ami _implementation detail_.

Így született a jelenlegi, 

Unsafe

es, meg egyéb techdebtek is. Mindenki tudta/tudja, hogy nem kéne, de mégiscsak elő-elő fordul.

na, mostantól ilyen sincs.

LibreJDK nehezen, a Java nevet nem fogja elengedni az Oracle. De lehet belőle OpenJakarta :D

Egyébként nekem tetszik az új irány (time based release; új nyelv és vm funkciók; etc) - most sokkal kevésbé örülnék egy Java-forknak, mint 2 éve örültem volna neki.

szerk.: a TCK is GPLv2?

( vilmos.nagy | 2018. 04. 21., szo – 20:07 )

Valahol érthető, az Oracle pénzt akar fejni ebből a tehénből is. Az EE-elengedése után kell valamiből a pénz.

Egyébként a következő Java verziókra is csak fél évig ad az Oracle supportot ingyé: https://medium.com/codefx-weekly/no-free-java-lts-version-b850192745fb

A jó hír, hogy az AdoptOpenJDK projekt feléledt a tetszhalálból, s már buildel mindent. Gondolom, a RedHatnek nem kevés érdeke van benne, hogy legyen egy ellenpont az Oracle-lel szemben.

További jó hír, hogy elég komolynak látszik az ígéret, hogy az Oracle JVM egy brandelt OpenJVM lesz a jövőben, s minden olyat, ami eddig az egyikben volt / a másikban nem, egységesítenek. Ez egy rahedli érdekes dolog kinyitásával, s az JFX elengedésével sztem mind pozitív.

Kezdem úgy látni, hogy a RedHat az egyetlen IT nagyvállalat, amelyik hosszú távon is komolyan veszi az ügyfeleit és az általa karbantartott platformokat, mintsem csak újabb összegek lehúzására igyekszik beállítani az üzleti stratégiát, üzleti arroganciával kialakított kényszerhelyzetek mentén pörgetve a profitgépezetét (ahogy egyébként a többiek művelik). Persze, a systemd-t és a pulseaudio-t ettől még nem bocsájtom meg nekik, de azzal főként csak RedHat-on kívül volt probléma és utóbbi sokkal inkább köszönhető a corporate-idealista projektvezetőknek más Linux-oknál (Ubuntu, Debian stb.), mintsem személy szerint Poettering-nek.

Egyébként igen, csak hiányoztak már az egységsugarú, ne beszélj róla, ha nem vagy az expertje kategóriájú hozzászólásokat. Mert ha használom is, akkor is, majd lesz nálam fősodratúbb, elitistább hupu, aki megmagyarázza, hogy ő "jobban használja", ezért neki van igaza.

Nem kell szeretni, sem nem szeretni. Problémákat kell megoldani.

Mert megtehetem és mert attól még, hogy mérnök uraságod bármiben is tapasztaltabb, nem ér többet a véleménye. Egyébként a mai napig használok RHEL 6-ot és CentOS 6-ot is, csak hiányzotak már az ilyen primitív beszólásaid, illetve az, hogy ezt ismét ráapplikálhassam egy szélsőségesen elitista, egységsugarú kirohanásodra: http://a.te.ervelesi.hibad.hu/nem-igazi-skot :P

Jól sejtem a frusztrációd mögött, neked van sok negatív tapasztalatod az üzleti filozófiájukkal kapcsolatban. Az elitista hitetltelenítési kísérleteid helyett inkább mesélj arról, mert érdekel.

"Mert megtehetem és mert attól még, hogy mérnök uraságod bármiben is tapasztaltabb, nem ér többet a véleménye."

Nem a véleményem ér többet, hanem az tapasztalatom.

"Egyébként a mai napig használok RHEL 6-ot és CentOS 6-ot is, csak hiányzotak már az ilyen primitív beszólásaid"

Oké, és mennyit is fizetsz a support miatt évente? Úgy nagyságrendileg 1000 dollárra kerekítve.

Sejtettem, hogy kiveri a biztosítékot. :) Igen, mert ha én azt mondom, hogy megkárosítottak 400 millió embert a frissítés kivezetésével, az attól nem lesz igaz, hogy nekem lopott az XP-m (fősodratú, szélsőségesen corporate-idealista gondolatmenet).

A vallásomról meg annyit, hogy ahogy Jézus nevében is öltek már a keresztesek, kivételek nálam is vannak. A Windows XP-t, a Total Commander-t és a Microsoft Office 2003-at megvettem, bár már elég régen volt, ha ma kéne megvennem, lehet, hogy nem tenném. Olyan rendszert meg minek vegyek meg, aminek van ingyenesen újracsomagolt alternatívája (CentOS)?

Egy biztos, ha esetleg véletlenül átállok Windows 7-re, vagy Windows 10-re, azért biztosan nem fogok fizetni. Ami most van itthon kísérletezgetésre, azokért se fizettem. Majd hülye leszek újra feltalált kerékért fizetni, mikor az XP is tud mindent, ami kell.

Értem, hogy szereted játszani itt az önjelölt lock-moderátort, de mi lenne, ha nem percenként tenyerelnél az F5-ön, és elfogadnád, hogy én vagyok annyira igényes, hogy többször, újból átgondolom, mit írok le és javítom, ha valami nem megfelelően korrelál eredeti gondolataimmal.

Azért eléggé kételkednék, hogyha az EE-s történet végén nem csappanna meg az Oracle bevétele abból a sztoriból (WebLogic, oktatások, vizsgák). Azon is meglepődnék, ha az EE nem olyan irányban fejlődött volna eddig, ami az Oracle-nek jó, vagy általa könnyen lefejleszthető. (Mondjuk a WebLogicba egyszerűen bele lehet rakni, esetleg már benne is van, de a többi EE-konténer fejlesztő szopni fog vele). Ez a befolyás elveszett az EE elengedésével.

Ha jól sejtem, azt senki nem cáfolta az Oracle-től eddig, hogy mostantól minden Java release 6 hónap free supporttal jön. Van az LTS, de az Oracle csak 6 hónapig buildeli. Ez már korábban is felmerült - így nem meglepő az OP-ban linkelt cikk -, s egy teljesen logikus döntés szerintem. Ez független a Java8-tól, a Java11-re is csak 6 hónap public support lesz, hiába LTS, hiába nem.

Meglepődnék, ha nem bevételnövelési céllal csinálnák (az Amazon mondjuk fizessen érte, vagy buildelje magának; számomra meg vonzóbb legyen az Oracle cloud)

Egyébként nekem szimpatikus az új irány, a gyors tempó, etc. Ha egyszer sikerült megugorni a Java9-et (nálunk még nem, a SpringBoot ~télen adta ki a 2.0-t, s egyéb frameworkök nem futnak még 9en, sajnos), onnantól szerintem nem lesz nagy szopás a féléves verzió ugrás. Az egyes cégek meg igenis járuljanak hozzá a JDK fejlesztéshez, szerintem ezzel nincs gond.

Ami kicsit zavar, az az EE körüli történet, hogy a specifikáció a tiétek, de a JavaEE nevet (s a javax package-t) felejtsétek el. De sosem szerettem az EE-t, így annyira nem hat meg.

Már miért csappana meg? Aki eddig weblogicozott, és nem tomcat+spring, azt most se fog áttérni, csak mert jobban opensauce lett a java ee.

Az oracle cloud tipikusan enterspájznak van, láttad az árakat? :D

Java 10 óta nincsenek olyan új fícsörök, mint pl a java8-ban a streams api vagy a lambdák. Max a .net-féle "var" a lokális változókhoz.
A 11 vezeti be a új, rendesen használható http klienst, ami http2-it is tud. Kb ennyi.

Fél év max. támogatás mellett?? Mifelénk az ilyesmit zsarolásnak hívják...
Amiket eddig olvastam e témában, azok alapján nagyon remélem, hogy ebbe beledöglik az oracle.
Kísértetiesen emlékeztet az egész a manyup vagyon "megóvására", mikoris közölték, hogy vagy önként adod amid volr vagy úgyis tönkretesszük a pénztárakat, ahol a megtakarításod van. (Kéretik a politikai szálat hanyagolni, csak demonstrálni próbáltam, hogy ezt is ugyanolyan bűncselekménynek tartom: zsarolás+erőfölénnyel való visszaélés)

Nem friss, de korábban még hihetőnek tűnt az openjdk verzió, viszont az én értelmezésemben valahogy úgy tűnik, hogy LTS verzió nem lesz, csak azoknak akik az oracle, fosztogatással felérő árait képesek lesznek megfizetni.
Az ígéreteket egyelőre hanyagolnám, LTS openjdk vagy lesz vagy nem, szerintem inkább az utóbbi, hiszen ha ilyen egyszerűen meg lehet kerülni, akkor az oracle-nek mi érdeke fűződne mindehhez?

Ha azt mondom,
Oracle JDK = Red Hat Enterprise Linux
És
OpenJDK = CEntOS
, úgy már tisztább a dolog?

Miért éri meg valakinek RHEL licencet venni, amikor ott a CEntOS build egy picit később, ami lényegében ugyanaz? Persze a RH-t senki nem anyázza. Míg az Oracle-t mindenki.

Egyrészt, mióta binárisan is azonos a kettő, azóta én sem értem, miért éri meg a RHEL használata, feltéve, hogy a javítások is ugyanúgy jönnek CentOS-ra is. (Jönnek?)

Másrészt nekem eddig az jött le, hogy az openjdk esetében nem lesz (talán nem is volt?) hosszabban támogatott verzió, arra meg nem lehet alapozni már egy közepes méretű cégnél sem, hogy félévente új jdk/jre bevezetése. Egy komolyabb rendszer alapos tesztelése nem két napos munka akkor sem, ha nem kell az új miatt átírni a szoftvert. És elég sok rendszer készült javaban.

Ui: és linuxra van alternatíva, ha a RHEL valamiért nem felel meg, javara... hát nem annyira.

"feltéve, hogy a javítások is ugyanúgy jönnek CentOS-ra is. (Jönnek?)"
Jönnek, késéssel. Pont ez a lényeg. Fizetsz az azonnali, folyamatos upstream supportért, vagy vársz arra, hogy a community elvégezze azt a dolgát, amit megígért, hogy elvégzi. Ami persze továbbra is csak egy ígéret marad, míg a RHEL-nél szerződésed van, SLA-val, a RH által vállal határidőkkel. Amiért fizetsz is rendesen. Na, ez a különbség az OpenJDK és az Oracle JDK között is. Fizetsz a határidős javításokért, támogatásért, vagy megvárod, míg a közösség elvégzi azt a dolgot, amit megígért. Amit vagy betart, vagy nem, nincs jogi utad kikényszeríteni őket. Míg az SLA-s szerződések be nem tartását megtámadhatod bíróságon is akár.
Pont erről szól az OpenJDK és az Oracle JDK is.

"javara... hát nem annyira."
Bármikor forkolhatod az OpenJDK-t, van jó pár alternatív JVM is (IBM J9, vagyis ennek a nyílt változata, az Eclipse OpenJ9, illetve hát: https://en.wikipedia.org/wiki/List_of_Java_virtual_machines )

Hány java fork létezik, ami 1:1-ben helyettesíteni tudja az oracle/sun változatát?
Jó, rég volt, de pl. volt rá példa, hogy a sun jre alatt futott valami, ibm jre meg gyors volt, de rendre összefosta magát az adott szoftver.
Szóval ez az egész egy jókora disznóság az oracle részéről ennyi év után.

A orákel. Ebből _is_ él(ne, ha lenne olyan barom, aki kifizetné ezt).
Ez nyomásgyakorlás leginkább. A sok béna cég a pénzből ért: Eddig a maradás volt az olcsóbb (0$ nemdolgozni rajta); mostmár, hogy nem lesznek patchek, jobban meg fogja érni frissítgetni a jvm-et, még ha nem is írod újra/refaktorálsz, hogy az új fícsöröket kihasználd, minthogy $5k/core-t fizess.

Vagy ott az openjdk :D