A Java megalkotója elhagyta az Oracle-t

Oracle

Újabb széles körben ismert, egykori Sun alkalmazott döntött úgy, hogy nem kíván a továbbiakban az Oracle alkalmazottja lenni. Most James Gosling, a Java atyja állt odébb. Ahogy azt új blogjában írja, "Igen, valóban igaz a szóbeszéd, kiléptem az Oracle-től egy héttel ezelőtt (április 2-án)".

A felmondás okait pontosan nem nevezi meg, de szavaiból érezni lehet, hogy nem volt egészen elégedett a Sun felvásárlás után az Oracle-nél tapasztaltakkal. Egy másik blogbejegyzés szerint kisebb szabadságot élvezett, mint a Sun-nál, illetve nem győzte meg az Oracle Java-val kapcsolatos jövőbeli stratégiája.

Gosling egyelőre nem tudja mihez kezd. Másik állást fog keresni.

A blogbejegyzés itt olvasható.

( honorshark | 2010. 04. 11., v – 08:57 )

Kerdes: Mi lesz a Java-val? (Nem emiatt, szimplan az Oracle felvasarlast kovetoen. Nem igazan szimpatikus a dolgok alakulasa.)

Az OpenJDK okán nem tud elkallódni. A RedHat stack szépen fut OpenJDK és a JBoss, s ez JavaEE stack. Egyre több Linux alatt van IcedTea (=OpenJDK), mint JRE, ettől se kell tartani. Az Oracle annyit tud csinálni, hogy fizetőssé tesz új fejlesztéseket, mint például a G1 GC lett volna (http://www.javaforum.hu/javaforum/0/news/55/page/news.detail/action/new…), amelyet "visszavontak" a közösségi fellépés okán.

Az Oracle egyébként nem fogja levágni az arany tojást tojó tyúkot, hiszen a Java-ban eddig is volt neki is jelentős bevétele, egyszerűen az IBM lenyomására készül, ahhoz pedig teljes stack kell hardvertől, a middleware-en át a kliens technológiákig. Most megszerezte ezt, és racionalizál. Hogy jól döntöttek-e egy-egy termék kapcsán, az majd kiderül utólag.
--
http://wiki.javaforum.hu/display/FREEBSD

A Java nyílt fejlesztői és futtatási környezetével semmi sem lesz, fejlődni fog. Az, hogy a Java megalkotója távozott a cégtől nem jelenti azt, hogy vége a világnak. Nem csak ő dolgozott a Java-n. Megy szépen minden és mindenki a maga útján, de hogy őszinte legyek, a Java-ban én nem látok jövőt. Egyes területeken esetleg, ahol 100% multiplatform kell, talán van jövője, de szépen lassan vissza fog húzódni a jelenlegi felhasználási területe ezekre a speciális esetekre.

Update: bocs, ezt a főszálhoz akartam!

SKL - leírásgyűjtemény és informatikai portál

Ne essék félreértés, a Java-val semmi bajom, nem azért írtam, amit írtam, mert gyenge fejlesztésnek tartanám. Viszont folyamatosan figyelve az informatika fejlődését, nekem valahogy nem úgy tűnik, mintha ez a fejlődés a Java vitorlájára hajtaná a szelet. A Java alkalmazások teljesítménybeli problémáiból adódóan a nagyok inkább a natív utat választják a multiplatformság helyett. Ez sem tesz túl jót ennek a fejlesztési ágnak. Mint mondtam, vannak területek, amik megigénylik a Java adta lehetőségeket. Ilyen területek az elkövetkezendő években biztosan lesznek, de elképzelhető, hogy egyszer el fog tűnni a rá való igény. A másik pedig az Oracle hozzáállása, amit kár ragozni.

Remélem nincs igazam és remélem a Java még hosszú-hosszú ideig élni fog.

SKL - leírásgyűjtemény és informatikai portál

Komoly helyeken a munkaerőpiaci megfontolások jobban dominálnak.

Egy garázsprojektet bármilyen eszközben el lehet indítani amihez az alapítók értenek, aztán ha világcéggé válnak és több száz programozót kénytelenek felvenni, akkor jöhet a migrálás java-ra. ;)

szerk.: persze vannak technikai előnyei is a Javanak, de sok esetben a menedzsment ezeket kevésbé, míg az általam kiemelt előnyét sokkal jobban ismeri

az a vagy az gondolom "vagyok" akart lenni :-)

mar ezer postban kitargyaltuk, de alljon itt meg1x: az ecosystem az, ami a javaban nagy elonye. tegyuk fel, hogy meg kell irnod egy alkalmazast, ami beszel SOAPot, tudja titkositani a forgalmat, van kulccsere, hogy meggyozodjenek arrol, hogy tenyleg ok azok, akik, etc.

C++ban ezt mennyi ido, lowlevel socketekkel? amennyire hallottam, a gSOAP messze nem olyan jo erre a feladatra. es mi van ha hirtelen azt kerik, hogy lehessen RESTbe hivni? ha jol faktoralod a kodod, Javaban ezt 1-2 ora alatt meg lehet csinalni...

Ez egy nagyon-nagy ökörség volt, már ne is haragudj. Nagy cégeknél nagyon szeretik a java-t használni, mert baromi jól lehet vele rendszereket integrálni, gyorsan lehet vele fejleszteni, és ami a legfontosabb, jó minőségűek lesznek a kódok (nehéz gányolni). Vannak célfeladatok, amire nem j2se-t vagy j2ee-t kell használni, ez teljesen igaz, viszont teljesítményproblémákról én nem hallottam még eddig. (java sebessége közelíti a cplüsplüs sebességet)

"mert baromi jól lehet vele rendszereket integrálni" - rendszert integrálni környezettől függetlenül igen nagy szívás. Ebben a Java nem előny. Inkább J2EE-t mondtál volna, de ... nem mondok róla semmit.

"ami a legfontosabb, jó minőségűek lesznek a kódok" - sok Java kódot láttam, amit indiaiak írtak. A copy-paste kultúra ellen semmi sem véd. Márpedig az elébb emlegetett nemzet kódolói hihetetlen pusztítást végeznek a szakmában.

"Vannak célfeladatok, amire nem j2se-t vagy j2ee-t kell használni" - ez nagyjából megállja a helyét. Ugyanakkor ez a típusú megközelítés (J2EE és társai) hanyatlásnak indult.

"teljesítményproblémákról én nem hallottam még eddig" - pedig ebben a világban bőven akad. És pont a J2EE világban elterjedt tranzakcionális adatbázis kezelés az egyik rákfenéje a teljesítmény problémáknak.

"java sebessége közelíti a cplüsplüs sebességet" - A JIT ma már valóban jó teljesítményre képes, viszont a Java tervezéséből fakadóan nem túl jól sáfárkodik a memóriával. Teljesen hétköznapi probléma itt az elfajuló memóriaéhség. Egy jól megírt C++ kód viszont sokkal kompaktabb, memória szempontjából meg durván ráver a Javára.

Ha már előnyt szeretnék mondani a Java mellett az az Eclipse és a refaktoráló segédrendszere. Ez talán a legnagyobb és mindenképpen jelentős előnye a többi nyelvvel kapcsolatban.

--
Kinek nem inge, ne vegye gatyára

"java sebessége közelíti a cplüsplüs sebességet" - A JIT ma már valóban jó teljesítményre képes, viszont a Java tervezéséből fakadóan nem túl jól sáfárkodik a memóriával. Teljesen hétköznapi probléma itt az elfajuló memóriaéhség. Egy jól megírt C++ kód viszont sokkal kompaktabb, memória szempontjából meg durván ráver a Javára.

... es csak 10x annyi ido megirni!

Amugy egy feligmeddigoff kerdes.

Ha a java gyors (mert ugye ezt Franko mar bizonyitotta), konnyu irni (ezt sokan mondjak), profi (ezt is sokan), mindenre jo.... akkor miert nem irodnak benne ... bongeszok , video lejatszok, mittudomen... minden project amit hasznalok/latok az vagy cpp-ben kezdodott, vagy abba lett atirva. De ha ilyen jo a java miert? (Komolyan kerdem, nem flame es nem ironia. Kivancsi vagyok mindossze.)

Mivel a legtöbb alkalmazás windowson fut, ezért ott a c# nyerő, amennyiben
nem jön elő olyan hülyeséggel a customer, hogy neki most linuxosak lettek
a gépei, át kellene írni...

c#-ban egyébként általában pofásabb dolgokat lehet csinálni, de igazából ott is belefutottunk olyan projekt átvételbe, hogy a "fejlesztő" összeklikkelte a gui-t a csodás designerrel, csak aztán nem lehetett továbbfejleszteni, ala delphi, és ment a nagy refactoring.

Egyszerű: C/C++ nyelven már kész... :)

Lehetne Java nyelven újra megírni ilyesmit, ahogy az MS világban teszik is: kezdenek mindent .NET platformra szervezni, de ez idő és pénz. Az alsó réteg, a kernel nem lehet Java, mivel a Java nem rendelkezik hardver-kezelő API-val, se utasításokkal. A kernel feletti rétegekre pedig vannak példák, lásd az Android platform. De itt se írtak meg mindent Java-ban, ha már van kész C/C++ megoldás, nincs értelme.
--
http://wiki.javaforum.hu/display/FREEBSD

De ha elkezdenek egy teljesen uj projectet akkor azt miert nem java-ban irjak akkor? Ertsd pl smplayer, utorrent, irfanview, mittomen akarmelyik nagyobb nevu project ami scratch-rol indult es ugy szuletett meg. Jo.. uTorrent epp azert kicsi mert. De ha java gyors, kicsi, etc, akkor ugyanugy bevetheto lenne nem? ^^"

(Azert mondom mert meg nem lattam sose desktop alkalmazast java-ban ... marmint amit ugy effektiv sokan hasznalnak, etc.. a peldaimbol latni mikre gondolok, az alap dolgok linuxon es Windowson is. (Vagy pl Pidgin hogy MAC is bejojjon ide Adium formajaban))

Azért, mert minden épkézláb Java fejlesztő hülyére keresi magát szerver oldali fejlesztéssel, ahova alig találni fejlesztőt, és eszébe sem jut kliens oldalra fejleszteni, ideje sincs rá. C/C++ nincs szerver oldalon elterjedve, a kernel és rendszerprogramozók köre limitált, a többieknek marad a kliens oldal...

Hozzá kell tenni, hogy a legtöbb kliens oldalra fejlesztő cég Windows-ra fejleszt, így régebben Delphi volt a platform, mostanában pedig .NET/C#, ami ugye menedzselt kód, Java alapokról ágaztatva.

Azert mondom mert meg nem lattam sose desktop alkalmazast java-ban ...

Kis apróságok szoktak lenni, nagyobb program a NetBeans, az Eclipse például, mint fejlesztőeszközök, de valóban nem jellemző, hogy Java lenne kliens oldalon. :)
--
http://wiki.javaforum.hu/display/FREEBSD

A javanak nem erossege a grafika, meg a SIMD (MMX/SSE stb) utasitasok is hianyoznak belole, annyira jo JIT-et meg meg nem tudtak irni, ami a kezzel optimalizalt MMX koddal versenyezhetne, plane, ha a forras sem vektoros.

Azt lehetne, hogy raknanak a javaba egy codec api-t, irnanak hozza nativ codec plugineket, es javabol azokat lehetne hivogatni. Kellene ugyanez demuxerekkel (bar az kevesbe cpu es optimalizalas igenyes, akar javaban is meg lehetne irni), es video output drivereket (amit megint csak nativan tudsz mivel kernelt/os-t kell erosen izelgetned amire a java alkalmatlan). Igaz akkor egy video lejatszo mar csak par fuggvenyhivasbol allna :)

Nem tudom pl. az opengl tamogatas is hogy all javaban, mikor utoljara javaztam kb 10 eve, akkor meg csak 3rd party cuccok voltak erre es azok is eleg bugosak es lassuak.

A'rpi

A javanak nem erossege a grafika, meg a SIMD (MMX/SSE stb) utasitasok is hianyoznak belole, annyira jo JIT-et meg meg nem tudtak irni, ami a kezzel optimalizalt MMX koddal versenyezhetne, plane, ha a forras sem vektoros.

A Java nem is támogatja ezeket, de a JRE igen. A Java3D például a JNI libeken át egészen a videókártyáig nyúl, tehát az ember képes Java nyelven hardveresen gyorsított 3D program írására. A Java6u10 óta pedig a Java2D is hardveresen gyorsított... nézz meg néhány demó JavaFX videót vagy példa kódot (pölö: http://www.youtube.com/watch?v=Y6BqmytKQMA&feature=related). :)

Nem tudom pl. az opengl tamogatas is hogy all javaban, mikor utoljara javaztam kb 10 eve, akkor meg csak 3rd party cuccok voltak erre es azok is eleg bugosak es lassuak.

Hátigen... végülis 10 év az informatikában nem idő, ennyi idő alatt semmi nem szokott történni... :)
--
http://wiki.javaforum.hu/display/FREEBSD

Hogy miért? Több oka van:

1, kezdő programozók c++-ban próbálnak ügyeskedni, ami szerintem nagyon rossz kezdés, lásd valakinek a commentjét a 45-ösről és a majmokról :)

2, ezek a kis progik általában nagyon betöltés igényesek, ami egy kicsit több idő java esetén (amíg elindul a java, stb.) de pl. ott van a jdownloader, ami nagyon jó kis cucc, és egész használható

3, sok olyan program van, ami igazából codec-et használ, videólejátszó, akármi, aminek ezek a részei meg vannak optimalizálva mmx-szel, egyéb varázslatokkal. Itt nyilván a java nem rúghat labdába. (átlag nagycéges program tipikusan NEM ilyen)

4, sok rossz kóder. De tényleg. A programozók max. 20% tud igényes, megtervezett, jó kódot írni, a többi az indiai jómunkásembertől a dephi varázslón át a php script kiddie-ig terjed, aztán van egy sáv, aki próbál fejlődni, és vannak az igazán jók, akik eleget dolgoznak ahhoz, hogy a szabadidejüket ne kódolással töltsék, hanem mondjuk a családjukkal....

"sok Java kódot láttam, amit indiaiak írtak"

ahahah! rátapintottál a lényegre. ha egyszer betévedsz az msdn topikjaiba, nézzed meg, hogy az indiai nevű userek mennyire hihetetlenül ostoba kérdéseket tesznek fel, s a válaszok 103,08%-a link a dokumentációra. Amit 1000thx jelleggel köszönik meg, hogy segítettél és hogy sikerült.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( zidane2005 | 2010. 04. 11., v – 10:57 )

Tudtam, hogy sokan fognak távozni és azon is gondolkoztam már korábban, hogy akár Gosling is. Utánara arra gondoltam, hogy leginkább a Java miatt csinálták az egészet és arra a "részre" vigyázni fognak. Ehhez képest most ez...

Hova fog menni? Talán ezek közül kerül ki:
-Red Hat
-Google
-Microsoft [.net]

( therion | 2010. 04. 11., v – 14:08 )

Ebben a helyzetben nagyon örülök, hogy már GPL alatt ki vannak adva a kódok. Most ha az Oracle fizetőssé tenné az új fejlesztéseket, akkor szerintem igencsak megkockáztatná a technológia forkolódását.

Sőt, szerintem abszolút nem kizárt hogy idővel (komoly közösségi támogatás esetén) az OpenJDK vonal lenyomná a "hivatalos" vonalat. Lehetséges, hogy komoly vállalati háttér is odaállna a nyílt verzió mögé (főleg IBM-re gondolok).

Amikor a GNU projekt megpróbálta összehozni a Java osztálykönyvtárát évekkel ezelőtt (Classpath), akkor nagyon jó munkát végeztek, de sok éves hátrányuk volt a Sun mögött. Jelen helyzetben viszont a fizetős Oracle verzió és a szabad verzió egy szintről indulna.

Ti mit gondoltok erről?

Az "OpenJDK vonal lenyomná a "hivatalos" vonalat" úgy érted, hogy a Java elveszíti a hordozhatóságát, és két nem teljesen kompatibilis, két irányba fejlődő részre fog szakadni?

Lehet, hogy ebből lesz vita de szerintem a platformnak jelenleg is a hordozhatóság az egyik fő ütőkártyája. Inkompatibilis Java verziók ezen sokat ronthatnak.

Én nagyon nem örülnék neki, ha 3 féle JVM implementációt kéne telepítenem, és minden alkalmazáshoz külön beállítani hogy azt melyikkel futtassam.

Szóval vagy tökéletes egyetértésben bővítgetik a fejlesztők az OpenJDK-t és az Oracle (Sun)JDK-t meg a többi JDK-t továbbra is, vagy szomorú leszek. :(

Nyilván én sem örülnék két inkompatibilis implementációnak. De szerintem az Oracle bizony ezt kockáztatná meg, ha meglépné hogy a saját platformját vagy annak egy részét fizetőssé tenné. De nem biztos, hogy ez lenne belőle, ezért is hoztam fel a GNU-s példát. A Classpath fejlesztőinek a célja egy teljes JRE implementáció létrehozása volt, de a több éves hátrány miatt ez nem sikerülhetett neki, viszont elég messzire eljutottak. Most viszont az OpenJDK formájában már van korszerű alap a jövőbeni fejlesztésékhez, függetlenül attól, hogy mit csinál az Oracle. Tehát akár még a két egymással kompatibilis, csak technológiai háttérben különböző ág sem elképzelhetetlen.

Viszont én is inkább bízok abban, hogy az OpenJDK eltántorítja az Oracle-t minden ilyen lépéstől.

Hah! Dehogynem!

Pl. mindkettő megvalósítja a szabványt, és emellett bővíti is két különböző irányba. Láttam már ilyet.

Amikor dolgozol vele, akkor meg nem figyelmeztet, ha nem szabványos részét használod, és nem ajánlja fel helyette a szabványos megoldást, hogy inkább azt használd.

Ha sok a bővítés, a fejlesztők egy idő után nem képesek a szabványos részt elkülöníteni a nem szabványostól, így elkezdenek nem hordozható kódot fejleszteni.

Vagy itt a szabvány a bővítést is tiltja? Azaz nemcsak megköveteli bizonyos elemek meglétét, hanem tiltja azon túli extra dolgok implementálását is?

szerk: Gondolom nem, mert akkor az új java verziók nem is szabványosak... Vagy mindig átírták hozzájuk a szabványt? Azaz pl. amikor bevették a generics-et az 1.5-ben, új szabványt írtak? (Persze a további bővítés tiltásával!)
Ekkor meg úgy alakulhat ki inkompatibilitás, hogy kétfelé ágaztatják magát a szabványt is, és lesz JavaX meg JavaY szabvány. :)

Szerintem meg az inkompatibilis bővítések - a gyakorlati életben általában - megszüntetik a hordozhatóságot. Akkor is ha van egy központi szabványos mag, amit az összes implementáció ismer.

Ugyanaz bekövetkezhet mint most pl. az összes többi programnyelvvel/környezettel:
ha hordozható kódot akarsz írni, az komoly intellektuális erőfeszítésbe kerül, mert szét kell tudnod válogatni az adott általad használt implementáció jellegzetességeit a szabványtól.

A nyelv halála lenne a nem szabványos bővítés. De azt már szerencsére nem lehetne java-nak nevezni, a licence feltételek miatt.
Pont ezzel szokták megtörni egyébként a jó kezdeményezéseket: valamit nem implementálok, plusz beleteszek olyat ami viszont plusz. A microsoft is ezzel próbálkozott anno.
Vagy pl. ezért nem lehet alkalmazásszerverek között kódot hordozni. Nagyon könnyen becsúszik valami nem szabványos dolog.

Hogyne lehetne. Altalaban a szabvanyok nem 100%-ig specifikusak (hiszen az maga a kod), az implementaciok pedig nem tokeletesek. Erre a legszebb pelda a C++ forditok helyzete, de a Microsoft CSC es a Mono kulonbozo viselkedese is mokas (Java compilereket sajnos nem ismerek belulrol), pedig a szabvanyt asszem mindketto megvalositja.

----------------------
while (!sleep) sheep++;

a c++ szabványt kb. egyetlen fordító sem valósítja meg teljesen.

a java-nál az a helyzet, hogy a sun hosszú időn keresztül azt csinálta, hogy előbb elkészült a referencia implementáció, és csak akkor lett végleges a szabvány (ez sokaknak fájdalmas is volt), amikor gyakorlatilag volt a szabványnak megfelelő java release is már. ennek persze az egyik következménye, hogy nem nagyon tud más vendor labdába rúgni mellette, hiszen akkor kezdhetik a saját verziójukat véglegesre gyúrni, amikor a suné már ki is jött.

( profeta | 2010. 04. 11., v – 14:38 )

Nem az a baj, hogy ki megy el, és ki marad. (bár a nyelv atyját marketing okok miatt is érdemes lett volna megtartani ...)
A baj ott van, hogy a java azért (is) tudott elterjedni, mert a sun nagyon komolyan vigyázott rá, hogy minden platformon állítgatás nélkül _pontosan_ ugyanúgy működjön, nem engedtek különböző változatokat megjelenni, és a specifikációt összegányolni. (lásd a microsoft elleni pert, vagy a gyakorlatilag bukott ME verziókat)
Mindig is rühelltem az olyan api-kat mint az SWT (annak ellenére hogy használható), mert a natív részek miatt minden platformon más bugjai vannak.
A másik dolog, a stabilitás és a rengeteg kész szabványos api. Sajnos amit az oracle-től eddig láttam java ügyben, az siralmas volt. Összevásároltak mindent ami ígéretesnek tűnt, aztán ment a kukába.
A blogokat olvasva pedig kiderül, hogy nem egyedül JG mondott fel a java csapatból.
A közösségi forkokkal az a baj, hogy ha nincs mögöttük egy tőkeerős, egységes koncepcióval rendelkező, erőskezű vezetés (a linux kernel is ilyen), akkor nem tudnak fejlődni, vagy elaprózódnak.
Most itt lenne a nagy lehetőség, hogy a java-t egy kvázi független szervezet kivegye az oracle kezéből, de nem hiszem hogy meg fog történni, pedig igény volna rá. Nagyon sokan alapoznak a java-ra, olyanok is, akik baromira nem szeretnének az oracle-től függeni.
A legszomorúbb az egészben, hogy olyan, hasonlóan fejlett multiplatformos alternatíva, amire a nyakamat rá merném tenni, nincs. Az utcában sem.
Azért talán a java 7 még a jelenlegi tervek szerint elkészül, és sok évig használható lesz. A modularitással nagyon jó irányba indultak el.

Azt emberrel történő interakció (GUI) mondjuk nyugodtan lehet eltérő platformonként, mert az ember ehhez elég rugalmas, hogy kezelni tudja.

Folyamatosan vannak is ebbe az irányba lépések (pl. natív GUI look&feel), ez azonban meglehetősen komplikált, ezért szerintem elfogadható kompromisszum volt idáig, hogy inkább az egységességre helyezték a hangsúlyt.

Mélyebb rétegekben viszont nem értem mi hátránya lehet az egységességnek? Vagy mi előnye annak, ha a Java programok alapértelmezetten eltérően viselkednének platformonként?

Ha valaki operációs rendszer, vagy hardware specifikus dolgokat akar használni, megteheti így is, de szerintem nem baj ha nem ez az alapértelmezett viselkedés.

( current88 | 2010. 04. 11., v – 19:32 )

Én nem tudom az Oracle mi a francot csinál, vagy csak finnyások a volt sun-os alkalmazottak, de szerintem ha jó munkát végeznek, akkor senkit sem érdekel mennyire finnyás, mennyire nagyképű, ha hasznot termel, akkor jó.

gondolom (csak tippelek), hogy a sunnál nagyobb volt a szabadság, a lazaság, arra koncentrálhattak jobban, amit szerettek. aminek meg volt az az ára, hogy nem ment olyan jól a sun szekere. Az oracle meg gondolom formalizáltabban, projektekben, dokumentációban, stb. gondolkodik, ettől a programozók egy része falramászik. meg a nem programozók egy része is, pl. én:)