Itt a Java 19!

Java

Kiadási megjegyzések itt, letöltés itt.

( joco01 v | 2022. 09. 20., k – 21:19 )

A virtual threads jó cucc lehet, de az én szívem már ellopta a Kotlin.

( Raynes | 2022. 09. 20., k – 21:41 )

Hogy szalad az idő, már a 19-esnél tartanak. Évek óta nem követem, Java-t is alig használok. Böngészőkbe régóta nem kell már pluginként, eleve vonatkozó weboldalakon (régen ilyen chess.com, chess.ru, chessgames.com-on használtam) is kiváltották JS-tel, desktopon Electron-appokkal, és offline desktopos felhasználásra is kb. szökőévenként használtam ehhez-ahhoz az utóbbi 10+ évben. Néhányszor Arena Chess GUI-hoz, meg PDFSam-hez, de már ezeket se használom, mióta ezeket nálam váltotta a scid és a pdftk (bár ez függőségnek behúzza a Javát), pdftricks. Magyar vonatkozásban is már csak ÁNYK-AbevJava az egyetlen gyakori felhasználási terület, az is csak azért, mert évek óta töketlenek átírni valami normálisabb webes változatra, ami nekik is könnyebb lenne.

Ebben az évben is eddig kellett egyszer, egy androidos alkalmazásból kellett egy kódrészlet, hogy linuxos parancssoros programozási projektben felhasználjak, egy SQLite adatbázis kezeléséhez. Ehhez először Android Studio-t próbáltam, ami nem vált be, majd végül jd-gui-val csináltam, annak is kellett a Java. Már annyira elavult cucc, hogy tiling WM-eknél általánosan kell a _JAVA_AWT_WM_NONREPARENTING környezeti változót definiálni 1-es értéken, különben üres ablakok lesznek a Java-alkalmazások helyén. Így kb. abeves és androidos szutykokat leszámítva semmihez nem kell, minden másra van valami értelmesebb alternatíva. Ilyen hülyeségek miatt viszont nagyon makacsul tartja magát, pedig rég ki kellett volna már halnia, ahogy az Adobe Flash-nek, MS Silverlightnak, és a többi hasonló baromságnak.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ez van. Bár még esélyesen lehet pár milliárd kósza user, aki épp ilyen buborékban él. Azzal is tisztában vagyok, hogy vannak cégek, szervezet, meg főleg bankok, akik használják belsőleg, de az engem hol érdekeljen? Ez nem a Java fontosságára és minőségére érv, hanem arra példa, hogy sokan elavult megoldásokhoz a végtelenségig ragaszkodnak, mert lusták, fukarak, stb. újraírni, modernizálni. Lásd 60 éves cobolos mainframe kódok még sok amcsi szervezetnél, cégnél, agyrém kategória. Csak arra jó példa, hogy aki gányolni akar, az gányolni fog, akármiben is, és foggal-körömmel ragaszkodni fog hozzá, max csak a hullájának a kezéből fogod kifeszegetni, de akkor is csak úgy, ha megvárod, míg elmúlik a hullamerevség.

Egyébként rosszul emlékeztem, nem a Chess Arena-nak kellett a Java, hanem a Jose nevű sakk GUI-nak. Nem hiába, olyan régen használtam ezeket is, hogy már azt is elfelejtem, hogy melyik-melyik, hogy hívták, stb.. Ezek a grafikus sakk-keretprogramok pl. egy problémás műfaj, mert van sok jó, de az mind Windows only (jól futnak ugyan Wine-ban, de azzal szenvedjen, akinek hét anyja van), ami kevés meg nem, az nem ér fel minőségileg, vagy csak ilyen félpatkolás, hogy Java, meg nem tudom milyen szutykok kellenek hozzá. A sakkozás sajnos mindig is ilyen szűk réteg hobbija volt, és emiatt ebben túlélnek ezek a proprietary, Windows only megoldások. Úgy értve, hogy ma már a legtöbb sakkmotor azért a nyílt UCI protokollt használja, meg sok ilyen motor eleve FOSS, pont a legerősebbek (Stockfish, Lc0, RubiChess, stb.), de a grafikus keretprogramoknál, megnyitáskönyveknél, stb. még tartják nagyon erősen magukat a fizetős, zárt forráskódos barmolások, kicsit megrekedtek a 90-es és kora 2000-es években.

Most legutóbb az androidos projekthez is csak azért kellett Java, mert a Google ragaszkodik ehhez a szutyokhoz Androidon még mindig. Hála istennek csak egyszer kellett, aztán töröltem is le a vérbe, de kicsit morbid ilyen szoftverekkel dolgozni, olyan, mintha az ember időutazna vissza 20-30 évet.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Hát igen, látom, sokakban trauma még a Java SE telepítő valamint az ÁNyK ökörségei, ami alapján végleg leírják a nyelvet is...

Mondjuk én ilyenek miatt is inkább hozzácsaptam a java SE/JDK alrendszert a projektjeimhez (nem pedig a telepítettet használtam). Sok hely, de legalább kevesebb a szívás...

Java-t is alig használok

Hogyne, okostelefonod sincs, bankban sem tartasz pénzt, stb. :)

rég ki kellett volna már halnia, ahogy az Adobe Flash-nek, MS Silverlightnak, és a többi hasonló baromságnak

Elképzelésem sincs, hogy mi lehet a hasonlóság a Java és mondjuk az Adobe Flash között. Flash-ben írták rendszerek milliónyinak a backendjét, egyszerű intranetes alkalmazásoktól, gyártásvezérléseken át pénzügyi rendszerekig?

( asch v | 2022. 09. 20., k – 22:53 )

\o/ Wow! Ez igen! A feature lista impresszív. Nagy Java rajongó vagyok, úgyhogy valóban örülök ennek. Java 1.2-t kezdtem könyvből tanulni, majd 1.4-et használtam először és az 1.5 generics volt az első olyan funkció amit már újként éltem meg és valóban sokat dobott az élményen.

A "Foreign Function & Memory API (Preview)" például olyan téma, amiben voltak hiányosságok eddig és szívtunk is vele rendesen már eddig is. Alig várom, hogy portoljuk erre a verzióra a cuccainkat.

A Virtual Threads is érdekesnek ígérkezik, igaz más nyelven de programoztam ilyesmit mostanában.

Szóval érdekesnek ígérkezik. Reméljük lesz lehetőség bevezetni ezeket az új funkciókat, mert mostanában úgy érzem hogy gyorsabban jönnek az újdonságok mint hogy birtokba tudnánk venni.

\o/

A Foreign Function & Memory API (aka Project Panama) már pár verzió óta previewban van, várják a visszajelzéseket, és akkor bekerül véglegesen is.

A Loom pedig valóban jó lesz. Most már csak igazán a Project Valhalla, ami nagy vállalás, és nagy változás, amit várok.

Egyre jobb runtime lesz a JVM.

( Hevi v | 2022. 09. 21., sze – 02:45 )

Szerkesztve: 2022. 09. 21., sze – 02:47

Vannak még cégek, ahol a legacy miatt sajnos a 8-as marad. Egyelőre.

Szerencsére eddig, ahol megfordultam, a business nyitott volt (mert végülis muszáj) a tech-dept felszámolására...

De ez sajnos idő.

Fogalmam sincs mi van a Java 19-ben. Mondjuk sokkal rosszabb nem lehet, mint a 8 a fércelt Functional Programming hackeléseivel.

A semminél jobb, de szar.

Jobban örülnék Swiftnek (nincs akkora támogatása, mint a Java-nak), vagy Kotlinnak (Swift utánérzet, és még Apple cuccokat se lehet vele natívan kódolni), de sajnos marad a Cobol Java ahogy elnézem...

Mi probléma nélkül upgradeltünk 8->11->17 irányban az elmúlt 4 évben. Minden kód 17 alatt fut már, használjuk is az új nyelvi elemeket, API-kat. Már várom a következő LTS-t, hogy updatelhessünk.

Mondjuk egy darabig használtunk 15-öt is, annyi volt az update 17-re, hogy a Maven build konfigban egy propertyt módosítottam, illetve más a Docker base image.

Én láttam már ilyen projektet, gyakorlatilag az összes így indul. Aztán jön egy kritikus pont, amikor megkérdezi a business, hogy (egy tanult exkollégát idézve) satuba mered-e tenni a golyóid, hogy az elvileg működő upgrade path a gyakorlatban is működik-e, miközben a cég a core business-ben a leállásokat úgy számolja, hogy 1 óra = 1 millió dollár mínusz. :)

Így van. És az alapos tesztelés nem egy perc még akkor sem ha esetleg teljesen automatikus. Ahogy vakcinát sem adunk ki hosszútávú hatástanulmányok nélkül, úgy szoftvert sem. És ha az a kérdés, hogy tud-e a program 1000 napig megállás nélkül futni, akkor azt 1000 nap alatt lehet tisztességesen leteszteleni, gyorsabban nem.

Nem vitatom, hogy rengeteg ilyen kritikus rendszer létezik, magam is láttam ebben a szellemben épültet, de ezek alapvetően rendszerarchitektúra problémák, ha ennyire nehezen változtatható. Lényegében a változásra nincs felkészítve, ami egy szoftvernél alapvetőnek kellene. Szóval ahol ilyen kockázatosnak ítélnek meg egy java 8->11->x átállást, ott lehet nem java verzió a legnagyobb probléma, hanem a rendszer hibatűrő képességének hiánya. 

A viccet félretéve, ahol tényleg ekkora a költsége a lehetséges bugoknak, ott ezt azért kezelik más módon, nem a Java 8 -> Java 17 update lesz ott az egyetlen hibaforrás.

Nyilván ha tényleg ekkora a kockázat, akkor a cégnek megvan a tőkéje, hogy megfelelő mennyiségű  és minőségű erőforrást (fejlesztés, tesztelés, üzemeltetést, biztonságot, menedzsmentet) szánjon rá, mellé téve mindenhez a vészhelyzeti forgatókönyveket, amiket előtte ki is próbáltak.

Szóval nem lehetetlen ez, csak akarni kell. Van olyan projektre rálátásom, ahol most jönnek rá, hogy bassza meg, nem jó dolog az, hogy olyan verziókat használnak runtime-okból, libekből, amelyeknek a támogatási periódusa 5 éve lejárt, 5 év alatt szartak a migrációra, most meg nagyon hirtelen fontos lenne, és csilliárdokba kerül. Sokkal fájdalmasabb az egy nagy migráció, mint a sok apró, ami be van építve a napi rutinba. Tudod, minden dolog akkor működik flottul, ha jól begyakorolva, sokszor csinálja az ember.

> És tudsz óránként 2 millányi értéket teremteni?

persicsb álnéven a piros sarokban Mészáros Lölő (*)

> Van annyi pénz a cégedben, hogy ha outage-et csinálsz, akkor leverhessük rajtad? :)

Nem feltétlenül kell, hogy legyen. Ha nem hiszed el neki / róla, akkor nem szerződsz vele. Ez (is) a te kockázatod.

(*) elnézést kérek instállom

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

8-ra váltásnál én sz-ptam át hosszú napokat, 8-ról 11-re már kevésbé vészes, a fő probléma a 3rd Party lib-ekkel volt amerre jártam. A 11 -> 17 pedig hihetetlen simán ment azon a cirka 30 Spring microservice-en amin végig mentem.

Na meg egy jó test base azért sokat tud gyorsítani az egészen 

return resolveUser("zeletrik").map { it.sign }

( K3cs1 | 2022. 09. 21., sze – 07:50 )

Mostani projektemen 11 LTS van. Következőn valószínűleg 17 LTS lesz. Úgy vettem észre, hogy a fejlesztés alatt álló projekteknél azért ragaszkodnak valamelyik LTS változathoz.

( zeletrik | 2022. 09. 22., cs – 10:01 )

Nagyon Kotlinosodunk, ami nem feltétlen baj, sőt!

return resolveUser("zeletrik").map { it.sign }