Az Apache Software Foundation távozott a JCP Executive Committee-ből

Java

Az Apache Software Foundation (ASF) megunta, hogy nem tudott dűlőre jutni az Oracle-lel (és korábban a Sun Microsystems-szel) a Java-val kapcsolatban, ezért tegnap beváltotta korábbi ígértét és kilépett a Java közösségi folyamatokat igazgató vezetőségi bizottságból, a Java Community Process (JCP) Executive Committee-ből.

Az ASF tíz éven keresztül volt tagja az JCP Executive Committee-nek, négy alkalommal nyerte el az év JPC tagja címet. Az ASF komolyan kiveszi a részét a Java ige terjesztéséből, hiszen otthont ad egyebek mellett az Apache Tomcat-nek, Ant-nek, Xerces-nek, Geronimo-nak, Velocity-nek és még vagy 100 fontos Java komponensnek. Emellett az ASF számtalan Java Specification Request (JSR) kidolgozója és több JCP technikai csoport tagja, hozzájárulója volt.

De miért lépett ki az ASF a JCP EC-ből?

Az ASF problémája nem új keletű. Az alapítvány egy, a Sun Microsystems-nek 2007. áprilisában küldött nyílt leveléből kiderül, hogy probléma évek óta húzódik. A probléma gyökere, hogy az ASF 2006 óta próbált beszerezni a Sun Microsystems-től egy _számára elfogadható_ licenccel rendelkező "Java Compatibility Kit"-et. Ez a tesztcsomag (Test|Technology Compatibility Kit - TCK) lett volna szükséges ahhoz, hogy az Apache Harmony projekt bizonyíthassa, kompatibilis a Java SE specifikációval és, hogy megkaphassa az erről szóló igazolást. Az ASF szerint a Sun által akkor kínált JCK licenc számára elfogadhatatlan volt, a szoftvereinek felhasználóira nézve pedig hátrányos, a felhasználási területre (Field of Use) vonatkozó, korlátozó kitételeket tartalmazott.

Az ASF szerint a JCK licence annak ellenére tartalmazott elfogadhatatlan korlátozásokat, hogy a Sun-t kötötte az általa aláírt Java Specification Participation Agreement (JSPA), amely egyébként a JCP működésének alapszabályait tartalmazza.

Az Oracle szerepe érdekes a történetben. Amikor 2007-ben a JCP tagok azt kérték, hogy a tesztcsomag legyen elérhető olyan licenc alatt, amely mentes a "Field of Use" korlátozásoktól, az Oracle részéről Don Deutsch támogatta a kérést.

Miután az Oracle felvásárolta a Sun-t, a ASF hiába fordult az Oracle-höz azzal a kéréssel, hogy a TCK-hoz számára megfelelő licenc alatt hozzájuthasson. Ekkor az ASF azzal vádolta meg az Oracle-t, hogy az nem tesz eleget a Java Specification Participation Agreement-ben (JSPA) lefektetett kötelezettségeinek, mert csak olyan licenc alatt kínálja a TCK-t, amely nem kompatibilis a nyílt forrású és szabad szoftveres licencekkel.

Éppen ezért az ASF arra kérte a JCP Executive Committee tagokat, hogy fejezzék ki támogatásukat azzal, hogy a Java SE 7 (és 8) specifikációinak megszavazásnál mellette szavaznak az Oracle ellenében. Az ASF kilátásba helyezte a JCP Executive Committee-ből való távozását, ha nem kap a tagoktól megfelelő támogatást a szavazáson.

Az Oracle azt válaszolta, ahogy az ASF vizsgálja felül álláspontját. Az Oracle szerint ő korrekt, a JSPA-ban lefektetett kötelezettségeinek megfelelő licenc alatt kínálja a TCK-t. Az Oracle a támogatását kérte a szavazáson, hogy haladhasson a Java fejlesztése.

A szavazás nemrég lezajlott. A EC tagok közül 12 - három ellenében - elfogadta a Java SE 7 és 8 specifikációit. Az Apache-on kívül csak a Google és Tim Peierls, mint önálló tag szavazott a specifikációk ellen. Ugyan az IBM, a SAP AG, az Eclipse, a Red Hat, a Credit Suisse és Wener Kell, mint önálló tag támogatták a specifikációkat technikai szempontból, de hangsúlyozták megjegyzéseikben, hogy elégedetlenek a TCK licencelésével. Az Oracle, HP, Ericsson, Fujitsu, VMWare és az Intel megjegyzések nélkül megszavazták a specifikációkat.

Tegnap az Apache Software Foundation ismét bejelentést tett. Ahogy írta, a fenti szavazás volt az utolsó esély arra, hogy a JCP EC bebizonyítsa, szándékában áll megvédeni JCP-t, mint nyílt specifikációs folyamatot. Mivel ez nem történt meg, az ASF levonta a következtetést: a Java Community Process nem nyílt specifikációs folyamat. A Java specifikációk proprietry technológiák, amelyet a "spec lead"-től közvetlenül kell licencelni olyan feltételek mellett, amelyet a "spec lead" megszab. Az ASF szerint az Oracle továbbra is komoly mértékben beavatkozik az "ökorendszer" kormányzásába. Az ASF szerint a EC vonakodik, vagy nem tud hatalmával élni a JCP kormányzási folyamatában.

Ezért az Apache Software Foundation azonnali hatállyal tegnap kilépett a JCP EC-ből.

( trey | 2010. 12. 10., p – 10:21 )

Kimaradt, hogy Tim Peierls, a JCP EC két független Java szakértőjének egyike is távozott.

--
trey @ gépház

( Exit | 2010. 12. 10., p – 10:51 )

Ez elég elszomorító hír. Az ASF egy csomó jó dolgot hozott a Java számára. Bár a projekteket továbbra is támogatja az ASF, de nem tartom elképzelhetetlennek, hogy egy saját platform fejlesztésébe kezdenek (esetleg a Google-val közösen). Aztán megint mehet a szabadalom háború.

A cikkben nem szerepel, de a Red Hat is megszavazta (IBM-hez, Eclipse-hez hasonló módon) a specifikációkat.

( anr | 2010. 12. 10., p – 10:59 )

nincs annal undoritobb dolog a vilagban, mint amikor jogaszkodassa fajul valami ertekes kezdemenyezes.
SHakespeare-nek nagyon igaza volt:
'The first thing we do, let's kill all the lawyers'.

--
Live free, or I f'ing kill you.

>>Meg a politikusokat, meg a bankarokat, meg mindenkit, aki nem mi vagyunk,
>>es akirol nem tudjuk, valojaban mit csinal.
Már ameddig hagyják nekik. :-)
Wikileaks: We open governments. (Hamarosan bankokat is)
Jöttek is halálos fenyegetések és gyorsan kiderült, hogy a szent nyugat semmiben sem jobb a szidott Iránnál. A wikileaks mégis működik ma is. :-D

Ha Assange az Egyesült Államokból tette volna ugyanezt, már régen "bebetonozta" volna őt a maffia valamelyik folyó fenekén. Azt gondolom te is olvastad, hogyha kiadnák Amerikának akár halálra is ítélhetnék. Nincs itt akkor különbség, csak jobbak az amcsi országimázs marketingesek. :-D
(Természetesen van egy csipet irónia ebben ahogy az előző hsz-ban is. Azért van -> :-D jel a végén. Csak ilyenkor eszembe jut mekkora felzúdulás volt a bölcs és felvilágosult liberális nyugati megmondóemberek részéről, amikor az iráni ajatollah távollétében halálra ítélte Salman Rushdie-t a Sátáni versek miatt. Most pedig Amerikából küldenek halálos fenyegetéseket Assange-nak a politika világából)

( lovas | 2010. 12. 10., p – 11:05 )

Egyre több szakember távozik.

Stephen Colebourne apró megjegyzése az egésszel kapcsolatban: "After all, there is no point helping to write specifications that you aren't allowed to implement". Kicsit hasonló a szituáció, mint ami az OOo-val történt. Oracle-féle open source = mindenki dolgozhat nekik.

Nemrég Bob Lee (jsr330, guice) nyilatkozott még egy hasonlóan érdekeset, amikor visszautasította a részvételt a java7 és 8 jsr-jeinek kidolgozásában, hogyaszongya amikor az Ora megváltoztatta a licenszelési feltételeket, azzal mindenkinek lehetőséget adott arra, hogy visszavonja a hozzájárulásait, így gyakorlatilag specifikációk tömkelegét kukázni lehetne.

( bervi | 2010. 12. 10., p – 11:57 )

"Ugyan az IBM, a SAP AG, az Eclipse, a Red Hat, a Credit Suisse és Wener Kell, mint önálló tag támogatták a specifikációkat technikai szempontból, de hangsúlyozták megjegyzéseikben, hogy elégedetlenek a TCK licencelésével."

ez kérem a szánalom csúcsa. az ilyen benyögések, hogy valaki "elégedetlen" valamivel, aztán ugyanúgy megszavazza, hát az az igazán nagy lófasz. kb. az itthoni politikusaink jutnak eszembe róla. hányadék. kb. annyi hasznuk van, mint az ms-féle pittyegéseknek, hogy "nem örülnek" ennek meg annak. na, hát ez is annyit ért.

Ha most elkezdenek "szarakodni", akkor a j7 végleg megdöglik, vagy az ora beszünteti a jcp-t. Érdekes egyébként h ki hogyan szavazott:

Tim Peierls: nem, annyira hülyék vagytok bazeg, szarjatok sünt
Google: nem, mert nem értünk egyet a licenszeléssel
SAP: igen, de... szegény ASF (farkat behúz, hátha Larry nem haragszik annyira)
EF: igen, mert nyomjuk az osgi-szerű stuffot, de... legközelebb nemmel szavazunk ha nem történik semmi, bibibí
IBM: igen, de... mi csak a technikai részére szavazunk igennel
Werner Keil: igen, de... szomorú vagyok
Red Hat: igen, mert siessünk-fussunk, de... nem fogják szeretni, és amúgy is ejnyebejnye h "valaki" pénzt akar csinálni a Java-ból
Credit Suisse: igen, de... ez így szerintünk is gáz, mert süllyed a hajó, Larry légyszi-légyszi
Hewlett-Packard, Ericsson, Fujitsu, VMWare, Intel: igen, "leszarom"

"Ha most elkezdenek "szarakodni", akkor a j7 végleg megdöglik, vagy az ora beszünteti a jcp-t."

na és, most jobb? gyönyörű széthúzás van, meg mindenki bólogat az oracle-nek, akármit csinál is. a j7 amúgy is döglődik már egy ideje... ha mindenki ellene szavaz, akkor az oracle vagy enyhített volna a licenszelésen, vagy magára marad. bármelyik jön is össze, meg lehetett volna szorongatni. ehelyett ez a farokbehúzás van, ahogy mondtad.

nem tartom kizártnak, hogy larry nem győz majd pislogni pár év múlva, amikor mindenki áttér .net-re. már jelenleg sem a technikai felsőbbrendűség tartja életben a javát, hanem a számbeli fölény szakemberek tekintetében. de ez sem fog örökké tartani, főleg ilyen attitűd mellett.

Így mindenki tudja a pecsenyéjét sütögetni JSR-eken belül. A hbernate/jboss/red6 is marha csalódott lett volna korábban, ha a JPA-t nem ők kakkantják. Látszik, hogy egy ótvar haszonleső banda a nagy részük. Ha az ora kiveszi a jcp-t a képből, akkor már semmi nem fogja megkülönböztetni a java-t a .net-től, céges roadmap alapján haladna előre, aztán mindenki azt kiabál a partvonalról, amit akar.

A .net-es migrációt annyira nem tartom valószínűnek, meg azt sem, hogy rövid időn belül mindenki világgá futna. Inkább az alternatív technológiák erősödése, mint pl. node.js a nosql trend hátán

ugyan már :) ezek az "alternatív technológiák" fasorban sincsenek a javához meg .nethez képest. a többiek meg sütögethetik a pecsenyéjüket, de ebből így hosszú távú fejlődés nem lesz. az oracle szintén nem úgy tűnik, mintha oly nagyon rá akarna menni a dologra, inkább amolyan fejős tehénnek tekintik láthatólag.

Némi lebecsülést vélek felfedezni a hozzászólásod első részében :) Szerintem pont ezek az újabb technológiák azok, amikkel nagyon meglephetik főként a java-t.
Az oracle meg nekem úgy tűnik, szeretne olyan kontrollt a sun technológiái felett, mint ahogy a többi felett is. Fog az fejlődni, csak köszönet nem lesz benne. Majd rákerül az árcédula az enterprise java-ra, mert "enterprise" :)

"Látszik, hogy egy ótvar haszonleső banda a nagy részük."

Mé? Miért rossz az, ha valaki hasznot akar látni a munkájából!? Attól még a közösségnek is jó a JPA, amúgy meg nem muszáj használni.
Én úgy látom, hogy van egy elterjedt tévhit még mindig, hogy az open source szoftvereket főleg lelkesedésből írják az emberek szabadidejükben. Hát ha tényleg így lenne, nagyon nem állnának ilyen jól, meg leginkább sehogyse.

Rosszul értelmezed. Nem a hétköznapi értelemben vett haszonról beszélek, hanem a saját kis mocska iránt van mindegyik leginkább elkötelezve. Itt már szó sincsen semmiféle communityről, max egy olyan érdekközösség, ami kitudja melyik pillanatban hullik darabokra perek mentén.

A java community-re eddig nem volt ennyire jellemző ez a kicsinyesség, mert mindenki megtalálta benne a hasznát középtávon. Mint láthatod a nagyobb technológiai óriások eszközként használják a nagyobb üzleteik bonyolítására, és nem rosszul csavargatták. Erre most agyatlanul felrúgnak mindent, mert magán a technológián kezdenek el vitatkozni/élősködni. Kretének.

Ja mégvalami: egyrészt a java nem FLOSS, épp ez az egyik probléma. Másrészt a FLOSS-szerű óriásprojektek részvevői nem hobbisták, hanem éppen hogy nagyobb cégek, akik tökéletesen tisztában vannak az érdekeikkel, és a saját hasznosságukkal/hasznukkal. Nem mások kedvéért fejlesztenek, de figyelembe szokták venni mások érdekeit egy bizonyos pontig. Jelen helyzetben épp talán az ASF volt az egyetlen, amelyik nem profit alapon áll hozzá a dolgokhoz.

amikor majd a "klasszikus" kozep- es nagyvallalatok is be merik/tudjak/akarjak vallalni (telco szektor, bankok stb.), akkor lehet azt mondani, hogy hoppa, annyi a javanak/c#-nak/cobolnak. azert, mert nehany technologiai l'art pour l'art ceg vegtelen mennyisegu okos emberrel es igazabol kvazi felelosseg nelkul megcsinalja sajat maganak a szuper node.js rendszeret, az jo es szep, de meg nem eleg.

Már csak annyit érdemes észrevenni, hogy a java felhasználási területének csak egy része az, amit emlegetsz, és akkor meg is volnánk. Lassan minden kismacif.sza fejlesztésnél is a java-t veszik elő, ha php-s nincs a közelben. Nem arról beszéltem egyszer sem, hogy ezzel majd aztán jól lealázzák a Larry-éket, hanem arról, hogy esélyt adnak ezzel a szarakodással az ehhez hasonló kezdeményezéseknek.

Mindenhol. Amint valaki enterspájzról beszél és nincs a bekezdésben ott, hogy Java-ban lesz/van, azonnal indul a fikakotró gép és rátolja az összes trollt a topicra.

Illetve egy "épkézláb" vállalati alkalmazás miért nem lehet webes?

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

Muhahahaaa.. En, mint Java fan. Muhahaha... Koszonjuk.

Alapvetoen PHP-val keresem a kenyerem. Java-t ha nem muszaj, inkabb kerulom. Ellenben megvan annak is a helye, mint ahogy a PHP-nek is. A ket halmaznak van ugyan kozos resze, de semmikepp nem reszhalmaza egyik a masiknak. Nem java fansag kerdese ez, hanem csupan annyi, hogy nem pisalok szembe a szellel es nem kell eroltetek egy taknyolt-ganyolt nyelvet mindenhova csak azert, mert azt (is) ismerem es konkretan abbol elek.

----------------
Lvl86 Troll

én úgy gondolom, hogy lehet php-ben normálisan programozni (php 5.3-ra gondolok alapvetően), és szerintem egy középvállalati ügyviteli szoftvert (100-200k sor) meg lehet benne valósítani. Ezt egyébként úgy állítom, hogy még sosem csináltam 20k sornál nagyobb projektet, úgyhogy nyitott vagyok az ellenérvekre.

Lehet, elozo projektem pont egy ilyen PHP-s ugyviteli rendszer volt (vegeredmeny olyan 200-250kloc kozott + kulso vackok, kodoltuk 3-6-n) es vegul is nem lett rossz az eredmeny.

Problema abbol adodik, hogyha nem ragaszkodtak volna a webes felulethez, akkor kb. fele ennyi munkaval es szopassal, rovidebb ido alatt, .NET/WinForms alatt joval kulturaltabban is meg lehetett volna valositani ugyanezt.

Es nem, hiaba vannak a PHP5.3-ban mar nevterek meg LSB meg minden kutyaluka, attol meg a nyelv alapja rohad. A mindenfele szintaktikai ganyolastol eltekintve (illogikus parameter es fuggvenyelnevezesek, stb.) nagyon zavaro tud lenni sok esetben a szigoru tipusossag hianya*, eszkozok gyengesege (normalis refactoring PHP-hez?) es hogy nehez ugy megirni a rendszert, hogy meg veletlenul se tudja egy "utcarol beesett" ember telibeturni a retegezest (gondolok itt a random helyre beirt echo-kra, debugbol belerakott print_r-ekre).

* Akarki, akarmit is mond, egy ideig segit, egy ido utan viszont gatol. Nagyon. Raadasul, ami van, az is szarul van megoldva. Pl. tok jo dolog a type hinting, foleg, mert segiti az IDE-ket is, csak epp null -t nem lehet atadni. Akkor ket opcio van: vagy leszedjuk a type hintinget es elkezdjuk kezzel ellenorizni, vagy nem lesz ellenorzes. Fail.

----------------
Lvl86 Troll

Problema abbol adodik, hogyha nem ragaszkodtak volna a webes felulethez, akkor kb. fele ennyi munkaval es szopassal, rovidebb ido alatt, .NET/WinForms alatt joval kulturaltabban is meg lehetett volna valositani ugyanezt.

ez már egészen más téma (desktop vs web).

A nyelvnek egyébként tényleg vannak szar dolgai (pl. a null-dolog engem is felb*sz néha), de minden más nyelvnek vannak. Java-ban pl. lassú a reflection, ami sokkal nagyobb szopás mint a legtöbb dolog amit a php szemére szoktak vetni.

pont ez az, hogy php-ben is van. Pontosabban kétféleképpen van, az egyik a magas szintű amit tényleg reflectionnek hívnak, meg van az alacsonyszintű ami létezik azóta hogy van php ($fn(), new $class(); stb, ilyesmikre gondolok). A magas szintűt még nem benchmarkoltam, az alacsony szintű viszont gyakorlatilag nem jár teljesítményveszteséggel, és ez a lényeg.

Én szeretem használni a reflectiont php-ben és java-ban is, csak java-ban kicsit mindig összeszorul a gyomrom hogy na most akkor ez hányszor is fog lefutni és mennyire vágja haza a teljesítményt. Persze erre szokás olyanokat mondani, hogy a maintainability-t ne áldozzuk fel a teljesítményért, meg hogy tökmindegy mert az alkalmazás sebességét úgyis az adatbázis sebessége határozza meg, amikben van is igazság, dehát akkoris... na. Érted :)

(Tul) alacsony a szint. Konnyen el lehet benne kezdeni taknyolni-ganyolni valami mukodonek latszo dolgot anelkul, hogy egyebkent a komolyabb dolgokrol mar a leg minimalisabb fogalma sincs az illetonek.

Ahhoz, hogy valaki elkezdjen .NET-ezni vagy Java-zni, ahhoz minimum az OOP-vel baratsagban kell lenni. PHP-hez sajnos sok esetben eleg a CTRL+C,V ismerete.

(Valamelyik heten fogtuk a fejunket, hogy valaki mennyire meg akarta nekunk magyarazni, hogy egy hiba mennyire le van kezelve, csak epp nekunk az jott le ebbol, hogy fogalma sincs, hogy mi az az Exception. Persze, a mi rendszerunk van tulbonyolitva :).

----------------
Lvl86 Troll

"nomeg cérácshoz fizetős ide van csak.
Tudom, van free is"

na most akkor jó lenne eldönteni, nem warezről beszélni hülyeségeket (céges környezetben az marhára életképes modell). de biztos, ami biztos, segítek: tényleg van free.

az már csak mellékes, hogy a vs egyszeri(!) megvásárlása töredéke egy nagy szoftveres projekt esetében az összköltségnek, és persze egy ide-vel nem csak egy projektet lehet fejleszteni... jelenleg 160k a pro verzió, ami egy it cégnél mondjuk a portás vagy a biztonsági őr egyhavi bére kb.

de mondjuk ha egy cégnél az az elv, hogy mindegy, hogy szar, csak free legyen, akkor oda tényleg kár vs-en gondolkozni.

Tudod, elég fura, amikor azt hallom valakitől, hogy azért nem tanul meg C#-ozni, mert csak fizetős IDE-je van, s amikor felvilágosítom, hogy a sharpdevelop eléggé ingyenes, akkor közli, hogy "free? akkor csak szar lehet"...

Én spec teamsystemmel dolgozom, amikor cérácsozni kell, szal értem miről beszélsz :)

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

Nem akarok nagyon huhogni, mert a node.js egyelőre inkább csak megérzés. Akivel eddig beszéltem róla, mind nagyobb érdeklődést mutatott iránta, mint amennyire a php vagy a .net lázba hozta. Amúgy FYI az utóbbi 1 évben rengeteg kódot toltak bele, portoltak "pár" framework-öt, és mondjuk egy php-nak lassan csak annyi előnye van vele szemben, hogy van bőven hozzáértő. Nem mellesleg a V8-at épp most gyorsították egy nagyságrenddel, így a node.js-isten bármikor lealázza a javaistent grizzly-stül ;]

Mondjuk ennek a projektnek sem ártana pár nagyobb pártfogó...

Na mindegy, persze nem kőbevésett igazságot hintek, de majd elválik 1-2 éven belül hova jutnak.

Ja igen a java szent tehene a "szigorú típusosság", ami már első körben beledöglik a kútba az int-Integer problémával, és az enum és generics kezelése végképp a sírba kergeti a nagy szakembert (enum alapú generics-es osztályra írj dinamikus proxy-t ;] garantált foshalom).

Egy SOA rendszer esetében, amikor a kliens a böngésző, lehet kukázni a típusosság előnyeit. A kliens szarik a nagykönyvbeli típusokra, a service szenved a talán sikeres konverzióktól, a perzisztencia réteg meg egyszerűen röhejessé válik a kezelhetetlen generics problémák miatt, és akkor még nem is említettem azt, hogy ott is bőven akadnak adatkonverziós marhaságok, pláne ha valami viccesebb nosql adatbázist nyomnak az ember kezébe.

De papíron jól mutat az, hogy "szigorú típusosság"

Java generics-l nincs tapasztalatom, C#-l van. Ott is lehet cifra dolgokat csinalni, de esszel elve el lehet kerulni egy csomo mindent. Szvsz nem azert vannak a nyelvi elemek, hogy mindenaron hasznalni kell azt, hanem lehetosegek. Kb. a CSS kodolastol a C++ templateig el lehet ezt mondani mindenre.

----------------
Lvl86 Troll

Hagyjuk ezt a marhaságot, nem a típusosság miatt szereti senki sem a javát, legalábbis az egyetem utáni időszakban. Elég sok projektet láttam már, de egyiknek sem az volt a lényege, hogy típusos legyen, hanem hogy meg kellett oldani egy-két konkrét feladatot, és egy rendszert kellett lerakni az asztalra. Erre elég sokminden jó -- mondom ezt úgy h az 1.1 óta java-val foglalkozom.

A java erőssége nem a típusosságban van, hanem azokban a framework-ökben, amiket mindennap használ az ember, és a végletekig leegyszerűsíti a melót ótvarnagy rendszertervvel a hátamon. Ezt egyelőre semmi nem tudja igazán felülmúlni -- egyelőre.

Az, hogy neked nem jön be a JS, egy dolog. Sokan vannak így. Nekem meg nem jön be a php, ruby, meg a tsai, de rég tudhatja mindenki, hogy -- már azon az empirikus alapon, hogy sokan használják -- használhatóak :) Ennek a node.js-nek is bőven vannak gyerekbetegségei, pl hiányzik egy általános perzisztencia-réteg, a magas szintű tranzakciókezelés, meg sok egyéb apróság, ami a java esetében régóta adott. Viszont bőven vannak előnyei a bődületesen nagy neveknek számító servlet container-ekkel, és EE szerverekkel szemben. Nem mondom, hogy az iménti komment szerint egy repülőtéri rendszert, vagy egy ordas bank rendszerét kell akarni megoldani vele, de egyre jobba nhasználható eszköz.
Orbitális tévedés félvállról venni egy olyan alaprendszert, amiről elég sokan csak elismerően tudnak nyilatkozni. Nincsen alma meg körte, csak állástalan informatikus.

( gabrielakos v | 2010. 12. 10., p – 13:55 )

Hosszútávon aggódom. Mert egy darabig még elviszi a lendület ezt a világot, de ha nagyon lekörözik a Java-t a többi technológiák, akkor egy csomó ember és cég lesz bajban.

--
Gábriel Ákos

valahogy úgy is lehet, igen.

http://dotneteers.net/blogs/vbandi/archive/2010/12/06/just-how-producti…

"We also decided not to write any code"

valós alkalmazásnál nyilván nem lehet így, de igenis iszonyat sokat tud segíteni egy jó ide (jó = vs és tsai). és itt most közel sem csak arról van szó, hogy a sys-t kiegészíti System-re.

Sajnos ez nem a platformokat/eszközöket, hanem a fejlesztőket minősíti. A .NET-es srácok ügyesebbek voltak, mint a többi csapat. Semmi olyan nem volt a feladatban, ami megakadályozta volna az iPhone és az Android csapatot abban, hogy hasonló szintű teljesítményt nyújtsanak a saját platformjuk eszközeinek a felhasználásával.

Mondjuk a cikkből nem derül ki, hogy pontosan milyen volt a többi App, mert a WP7 telefon kamerája elég rossz képeket csinált. :)

Egyébként az évek során használtam VS-t, XCode-ot, Netbeanst és Eclipse-t is, és nekem idáig az Eclipse jön be legjobban fejlesztésre. C, C++, Java, Python, PHP mind nagyon jól támogatott benne, és ezek a fő nyelvek amiket használok. Ha C# projektről van szó, akkor persze VS, Objective-C-re pedig sajnos még muszáj XCode-ot használni. (Egyszerűen nem tudok az XCode-dal megbarátkozni, és most nem az IF Builderre gondolok, hanem a kódolás/debuggolás részére, pedig már a shortcutok is át vannak konfigurálva Eclipse kompatibilisre.)

Üdv,
Gergely

Ugyan, hagyd már.

A wiw 2005-ben lépte át az 1m usert, a myspace 2006-ban a 100m-et.

Aztán a wiw ezt az 1m-et se tudta kiszolgálni, a performancia problémákat úgy próbálták kezelni, hogy limitálták az új tagok számát (emlékszel még, hogy mi ment a meghívókért?), az emberek meg úgy, hogy mentek facebook-ra (ami közben lenyomta a myspace-t).

Ennyi, nem kell ebbe a matávot belekeverni.

Mert Jason hozzászólása számomra azt a benyomást keltette, hogy szerinte a facebooknak azért nincsenek performancia problémái az iwiw-vel szemben, mert az php-ban íródott. Hozzászólásomban arra akartam rávilágítani, hogy a facebook egy heterogén platform és a frontendet kiszolgáló php mellett például használnak java-t is egy olyan területen, ahol számít a megbízhatóság és a sebesség is. Valószínűleg azért jó a teljesítményük, mert több vasuk van mint az iwiw-nek és lehet, hogy jobban is értenek ahhoz amit csinálnak (vagy többet költenek rá, pl.: van kapacitásuk saját php2Cpp fordító írására is).

( asola | 2010. 12. 10., p – 21:27 )

Ha az Apache csinál Java szerű platformot, akkor én meg a cégem például az első lehetséges alkalommal elkezdi migrálni a projektjeit.

Valószínűleg szar és költséges munka lesz, de hosszú távon megérné, mert az Oracle-t már jól ismerem és SEMMI DE SEMMI jóra nem számítok tőlük a Java vonatkozásában.

Ha nekem kellett volna választanok, akkor ők lettek volna a legutolsók, akire rábíztam volna a Java-t.