Tag Archives: java

  • Lambda funkce v Javě 8 – prokletí nebo vykoupení?

    Já osobně jsem se poprvé s lambda funkcemi setkal ještě za svých studentských časů na mé Ostravské alma mater, kdy jsem byl hluboce zanořen do samostudia jazyka Scala. Tehda to bylo taky poprvé, co jsem se začal seznamovat se základními koncepty funkcionálního programování, které mi přišly zcela mind-blowing. Krom toho taky mnoho featur Scaly byly mind-blowing samy o sobě a už toho času jsem měl takový ten pocit, který mi říkal: “Jó, tak takhle bude možná Java vypadat až za 3 roky”. Trošku jsem se přecijenom zmýlil, protože Java 8 přišla až za 4 roky a některé další featury ze Scaly se plánují snad až do Javy 10. Dnes už je to 2 roky, co máme lambdy a Stream API k dispozici a přesto (k mému údivu) narážím až na překvapivě velké množství Javistů, kteří je buď nepoužívají, anebo ani neví, co to vlastně je. Ba co více, nedávno jsem narazil i na kolegy, kteří mi vyloženě tvrdili, že lambdy jsou hnus a že nechápou, jak do Javy mohl někdo něco takového dát. Právě tento názor, který mě upřímně docela dostává, mě motivoval napsat tento článek, ve kterém se vám pokusím zběžně ukázat, proč jsou lambdy boží a proč zřejmě ten nejpodstatnější důvod, proč si zvolit jakýkoliv jiný jazyk než Javu, je již od verze 8 nenávratně passé.

    Celý článek

  • Co je RxJava a k čemu je vlastně dobrá

    Už před pár měsíci jsem si tento nadpis přidal mezi rozpracované koncepty tohoto blogu, ale záhy jsem si uvědomil, že na tuto otázku ještě nedokážu zcela uspokojivě odpovědět. Vzpomínám si, když jsem na Devoxxu v Krakově viděl RxJavu poprvé, krom toho, že mi nebylo úplně jasné, jak to přesně funguje, jsem si kladl jednu a tu samou otázku: “K čemu je to sakra dobré?”. Není to to samé, co už umí Streamy v Javě 8? Čas i zkušenosti pokročily a tak nastala chvíle podělit se o to, jak vidím RxJavu já.

    Celý článek

  • Java EE, to je Java Ne-e. –Pavel K.

    Celý článek

  • Java tip: For není fór a split není řiť

    For()

    Už jste se někdy přistihli při psaní tohoto cyklu?

    for(int i = 1; i < something; i++) {
    //Do something
}

    Pak vězte, že v (dle mého názoru) opravdu velkém počtu případů je to znamení, že je něco špatně. Buď máte špatný design, anebo to jde celé udělat jinak a mnohem lépe. Ne vždy se tomu člověk vyhne, ale čím častěji, tím líp.

    Split()

    Další věcí je metoda String.split(). Použili jsme ji asi všichni, ale přiznejte se, kolik z vás ji opakovaně používá na parsování Stringu ve smyslu, že pak použijete pouze něco z výsledné množiny? Na to mám pouze jednu odpověď: Naučte se regulární výrazy a vyzkoušejte Rojo 🙂.

    NějakýInterfaceImpl

    Původně jsem se domníval, že je to spíše věc ojedinělá, ale nedávno jsem v praxi narazil již na druhého člověka, který, jak se zdá, má až chorobnou touhu vytvářet interfacy 🙂 . Jedná se především o DAO třídy. Moje představa o použití interfacu z hlediska designu je taková:

    1. Očekává se, že něco může mít vícero implementací
    2. Tyto implementace jsou volány “přes jediné API” / nebo též “stejným způsobem”

    Pokud si tyto dvě otázky položím v případě DAO tříd, tak jsem názoru, že každé DAO má mít vždy pouze jednu jedinou implementaci, a i kdybych připustil, že by někdo někdy chtěl mít pro 1 DAO implementací více, tím hůře si dokážu představit, proč by je chtěl volat stejným způsobem? 🙂 S tímto i úzce souvisí názvosloví končící na Impl, kde vám hned vysvětlím, proč ho nemám rád. Samotná neurčitost názvu na mě působí dojmem, že implementace daného interfacu je skutečně pouze jedna, čímž smysl interfacu samotného vlastně popírá, jinak by se přeci jmenovala nějak smysluplně, nebo ne? Např. měl-li bych interface Service, čekal bych implementace jako FileService, NetworkService, ale rozhodně ne ServiceImpl 🙂 . Z tohoto mi plynou hned dvě ponaučení:

    1. Přemýšlejte nad názvoslovím, protože již ono samotné může odhalit chybu ve vašem myšlení
    2. Nedržte se striktně naučených pouček o čistém kódu, ale běžte více do hloubky daného problému a, zkrátka, přemýšlejte 🙂 . Aneb jak již jednou někdo řekl: “Všechny generalizace jsou mylné, včetně této”.

    PS: Další důvod proč nedělat interfacy tam, kde jsou zjevně zbytečné, je ten, že když si na některou metodu takového objektu v Eclipsu se stiskem CTRL kliknu, nedostanu se přímo do kódu, ale do interfacu samotného, což je strašně otravné 🙂 .

  • Rojo benchmark s JMH

    Zrovna nám nedávno vyšlo Rojo ve verzi 1.0.3 a já jsem si říkal, jak je na tom tato knihovna s výkonem. Rozhodl jsem se ji tedy trochu otestovat a proměřit pomocí JMH a i přesto, že se mi způsob vytváření nového benchmarku přes maven archetyp příliš nepozdával, tak se mi to nakonec rozjet podařilo 🙂 .

    Celý článek

  • Když už jsem ho nemohl donutit, aby mi dopsal ten interface, tak jsem si k němu alespoň přisedl. –Pavel K.

    Celý článek

  • Nejšikovnější způsob, jak v Javě inicializovat pole

    Věděli jste, že se to dá udělat i takto?

    Object[] objects = {1, "2", 3.5f};
String[] strings = {"one", "two", "three"};
int[] ints = {1, 2, 3};

    Já teda ne … až dodnes :-). Ale krom toho: pole nepoužívejte – jen když musíte ;-).

  • Rojo: Java knihovna pro mapování regulárních výrazů na POJO objekty

    Možná si někteří z vás ještě vzpomenou, jak jsem kdysi psal o “mikro-knihovně” Re. Čas i myšlenky trochu uzrály, a tak tu máme nástupce, který jde ještě o krok dál. Mám zároveň radost, protože je to má první knihovna, která je dostupná  i přímo z centrálního Maven repozitáře! Pojďme mrknout na to, co umí …

    Celý článek

  • Argument pro management je jasný … 8 je větší jak 7. –Pavel K.

    Celý článek

  • Nejlepší třída je, když je všechno zakomentované, a je tam jen jediná metoda, která nic nedělá. –Jakub K.

    Celý článek