A Java 20 éve

Java

20 éves a Java!

"Az Oracle, a felhasználók és a fejlesztő közösség világszerte a Java 20 évét ünnepli. A Java napjainkban a munkahelyi és személyes életünket is érintő szoftver kritikus gerinceként szolgál. A nagyvállalati big data innovációktól kezdve, a felhőn, a közösségi felületeken, a mobilos megoldásokon és az Internet of Things összetevőin keresztül a hálózatba kapcsolt autókig, okostelefonokig, valamit a videojátékokig bezárólag a Java tovább segíti a fejlesztők munkáját, hogy kitágíthassák a technológiai innovációk határait."

[ Oracle blogbejegyzés | A Java 1991-től napjainkig | Oracle sajtóhír ]

( wowbagger v | 2015. 05. 21., cs – 14:37 )

Nem csak a halottaknál szokás kiírni a záró évszámot? :)
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.1 | 3.10.55-janos

( uid_228 | 2015. 05. 21., cs – 16:26 )

Kevés olyan technológia jut eszembe, amit ennél jobban gyűlöl az emberiség nagy része. :D Talán a Flash. :))

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

+1.
Csodalatos otlet + irgalmatlanul szar megvalositas.
Mondjuk, en mostanaban vagyok ra ideges, amikor xy szerveren futo java remote console tiltva van, amig nem engedelyezem a cpl-ben.
Miert kell a felhasznalot total hulyenek nezni? Miert nem lehet egy szint a High alatt, ahol nem kell direkt felvinni az ip-t abba a szarba ?

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Ne tévesszük össze a Java nyelv, a Java SE API és a Java runtime fogalmakat.

Androidra Java nyelven (Java 7 nyelvi elemek), részleges Java SE API-val és Android API-val lehet programozni, ami Android 4.4-ig alapértelmezetten Dalvik VM alatt futott, azóta meg Android RunTime van, ami egy AoT compiler és nem JIT. Nem is Java bytecode-ra, hanem DEX-re fordul le a kód.

Mert? Mitől lenne Java, ha most nem az? :)

A JVM teszi azzá? Akkor a Ruby Java lesz, ha JVM-en fut?
Vagy a Java SE API megléte teszi azzá? Akkor a GCJ az már Java?

Miért gondolod, hogy Te képben vagy azzal, hogy mi a Java?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ok, nem vagyok naprakész ezt bevallom, de ettől még az eredeti állítás amiről idáig jutottunk, vitatható "manapság kb. 1% használ kliens oldalon java-t", mert nagyon sokan 4.4 vagy régebbi verziót futtatnak. Persze kérdés minek vesszük az 1%-át, meg az is kérdés lehet mit tekintünk Java-nak.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - első rész

"szerver [...] oldalon futtatja, ahol igazából a helye van."

Érdekes, de a fő ígéret mintha "write once, run anywhere" lett volna, az meg pont kevéssé érdekes szerver oldalon...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"Érdekes, de a fő ígéret mintha "write once, run anywhere" lett volna, az meg pont kevéssé érdekes szerver oldalon..."

Miért ne lenne érdekes? Itt például fejlesztői oldalon van 32 bites Win7, 64 bites Win8, 32 és 64 bites mindenféle Linux vegyesen, illetve van Macbook is... szerver oldalon meg van 32 bites Win 2008, 64 bites Win 2012, 32 és 64 bites CentOS/RHEL... mindenhol fejleszthető és futtatható a Java fordítás végeredménye pedig bináris függőségeket használunk.

Szóval?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Centoson a Cassandra openjdk8-at hoz magával és mű
ködik is. Teljesítmny adataim nincsenek. De ez már inkább az a kérdés, hogy az adott tool milyen verziót támogat. A támogatott JRE/JDK verzióval viszont fut minenhol.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - első rész

"A Javan kívül ilyennel még nem találkoztam. Ha fut a vm/nyelv, jó eséllyel fut minden, ami nem akar platformfüggő lenni."

Én azért találkoztam Java-n kívül is mindenféle problémával FreeBSD alatt (elég sok időt eltöltöttem FreeBSD-vel szerveren és laptopon is). Nem hiába van tele egy csomó ifdef-el az összes forrás vagy megy rá egy csomó patch az adott forrásra, mielőtt fordul...

"Miben áll szerinted ez a kokányolás, miért kell ott kókányolni egy multiplatform vm-et?"

Egyrészt a (Java)VM nem multiplatform, a VM-ben futó mindenféle dolog a multiplatform. Másrészt, ha nem kókányolás lenne, akkor gond nélkül menne minden... szóval Q.E.D. :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ifdef freebsd ruby, php, python stb kódban? Nem sűrűn...
Erről beszélek, nem a c-s linuxism-ről (ami solarison is ugyanúgy, ha nem jobban gáz pld).

BTW, a Cassandra annyira java, hogy lassan akár c-ben is írhatnák. Malloc, fallocate, eléggé belehánytak a java bilibe.

Azaz kókányoltak. :)

--
zsebHUP-ot használok!

Nem a Java kódokkal vannak gondok FreeBSD-n, hanem a JVM-el van gond, ami futtatná azokat a Java kódokat... gondolom még mindig a Linux emulációs rétegen át megy csak és még így is sok patch kell hozzá, hogy forduljon...

"BTW, a Cassandra annyira java, hogy lassan akár c-ben is írhatnák. Malloc, fallocate, eléggé belehánytak a java bilibe."

A JNA nem belehányás, de azt hiszem bele se kezdek a magyarázatba... :/

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Én szerintem 2010-ig használtam Java-t FreeBSD-n, mindig kellett Linux emuláció a fordításhoz és rettentő sok patch-et kellett még letölteni.

A Cassandra JNA-n át való opcionális memóriakezelése pedig más okból szükséges, de erre most nem térnék ki.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mi más okból, mint hogy nagy memóriát, sok, illetve változó objektumot kezelni nem hatékony a JVM-ben?
BTW, a freebsd-ben megjelent jemalloc-kal. Lol. :)
Akárhány projektet láttam (elasticsearch, opendj legutóbb), mindegyik szenved, ha elkezdenéd használni egy mobiltelefonnál nagyobb vason.
Prediktív teljesítmény és java nem rokon fogalmak. :)
--
zsebHUP-ot használok!

"Mi más okból, mint hogy nagy memóriát, sok, illetve változó objektumot kezelni nem hatékony a JVM-ben?"

Hatékony, létezik egy tucatnyi design pattern a különféle esetekre, a megfelelőt kell használni, ritka esetben például JNA-t.

A Cassandra például azért használ a JNA, mert a design pattern szerint egy egy fizikai (vagy virtualizált) gép = egy Cassandra node. A Cassandra pedig a végletekig kihasználja a rendelkezésre álló memóriát, ha egészen pontos képet kap arról, hogy mi van swap-en, mi van memóriában és az adott SSTable alatt milyen storage van, az mikor van szinkronban a memóriával, akkor sokkal hatékonyabban tud dolgozni, mintha ezekről nem tudna, mert elfedi ezeket az információkat a JVM (aminek ugye ez a dolga).

"Akárhány projektet láttam (elasticsearch, opendj legutóbb), mindegyik szenved, ha elkezdenéd használni egy mobiltelefonnál nagyobb vason."

Most mit mondjak erre... talán nem való Neked a Java projektek üzemeltetése és/vagy a FreeBSD-n való üzemeltetése. :/

Én meg akárhány projektet láttam, képes voltam megfelelően használni és üzemeltetni is... esetleg meg kellene érteni a működésmódot és az üzemeltetési sajátosságokat, de ahogy látom az eddigi hozzászólásaidból: nem sikerült.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Hatékony[...] A Cassandra például azért használ a JNA, mert a design pattern szerint egy egy fizikai (vagy virtualizált) gép = egy Cassandra node. A Cassandra pedig a végletekig kihasználja a rendelkezésre álló memóriát, ha egészen pontos képet kap arról, hogy mi van swap-en, mi van memóriában és az adott SSTable alatt milyen storage van, az mikor van szinkronban a memóriával, akkor sokkal hatékonyabban tud dolgozni, mintha ezekről nem tudna, mert elfedi ezeket az információkat a JVM (aminek ugye ez a dolga)."

Jonathan Ellis szavai:
"RAM capacities have been increasingly roughly in step. But the JVM’s ability to manage a large heap has not kept pace."
http://www.slideshare.net/jbellis/dealing-with-jvm-limitations-in-apach…
Ráadásul még frissebb is, mint a te információid. :)

"esetleg meg kellene érteni a működésmódot és az üzemeltetési sajátosságokat, de ahogy látom az eddigi hozzászólásaidból: nem sikerült."
Összefoglalnád a működésmód és üzemeltetési sajátosság kvintesszenciáját, amelyeket nem sikerült megértenem az eddigi hozzászólásaim alapján?

Miket állítottam:
"Kivéve, ha orientdb-t, cassandrát, vagy hasonlókat szeretnél futtatni mondjuk openjdk-val. :)" (a write once, run anywhere-re)
Cassandra:
https://issues.apache.org/jira/browse/CASSANDRA-8325
Amikor egy java programban memóriapointerekkel zsonglőrködnek és segfaultolják a VM-et, hát ez tényleg a menedzselt kód diadala.

Orientdb:
https://github.com/orientechnologies/orientdb/issues/3501
(fele annyira sem néztem bele, mint a cassandrásba), jó, hát JDK-t választani tudni kell... Nekik is meg kell még érteniük a működésmód sajátosságait. :)

"BTW, a Cassandra annyira java, hogy lassan akár c-ben is írhatnák. Malloc, fallocate, eléggé belehánytak a java bilibe."
OK, a Cassandra egy java wrapper a low level kódhoz, így szebb? :)

"Akárhány projektet láttam (elasticsearch, opendj legutóbb), mindegyik szenved, ha elkezdenéd használni egy mobiltelefonnál nagyobb vason."
https://www.elastic.co/guide/en/elasticsearch/guide/master/heap-sizing…
"meg kellene érteni a működésmódot és az üzemeltetési sajátosságokat". Azaz ne használj sok memóriát, és/vagy tuningold szarrá a JVM-et (de ne használj sok memóriát)?

Az opendj is tud olyat, hogy LDAP válaszidőket mérsz, és amellett, hogy amúgy gyors (bár pld. egy C-ben írt LDAP szerver ugyanannyi CPU idő elhasználása mellett *jóval* gyorsabb), néha elalszik kicsit.
Remélem az üzemeltetője majd megfontolja a javaslataidat és megérti ezeket. Rögtön a gyártója után, aki a programot írta és a jvm paramétereket hozta. :)

"Ráadásul még frissebb is, mint a te információid."

Ráadásul azt írja, amit én is... elolvastad az egészet (és még néhány előadást a témában)? Vagy csak belelapoztál, mert rákerestél kulcsszavakra? :/

"https://issues.apache.org/jira/browse/CASSANDRA-8325
Amikor egy java programban memóriapointerekkel zsonglőrködnek és segfaultolják a VM-et, hát ez tényleg a menedzselt kód diadala."

Ilyen az, amikor random keresel problémákat, amelyeknek nem érted a lényegét. Végigolvastad az összes kommentet? Megnézted a javasolt patch-et? Megnézted, hogy mi okozta a problémát? Szerinted a Cassandra tehet arról, hogy a FreeBSD alatt fordított OpenJDK natív C nyelven írt részében és/vagy a Linux emulációs rétegben nem implementáltak megfelelően egy metódust (... az Unsafe hívás ugye...), ezért körbe kell programozni (javasolt patch), mert a Cassandra fejlesztők közül senki nem ért a FreeBSD-n forduló C kódhoz?

"Orientdb: https://github.com/orientechnologies/orientdb/issues/3501"

Ahham... lássuk csak: "java.lang.NoClassDefFoundError: Could not initialize", ahja, valamit kihagytak az OpenJDK-ból. Ahham... csak FreeBSD-n nem megy, tehát a FreeBSD-n futó OpenJDK-ban nincs valami meg, ami kellene. Micsoda meglepetés.

Tényleg csodálkozni kell azon, hogy a FreeBSB-n nincs Java, mert ami van, az olyan, mintha nem lenne? Nem a futtatandó Java binárisokkal van a baj, hanem a FreeBSD-n lévő Java konténerrel, ami egy kalap szar, de ezt már írtam.

Mit akarsz ebből az egészből kihozni? Talán ilyesmit: A FreeBSD tökéletes. A FreeBSD alatti JVM is tökéletes. Minden tökéletes, csak valami érthetetlen oknál fogva más -- JVM szempontjából támogatott -- oprendszeren tökéletesen futó Java binárisok nem tökéletesek FreeBSD-n, ezért a Java szar, nem a FreeBSD-n a JVM port. Logikus.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Ráadásul azt írja, amit én is... elolvastad az egészet (és még néhány előadást a témában)? Vagy csak belelapoztál, mert rákerestél kulcsszavakra? :/"
Nem, ezt még régebben olvastam, amikor először szembe jött a Cassandra unsafe, és próbáltam megérteni, hogy miért.
Gondolom ezt a "meg kellene érteni a működésmódot és az üzemeltetési sajátosságokat" mondatodra érted, mert a "Hatékony, létezik egy tucatnyi design pattern a különféle esetekre, a megfelelőt kell használni, ritka esetben például JNA-t" csak nem lehet, hacsak nem azt mondod, hogy "hatékony, csak meg kell találni a megfelelő workaroundokat, hogy az legyen".
Ezt a gondolatmenetet folytatva a kókányolt FreeBSD-s OpenJDK-n is tök jól fut a Cassandra, csak meg kell találni a workaroundokat hozzá :) (egyébként nyilván ez a helyzet, igaz én csak pár TB-ot tároltam benne játékból, szóval éles tapasztalatom sok száz PB-tal és csillió node-dal nincs, főleg nem FreeBSD-n).

"Ilyen az, amikor random keresel problémákat, amelyeknek nem érted a lényegét. Végigolvastad az összes kommentet? Megnézted a javasolt patch-et? Megnézted, hogy mi okozta a problémát? Szerinted a Cassandra tehet arról, hogy a FreeBSD alatt fordított OpenJDK natív C nyelven írt részében és/vagy a Linux emulációs rétegben nem implementáltak megfelelően egy metódust (... az Unsafe hívás ugye...), ezért körbe kell programozni (javasolt patch), mert a Cassandra fejlesztők közül senki nem ért a FreeBSD-n forduló C kódhoz?"
Nézd, te biztosan fényévekkel jobban értesz ehhez az egész ökoszisztémához, és a java szerelmese vagy. Kérlek világosíts fel, a sun.misc.unsafe pld. belefér a "write once, run everywhere", meg a szálindító "Felmásol, és fut. Ennyi a deployment" kijelentésekbe?
A sun.misc.unsafe a java publikus API-jának része? Minden JVM-ben implementált? Hívhatjuk még java programnak azt, ami csak egy JVM-en fut (és nem garantált, hogy annak a következő verzióján is fog még)? Nem tudom esetleg sikerült eljutni odáig, hogy megértsd, hogy az "eléggé belehánytak a java bilibe" alatt mit értettem?
A menedzselt kód iránti elkötelezett támogatójaként hová tennéd, a JNA-n innen, vagy azon túl a "tucatnyi design pattern" között?

Esetleg arról is van gyakorlati tapasztalatod, hogy azzal, hogy a JVM-en kívül futtatsz natív kódot milyen biztonsági problémákat hozol be? Komolyan érdekel. Linkelnél esetleg ebben a témában valami részletesebbet?

"Ahham... lássuk csak: "java.lang.NoClassDefFoundError: Could not initialize", ahja, valamit kihagytak az OpenJDK-ból. Ahham... csak FreeBSD-n nem megy, tehát a FreeBSD-n futó OpenJDK-ban nincs valami meg, ami kellene. Micsoda meglepetés."
Apám, és te vádolsz azzal, hogy nem olvasok. Elég lett volna csak a címig jutnod.
Rajtam kívül mindenki Linuxon próbálkozott, semmi köze a FreeBSD-hez, hacsak annyi nem, hogy megírtam: 6-os és 7-es OpenJDK-n nem megy, 8-ason igen, és mindezt FreeBSD-n próbáltam, mert -milyen meglepő- ez az az OS, amin a legkönnyebb csomagból tetszőleges verziójú javát felrakni, illetve akár egyszerre használni.
(tudom, más, supportált OS-ekre elég letölteni a targz-t, és kitömöríteni bármelyik könyvtárba)

"hanem a FreeBSD-n lévő Java konténerrel, ami egy kalap szar, de ezt már írtam."
Olyanokat írtál, amivel elárultad, hogy fogalmad sincs mi van most, sőt nagyjából arról sem, hogy mi volt régen. Nézz tükörbe, amit te arról gondolsz, hogy én mit gondolok a Javáról, mennyi tudással, na te pont azt gondolod, ugyanannyi tudással a FreeBSD-ről.
Legalábbis én így gondolom (de lehet, hogy nem komolyan). :)

"Mit akarsz ebből az egészből kihozni?"
Semmit. Egyszerűen viszonylag sok mindent láttam már egy adott techológiai halmazban, és nagyon sokféle szarral szívtam ahhoz, hogy kialakuljon az a véleményem, hogy ha túl sokáig, vagy túl alaposan akarsz használni valamit, rá fogsz jönni, hogy nincs tökéletes szoftver, mindegyiknek megvan a maga baja.
Ebben a témában trollkodtam kicsit, amit úgy látom te a kelleténél jobban magadra vettél, mert:
echo "Mit akarsz ebből az egészből kihozni? Talán ilyesmit: A FreeBSD tökéletes. A FreeBSD alatti JVM is tökéletes." | sed "s/FreeBSD/Oracle JDK/g"

BTW, boldog házassági évfordulót. :)

--
zsebHUP-ot használok!

"A sun.misc.unsafe a java publikus API-jának része? Minden JVM-ben implementált?"

Minden _támogatott_ JVM-ben implementált, része a TCK-nak is. FreeBSD-ben kókányolva van. Kell erről többet beszélni?

"Hívhatjuk még java programnak azt, ami csak egy JVM-en fut (és nem garantált, hogy annak a következő verzióján is fog még)?"

Megtörtént már párszor, lásd @Deprecated API, aztán meg nem publikus API-t bármikor kivezetnek. És? Ismert kockázat, lehet használni, de például a Java 9 környékén az Unsafe is jelentősen át fog alakulni, aki használja, tudja, hogy mikor mire kell készülnie, aki nem használja, annak meg teljesen mindegy. Mire akarod kihegyezni a gondolatmenetet? :)

"Olyanokat írtál, amivel elárultad, hogy fogalmad sincs mi van most, sőt nagyjából arról sem, hogy mi volt régen. Nézz tükörbe, amit te arról gondolsz, hogy én mit gondolok a Javáról, mennyi tudással, na te pont azt gondolod, ugyanannyi tudással a FreeBSD-ről."

Igen, én csak kb. 2002 és 2010 között használtam FreeBSD-t szervereken, laptopon, itt-ott, írtam cikket FreeBSD-ről a Linuxvilágba... aztán 2010-re választanom kellett, hogy Java vagy FreeBSD, mert a kettő együtt bizony szar. Nem is szar: kellemetlenül szar. Nyilván fogalmam sincs semmiről és ahogy az általad linkelt problémákat olvastam, pont olyan szar, mint 2010-ben... :/

"Egyszerűen viszonylag sok mindent láttam már egy adott techológiai halmazban, és nagyon sokféle szarral szívtam ahhoz, hogy kialakuljon az a véleményem, hogy ha túl sokáig, vagy túl alaposan akarsz használni valamit, rá fogsz jönni, hogy nincs tökéletes szoftver, mindegyiknek megvan a maga baja."

Óóó... én rengeteg problémáját ismerem a Java-nak, szoktam is mindenfelé hangoztatni. Viszont amikor olyan irányból támadják, amiről nem tehet (például szarul futnak a Java projektek FreeBSD-n), akkor azért szoktam védeni is, mert ugye innen indultunk: "FreeBSD-n tulajdonképpen nincs se OpenJDK, se Java. Egy kókányolt OpenJDK van, ami ezer sebből vérzik..."

Néhány szent őrült foglalkozik azóta is a FreeBSD OpenJDK portjával, soha nem próbálták a TCK-t, soha nem volt egységes, felhasználói visszajelzések alapján szögelték körbe a problémákat és minél frissebb és határokat feszegetőbb alkalmazást próbáltál futtatni, annál inkább aknamezőn jártál, amivel soha nem tudhattad, hogy a következő percben is fog-e menni, vagy a következő frissítés után is fog-e menni. Desktop alkalmazások alá jó, szerverre és/vagy production környezetben a FreeBSD Java-t el kell felejteni. Ez van.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

mert ugye innen indultunk: "FreeBSD-n tulajdonképpen nincs se OpenJDK, se Java. Egy kókányolt OpenJDK van, ami ezer sebből vérzik..."
Inkább ide érkeztünk, de mindegy, sajnos nem sikerült megértened mi a bajom.

Többek között az, hogy Java-programozók, akiknek jellemzően (nekem legalábbis ez a tapasztalatom) pld. nincs multiplatformos, alacsony(abb)szintű programozási ismeretük olyan helyeken kezdenek el nyúlkálni egy internal API-val, aminek a hatásait nem feltétlenül értik meg, és a Java egyik nagy előnye, a write once, run everywhere, illetve a C-ből ismert biztonsági hibák egy részének hiánya szép lassan átalakul azzá a hákgyűjteménnyé, amit te is sérelmeztél korábban a C kódokban a FreeBSD-s életedből (itt ezért nem megy, ott azért, ifdef hegyek, programozási hibák miatti sechole-ok, DoS stb. -ezeket már én teszem hozzá, bár az ezt firtató kérdésemre nem reagáltál, lehet, hogy ez az aspektus téged hidegen hagy...).

Innen indultunk, a példaként felhozott FreeBSD-be (amit azért dobtam be, mert konkrétan érintett, és éreztem, hogy nálad el kell kerülnöm, hogy guglizzam a problémákat) már csak te kapaszkodtál bele görcsösen.

Mindezt úgy, hogy -egy javában járatos szakembert idézek-:

""Nem beszélek érzésre, a natív kód gyorsabb mint a menedzselt, ezt tudja mindenki.""
"Az a helyzet, hogy ez nem igaz, de ezt tudja mindenki, aki érti a menedzselt kód működését."

szerinted erre semmi szükség, hiszen nem igaz, hogy a natív kód gyorsabb, mint a menedzselt, meg javában hatékonyan lehet memóriát kezelni, mégis ezek a projektek próbálják a menedzseltből egyre inkább natív kód fennhatósága alá menteni a dolgaikat -mert néha ez a jó design pattern. OK, ha te mondod...

És ha még mindig nem érted mit próbálok közölni, nézd meg például ezt:
https://groups.google.com/forum/#!topic/elasticsearch/Nh-kXI5J6Ek
egy "javás" program elcrasheli a jvm-et Solarison. Amin ugye ezek után tulajdonképpen nincs se OpenJDK, se Java, csak egy kókányolt valami, mert core-t dob a JVM. Mint FreeBSD-n.
Vagy hogy ne menjünk olyan messzire a Cassandra vs. FreeBSD-től ezt:
https://issues.apache.org/jira/browse/CASSANDRA-6628

Mivel a hozzászólásod utolsó bekezdésével maximálisan egyet tudok érteni, megpróbálom én is összefoglalni neked ennek a szálnak a tartalmát:
Korábban a Java azt jelentette, hogy ha rendesen, kiskapuk nélkül programozott benne valaki, az a nyelvi keretek közt, hibátlan JVM esetén megbízhatóan működött bármilyen platformon, amin a Java elérhető (azt most inkább nem feszegetném, hogy néha mégsem, adott JVM verzióra ez azért igaz volt).

Most azt jelenti, hogy a Java programok kb. x86/Linux-onlyvá válnak, mert hiába van egy nem kókányolt JVM-ed (az Oracle JVM-jét ugye hívhatjuk ennek Oracle Solarison?), ez még nem garancia arra, hogy egy szaros program el ne crashelje az egészet a picsába, ha épp a fejlesztője nem látott ki a linuxos notebookja mögé.

Szerintem hagyjuk, több időnk marad másra. :)

Ha esetleg elolvasnád, hogy mi is volt a probléma. Valami jóképességű olyan osztályt használt, aminek az a neve, hogy sun.misc.Unsafe... Rögtön ment is a bugreport, és
MÁSNAPRA már javították is (eltávolították az unsafe osztály használatát.

Tehát, továbbra is az a helyzet, hogy bár lehetőség van kézzel memóriát kezelni, és kinyúlogatni a JVM-ből, viszont nem véletlenül vannak ezek az osztályok Unsafe és hasonló módon elnevezve, illetve a jobb IDE-k hibának is jelölik ezen osztályok használatát. Ha ezek utána a fejlesztő úgy gondolja, hogy ő tudja, mit csinál, lelke rajta, lehet, viszont akkor
kezelnie kell a felmerülő problémákat.

"elcrasheli a jvm-et Solarison"

Képzeld. Linux-on is van ilyen! Meg Windows-on is! Tudok mutatni egy csomó példát. És?

Egy része JDK bug, amit javítanak a támogatott platformokon, a másik része pedig a különféle unsafe hívásokból van. A neve is mutatja, hogy mi ez. A Java múlt egyik öröksége, amit teljesen ki fognak vezetni a Java 9-ben és nincs már sok létjogosultsága Java 6 felett se... megvan az oka, leginkább a sandbox-ból való engedélyezett kinyúlás és olyan információk beszerzése, amire nincs és alapvetően nem is kell Java API, de ezt már írtam. Csak nem értetted meg. Vagy nem akartad megérteni.

"Korábban a Java azt jelentette, hogy ha rendesen, kiskapuk nélkül programozott benne valaki, az a nyelvi keretek közt, hibátlan JVM esetén megbízhatóan működött bármilyen platformon, amin a Java elérhető (azt most inkább nem feszegetném, hogy néha mégsem, adott JVM verzióra ez azért igaz volt)."

Pont korábban volt jellemző a JVM teljesítményproblémái miatt, hogy kiskapukkal programoztak. Az Unsafe például 2000-ben került publikálásra a J2SE 1.3-al, előtte is létezett a Java 1.2 (!) verziótól, csak nem ezen a néven. Vagyis ezek a lehetőségek 15-17 évvel ezelőtt kerültek a platformba... akkor, amikor még rendes JIT se volt, nemhogy működő HotSpot. A J2SE 5 és a Java SE 6 környékén oldották meg a teljesítmény problémákat -- igen, nagyjából 10 éve, azóta mindenhol szorul vissza a JVM-ből való natív kihívás.

Baszki, nem most kezdték el használni, hanem most kezdik kivezetni a 10-15 éves legacy kódokból! Szóval minden igaz, csak nem osztogatnak, hanem fosztogatnak... :/

"Szerintem hagyjuk, több időnk marad másra. :)"

Ahja... van egy hibás prekoncepció-halmazod, ami onnan indul, hogy a Java nem támogatott FreeBSD platformon és ezt nem tudod se feledni, se továbblépni rajta, se megérteni az okát... felőlem szophatsz továbbra is a Java projektekkel FreeBSD-n, ez miatt mutogathatsz az OpenJDK-ra és arra a néhány szerencsétlen Java alapú programra, amelyek nem futnak normálisan az FreeBSD-OpenJDK kombináció hiányosságai miatt -- ám napokon belül megpróbálnak workaround-ot kiadni a hibára, ahelyett, hogy a FreeBSD oldal javítana a kompatibilitáson! -- de ettől még nem olyan a világ, amilyennek sarkítva bemutatod és nem is lesz lesz olyan a világ, amilyennek szeretnéd látni...

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Képzeld. Linux-on is van ilyen! Meg Windows-on is! Tudok mutatni egy csomó példát. És?"
Semmi gond, jól van ez így. Tegyél elé tűzfalat, az majd megoldja a problémát.

"azóta mindenhol szorul vissza a JVM-ből való natív kihívás. Baszki, nem most kezdték el használni, hanem most kezdik kivezetni a 10-15 éves legacy kódokból! Szóval minden igaz, csak nem osztogatnak, hanem fosztogatnak... :/"
Ha te mondod...

[bra@qtyafasza ~/git/cassandra]$ for tag in `git tag | sort -V`; do git checkout -q ${tag}; printf "${tag}\t"; grep -r sun.misc.Unsafe . | wc -l; done
cassandra-0.3.0-final 0
cassandra-0.3.0-rc1 0
cassandra-0.3.0-rc2 0
cassandra-0.3.0-rc3 0
cassandra-0.4.0-beta1 0
cassandra-0.4.0-final 0
cassandra-0.4.0-rc1 0
cassandra-0.4.0-rc2 0
cassandra-0.4.1 0
cassandra-0.4.2 0
cassandra-0.5.0 0
cassandra-0.5.0-beta1 0
cassandra-0.5.0-beta2 0
cassandra-0.5.0-rc1 0
cassandra-0.5.0-rc2 0
cassandra-0.5.0-rc3 0
cassandra-0.5.1 0
cassandra-0.6.0 0
cassandra-0.6.0-beta1 0
cassandra-0.6.0-beta2 0
cassandra-0.6.0-beta3 0
cassandra-0.6.0-rc1 0
cassandra-0.6.1 0
cassandra-0.6.2 0
cassandra-0.6.3 0
cassandra-0.6.4 0
cassandra-0.6.5 0
cassandra-0.6.6 0
cassandra-0.6.7 0
cassandra-0.6.8 0
cassandra-0.6.9 0
cassandra-0.6.10 0
cassandra-0.6.11 0
cassandra-0.6.12 0
cassandra-0.6.13 0
cassandra-0.7.0 0
cassandra-0.7.0-beta1 0
cassandra-0.7.0-beta2 0
cassandra-0.7.0-beta3 0
cassandra-0.7.0-rc1 0
cassandra-0.7.0-rc2 0
cassandra-0.7.0-rc3 0
cassandra-0.7.0-rc4 0
cassandra-0.7.1 0
cassandra-0.7.2 0
cassandra-0.7.3 0
cassandra-0.7.4 0
cassandra-0.7.5 0
cassandra-0.7.6 0
cassandra-0.7.6-2 0
cassandra-0.7.7 0
cassandra-0.7.8 0
cassandra-0.7.9 0
cassandra-0.7.10 0
cassandra-0.8.0 0
cassandra-0.8.0-beta1 0
cassandra-0.8.0-beta2 0
cassandra-0.8.0-rc1 0
cassandra-0.8.1 0
cassandra-0.8.2 0
cassandra-0.8.3 0
cassandra-0.8.4 0
cassandra-0.8.5 0
cassandra-0.8.6 0
cassandra-0.8.7 0
cassandra-0.8.8 0
cassandra-0.8.9 0
cassandra-0.8.10 0
cassandra-1.0.0 0
cassandra-1.0.0-beta1 0
cassandra-1.0.0-rc1 0
cassandra-1.0.0-rc2 0
cassandra-1.0.1 0
cassandra-1.0.2 0
cassandra-1.0.3 0
cassandra-1.0.4 0
cassandra-1.0.5 0
cassandra-1.0.6 0
cassandra-1.0.7 0
cassandra-1.0.8 0
cassandra-1.0.9 0
cassandra-1.0.10 0
cassandra-1.0.11 0
cassandra-1.0.12 0
cassandra-1.1.0 5
cassandra-1.1.0-beta1 5
cassandra-1.1.0-beta2 5
cassandra-1.1.0-rc1 5
cassandra-1.1.1 5
cassandra-1.1.2 5
cassandra-1.1.3 5
cassandra-1.1.4 5
cassandra-1.1.5 5
cassandra-1.1.6 5
cassandra-1.1.7 5
cassandra-1.1.8 5
cassandra-1.1.9 5
cassandra-1.1.10 5
cassandra-1.1.11 5
cassandra-1.1.12 5
cassandra-1.2.0-beta1 5
cassandra-1.2.0-beta2 5
cassandra-1.2.0-beta3 5
cassandra-1.2.0-rc1 5
cassandra-1.2.0-rc2 5
cassandra-1.2.1 5
cassandra-1.2.2 5
cassandra-1.2.3 5
cassandra-1.2.4 5
cassandra-1.2.5 5
cassandra-1.2.6 5
cassandra-1.2.7 5
cassandra-1.2.8 5
cassandra-1.2.9 5
cassandra-1.2.10 5
cassandra-1.2.11 5
cassandra-1.2.12 5
cassandra-1.2.13 5
cassandra-1.2.14 5
cassandra-1.2.15 5
cassandra-1.2.16 5
cassandra-1.2.17 5
cassandra-1.2.18 5
cassandra-1.2.19 5
cassandra-2.0.0 6
cassandra-2.0.0-beta1 6
cassandra-2.0.0-beta2 6
cassandra-2.0.0-rc1 6
cassandra-2.0.0-rc2 6
cassandra-2.0.1 6
cassandra-2.0.2 6
cassandra-2.0.3 6
cassandra-2.0.4 6
cassandra-2.0.5 6
cassandra-2.0.6 6
cassandra-2.0.7 6
cassandra-2.0.8 6
cassandra-2.0.9 6
cassandra-2.0.10 6
cassandra-2.0.11 6
cassandra-2.0.12 6
cassandra-2.0.13 6
cassandra-2.0.14 6
cassandra-2.0.15 6
cassandra-2.1.0 12
cassandra-2.1.0-beta1 7
cassandra-2.1.0-beta2 13
cassandra-2.1.0-deb 12
cassandra-2.1.0-rc1 12
cassandra-2.1.0-rc2 12
cassandra-2.1.0-rc3 12
cassandra-2.1.0-rc4 12
cassandra-2.1.0-rc5 12
cassandra-2.1.0-rc6 12
cassandra-2.1.0-rc7 12
cassandra-2.1.1 15
cassandra-2.1.2 15
cassandra-2.1.3 13
cassandra-2.1.4 13
cassandra-2.1.5 13
cassandra-2.2.0-beta1 11

Ahham... leírom, hogy Java 5 és főleg a Java 6 óta erre egyre kevésbé vagy szükség, mindenki gőzerővel vezeti ki, mert nem fog működni Java 9 esetén, erre hozol egy példát a Cassandra-ról, ahol megjelent az Unsafe a Cassandra 1.1.0 verziójában, amelynél még az OpenJDK 6 se volt támogatott... :/

...és ugye azt is tudod, hogy az off-heap és biztosan nem swap-en lévő cache miatt van Unsafe... ahol az injektált JNA C kódot cserélték Unsafe-re, mert a JVM jelenleg nem képes azt biztosítani, hogy a heap nem kerül swap-re, lévén ez nem a dolga... de ezt is leírtam már háromszor, ha nem hiszed, esetleg nézz forrást, ne csak számold a sorokat... :/

...és nem azért nem megy, mert FreeBSD-n Linuxos C kódot injektálnak (mert az Unsafe _nem_ C kód injektálás, a JNA viszont az!), hanem konkrétan szar az Unsafe implementáció, de ezt elengeded a füled mellett... de tudod mit? Leszarom, mert nem fogod vagy nem akarod megérteni.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Jót el cseverésztek itt :) de a matematikai valószínűsége, hogy dűlőre huttok igen alacsony.

Az, hogy a Cassandrás srácok a Java-t választották merem feltételezni, hogy nem a véletlen műve és a kiragadott szarságok mellett biztos nyertek is valamit ezzel a döntéssel. Az hogy sun.*-os csomagot használnak, szintén a Cassandrás srácok döntése, nics is ezzel semmi baj, ha számoltak a következményekkel, fel kell jól tünteni, a támogatott JDK-k listáját oszt csókolom, ha adott operációs rendszeren támogatott (lehet vitatkozni mit nevezünk támogatottnak, de az biztos, hogy a lefordul != támogatottal, a *BSD-s OpenJDK port, mert az egy port, a projects alatt érhető el, ami nekem sugall valamit) az a verzió, akkor futni fog, ha nem nem.

A JNA/JNI pluszt ad a Java világához és nem elvesz tőle. Nem kötelező használni, de előfordulhatnak olyan esetek, lévén a Java nem a szent grál, hogy optimálisabb így megoldani valamit azzal ilyen-olyan okból.

Nem okoskodni akarok, és még csak 6-7 éve foglalkozom Javas alkalmazások fejlesztésével és üzemeltetésével, hogy érdemes a célhoz választani az eszközt és nem fordítva.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - második rész

Nem azt mondtam, hogy érdektelen, hanem azt, hogy kevéssé érdekes...
Ezzel csak arra próbáltam rámutatni, hogy a "szerver oldalon, ahol helye van" kijelentés kicsit fura, mert a nyelv alkotói nem oda tervezték.

Megjelenésekor a böngészős applet volt a killer feature, most meg pont ezért rühellik sokan, akik meg nem, azok szerint sincs ott helye.

Szerver oldalra kb azért került amiért manapság a js...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Nem az a kérdés, hogy most miért van ott, hanem, hogy miért került oda az 1.2 '98-ban. Mert akkor még nem volt az az ecosystem körülötte ami most van és a nyelv alapvető feature-ei nem voltak must have-ek szerver oldalon.

Az én gyanum az, hogy ha a Sun kb bármelyik másik high level nyelvbe invesztál ugyanennyit, akkor most az a nyelv lenne megkerülhetetlen.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"ha a Sun kb bármelyik másik high level nyelvbe invesztál ugyanennyit" én kinézem a Sun mérnökeiből, hogy azért válaszották ezt, mert alkalmasnak találták, és elgondolkoztak legalább egy alternatíván. És a kérdés nem azon van high-end-e vagy sem, hanem azon, hogy statikusan és erősen típusos, valamint managelt nyelv, amik nélkül még a modern eszközökkel, nem beszélve az akkoriakkal, is eléggé nehéz elképzelni akkora méretű enterprise :) fejlesztéseket, amikről most beszélünk.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - első rész

"Nem az a kérdés, hogy most miért van ott, hanem, hogy miért került oda az 1.2 '98-ban."

Mit tettél volna oda '98-ban?

"Az én gyanum az, hogy ha a Sun kb bármelyik másik high level nyelvbe invesztál ugyanennyit, akkor most az a nyelv lenne megkerülhetetlen."

Ugye a Sun idejében felfedezte, hogy mi a managed code előnye, mégis, melyik nyelvbe kellett volna invesztálnia?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Szerver oldalra azért került, mert kevesebb teret enged a C/C++-ban gyakori hibáknak, és a fejlesztési időt is lerövidítette valamelyest. Szóval nem oda szánták, de egyrészt kiderült, hogy elég jól illik oda, másrészt a SUN alapvetően szerver vendor volt. Ezen kívül lassú volt a mint a dög és rengeteg erőforrást igényelt, és ez a szerver oldalon volt a legkevésbé szempont, ha C-vel kellett összehasonlítani. A probléma egyesek fejében az, hogy ez a régi állapot rögzült mint tévhit. Ma már nem hogy lassú, hanem elég gyors (C > Java > Lamp), és az erőforrás igénye már nem olyan durva, ha relatívan nézzük a mai programokhoz.

A kezdetek óta azért eltelt némi idő úgy. hogy talán a legnagyobb fejlesztői közösség állt a nyelv és a platform mögött.
Van egy remek standard library, amit csak annak ér szídni, aki a jobbat tud felmutatni máshol. Addig is szídjuk mi, akik dolgozunk vele (De csak addig, amíg valamiért nem kényszerülünk egyéb nyelveken dolgozni, akkor rögtön megszeretjük újra).
És ez csak a standard library, szóval lehet mondani hogy van Qt C++-ban, meg RoR, meg satöbbi, de akkor apache.org, google dolgai, vagy github-on lehet keresni. Aki nem talál neki tetsző library-t Java-ban az valószínűleg nem kereste eléggé.
Szeretjük szídni a mavent is, bár mostanában már csak az XML miatt utálom. Főleg mióta kénytelen voltam szembesülni python2 vs. python3, .rvm, cabal hell és hasonló rémségekkel. Itt megintcsak kíváncsi lennék ennél jobb package management és build megoldásra, máris nézném mint lehetséges alternatív nyelvet fun projektekhez.
Mi van még... natív crypto, javamail, async/sync io streamek, sql, logging, távoli menedzsment... ezek csak a sima JDK alap képességei, nem is a JavaEE. És nagyrészt mind használható, a legtöbb library nem ezek kiváltására van, hanem további funkciókra.

Ha nem csak a nyelvet nézzük, hanem a JVM platformot, akkor van Groovy, Scala, Clojure. Három teljes értékű nyelv a maguk saját standard library-kkel, amikből minden java dolog használható. A Scala csak magában egy meg nem kerülhető dolog lenne, többit nem annyira ismerem. Akka, ScalaJS, scalaz.

És akkor még BigData-val nem is foglalkoztam, nem ismerem, de ott van egy csomó dolog a Hadoop körül.

Volt elég sok dolgom PHP-vel, Pythonnal, Ruby-val, Javascripttel az utóbbi pár évben. Szeretek új dolgokat megismerni, hátha valami jobbat találok mint ami van. Haskell, Erlang megismerése nagyon hasznos volt, de az összképet nézve nem tudnék olyan környezetet mondani, amire megérné váltani a Java-ról. És akkor még a Scala-t hozzá sem adtam a dolgokhoz.

Hogy a JS miért került szerver oldalra, nem tudom. Érdekes nyelv. Inkább JS mint PHP vagy hmm.. talán mint Python, de nem összevethető a Java-val (szerver oldalon).

Lehet rosszul fogalmaztam, én csak azon lamentáltam, hogy ahhoz képest, hogy a Java nem szerver oldalra lett tervezve, mien érdekes, ha valaki azt mondja, hogy oda való, (és emberek azért utálják, mert ott használják ahova nem való, pl applet).

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Ok, a végére már nem csak neked lett válasz...
Azért amire eredetileg lett tervezve (beágyazott eszközök, telefonok), azzal 10-15 évvel megelőzte a korát. Végül az Android-on kb. azt csinálja amire kitalálták eredetileg.
Az hogy a szerveroldalon akkora siker lett nekem pont azt bizonyítja, hogy remek nyelv. Az, hogy ekkora ökoszisztéma épült köré, szintén.

Legfeljebb csak azért gyűlölik, mert lassan 4+ kattintás kell ahoz hogy el lehessen indítani egy oldalon.

(Nem, azóta sem lett jó ötlet játékokat, rajz/hangprogramokat, file-műveletetek igénylőeket stb. js-ben futtatni, és rábízni magunkat a különféle böngészők homokdobozára.)

( _Franko_ v | 2015. 05. 21., cs – 17:59 )

Mondjuk nagy kár, hogy nem a Google vette meg a Sun romjait, az Oracle eleinte nem is értette, hogy mit vett, amikor meg másfél-két évvel később rájött, addigra minden kulcsember lelépett vagy a projekt ágazott el... :/

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( mauzi v | 2015. 05. 21., cs – 18:44 )

Only two remote holes in the default install, in a heck of a long time! ... öööö, ja, az nem a Java, hanem egy másik mosópor.

( Xterm v | 2015. 05. 21., cs – 20:26 )

ha már egy évvel leszünk az után, hogy karóbahúzták ennek a szemétkupacnak az összes fejlesztőjét, akkor majd ünneplek én is... bár... elrettentő példának mindig jó lesz a java

--
xterm

( sheridan | 2015. 05. 21., cs – 21:27 )

Ha már Java event... Ezt akkor most emlékül postolom a 2008-as "nagy szívások éjszakájának" - aki az akkori team közül még emlékszik rám és arra, hogy miről dumálok és netán olvassa is ezt, annak csirió... vigyázzatok magatokra...

"Saying Java is good because it works on all operating systems is like saying anal sex is good because it works on all genders."

( hardhead | 2015. 05. 22., p – 00:17 )

Értem én, hogy 20 éves. De mi ebben a jó? :)

( GCS v | 2015. 05. 22., p – 10:04 )

Cikkhez hozzá lehetett volna írni, hogy ez a Java 20. születésnap egybeesik az atyjának tartott James Gosling (szintén kerek, 60.-ik) születésnapjával.

( legradi v | 2015. 05. 22., p – 14:14 )

Vessetek a mókusok elé, de szvsz a Java programozási nyelv, valamint a hozzákapcsolódó technológiák tartalmaznak érdekes, izgalmas és jövőbemutató elemeket.

Persze ezeket a jelenben -- vagy talán a múltban -- lehetett volna sokkal jobban is kidolgozni...

============================================
"Share what you know. Learn what you don't."

( bithalver | 2015. 05. 22., p – 22:31 )

Szoval csak 20 evvel kellene visszamenni az idoben megszuntetni ezt a ...-t. (nyomdafesteket nem turo reszek kivagva).

Keves programnyelv van, amiben irt kod szinte kivetel nelkul hanyingert okoz ahanyszor meglatom.

Mi a fenéért bántják a Java-t? Mert az Oracle (de már a Sün is) elcseszi futtatókörnyezetet és úgy unblock rossz kézben van a technika? Vagy mert bytecode-ba fordítják natív kód helyett és az milyen már? Vagy mert eleve a C(++) a király?
Szerintem egy könnyen használható nyelv és technika, amit azért a közutálat ellenére elég sokan támogatnak és népes fóruma van a neten. Olyan dolog még nem volt, amire ne találtam volna vagy mintakódot, vagy komplett osztályt.
Tény, hogy pl játékprogram írására nem egy jó nyelv, de minden más céges környezetbe szükséges gyors fejlesztésre jó nyelv és jó technika. Mondom ezt annak ellenére, hogy pl a JRE telepítők miatt tényleg kijárna két nagy pofon valakiknek
Isten éltesse az alkotókat, Isten éltesse a nyelvet!!! És egy nagy Voga verést minden fújolóra!

Mert büdös nagy trollok. Mi másért jönnének ide? Rohadtul nem kötelező használni, de mivel van aki szereti, így mindig akad valaki, aki az oktalan böfögésekre reagál, hiszen a felhozott érvek túlnyomó többsége nem is állja me a helyét (pl "azt igérték, hogy egyszer megírom és fut mindenhol" kontra "képzeld fut mindenhol csak hülye vagy"). Felesleges zavarkeltés. Ha nem szeretem a Gézát nem megyek oda a Géza szülinapi bulijára, ahol a Géza legjobb haverjai vannak, hogy hirdessem mekkora egy paraszt ez a Géza, hacsak nem feltett szándékom, hogy verekedést szítsak. Na nem hiszem magam zseninek, hogy átláttam a szitán ;)

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - első rész

Olyan emberektől várod egy programnyelv objektív megítélését, akik szerint az ideális nyelv a programozás-oktatás elkezdésére gyerekeknek a C/C++. :)

A Java egyáltalán nem olyan rossz, mint amilyennek beállítják, sőt. Mondom ezt úgy, hogy alapvetően .NET-párti vagyok.

( M0Rph3U5 | 2015. 05. 24., v – 07:32 )

Nekem úgy tűnik, java-ban csak fejleszteni szeretnek. Azaz dev oldalról népszerű, de felhasználói oldalról meg utálják nem véletlenül. Hiába a platform-függetlenség, ha a legtöbb applikáció használhatatlan fostaliga. Legtöbbször még a tab használatát sem ismerik az appok.

Azon a véleményen vagyok én is, hogy az elgondolás jó, a megvalósítás meg azt eredményezi, hogy: elégedett fejlesztők vs. felhasználók, akik kiírtanák a java-t gyökerestül.

---== ::: M 0 R p h 3 U 5 ::: ==---

Igazából velem együtt a legtöbb Java fejlesztő tudja, hogy gyengén szerepel a cucc desktopon. Az applet egy fostaliga, a javafx se ért el áttörést, a swinges kinézet meg 10 éve is übergázul nézett ki. És eléggé lassú is a cucc. Persze ott a JIT, de pont a startupnak kéne gyorsnak lennie, a JIT meg pont akkor nem szólal meg, csak később. Szóval inkább backend oldalon működik jól (de ott eléggé).

--
arch,debian,openelec,android

Mi kliens oldalon is fejlesztünk java-ban, swing-gel. Saját CSS frameworkot írtunk Swing fölé, és eléggé jól néz ki az alkalmazásunk. És az sem igaz, hogy lassú, ezt nem tudom, honnan veszed. Nem kell GUI szálban számításokat végezni, és nem lesz lassú. De ha nem tetszik a Swing, akkor ott a JavaFX2, ami aztán tényleg nagyon szuperül néz ki, és hw gyorsított. A startupot sem igazán értem, a mi alkalmazásunk kb. 1-2 másodperc alatt indul. Szóval meg lehet írni rendesen a programot, és akkor nem lesz se lassú, se ronda.

Nem beszélek érzésre, a natív kód gyorsabb mint a menedzselt, ezt tudja mindenki. De ha úgy tesszük fel a kérdést hogy érzékelhetően lassabb-e mai körülmények között akkor nem biztos hogy igennel válaszolunk. És a termékünk eladhatóságánál ez a lényeges.

--
arch,debian,openelec,android

> s eléggé jól néz ki az alkalmazásunk
És tudja már a natív freetype-os megjelenítést, vagy még mindig valami saját hányást hekkel?

SWT-n kívül még nem láttam egy implementációt sem, ahol ment volna (egyszer mintha valami patchelt openjdk-ban, de azóta sem futottam vele össze)

Nem ez volt a kérdés...

A kérdés arra vonatkozott, hogy a rendszer fontbeállításait tudja-e használni fontconfig/freetype-on keresztül? Gy.k.: Ugyanúgy fog hintelődni a font, mint ahogy a GTK-s, Qt-s GUI-k fontjai?

Legutóbb amikor megnyitottam a NetBeanst, sehogy nem lehetett ugyanazzal a monospace fonttal ugyanazt a megjelenítést elérni.

Őszintén, fogalmam sincs hogy linux alatt hogy megy, de windows7 alatt úgy látom, hogy jó... legalábbis nekem nem tűnik rossznak, szép, élesek a fontok.
Most néztem a javafx2 ensemble-t, ott is jónak tűnik. 8-as JDK-t használok. Kicsit utánaolvastam, mások is azt írják, hogy linux alatt 8-as JRE/JDK-val jó.