"The Ceylon Project - a Java nyelv következő generációja"

Java

Gavin King - Red Hat/Hibernate/Seam híresség - nemrég lebbentette fel a fátylat arról a csúcstitkos projektjéről, amelyen az elmúlt több mint két évben dolgozott. Ez nem más, mint egy új nyelv és SDK, amelyet azzal a céllal tervezett, hogy leváltsa a Java-t enterprise környezetben. A projekt különösebb csinnadratta nélkül bukkant elő rejtekéből a QCon Beijing rendezvény egyik vitaindító előadásában "The Ceylon Project - the next generation of Java language?" címmel. [...] Az előadás diái szerint a Ceylon Project célja létrehozni egy programozási nyelvet és SDK-t az üzleti számítástechnikai világ számára, szem előtt tartva a Java erősségeit és gyengeségeit egyaránt.

Részletek, diák, egyebek itt.

( ijanos | 2011. 04. 13., sze – 14:53 )

Aranyos meg örülök hogy szivárognak a funkcionális programozásból a dolgok a mainstreambe de a JVMre ott van már a Scala (meghát a Clojure) most a redhat is belefog és lefejleszt egy új fordítót, elkészít hozzá egy újabb STLt... kicsit pazarlásnak érzem.

En meg annak, ha az annotaciokat es az XML-programozast vegre ki lehetne dobni a kukaba, mert lenne egy alap JVM nyelv, ami az ezek altal implementalt dolgokat (lasd Spring) elegansan megvalositana. Scala vagy Clojure vagy akarmi, innentol mar tulajdonkeppen mindegy... ez egy legalabb akkora ugras lenne, mint volt anno a GC.

A kerdeses library modositasai miat a futo kod es a verzio koveto rendszerben levo kod mar nem lesz azonos. Amint egy nem trivalis, azaz enterprise meretu project Productionbe kerul. Ez mar egy eleg jelentos hatrany tud lenni, mivel a stack trace alapjan meg nehezebb lesz megtalalni a hibat, mivel a kerdeses reszek az eredeti forrasban mar nem fognak letezni.

Ezen az alapon ne használják springet, meg hibernate-et se enterspájz méretű projectben, pláne nehogy productionbe kerüljön. tele leszel olyan cglib-es proxy-kkal meg tsaival, hogy öröm nézni a többszáz elemű stacktrace-t, pláne ha hatszor újradobott exception-ről van szó.

Nem a lombok lesz egy ekkora projektben a jelentős hátrány, hanem a hájbernáte.

Amúgy meg a VCS-el mi a gond???

A VCS sel semmi, mindosze a Lombok modositasa utan a futo kod es a VCSben levo mar nem lesz azonos igy a debugolas jelentos mertekben megnehezul.

A Hibernate es a Spring eseteben nem a tenyleges foraskodot irodik at.

Ha mar minden aron a getter/setter boilerplatetol akarunk megszbadulni, akkor mar inkabb aspektekkel. Spring Roo-ba van ilyen kepeseg, bar nem trivialis projektek eseten szinte megkerdojelezheto a hasznalhatosaga.

A Hiberante eseten kulonben sem az altala legyartott CGLIBes proxyik leszenek a fo gond. Komeneted alapjan valoszinuleg volt hozza szerencsed.

No, egyrészt még nem debugoltam lombok-os osztályt, így nem tudom 100%-osan védeni, bár nem egy kispiskóta eszközről van szó, ha megoldották, hogy az eclipse-be épkézláb módon integrálódjon (outline, assist ...), akkor elég nagy bizonyossággal merem azt gondolni, hogy a nem generált metódusok kivételével ugyanúgy debugolható. A generált metódusokkal kapcsolatban meg annyit, hogy még nem futottam bele olyan hibába, ahol az ilyen egyszerű getter/setter lett volna a büdös, szóval... eddigi tapasztalásom alapján merném használni a jelenlegi projektjeinkben is. Persze alapfeltétel, hogy mindenki tudja használni, mert egyébként nem ér semmit.

A hibernate/spring páros esetében ellenben volt már rá példa, hogy debugolás során egy bean-nek még az id-je sem került elő egyáltalán. Én ezen a ponton már más haját téptem, de gondolom ismerős a szitu. A proxykkal kapcsolatban az a meglátásom, hogy amíg 1-2 van két réteg közt, addig még valamennyire elviselhető, de ha mindenféle AOP-áldással, JTA-val megtűzdelve próbálsz egy kódot vizsgálni, egyre inkább a nullához konvergál a support hatékonysága.

Mindezt csak azért mondom, mert szerintem nem a lombok fogja derékba törni egy nagyobb projekt támogatását. Vannak erre a feladatra sokkal komolyabb és elterjedtebb aspiránsok.

A fo gond nem is az extra getter/setter, hanem a megvaltozott sor szamok. Ez a stack tracek olvashatosagat jelentosen ronthatja. Bar ha ezeken sporolunk, akkor lesz ott mas magic, ami ennel sokkal rosszabb.

JTA+JPA(Hibernate)+Spring, na attol garantalt az elme baj. Foleg, ha meg nincs "szabad" strukturalis kontroll a DB felet es van backward compatibility kovetelmeny. Ha ezt meg megtuzdeljuk halado Springes featurokkel, pl autowire, massziv konfiguracio kategoriajaba tartozo annotacio hegyekkel, akkor aztan kesz az elmebaj.

Minnel tobb a magic annal gyorsabb (kezdetben) implementalni, de annal nehezebb lesz kibogozni, hogy mi ment tonkre.

Nalunk szerencsere idejeben megszbadultunk a Hibernatetol, helyet van "aranyos" iBatis. AOP csak kulon engedelyel, ha nincs mas megoldas. Springes annotaciok a SpringMVC-n kivul minden mashonnet kitiltva.

Ezzel a kijelentéssel azért óvatosabban bánnék. Nálunk pl rengeteg dolog "tökéletesen működik" hibernate alapon. Ezt a kliensek "tudják", a kommunikáció ebből a szempontból tökéletesen működik. Az viszont már csak belső igazság, hogy rengeteget szopunk miatta/vele. Nem akarnám ezt extrapolálni a világmindenségre, de pár helyről hallottam már vissza hasonló dolgokat, ami miatt értetlenül állok azelőtt a jelenség előtt, hogy mindenki lelkes ovulációban kitörve meg van veszve, hogy mennyire jó és tudományos, hogy a projektjeikben hibernate-alapú a perzisztencia réteg.

Továbbra is csak ismételni tudom azt a kicsit módosított Murphy-tételt, miszerint a hibernate-el elég jól orvosolhatók azok a problémák, amik hibernate használata nélkül fel sem merültek volna.

Mondjuk úgy, volt már 1-2 kisebb projekt, ahol használtam a hibernate-et, de ugye mindig a nagyobbaknál derül ki, hogy ami a kisebbben jónak tűnik, a nagyban már bukós...

Most egy logikai DB interface-ünk van, és e mögé pakoltuk be a szimpla SQL query-ket. Olyan, mint egy EJB, csak az enterprise nélkül :D

Mondjuk ezt annyira imádom. A hibernate tipikusan az, amit az ember a büdös életbe nem fog érdemben ismerni, amíg egy nagyobb projekt keretein belül nem használja legalább 1-2 évig. Egy kisebb projektnél lehet sokféle fals benyomása, de így gyakorlatilag eltanácsoltad a használatától mindazokat, akik eddig bepróbálkoztak vele valaha is.

Nem ismered, ne használd. Használat nélkül meg lehet ismerni? Nem ;] köszi

Én csak azt mondtam, hogy ha zéró szakértelemmel (és ezt megint nem arra értem, hogy 1 ember vagy x ember egy csapatból, hanem mindenki) rendelkeznek hibernate témakörben, akkor az egy relatíve jó döntés volt, hogy nem vezették be.

Ha a projektben van annyi tartalék idő, hogy szabadon lehet ismerkedni egy ismeretlen (=zéró szakértelem) technológiával és kitapasztalni a problémákat és az azokra adaható válaszokat, akkor hajrá, de nekem az a tapasztalatom, hogy egy projektben ritkán szoktak betervezni ilyen időket.

Az meg egy teljesen más helyzet, amikor van olyan ember is, aki azért ismerős a hibernate háza táján. Ekkor meg ugye az a felvetésem nem állja meg a helyét, hogy zéró szakértelem.

Nem a zero szakertelemmel volt a gond, hanem a DB struktura elkepsztoen pocsek allapotaval. Ami nem volt orvosolhato a backward compatbility kovetelmenyek es a customer oldali DBA ellenallasa miat. Igy pl egyetlen kereses, kb 70MB memoriat evet meg es lassu volt. Figyelembe veve, hogy szerverenkent 1500 felhasznalo van es 2.5GB heap, igy napi 90 ujarainditas volt app sezerverenkent.

Az iBatis alap megoldas mar memoria szempontbol elfogadhato volt, de 2-5 masodperces valaszido nem (DB processzor terheleserol nem is beszelve). Igy vegul keszult hozza egy kulon specializalt alkalmazas, ami 3-4 nagysagrendet ravert a DB alapu megoldasra.

A Hiberante addig mukodik, mig kozzel teljes kontrolod van a DB struktura felett es nincsen, vagy legalabbis minimalis, backward compatbility kovetelemeny. A teljes kontrol miat feltetelezheto, hogy rendesen normalizalt az adatbazis. Illetve a DB tartalom modosito muveletek realative magas aranya (nalunk 10% alatt volt).

A masik fo gond, hogy a Hiberante altal kiadott SQL utasitasok gyakorlatilag optimalizalhatatlanok. A legtobb amit tehetsz, hogy tele pakolod a DB-t indexekkel. Amik egy ido utan negativan foglyak befolyasolni a teljesitmenyt. Mind memoria mind a sok index frissitgetese.

Épp ez a linkelt példa lényege, hogy lightweight, jdbc használat könnyítő libként is lehet használni a Hibernatet...
Azok a "mágikus" funkciói a hibernate-nek, mint a menedzselt entitások, a dinamikus proxyk, first level cache, HQL, mind külön-külön elhagyhatók, ha nem akarja az ember használni őket.
De ha tudsz jobbat ne tartsd magadban.

Hogy jobb-e az jo kerdes, rendszerint iBatis/myBatis vagy Spring JDBCTemplatje sokat tud egyszerusiteni a native JDBC-n.

A linkelt pelda egyebkent elege csuny megvalositas szempontjabol. String konkatenacioval lehetoleg ne rakosgassunk ossze Java kodbol SQL queryiket. Sot lehetoleg ne is taroljuk oket Java kodba. Unit tesz eseten szvsz megbocsajthato.

Egesz jo, a 2.3.4 verzio van hasznaltuk. A 3as migracio egyenlore kerdeses, a formatum valtozasok miat.

Keszult hozza egy Java Interface alapu, Convention Over Configuration elvekre epulo absztrakcios reteg. Ez lehetove tette, hogy tenylegesen csak az Interface-t es a mapping XML-t kelljen megirni (az esetek nagy reszeben). A konkret DAO implementacio dinamikus proxyikal jott letre deploy idoben. Igy minden konkret implementacio megorokolte a mar tobbszorosen kiprobalt callbackeket. Illetve az osszes DB-bol jovo entitas immutablekent lett definialva. Mivel a DB muveleteink 95% read only.

DBA reszerol jelentosen kisebb volt az ellenallas, mivel az SQLek optimializalhatobba valtak. Bar sajnos meg mindig tulsagosan szeretik a tarolt eljarasokat a Prepared Statementekkel szemben.

A deklarativ tranzakcio kezeles es iBatis integracio Springen keresztul tortent.

Ez oke, csak ne keverjuk az annotation processing-el a Lombok-ot. A Lomboknak em sok koze van hozza, eltekintve hogy az annotation processing infrastrukturat hasznalja arra, hogy beepuljon, de attol meg az annotation processor-ok altalaban uj forrast gyartanak (amit a kov korben a Javac beolvas es lefordit), szemben a Lombok-al, ami meg bytekodot pakol a forditott class-ba.

Ami a sorszamokat illetve line order-t illeti, nem kellene neki feltetlenul rossznak lennie, ha csak setter/getter bytekod generalasrol beszelunk... eltekintve persze a getter/setter sorszamaitol, amire viszont valljuk be, sok szukseg nincs, tekintve hogy egy utasitasos metodusokrol beszelunk... a metodus neve tehat megmondja mit is csinal, es nem lehet tulsokfelekeppen megirni egy gettert vagy egy settert.

( NagyZ v | 2011. 04. 13., sze – 15:02 )

hulyeseg, plane, h JVM felett fut.

( _Franko_ v | 2011. 04. 13., sze – 16:26 )

Ha nem lesz hozzá zero work Java2Ceylon konvertáló, akkor kb. halott ügy... sok cégnél még most állnak át 1.4-es Java-ra, mert még ez is sok munkával jár, nemhogy egy pármillió soros kódbázist átrittyentenek egy ismeretlen platformra.

Ezen túl alapvetően két dolgot tudok felhozni a cucc ellen:
- Enterprise világban kb. az utolsó dolgok között vannak fontossági sorrendben azok a nyelvi elemek, amelyekről szó van, ugyanakkor szó nincs azokról a dolgokról, amitől egy nyelv Enterprise lesz: a high availability és a reliability megoldásokat pedig nem látom a Ceylon mögött - pont az a RoR és a Scala problémája is.
- Ha nem Enterprise célra lesz, arra most is dögivel vannak jobbnál jobb megoldások, azokkal meg nem fogja tudni felvenni a versenyt.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( uid_228 | 2011. 04. 13., sze – 17:40 )

Már megint egy újabb XML-to-exception konverter? :)

--
Web 2.0: you make the content, they make the money.

( imp | 2011. 04. 13., sze – 18:32 )

Gavin King? Van szakálla? Nincs? Kthxbai, end of story.

( prygme | 2011. 04. 13., sze – 20:23 )

újabb vaporware Kínából. úgy látszik minden évtizedben elő kell állniuk valami ilyesmivel. csakis MING/OSt kell majd alatta használni, úgy az igazi:D

lesznek impozáns bemutatók, ígéretes roadmap és minden külsőség, csak éppen használható kód nem lesz soha.

( Csab | 2011. 04. 13., sze – 23:34 )

Minek kellett ehhez új nyelv?

A munkahelyemen azt a nyelvet kedvelik, amelyiket egyetemen oktatnak. A C# is hihetetlenül hasonlít a C++ java keverékre, gondolom az MS nem akart befürdeni. Emellett volt pénze oktatásra és reklámra...

Nekem ettől a nyelvtől Pascal reloaded érzésem van. Úgy látszik egyesek nem tudták megérteni, hogy a Pascal szerencsére kihalt.

( sz332 v | 2011. 04. 14., cs – 05:32 )

Megnéztétek egyébként a slide-okat?

- does not support method overloading??? WTF???
- egy csomó hagyományos keyword-tól megszabadultunk. Ez tényleg jó?
- := ??? visszatér a pascal? de jó, írjunk egy kicsit többet...
- nincs konstruktor, hanem az osztály kódjába írjuk bele a hozzá tartozó kódot. Igényes.
- a html-es példa még esetleg elég használhatónak tűnik így első látásra, de kb. ennyi

összefoglalva: egy újabb "zseniális" nyelv, aminek ebben az állapotban nem jósolok túl nagy jövőt, megérdemelten.

"a html-es példa még esetleg elég használhatónak tűnik így első látásra, de kb. ennyi"

Az groovy-ban is hasonló, és azzal minden java-s kód használható, sőt a java érvényes groovy kód. Abban van konstruktor, named parameter, method overloading, megmaradtak a keywordök is, de a típusok opcionálisan elhagyhatók (def). Satöbbi. Plusz grails.

( Cobalt | 2011. 04. 14., cs – 08:27 )

Ugytunik, hogy minden "nagy nevu" programozonak elobb utobb akkorara no az egoja, hogy nem birja ki, hogy ujra feltalalja a kalapacsot. Egyesek megelegednek egy frameworkel, de nemelyik nem birja ki es ir egy "uj nyelvet".

( Hevi v | 2011. 04. 15., p – 04:22 )

Támadnak a Cylonok!

Őőő... Ceylonok!