tifyty

pure Java, what else ?

Kirügyeznek a lombok

Annotációt írni elég egyszerű. Utána azt futási időben használni reflection-nel lehet, és szintén nem tartozik az ördöngösség kategóriájába. Persze mindenkinek más a bonyolult: amihez értek az már nem is bonyolult. Ugye?

Érdekelt az is, hogy hogyan lehet az annotációkat fordítási időben feldolgozni. Ha már írtam teljes interpretereket, fordítót, akkor ezt is meg kell, hogy értsem. Meg is értettem, de be kell vallanom őszintén, hogy annyi időt nem tudtam rá szentelni, hogy ki is próbáljam. [2014-03-21 UPDATE: azóta két olyan OS projektet is készítettem, ami használja ezt az API-t. https://github.com/verhas/fluflu és https://github.com/verhas/scriapt ] Nem is akartam, nem érzem olyan fontosnak a mostani és a várható feladataimban. Ennek ellenére jó tudni, hogy mi, hogyan tudna működni, vagy mi, hogyan működik. Tudom ajánlani a témában a ezt a cikket.

Röviden arról van szó, hogy lehet olyan Java kódot írni, amit a javac fordítási időben, mikor a szintaxis fát már elkészítette meghív, és amelyik kód hozzá fér a felépített fához. Pontosabban olvasni tudja a felépített fát, és ebben az annotációkat és ennek alapján lehet generálni riportokat (pl. Sonar), újabb osztályokat stb. De írni nem “lehet” a szintaxis fát, nincs rá API, amelyik megengedné, hogy menet közben módosítsunk a kódon.

És akkor egyszer csak látom, hogy kirügyeznek a lombok project.

Mi a lombok projekt?

A lombok projekt olyan annotációkat kezel fordítási időben, amelyekkel nagyon sok mechanikusan leírható kódot meg lehet spórolni. Ilyenek például a delegátorok, a setterek, getterek, log változók inicializálása. Persze ezeket le lehet generáltatni a kódba, például Eclipse-szel, de ez rontja a kód olvashatóságát, és karbantarthatóságát. Aránylag egyszerű szabály: több karakter, több lehetséges bug. Személy szerint egyébként is fázom az olyan megoldásoktól, amikor egy fájlon belül van generált és manuális kód. Még azt sem szeretem, ha egy könyvtárban vannak generált, és manuálisan szerkesztett fájlok. Ebből a szempontból például a maven gyönyörűen elválasztja a kettőt: minden ami generált megy a target könyvtárba.

Persze az olvashatóság csak akkor jobb, ha tudjuk, hogy az annotációk mit jelentenek. A lombok által nyújtott kiegészítésekben ezt a megértési szintet elég hamar el lehet érni. Nézzünk egy egyszerű osztályt:

package com.verhas.lombokTest;

import lombok.Getter;
import lombok.Setter;
import lombok.extern.java.Log;

@Log
public class Person {

	@Getter
	@Setter
	private String name;
	@Getter
	@Setter
	private int age;

	public boolean isRetired() {
		log.fine("age of ther person '" + name + "' is " + age);
		return age > 65;
	}

}

Azt gondolom, hogy nem kell magyarázni, hogy az annotációk mit jelentenek. A legszebb a dologban, hogy nem csak a parancssori java fordítóba lehet bekonfiguálni, de egyszerűen egy dependency taggal a maven projekt fájlba is be lehet venni, és Eclipse-be is könnyen bekonfigurálható. Így már a kód hegesztése közben is működnek a piros, sárga aláhúzások, és a kód completion is. Maga az install csak annyiból áll, hogy letöltöd a lombok.jar-t, és kiadsz egy

$ java -jar lombok.jar

parancsot. Elindul a program, feldob egy Swinges ablakot, kiválasztod, hogy melyik Eclipse installációk alá tegye fel magát (nekem volt épp kettő is, sima meg egy STS) és be is rakja magát. Ha pedig megkérdezed ezen a felületen, hogy mit is fog csinálni, akkor röviden és érthetően elmondja, hogy nem setup.exe registry varázslat ami folyik (nekem Mac-en érdekes is lenne), hanem melyik fájlt hova másolja, melyik fájlba mit ír bele. Ha pedig van némi ismereted a Javac compiler hook-okról, akkor nem is tűnik érthetetlen boszorkánykodásnak.

Ha a fenti kódot lombok nélkül akarjuk, akkor a következőt kell írnunk:

package com.verhas.noLombok;

import java.util.logging.Logger;


public class Person {

	private static Logger log = Logger.getLogger(Person.class.getName());
	private String name;
	private int age;

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public int getAge() {
		return age;
	}

	public void setAge(int age) {
		this.age = age;
	}

	public boolean isRetired() {
		log.fine("age of ther person '" + name + "' is " + age);
		return age > 65;
	}

}

Szerintem átláthatóbb, és rövidebb a kód az annotációval. Azzal az állításommal, hogy átláthatóbb lehet vitatkozni. Azt, hogy rövidebb okos embernek eszébe sem jut vitatni.

De van ennél sokkal durvább dolog is, amit tud a lombok. Nézzük meg például ezt a kis kódot:

package com.verhas.lombokTest;

import lombok.experimental.ExtensionMethod;

import org.junit.Test;

@ExtensionMethod(Extensions.class)
public class ExtensionTest {
	@Test
	public void testExtensions() {
		String s = null;
		System.out.println(s.or("hello"));
	}
}

Mit fog kiírni? Virít róla a Null Pointer Exception (közkeletű nevén NPE, ami egyesek szerint a no problem exception rövidítése). És nem! A lombokkal, ha az Extension osztály a következő:

package com.verhas.lombokTest;

public class Extensions {
	public static <T> T or(T obj, T ifNull) {
		return obj != null ? obj : ifNull;
	}
}

A fenti programunk a hello stringet fogja kiírni? Hogy mi van?

Csak az van, hogy a lombok feldolgozza az Extensions osztályt és látja, hogy van benne egy olyan statikus metódus, amelyik alkalmazható String-re is, és lám pont akarunk is alkalmazni egy ilyen metódust egy String típusú változóra. Nosza, fogja a lombok, és lecseréli egy statikus hívásra, aminek az első paramétere maga a string. Hogy a String osztály final? Nem is írja át, nem is származtat le belőle, csak úgy néz ki. Figyelem! Ez egy fontos mondat: Nem az, csak úgy néz ki. Hogy jön ez össze a hápogással, a duck type irányvonallal?

Szóval itt van a megváltás. Vagy nem? Nem kell áttérni Scala-ra, hogy

final HashMap<String,Integer> x = new HashMap<String,Integer>();

helyett

val x = new HashMap<String,Integer>();

írhassunk. Ezt is tudja a lombok.

Mi a bajom a lombokkal?

Csak az, hogy nem szabványos. Csak az, hogy tönkreteheti a Java nyelvet. Kikerült a szellem a palackból, és mint az élet minden területén, kiereszteni könnyebb a szellemet, mint utána visszazárni. Persze lehet szeretni az ifriteket. Ízlés kérdése. Eddig azt lehetett mondani, hogy a Java nyelvben minden az, aminek látszik. Nem lehetett nyelvi elemeket létrehozni olyan szabadon, mint pl. groovy-ban, de a duck type elv működött. Mostantól, ha elszabadul a pokol…

Nézzük először azt, hogy nem szabványos.

Olyan API-t használ… Bocsánat. Éppen ez az, hogy nem API. Olyan metódushívásokat használ, amelyek nem API-k, nem garantáltak. A fordítási folyamat során visszanyúl a kódba és módosítja a fordító által legenerált, és a lombok számára csak olvasásra felkínált absztrakt szintakszis fát (abstract syntax tree = AST). A nyulat szeretjük, a visszanyúl viszont dögöljön meg. De él és virul és működik. Meddig?

A lombok nem futási idejű függőség, a generált csomagba (pl. WAR) nem kell, hogy a lombok.jar bekerüljön. Mivel a JVM és a byte kód szabvány, és azt végül a java compiler generálja a módosított AST alapján, az futni fog minden szabványos JVM-en. Emiatt nem kell aggódnunk. A lombok legyen ott a fejlesztő gépén (kivéve Dénest, aki ma is vi-t használ Java fejlesztésre, bár lehet, hogy már áttért emacs-ra) és legyen ott a build szerveren. Ugyan a lombok nem definiált hívásokat használ, de működik.

És működni fog egy java security update után is? Nem fog megváltozni az a hívási struktúra abban a fordítóban? Erre nincs garancia. És melyik fordítóval fog működni? Egy másik, teljesen szabványos java fordítóval? A stackoverflow oldalon gyönyörűen le van írva (az egyik lombok lead developer írta idén (2011) májusban):


A lombok belső API-t használ […]. Ugyanakkor, mivel a lombok csak a fordítási időben van jelen, ezért félrevezető az az állítás, hogy csak a sun VM-en futnak a programok. Csak az ecj vagy a sun javac fordítóval fordul. Ugyanakkor az elérhető VM-ek döntő többsége, ha egyáltalán szállítanak saját fordítót, ezen kettő közül valamelyiket használja. Például az Apple VM a szabvány javac fordítóval jön ki és így a lombok ragyogóan működik mac-en. Ugyanez igaz a soylatte VM-re.

Míg javac-cal kapcsolatban szorosan követnünk kell a frissítéseket, mert nagyon sok munka folyik ott most is, addig csupán egy apró módosítást kellett tennünk az Eclipse sok verziója alatt. Így, bár belső API-t használunk ezek relatíve elég stabilak.

Mi lesz akkor, ha alaposan átszabják a javac belső API-t? Mi lesz, ha a lombok projekt nem követi, mert mondjuk elfogy a pénzük? Hány dollár/euró a projektünk üzleti értéke, és mekkora a lombok? Rábíznánk magunkat egy 1 dolláros Ltd supportjára és arra, hogy a projektünk addig él, és a kódunk addig karbantartható, ameddig az él? (Nem tudom maga a lombok projekt mennyire stabil, ezek elvi kérdések.)

Persze vannak menekülő utak. A projekt része a delombok, amelyik legenerálja a lombok nélküli forráskódot, és onnan kezdve megy a projekt tovább lombok nélkül. Szóval feltételesen fogadjuk el, hogy használhatjuk a lombok-ot, nagy rizikót nem jelent a nem támogatott api használata, de hát legyen.

A másik dolog a szellem kiengedése a palackból. Ami a lombokkal elkezdődik az átalakítja a Java-t. Ez a nyelv már nem Java. Ez a nyelv már olyan nyelvi elemeket tartalmazhat, amit bármelyik fejlesztő maga kitalálhat. Nincs egy szigorú szabványosítási folyamat. Pár év múlva eléd tolnak egy kódot, amit a java fordító lefordít, hogy javítsd ki, hiszen Java programozó vagy, és fogalmad sem lesz, hogy mit csinál a kód, és hogyan kellene kijavítani, mert a fordítás során az AST-be belenyúlkál James Plaster félszenior, félisten Java fejlesztő által kitalált überfasza lombok klón, és onnan kezdve minden másképp volt. Az int lehet Integer, a Long viszont lehet long, és még az sem biztos, hogy egy foo.callMe() NPE-t dob ha foo történetesen null.

Majd lehet magyarázni, hogy Java fejlesztő vagy, de lombok vagy “gyokerek”, vagy “torzsek” kiegészítést nem ismered. Már a keretrendszereket sem lehet mindet ismerni, de ami ez után jön… Én nem akarok Java kódot duplán debuggolni: egyszer megnézni, hogy milyen byte kód generálódott, és egyszer, hogy az miért nem működik.

Igazából már a groovy-val elkezdődött, hiszen a Groovy deklaráltan odaadja az AST-t, hogy nyúlj bele. De talán a közösség kidobja magából az elvetemült AST masszírozó kiterjesztéseket. Talán a Java közösség eléggé felnőtt, és a Java maga eléggé fegyelmezettségre nevel.

Izgalmas ez a szakma!

Megjegyzések:

Ismereteim szerint a legutolsó Apple VM az 1.6 volt. Az 1.7-et már az ORACLE állítja elő. Pont mint a Windows esetén, mégis mekkora sírás volt, hogy megszűnik a Java OSX-ra. No mindegy. A másik, hogy az AspectJ is hasonló dolgokat csinál, mint a lombok, DE NEM nyúl bele az AST-be, hanem csak a legenerált byte kódba. Namármost lehet, hogy ez sokkal gusztustalanabb, viszont a bytekód az szabványos. Ha bele lehetne (bocs: szabadna) nyúlni az AST-be, akkor az AspectJ-nek is abba kellene belenyúlnia, mert ott (lenne) a helye az ilyesminek.

Mindezek ellenére azért a jövő héten megnézzük, hogy hogyan lehet lombokkal mixin-t készíteni.

14 responses to “Kirügyeznek a lombok

  1. Gábor Lipták november 21, 2012 10:45 de.

    Egy apróság a final HashMap<String,Integer> x = new HashMap<String,Integer>(); kapcsán:

    Guavával ez ennyi: HashMap<String,Integer> x = Maps.newHashMap();

    I love guava 🙂

  2. andropov november 21, 2012 12:21 du.

    Szerintem az AspectJ és a Lombok azért is működik másképp, mert más a célterületük. A Lombok egy kódolási kényelmet adó tool, míg az AspectJ inkább egy-egy sor beszúrását biztosítja – akár csak jar szintjén meglevő cuccokba (legalábbis én erre használtam). Mindezt úgy, hogy az Eclipse-n kívül is megy.

    A tool fejlesztő szemszögéből: Amikor az IDE-n belül vagy, akkor választhatsz, hogy AST-t manipulálsz, vagy bytekódot. Itt még könnyebb is az AST-t használni, mert az Eclipse biztosít egyszerűen használható API-kat erre. Viszont az Eclipse-n kívüli világban az AST eléggé felejetős, a bytekód pedig könnyen elérhető, hisz az kell a futtatáshoz. Az AST manipulációhoz kell a forrás is, ami nem mindig elérhető, illetve a bytekód huszárkodást jóval gyorsabbra is meg lehet írni.

  3. Ivan Ketler november 21, 2012 2:38 du.

    Annak idején a Java kifejlesztése során nagy hangsúlyt kapott, hogy a lehető legtöbb elkövethető hiba már fordítási időben kiderüljön. Az annotáció határeset, a getter/setter tán rövidebb kódot ad de olvashatóbbat semmiképp, és az IDE részéről is kéne hozzá támogatás (outline-ba bekerüljön vagy ne; ha a meghívás helyén keresem a deklaráció helyét akkor odavigyen /pontosan hova is, az annotációra?/, hasonlók). A getter meg a setter eleve kicsit OO-ellenes ízt kaphat, és sokan a gondos tervezés helyett inkább ezeket használják rosszul, szóval nem vagyok abban biztos hogy ilyen formában szükség lenne rá (pl. egy adatobjektum esetén a setName(last, middle, first) az üzleti logika szempontjából védhető, külön a setLastName, setFirstName, setMiddleName már nem igazán). De ez egy külön vita tárgya.

    Az eredeti koncepció ellenére, amikor a kódban mindenféle vezérlő stringeket helyezünk el majd ezek vezérlik a futást és az üzleti logikát, az már szerintem erősen kerülendő, bármilyen könnyű is automatikusan generálni ilyeneket, a property change és a property listener is szerintem eléggé nehézzé tudja tenni a hibakeresést, forráskód olvasással sokszor nem is lehet megtalálni a hibát csak debuggerrel. Szóval már ez is eléggé bonyolítja az életet.

    Ez a legújabb agymenés, ahol egy tök máshol elhelyezett annotáció megváltoztathatja bizonyos objektumok viselkedését, és ahol rejtett paraméterek bukkanhatnak fel, mindez úgy hogy a debugger nem is igazán esélyes rá hogy megtalálja a tényleges forrást hiszen az ő belső adatstruktúráit nem hülyítjük meg csak a fordítóét, hát ez engem eléggé lelomboz. Talán tényleg itt az ideje, hogy inkább kecskepásztor legyek, ott legalább a határidők is más értelmezést nyernének.

    Márpedig a nagyobb programok esetén( x) programozó összesen (y) emberévet fordít a fejlesztésre, majd (z<<x) programozó (t » y) emberéven keresztül „méjnteneli” és továbbfejleszti a kódot. Ha az eredeti csapat (x-z) programozója ilyen, kevéssé karbantartható trükköket alkalmaz, akkor (t>>y) könnyen igazzá válhat, az pedig pénzben is kifejezhető komoly veszteséget fog eredményezni.

    Másként megfogalmazva:

    Az ipari alkalmazások esetén a fejlesztési és utána a karbantartási periódus emberévekben kifejezve nagyjából ugyanannyi; sok programozó fejleszt egy-két évig, majd kevés programozó karbantart sok évig. Ha a nehezebb javíthatóság miatt a kevés programozó nem elég, és kevés+valamennyi kell, akkor a valamennyi programozó bére tiszta veszteség, ami megtakarítható lett volna azzal, hogy a fejlesztésnél karbantartható kódot ír a sok programozó (s ez ráadásul nem is kerül extra időbe, csak némi odafigyelésbe).

  4. tamasrev november 24, 2012 8:00 du.

    Lőjetek le, de nekem tetszik ez a nem-az-fut-ami-oda-van-írva dolog. Legalábbis tudok egy szcenáriót, amire nagyon jó (csak nem biztos, hogy pont lombokkal kell megvalósítani) :

    Többször láttam már, hogy inline-olással akarnak optimalizálni. Pl nem getterek és setterek vannak, hanem publikus fieldek, amiket employee.name = “bela” szintaxissal lehet röcögtetni. Ehelyett a spagettibiztos módszer helyett sokkal jobb lenne ilyeneket látni, hogy:
    @InlinePublicAcces private String name;
    @InlineMethod doReoccurringStuff() { /* only 2 lines */ }

    Lehet persze vitatkozni/méregetni, hogy mennyit gyorsítanak ezek a megspórolt stack műveletek, főleg hogy a jit is optimalizál (gondolom, nem sokat). De én már azzal is boldog lennék, hogy ha Fejlesztő Ferenc elkezd egy marhagyors irc-klienst írni, akkor a kód szétbaszása helyett okos annotációkat írna. (És ha 2 évvel később rájon, hogyan kell tényleg optimalizálni, akkor csak fogja és kitölrni az összes @Inline-t)

    • v november 24, 2012 8:38 du.

      Ha már így direkt módon kérted, hogy lőjenek le, akkor megteszem:

      “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil” Knuth, Donald (December 1974). “Structured Programming with go to Statements”. ACM Journal Computing Surveys 6 (4): 268.

      Ha többször láttad már, hogy inlineolással akarnak optimalizálni, abból nem azt a következtetést kell levonni, hogy akkor arra szükség van, és segíteni kellene valahogy jobban. Ha nem akarod látni, akkor csukd be a szemed (pl. mert bugfixing közben nincs idő refaktorálni, erről is lesz hamarosan egy post decemberben), vagy faktoráljad re. Mondjuk úgy, hogy megszünteted az inline-olást. Miért?

      Két oka van:

      1. A kódod minimális mértékben lesz lassabb. Nagyon fontos, hogy a kód jól olvasható, és ezáltal jól karbantartható legyen. Ez még akkor is igaz, ha emiatt lassabban fut. Például ha van egy web site-od, amelyik 1mp alatt válaszol, akkor érdemes-e összekuszálni a kódot, hogy 0.9mp alatt válaszoljon? Cserébe egy év múlva, amikor például tovább akarod fejleszteni kétszer annyiba kerül, mert a kód nem szép. A legtöbb optimalizált kód nem szép, és ezért csak akkor optimalizálunk ha tényleg kell, és csak azokat a kódrészeket, amelyek a mérések szerint lényeges gyorsulást hozhatnak.

      2. A kódod olyan minimális mértékben lesz csak lassabb konkrétan az inlineolás esetén, hogy nem lesz lassabb. Pont az inline egy olyan dolog, amit (nem ellenőriztem, de a dokumentációk szerint) a JIT nagyon is optimalizál. A JIT optimalizálásáról, és néhány érdekes dologról (messze nem teljeskörűen) volt egy cikk.

      Sokszor az optimalizált kód lassabb, mint a szép kód. Mert a jit jól optimalizál.

      Tehát Fejlesztő Ferenc elkezd egy marhagyors irc klienst, és beveti az összes olyan trükköt, amit még az 1980-as években C programozás során tanult. Odafigyel arra, hogy i++ helyett ++i legyen, és ehhez hasonló trükkök. És az eredmény valószínűleg egy karbantarthatatlan, feltehetően bugos, és lassú irc kliens lesz, ami valószínűleg funkcionalitásában sem lesz olyan jó, mint egy mirc, egyszerűen, mert nincs mögötte UX szakértő. Fejlesztő Ferenc boldog lesz a kóddal, de csak ő fogja használni, és nem érti, hogy a világ miért nem lelkes, és miért nem használja.

      • tamasrev november 24, 2012 9:52 du.

        Szerintem félreérted, amit írtam. Vagy pont, hogy szó szerint értetted a metaforákat. Fejlesztő Ferenc itten nem irc klienst ír, hanem valamilyen más szoftvert, ami helyett irc-t használok.

        Kicsit konkretizálom: képzelj el mondjuk egy hirtelen nagyra nőtt céget, ami infrastruktúrát biztosít az össze-vissza ircelésre. Írnak irc klienst brózerbe, telefonba, mikrosütőbe. És írnak irc szervert is, aminek nagyon gyorsnak (és skálázhatónak) kell lennie. Igen, a metaforikus szoftver hirtelen szerver lett, csak hogy ne beszéljünk többet UI-ról. Ennél a cégnél Fejlesztő Ferenc vezető fejlesztő, mert ő írta azt a hihhetetlenül gyors szervert, ezért kinevezték vezetőnek.

        És ezen a ponton jön képbe Kommentelő Károly (én). Károlyunk egy karbantarthatatlan, bugos, és néhol feleslegesen lassú irc szervert lát. Választhat, hogy szóvá teszi a problémákat (és ha ezt túl nyíltan teszi, akkor új állás után néz), vagy szépen csöndben marad és reszelgeti tovább azt, ami van. No, ezt konkrétan már láttam megtörténni.

        Ez az a pont, ahol jó lenne a @Inline: Odamegy Kommentelő Károly a főnökéhez, Fejlesztő Ferenchez, hogy “Feri, találtam itt egy jó kis libet, amivel lassulás nélkül refaktorálhatók a publikus fieldek szabványos javabean propertykké”. Feri nézegeti, és tényleg. Innentől kezdve Károly szép lassan refaktorálhat, olvashatóvá teheti a kódot. Majd 1-2 év múlva eljön az igazság pillanata: “Feri, kitöröltem a @Inline-okat, maradtak a sima getterek/setterek, és csak két ezreléket lassult az egész.”

        Szerintem ez nagy előrelépés lenne.

        • Gábor Garami (@hron84) június 29, 2013 1:35 du.

          Tulsagosasn optimista vagy. A legtobb esetben sok evente egyszer van lehetoseged optimalizalni, az optimalizalas ugyanis nem termel penzt, kovetkezeskeppen nem is szokott ra lehetoseg adodni. Hogy miert mondom ezt?

          Ferencunk azert alkotott olyan kodot, amilyet, mert a hataridok epp elegsegesek voltak arra, hogy a kod es a tesztesetek (ha vannak) megszulessenek, de az optimalizaciora mar nem maradt ido. Egy ilyen kornyezetben szerintem netto hulyeseg elvarni, hogy most majd nekiallunk, es szep csendben reszelgetunk.

          Es ezen vajmi kevesse fognak segiteni a lombok, meg a fak vagy akarmilyen mas termeszetkozeli libek. Mert nincs meg a megfelelo kultura a csapatban, azt pedig egy java lib sem tud magaval hozni a projektbe.

      • tamasrev november 24, 2012 11:49 du.

        Hadd magyarázzam meg ugyanazt kicsit rövidebben: Az tök jó, hogy most mindkettőnk szerint nettó marhaság az inlineolós optimalizálás, főleg javaban.

        Nade, hogyan győzöd meg erről a főnöködet, ha ő máshogy gondolja – noch dazu odafigyel, hogy a kód ugyanolyan spagetti maradjon? Ha, teszem azt, van egy soktízezer soros kódbázis, amit 1-2 napig refaktorolgathatsz, mire elkezdhetnéd összehasonlítani a régi kódot és az újat? Na, itt segítenének ezek a @Inline-ok, mert a főnök szemében elfogadhatóvá teszik az encapsulation-t.

      • Mefi november 25, 2012 3:40 de.

        Az elso pontot kellene megertenie minden megrendelo oldali szereplonek.

  5. R november 27, 2012 11:42 du.

    Mondjuk nekem a legérdekesebb kérdés talán amit Péter is kiemel vajon mekkora támogatottságot élvez maga lombok én is használtam, és használom is viszont.. Az más kérdés hogy vajon mikor mondja majd az Oracle azt h ugyanmár jobban szemmel tartom ezeket a dolgokat mert igencsak elkanyarodtunk a java alap filozofiától (engem nem lepne meg).
    Viszont Péter ajánlanám figyelmedbe a Lambdaj projektet nagyon érdekes szívesen olvasnék róla véleményt tőled. Egy igencsak hiányzó részt foltoz be a javában amit talán időszerű lenne már megvalósítani ténylegesen a JDK részeként..

  6. tamasrev január 15, 2013 11:32 du.

    Totál mellékszál, csak most futottam bele a duck typing definíciójába: http://en.wikipedia.org/wiki/Duck_typing

    Azaz, ha úgy néz ki, mint egy kacsa, úgy jár, mint egy kacsa, és úgy is hápog, mint egy kacsa, akkor valószínűleg kacsa lesz az. És ha nem, hát az se baj, éljen az implicit, osztályhierarchia nélkül is működő polimorfizmus!

    Amúgy innen jutottam a duck typinghoz:
    http://simpleprogrammer.com/2013/01/13/so-you-think-you-can-polymorph/

  7. Gyorgy Abraham július 3, 2013 9:05 du.

    Van egy nagyon fontos dolog: a lombok a general contractnak megfelelő equals() és hashCode() implementációt szállit, sok fejlesztővel ellentétben… 🙂

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: