Egy "frissítés" margójára...

Ha már frissítetünk valamit amire kötelez minket a Nemzeti Kibervédelmi pütypürüty a "telepítőből" ne kapcsoljuk már ki a klienseken a java autoupdatet... Nem feltétlen kellene más farkával verni ...

Amúgy nem frissíteni kellene, hanem elásni jó mélyre , hogy véletlen se köszönjön vissza. ;)

( uid_395 v | 2019. 10. 24., cs – 19:50 )

btw annak oka is lehet.. van olyan állllllami rencccer sok cével ... ami csak és kizárólag bizonyos X.Y.A Java verziókkal megy. Fentebb, lentebb nem.
Pont. :)

Ez így van.. De ettől még... A Java az egy specifikus sz.r a .gov* szférában sajnos.... Még mindig.... És nem Java-t akarok fikázni, de azért basszameg ne csináljuk már azt hogy 1.5 (volt 3 éve még ilyen hogy 1.5ös java kellett) vagy 1.6 vagy 1.7 kelljen... Plussz úgy írják meg a programokat hogy még rakjál bele a java consoleba hogy -dSunJavaCompatible... hagyjuk már..

brr. sorry ez kicsit off volt a végén.

Dolgozunk olyan EU-s (nem kicsi) szervezetnek, ahol
- tavaly frissitettek a szervereiket meg a munkaallomasokat java 6-rol java 8-ra
- python a szervereken es a munkaallomasokon 2.6
- OS a gepeken RHEL 6 (kernel 2.6.32-754)

Csak akkor nyulnak hozza a base-line-hoz, ha valami EOL kozelebe er, vagy ha kelloen magas pozicioban levo embert sikerul meggyozni.

Ami működk, azt nem kell megjavítani. A RHEL6 egyébként kösz, jól van, jövő november végén lesz nyugdíjazva, és utána még 2024 június végéig lehet extended supportra előfizetni, úgyhogy azzal tényleg nem ell hűdenagyon rohanni - bár egy RHEL 6.10--ről RHEL 8.x-re váltás az azért combos ugrás lesz, mert RHEL7-re átállni nem lesz érdemes.

"nem véletlen, hogy ha springboot-os alkalmazásod"
Az, hogy a ratyisztani kodhalmaz spring boot (vagy az azt hasznalo ratyisztani fejleszto) nem kepes kezelni a signalokat, meg nem jelenti azt, hogy a JVM nem ad erre lehetoseget. (hint: van ra mod)

Mondom maskeppen: Ha valaki csak ganyol mert vagy nem erdekli vagy mert nem ert hozza, az nem a Java hibaja.

Akkor olvass utána, hogy springboot-os sz@roknál ez a default exit value, sikeres kilépésnél... Úgyhogy ezek szerint vagy mindenki, aki springboot-os vackot fejleszt gányol (ekkor igazam van, hogy a java-s fejlesztés ezen terülte gányolás-hegyeket jelent), vagy pedig maga a környezet sz@rul van megcsinálva, és onnantól gény az egész - és nem is nagyon van ingerencia ezt kijavítani.

Ez a JVM default. Pontosabban, ha a JVM kap egy signalt amit aztan az abban futo program nem kezel le, akkor a JVM a 128+signal number ertekkel ter vissza. (143-128=15-SIGTERM)

Tekintve, hogy a JVM-nek goze sincs arrol, hogy a benne futo program rendezetten lepett-e ki (kapcsolatok, fajlok rendesen lezarva, clean-up, stb) vagy arrol, hogy hiba nelkul elvegezte-e azt, amiert egyaltalan elinditottak, ez a viselkedes ertheto a JVM reszerol. Nyilvan nem hazudhat be egy 0-at kilepeskor ha nincs tudomasa rola mi tortenik. 

Az exit code beallitasa a programozo dolga. Meg lehet irni ugy a programot, hogy definialom, hogy a kulonbozo signalokra mi tortenjen es a vegen milyen ertekkel lepjen ki a JVM. Spring-ek ezek szerint ugy gondoljak, hogy nem fontos "normalis" exit code-ot beallitani kilepeskor. Azon lehetne vitatkozni, hogy mekkora a jelentosege az exit code-nak mondjuk web alkalmazsok eseten.

De kinyilatkoztatni, hogy a java "ratyisztáni kódhalmaz mindenestől" azert, mert valakik nem a sysadmin konvencioknak megfeleloen implementaltak egy framework-ot, az eleg eros.

Nekem leginkább tapasztalat , a fenti remekmű sokáig csak 1.6-os javaval (egyébként most is van olyan kispajtása aminek a "fejlesztésére" nem maradt EU-s lé) ment IE alatt, egyszer egy intézményből telefonálnak , hogy nem tudják megnyitni a dokumentumaikat nem fogod kitalálni , hogy min keresztül titkosítódtak el. ;) Akkor megtanulták , hogy az a böngésző egyetlen oldal megnyitására van.