A Java 20 éve

 ( trey | 2015. május 21., csütörtök - 14:34 )

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 ]

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

De halottakról jót vagy semmit, nem?


"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

A java "hadoklik"? Na de komolyan.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

És ha mától egy szöget se vernek bele az ökoszisztémába, másik 20 évig még Java fejlesztő hiányszakma marad :D Aggodalomra semmi ok.

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

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ó.

A böngészőben futó java plugint a legtöbb java fejlesztő is utálja. Igazából html5 óta szükség sincs igazán rá, szóval szerintem nem kellene erőltetni..

JavaScript?

Fuszenecker Róbert

csak kár, hogy manapság kb. 1% használ kliens oldalon java-t, a többi mind szerver (esetleg különálló alkalmazás) oldalon futtatja, ahol igazából a helye van.

"csak kár, hogy manapság kb. 1% használ kliens oldalon java-t"

Android? :)

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

Az, hogy az API Java, még nem jelent semmit. A security hibák amúgy is implementációs dolgok általában, az meg teljesen más ugyebár.

"Az, hogy az API Java" ennek fussunk neki még 1x
-
Konténerezett Hadoop és Cassandra cluster konfigurálása - első rész

Ugye megvan, hogy az Oracle pont azért perelte (sikertelenül) a Google-t, mert az Android API nagy része megegyezik a Java SE API-val? És ez szándékosan van így, így könnyebben elsajátítható az Androidos fejlesztés.

Érdemes a nyelvek számát megnézni, csak 10x annyi Java projekt van mint a soron követzőből, vagy most akkor hogy is van ez? Programoznak Java-ban Androidra, ami aztán egy JVM-en fut vagy nem?

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

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.

mhmxs nincs képben azzal, hogy milyen Java az, ami Androidon fut. Mert nem Java.

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

Bocsi, böngésző pluginra gondoltam.

"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

Mi is 32-64 bites windowson fejlesztünk, és jórészt SLES-re, és más linuxokra deployolunk, de volt, hogy a békeidőkben még Sun Solarisra fejlesztettünk. Felmásol,
és fut. Ennyi a deployment.

Kivéve, ha orientdb-t, cassandrát, vagy hasonlókat szeretnél futtatni mondjuk openjdk-val. :)
--
zsebHUP-ot használok!

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

Freebsd-n pld nem. Ha az openjdk támogatott, az állításod nem igaz sajnos.
--
zsebHUP-ot használok!

FreeBSD-n tulajdonképpen nincs se OpenJDK, se Java. Egy kókányolt OpenJDK van, ami ezer sebből vérzik...

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

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.
Miben áll szerinted ez a kokányolás, miért kell ott kókányolni egy multiplatform vm-et?
--
zsebHUP-ot használok!

jvm azert eleg advanced ;)

--
NetBSD - Simplicity is prerequisite for reliability

"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

Talán 2000 környékén használtam először javát freebsd-n és már akkor is natív volt. A linuxos a bootstraphez kellett, az is licenc okokból.

Ok, a java jó, csak memóriát ne kelljen benne használni, mert arra alkalmatlan. :)

--
zsebHUP-ot használok!

É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-apache-cassandra-fosdem-2012
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.html
"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

+1

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

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

Ebből a mondatból kiderül, hogy halvány fogalmad nincs arról, hogy miért van szerver oldalon Java... :)

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

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.

+1

Az emberiség _nagy_ része? LOL. Muhaha. Most jól megaszontad nekik!

Javamikulás? Én szerettem. ;)

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.)

De mit keres Dautch Tamas a Linussal?
---
Dropbox: http://db.tt/XMk0ssk

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

ha ezt kifejtenéd (mondjuk) a jövőheti meetupon, hálás lennék!
--
blogom

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.

Amióta csak emlékszem, a Java pluginokkal mindig voltak gondok.
--
https://www.digitalocean.com/?refcode=7504fb2af065

Nem csak a 20 éveseké Java pluginé a világ.

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

Azért mindennek van határa, csak úgy néz ki a te hülyeségednek messze innen. Hogy a jó életbe mondhatsz ilyet?? szoktál gondolkozni néha? De most őszintén!

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

+sok

+1

+1

+1

+1

A Java-ban a
- kliens oldali technológiák vagy a kliens által használt derivált platformok zavarnak (applet, javafx, android)
- a nyelv
- a jvm
- vagy a szerver oldali alkalmazások
zavarnak?

--
arch,debian,openelec,android

Kérlek ne zavard össze tényekkel :-D

további kérdés, hogy a szerver-oldali keretrendszerek közül a JEE vagy a spring vagy az egyéb zavarja? Merthogy egyiket se kötelező használni :P

Nem hiszem hogy tudna rá válaszolni, szaraz aszt kész :)

--
arch,debian,openelec,android

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."

Akkor jöhet a Java-mikulás :D

+1, csak egy napra :D

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

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.

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."

Pontosan, akik itt szidják valszeg utoljára Java5-tel dolgoztak. De psszt, meg ne tudják hogy létezik Java8 és Scala mert a végén túl sok lesz a kompetens konkurencia 2 év múlva és nem leszek monopol helyzetben :'(

+1

A Scala-t nem ajánlom azoknak, akik nap, mint nap Java-ban programoznak.
Ha megismerik, akkor utána kínszenvedés Java-ban programozni ;)

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.

és mégis, melyik programnyelv szimpatikus a számodra...

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.

Írd már le miben programozol szívesen, idióta!

Attól megnyugszol majd?
--
♙♘♗♖♕♔

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.

Egy natív alkalmazáshoz képest biztos hogy lassú (összehasonlítva). Persze ha az usernél 1-2 másodperc alatt elindul, akkor ez nem érzékelhető annyira.

--
arch,debian,openelec,android

Valami mérési eredményeket is tudsz mutatni, vagy csak ilyen érzésre beszélsz...

sokáig szeretnétek még azon rugózni, hogy a "lassabb, de nem releváns mértékben" helyzetben a "lassabb" vagy a "nem releváns mértékben" a lényeges? :)

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

"a natív kód gyorsabb mint a menedzselt, ezt tudja mindenki"

Egyik barátom pont nemrég mérte ki, hogy a C#/.NET kód semmivel volt lassabb, mint a natív C kód. Ma már nagyon ügyesek a JIT cimpilerek.

Fuszenecker Róbert

Igen, elég sokat fejlődött ez a terület.

--
arch,debian,openelec,android

"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.

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

> 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)

2011 óta van native freetype a java-ban... (http://bugs.java.com/view_bug.do?bug_id=6570735)
(2007-ben írták a bugreportot, de külső könyvtárral elérhető volt)

javítva

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ó.

Nem igazán értem a logikádat. A fejlesztő nem használ tabokat, ami a nyelv/könyvtár hibája??? Ezt mégis hogy?