ls -1Itt lakik a HUP PartnerünkHUP tweetjeiNépszerű témákNépszerű fórum témákÚj felhasználók
|
java-7 miért beszél magyarul?!Így áll a locale:
$ locale
LANG=en_US.ISO8859-1
LC_COLLATE="en_US.ISO8859-1"
LC_CTYPE=hu_HU.ISO8859-2
LC_MONETARY="en_US.ISO8859-1"
LC_NUMERIC="en_US.ISO8859-1"
LC_TIME="en_US.ISO8859-1"
LC_MESSAGES="en_US.ISO8859-1"
LC_ALL=
Tehát csak a LC_CTYPE magyar, semmi más. Na lássuk, mi történik: $ java
Használat: java [-opciók] osztály [arg-ok...]
(egy osztály végrehajtása)
vagy java [-opciók] -jar jarfájl [arg-ok...]
(egy jar fájl végrehajtása)
Akkor kedvem lenne ilyenkor egy kalapáccsal szétverni a monitort...
»
|
KeresésNavigációBelépésÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélInformációKövess minket! |
Gondolom a csomagban ami felkerült .jar file magyar nyelvű verziója volt.
Azért ennél pöttyet kifinomultabb a lokalizáció AIX-on is...
például, ha azt mondom, hogy 'LC_ALL=hu_HU.ISO8859-2 mc' akkor magyarul indul a mc, ha 'LC_ALL=fr_FR.ISO8859-1 mc', akkor franciául.
Speciel ez a java csak az OS-szinten is telepített nyelvekkel hajlamos működni, vagyis ezek közül választhatok (plusz utf-8-as verziók):
LC_ALL=hu_HU java -- magyar
LC_ALL=en_US java -- angol
Ez jó is. A gond az, hogy a LC_CTYPE-ot miért használja a LC_MESSAGE helyett?!
"Ez a java" = melyik java?
Az OpenJDK a forrasa alapjan elvileg logikusan mukodik (LC_MESSAGES-t hasznalja a megfelelo celra).
trusson keresztül futtatva a javát, nem látszik, hogy zsonglőrködik a locale-lel?
Azt jól látod, hogy mást csinál, mint amit a környezet predesztinálna.
@lx: de, látszik, hogy a magyar lokalizációt használja, de az nem látszik, hogy miért a LC_CTYPE-ot nézi...
@haspokember: ilyen java
Java(TM) SE Runtime Environment (build pap6470_27sr1fp1-20140708_01(SR1 FP1))
IBM J9 VM (build 2.7, JRE 1.7.0 AIX ppc64-64 Compressed References 20140707_205525 (JIT enabled, AOT enabled)
Ugy emlekszem, az IBM-fele JVM-nek van valami default system property file-ja, nem lehet, hogy abban van valami override?
Egyebkent meg hivd fel a supportjukat, kerdezd meg toluk, megiscsak ok az illetekesek :D
Mondjuk rohangál a /usr/java71_64 könyvtárban számos properties, majd szétnézek, hátha van ilyesmi opció
(Mondjuk kicsit fucsán nézni ki, hogy pl:
instead_of_LC_MESSAGES_use: LC_CTYPEEsetleg egy kalapács használata, amivel szétverhetném a kis képernyőt, amikor ilyen hülyeségeket olvasok? Mindezt a szegény ártatlan LC_CTYPE miatt!
.
Adatkozles.java :)
--
arch,debian,osmc,android,windows
:D
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
Namost talán úgy tűnik, hogy a legegyszerűbb módszer a legcélravezetőbb:
persze nem leszek meglepve, ha ettől meg más dolgok romlanak el...
Szerk: na jó, ez hülyeség volt. Az esetleg lehetséges, hogy a Java egyáltalán nem törődik a LC_CTYPE-pal, kivéve ezt a teljesen felesleges funkciót, hogy az üzenetek nyelvét ahhoz igazítja.
"Az esetleg lehetséges, hogy a Java egyáltalán nem törődik a"
Ez IBM J9 specifikus szerintem.
http://www-01.ibm.com/support/docview.wss?uid=nas8N1020141 ez megvolt már?
Köszönöm szépen, ez a user.language a nyerő!
Manapság miért használ bárki nem OpenJDK -t (vagy OpenJDK-ból bővített Oracle JDK -t) ?
Komoly a kérdés, nem kötözködök.
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
Persze, én meg azt kérdezhetném, hogy miért használ valaki Aix5.3-at 2018-ban. Mindenesetre az előbbi állítást így pontosítom: Ibm/Java7-től a -Duser.language segít a LC_CTYPE-tól megzavarodott nyelvi beállításon:
Mert a frissebb mondjuk nem megy az adott vason?
gondolom AIX-en szopó belőni, vagy van valami ami J9-specifikus (vö. vendor lock-in) :)
Nem esett le, hogy az oprendszer is egzotikus :)
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
Azért az "egzotikus" maximum a PC/Linux/Windows irányból nézve igaz, az AIX köszöni szépen közel harminc éves múltra tekinthet vissza, és ennek ellenére elég jól tartja magát :-P
Igen, és a market penetrációja is hatalmas...
Mert csomo enterprise progi el sem indul openjdk-val? Kompatibilitas ide vagy oda ez igy van sajna.
Lazán kapcsolódik: Az Oracle-féle Java 11 már nem free
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Az a gecinagy sárga hátterű doboz bizony "didn't realize".
Természetesen nem arról van szó, hogy az Oracle szét akarja verni a Javát, csak éppen úgy viselkedik (kb a 9-es óta), mint aki szét akarja verni a Javát.
Abból él, nem akarja szétverni. Csak megélni belőle xd
Tegyük tisztába hogy a referencia implementáció az OpenJDK, az OracleJDK pedig egy kibővített OpenJDK.
Az én kérdésem arról szólt, hogy miért kell egy harmadikat használni, aminek semmi köze az első kettőhöz.
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
Vn aix_ppc target: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/file/5ab7a67bc155/src/os
Fordíts magadnak :)
Ennyi van: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=30900301
Szerintem nem sok. az RI oldalon csak Linux, Mac, Windows buildek vannak.
Így marad a J9, ami előre van csomagolva, gondolom.
Nem ide, hanem egyel foljebb ment volna :D
Ertem en es nem jol fogalmaztam. Arra akartam kilyukadni, hogy valami ilyesmi lehet a hatterben, hogy ugyanugy ahogy az openjdk sem jo mindenre, mert az oraclejdk-ban vannak dolgok, talan az IBM is csinalt ilyen nyulkalasokat, amik ahhoz vezettek, hogy se openjdk-val, se oraclejdk-val nem mennek a dolgok ha IBM termekekrol van szo. Nem tudom, csak erre gondoltam, amikor irtam a kompatibilitas hianyarol. De nem ertek a javahoz, csak egy otlet volt a resezmrol, hogy a nagy IBM enterprise java-ban vannak olyan dolgok amik kellenek oda, ahova es mas nem is jo.
(fórum-ön-nekromanta)
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?