Zobrazují se příspěvky se štítkemJava. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemJava. Zobrazit všechny příspěvky

27. února 2012

Vývoj JCA resource adapteru pro HttpClienta

V poslední době jsem vyvíjel JCA resource adapter a vzhledem k tomu, že není zrovna moc dostupných informací a hlavně zkušeností k dohledání, tak bych rád přidal pár zajímavých odkazů a informací.

Úkol k řešení byl celkem zajímavý - výsledná aplikace běží na Webpshere serveru, kde jsou nastaveny všechny možné pooly a vše je takto řízeno z jednoho místa (to se moc libí administrátorům). Až na jednu věc a tou jsou HTTP spojení spravované knihovnou HttpClient. Ta má vlastní implementaci ThreadSafeClientConnManager a konfiguraci na nastavení connection poolu. Cílem tedy bylo vytvořit resource adapter, který bude instalován a spravován serverem. Ve výsledné podobě vznikla vlastní implementace rozhraní ClientConnectionManager, která komunikovala s resource adaptérem přes JNDI, který spravoval a poskytoval HTTP připojení z pooleru na serveru.

Jak na to? Nejdříve uvedu odkazy na vybrané články o resource adapterech:
Představa, že budu vyvíjet resource adapter oproti ostrému serveru mě na začátku hodně frustrovala, naštěstí existují zajímavé projekty ShrinkWrap a IronJacamar, díky kterým je možné vše testovat pomocí jUnit testů. Zejména projekt IronJacamar je pro vývoj resource adapterů skoro nezbytný - součástí projektu je i command line code generator, pomocí kterého je možné si v interaktivním průvodci navolit základní parametry resource adapteru a následně vygenerovat kostru Java tříd včetně XML konfigurace a testů. Pro úplný začátek úplně super - já jsem nějaký čas s JCA bojoval sám (dokonce jsem začal číst i specifikaci JCA jak jsem byl na tom špatně :) ) a tento nástroj mi hodně pomohl.

Nakonec ještě přikládám dva UML diagramy, které lépe vystihují výslednou implementaci:

Resource adapter architektura


HttpClient architektura

21. února 2011

Je Java produktivní jazyk?

Všechno to začalo zajímavým článkem "Java Kicks Ruby on Rails in the Butt", kde aspoň pro mě se objevila velice zajímavá myšlenka:

The productivity in Java world is a cultural problem, not a technical one.

Na uvedený článek se objevilo spoustu reakcí v Java světě a mě to přinutilo popřemýšlet a napsat pár myšlenek v tomto článku.

Já osobně moc tyto srovnávací články rád nemám, protože mi přijdou skoro vždy jednoúčelové. Cožpak někdo může říci, že Java je produktivnější než Ruby a naopak? Ve spoustě případů ano, ve spoustě případů zase ne.

Nicméně s uvedenou myšlenkou plně souhlasím. Opravdu to asi máme nějak v sobě, že když už ta aplikace bude Javovská, tak vždy bude mít alespoň tři vrstvy, že to musí být robustní, škálovatelné atd. atd. Doufám, že doba, kdy byly mainstream EJB, je již pryč, ale pořád se mi zdá, že není moc velké povědomí o alternativních řešeních jako jsou Grails, Spring ROO, v článku uvedený OpenJava nebo třeba DB forms. Nebo obecně o dostupných knihovnách - takové Jakarta Commons by snad měl znát úplně každý a pokud si někdo uvedené funkce píše sám, tak to fakt nechápu. V minulosti jsem již psal o rychlém rozcestníku na základní knihovny.

Dnes více než v minulosti je nutné se vyznat - nestačí znát jen Java jazyk jako takový, ale je potřeba znát všechny možné knihovny a frameworky, znát přednosti a nevýhody jednotlivých řešení, umět si vhodně vybírat. To samé se dá říci o programovacích jazycích - Java jako základ ano, ale pro určité úlohy je lepší třeba Groovy, jinde Perl apod.
(Pozn.: když se na tyto všechny jazyky koukám z pohledu projektového vedoucího, tak jsem pořád tak nějak k tomu skeptický - čím více bude jazyků potřeba na vývoj, tím horší (= dražší) bude pak údržba. To nepočítám náklady na osvětu a zaškolení týmu.)

Možná je to tím, že jsem na volné noze, kdy efektivita má pro mě přímou úměru k výši výdělku, že se tak o všechny možné knihovny zajímám. Já již asi rychleji psát kód nebudu, ale tím, že ho budu psát méně a více výslednou aplikaci skládat, tak mohu být efektivnější. Také za těch skoro 10 let co programuji již mám slušnou databázi odkazů a hotových řešení, že někdy více kopíruji, než vymýšlím nové věci.

Každopádně i když budu umět perfektně Javu, znát knihovny a celou platformu, tak jsem podle mě někde ve dvou třetinách kvalitního programátora. Když nebudu počítat vlastnosti jako pečlivost, systematičnost, zodpovědný, cílevědomý, které buď prostě máme nebo nemáme, tak je nutně potřeba znát řešenou problematiku, bez toho nemůže být řeč o programátorovi, ale o kodérovi.

16. května 2010

Jaká bude budoucnost Javy? - výsledky

Dnes skončila další anketa a to s těmito výsledky (celkem hlasovalo 77 lidí):

  1. Pozice Javy se moc měnit nebude (50%)
  2. To nejlepší má již Java za sebou (25%)
  3. Javu čekají světlé zítřky (19%)
  4. .Net časem získá převahu (14%)
  5. Budoucnost patří dynamickým jazykům (12%)
  6. Za 10 let si na Javu nikdo ani nevzpomene (6%)

Jako hlavní komentář mi dnes poslouží článek Dagiho Mračna, sluníčko a nebo smrádek a teploučko nad Javou. Sám bych to lépe nenapsal a s jeho názorem souhlasím.

Celkem mě překvapuje, že si tolik lidí myslím, že Java na tom bude pořád stejně. Mě se toto celkem špatně posuzuje, protože se soustředím jen na Javu a nemám moc času sledovat i jiné platformy, ale jeden příklad bych měl. Ve firmě nyní připravujeme novou generaci klienta našich aplikací (nyní jsou klienti programovány v Delphi) a nebylo celkem co řešit - vítězem se stal Silverlight od Microsoftu. Samozřejmě snaha byla o to, aby i klient byl v Jave, když celý server je Javovský, ale Java prostě v této oblasti zcela zaspala a JavaFX ve mě pořád nebudí takovou důvěru, aby jsme se nyní na ní mohli spolehnout na dalších 5, 10 let.

Sice si také nemyslím, že by se pozice Javy v nejbližších letech měla měnit, ale určitě je potřeba inovovat. Na závěr bych použil jeden předvolební slogan "Nezajímá mě zítřek, ale budoucnost". (snad jsem to napsal dobře :-) ).

28. ledna 2010

Inicializace a plnění kolekce na jediném řádku

Při psaní testů (zejména při vytváření testovacích dat) rád používám "zkrácené" zápisy pro inicializaci a plnění kolekcí.

Každého asi napadne použití Arrays.asList metody:


List<String> stooges = Arrays.asList("Larry", "Moe", "Curly");

To je krátké, elegantní, ale s jednou malinkou nevýhodou. Takto se dá vytvořit pouze seznam, ne např. množina (i když samozřejmě není problém vložit kolekci do kolekce a tedy vytvořit množinu ze seznamu).

Já kromě výše uvedeného ještě používám tento zápis (většinou, když potřebuji jednopoložkovou kolekci a není to seznam):

new ArrayList<String>() {{add("Larry");}}

Na první pohled možná trochu magické, ale když se to rozepíše do více řádků, tak je zřejmé, že se využívá inicializačního bloku. Navíc tento zápis se neomezuje jen na kolekce, ale na jakýkoliv objekt.

14. listopadu 2009

Definice rozhraní dohromady se třídami

Nedávno jsem procházel cizí kód a narazil jsem na definici rozhraní dohromady s definicí použitých tříd, viz následující příklad (příklad je uměle vytvořen):


public interface Connector {

Status getStatus();


/**
* Connection status.
*/
public static class Status {
private int code;


/**
* Constructor
*
* @param code Connection status code
*/
public Status(int code) {
this.code = code;
}


public int getCode() {
return this.code;
}
}
}

Mě by tato konstrukce nikdy nenapadla, proto mě to hned praštilo. Čím více jsem ale o tom přemýšlel a rozebíral s autorem, tak jsem vlastně zjišťoval, že moc argumentů, proč by to tak nemělo být, vlastně nemám.

Zde jsou mé dva argumenty, proč se mi to "nezdá":
  • První argument asi moc neobstojí, ale pro mě je celkem důležitý - rozhraní se definují pomocí rozhraní, třídy pomocí tříd. Proč to tedy míchat dohromady? Autor mi na to řekl, že chtěl zdůraznit spojitost mezi rozhraním a použitými třídami. Tomu moc nerozumím, protože všechny třídy použité v rozhraní jsou automaticky součástí API. Možná měl na mysli to, že kdykoliv budu pracovat se třídou Status, tak budu muset používat prefix rozhraní, tedy Connector.Status a tím tedy vždy bude zřejmá příslušnost třídy k danému rozhraní.

  • Všechny mé další výtky směřují na možné úpravy, rozšíření v budoucnu - to je jeden z důležitých aspektů kvalitního API, aby bylo možné zachovat zpětnou kompatibilitu a přitom mít možnost dané API rozšiřovat. Co když budu chtít třídu Status použít v budoucnu i v jiném rozhraní? Co když budu chtít vytvořit třídu StatusExt jako rozšíření třídy Status?

Přijde mi tedy, že kvůli minimální "výhodě" mohu mít v budoucnu problémy.

Spousta lidí má představu, co to asi tak API je, ale už jen pár lidí si dokáže představit, jak je těžké vytvořit kvalitní API. Já sám se v této oblasti hodně učím a to zejména z knížky "Practical API Design" od Jaroslava Tulacha. Ale je hlavně potřeba praxe a mít vůbec možnost taková API navrhovat a rozvíjet, což se ve standardních webových aplikacích moc často neděje.

Proto by mě moc zajímal názor ostatních - máte nějaký další argument na mojí podporu? Nebo se vám zdá, že to ani nemá cenu řešit, a že je vše v pořádku?

28. srpna 2009

Java na Macu - ach jo

Kdykoliv přijedu na Java konferenci (spíše to tedy platí pro zahraničí), tak vidím samé přednášející s Mac notebooky. Člověk z toho nabude dojmu, že s Javou na Mac OS nejsou žádné problémy, že je to zaslíbený operační systém pro vývoj Java aplikací.

Po měsíci programování v Mac OS takový pocit bohužel nemám. Mám (měl jsem) dva základní problémy.

Dělám na velkém projektu (cca 30 tisíc tříd) a nejsem schopen tento projekt se standardní Javou na Macu (poslední dostupná verze je Java for Mac OS X 10.5 Update 4) vůbec zkompilovat kvůli nedostatku paměti. Mac OS je 64 bitový operační systém, Java na Macu také a mých 4GB paměti na to nestačí. Abych mohl zůstat na Macu, tak jsem musel začít používat SoyLatte - BSD Java port na Mac OS. S touto 32 bitovou verzí Javy už s kompilací není problém. Pak jsem ale musel ještě řešit problémy s tím, že na projektu používané JDK 6 má některé knihovny v trochu jiné verzi. Musel jsem do classpath podstrčit ty správné.
Po těchto peripetiích funguji bez problému, možná jsem i trochu získal tím, že náběh aplikace se mi zrychlil přibližně dvojnásobně. HotSwap a JavaRebel fungují bez problémů. Ale 100% náhrada to určitě není, protože SoyLatte některé části klasického JDK nemá, např. podporu Java Web Start.

Druhý problém je s Intellij IDEA. Sem tam (v průměru jednou denně) se mi IDEA z ničeho nic zavřela. To bych ještě přešel, jenže neočekávaným ukončením aplikace se zneplatní veškeré cache, takže pak musím čekát cca 20 minut než se mi celý projekt znovu natáhne a zkompiluje. Nejdříve jsem "nadával" na moje oblíbené IDE, a když už mi to fakt vadilo, tak jsem začal hledat příčinu - a našel. Problém je opět v Javě. Na uvedené stránce je nějaký workaround, který se zdá, že funguje. Nyní tedy čekám na novou verzi Javy pro Mac OS, kde by měla být chyba opravena.

Není to vždy jednoduché, když se člověk chce držet svého oblíbeného IDE a operačního systému ...

2. června 2009

Jaký máte vztah k Java anotacím? - výsledky

Poslední anketa se týkala anotací a dopadla následovně (hlasovalo 125 lidí):

  • Používám, ale jen někde (43%)
  • Mám je rád, používám, kde se dá (38%)
  • Nemám je rád, snažím se jim vyhnout (10%)
  • Nevadí mi (8%)


Já sám jsem hlasoval pro "Používám, ale jen někde" a nejsem moc zastáncem používání anotací všude, kde se dá. Osobně nejčastěji používám Hibernate Annotations nebo JPA anotace a Spring a jUnit anotace při psaní testů.

Zeptal jsem se pár kolegů na jejich názor na anotace (1, 2) a v následujícím resumé se to pokusím nějak shrnout:

Argumenty pro:
  • jednoduché, intuitivní - toto se může lišit anotace od anotace, ale dost často je zápis pomocí anotace jednodušší než nějaká jiná podoba konfigurace.

  • větší flexibilita - díky používání anotací může být určité řešení flexibilnější než standardní verze bez anotací. Jako příklad bych uvedl Spring MVC - klasická verze vs. verze s anotacemi. Anotace přináší určitě větší flexibilitu, asi i větší jednoduchost používání a menší nároky na učení se klasického API kontrolerů, ale dle mého názoru to jeden nedostatek má. Zejména u větších projektů se hodí, když má projekt nějakou strukturu, nějaká pravidla a toto se hůře vynucuje pomocí anotací než při používání klasického API. Uvedu jeden konkrétní příklad: myslím, že je vhodné mít odkazy na JSP stránky a URL adresy mimo vlastní Java kód kontrolerů. V klasickém API mám settery na viewname, ale co u anotací? Vytvořím si vlastní předky, ale už to zase bude na úkor nějaké funkcionality, které mi anotace nabízejí.

  • pro popis metadat - anotace mi umožňují přidat klasickým třídám (POJO) nové vlastnosti, které není potřeba implementovat přímo v Java kódu. Např. že je třída resp. metoda deprecated, že je třída volána v transakci pouze pro čtení, že je metoda pouze pro uživatele s rolí READ apod.


Argumenty proti:
  • již není POJO - pokud chcete psát "lehké", testovatelné a flexibilní aplikace (z pohledu budoucích změn), pak je určitě dobré používat POJOs. Jen pak je možné používat dané objekty v různých scénářích a prostředích - testy vs. produkční nasazení, objekty ve webové vrstvě vs. DAO vrstva apod. Neplatí to obecně pro všechny anotace, ale některé anotace vyjadřují určitou implementační závislost nebo předepisují dané třídě určité chování, které je platné jen pro určité použití. Konkrétně třeba @Transactional. Nebo nastavení zabezpečení objektů pomocí anotací, EJB anotace apod.

  • konfigurace aplikace nepatří do Java kódu - já sám mám raději několik konfiguračních souborů, kde najdu veškerou konfiguraci než to vše mít roztroušené po jednotlivých Java třídách. Na to zase většina řekne, že je super vidět u každé třídy hned dané vlastnosti (např. nastavení transakce, zabezpečení) než to hledat někde v separátních souborech. Dle mého názoru je lepší mít konfiguraci oddělenou od Java kódu a mít tak možnost nezávislého nastavení aplikace (nebo jejich částí) pro více prostředí.


Anotace mi přijdou jako velice flexibilní nástroj, ale i tak pořád spíše tíhnu ke klasickému vývoji bez anotací. Ale zase je potřeba se na vše dívat z různých pohledů, takže vlastně nelze obecně říci, co je lepší - takto dopadly i výsledky ankety :).

25. května 2009

JavaDoc nedostatky

V poslední době často pracuji s cizím kódem a je to opravdu zázrak narazit na kvalitně napsaný a okomentovaný kód. Největší problém komentářů je ten, že buď vůbec nejsou a nebo jsou, ale jen papouškují to, co je hned zřejmé ze samotného kódu. O přínosu komentování jsem již psal, dnes bych rád uvedl několik nedostatků v JavaDoc komentářích, na které jsem měl možnost narazit (malá poznámka pro upřesnění - i když často používám slovíčko komentáře, tak v tomto článku dále vždy myslím JavaDoc komentáře, ne komentáře přímo v kódu):

  • míchání češtiny (někdy i s diakritikou) a angličtiny - dříve jsem preferoval pouze angličtinu pro psaní komentářů, ta čeština mi tam prostě neseděla. Dnes jsem spíše pro používání češtiny z těchto důvodů: čeština vždy bude pro nás čitelnější než jakýkoliv jiný jazyk a i psaní komentářů je jednodušší, větší přínos z pohledu poskytované informace. Osobně s angličtinou nemám problém, ale sám jsem zjistil, že v češtině jsem schopen se vyjádřit o dost lépe. Dělám nyní většinou na interních projektech bez zahraničních kolegů, takže není problém s mateřským jazykem. Každopádně když už, tak zvolit jeden jazyk, aby to nevypadalo jako na jednom projektu, kde bylo možné narazit na české, slovenské, anglické a dokonce německé komentáře.

  • zvýraznění první věty komentáře - První věta komentáře má větší význam oproti dalším větám - jednak je to první informace, kterou uživatel čte a jednak je používaná pro stručný popis v přehledu metod. První věta (z pohledu JavaDoc nástroje) končí tečkou, kterou následuje mezera, tabulátor, znak konce řádku a nebo první blokový tag. Takto tedy ne:

    /**
    * <p>
    * If is set, it use special ScrollableResultsDecorator, that enable or
    * disable to add object in final list
    * </p>
    * <h4>NOTE:</h4>
    * <p>
    * Also, it respects the total count of entries that overlap your paged
    * list.
    * </p>
    */


  • @author tag u metod - používat @author tag u metod nemá žádný význam, protože to JavaDoc nástroj nepodporuje.

  • nepopisovat to, co za nás udělá JavaDoc automaticky - Je zbytečné kopírovat komentáře z metod rozhraní do implementace, je zbytečné uvádět implementující třídy rozhraní atd. JavaDoc nástroj má algoritmus na kopírování komentářů z nadřazených tříd a na rozdíl od verze 1.3 se vždy nekopíruje celý JavaDoc komentář (buď celý nebo nic), ale třeba i jen jeho části jako @param, @throws a @return. Někdo to sice nekopíruje, ale používá @inheritDoc a @see, ale to nejsou srovnatelné alternativy. Např. při použití @inheritDoc se kopíruje jen určitá část celého JavaDoc komentáře a tag @see má zcela odlišnou sémantiku. @inheritDoc je vhodné používat, pokud chci rozšířit určitou část dokumentace nadřazené třídy nebo metody.

  • zdokumentovat synchronized a native modifikátory - V JavaDoc API nenajdete informace o tom, zda je metoda synchronizovaná nebo ne (je to implementační záležitost). Proto je nutné tuto informaci uvést v JavaDoc.

  • zbytečně neopakovat význam tagů - Zde mám na mysli toto "@return Returns the statementBuilder." Proč psát 2x, že metoda vrací statementBuilder?

  • místo názvů tříd a metod používat odkazy @link - Hodně často se v komentářích odkazujeme na jiné třídy nebo metody a o dost větší přidaná hodnota bude, když si uživatel mezi jednotlivými komentáři může překlikávat, než aby to musel manuálně hledat. Proto je vhodné používat tagy @link resp. @linkplain.

  • používat @literal nebo @code pro psaní s <> - S příchodem Javy 5 a možností parametrizace může být problém zápisu těchto konstrukcí do JavaDoc komentářů. To stejné platí i o HTML a XML kódu. Než používat &lt; &gt; jako náhradu za <>, tak je lepší použít tagy @literal nebo @code. Tím se výrazně zvýší čitelnost JavaDoc i bez nutnosti zpracování JavaDoc nástrojem. Bohužel tyto tagy nelze použít na víceřádkové ukázky kódu, kde nám jde o přesné zarovnání kódu. Snad v příští verzi, pořád je tedy (bohužel) nutné používat tento způsob:

    * <p>Ukazka konfigurace ve web.xml:
    * <pre>
    &lt;listener&gt;
    &lt;listener-class&gt;com.o2bs.globals.web.common.envconfig.EnvAwareLog4jConfigListener&lt;/listener-class&gt;
    &lt;/listener&gt;
    * </pre>


  • psát přehledné komentáře i bez nutnosti použití JavaDoc nástroje - Hodně lidí hledí zejména na výslednou HTML podobu JavaDoc komentářů a ne na to, jak to vypadá přímo v Java kódu. Je pravda, že výsledná HTML podoba je asi nejdůležitější, ale dost často se prochází čistý Java kód bez IDE (a nebo i v IDE je rychlejší číst JavaDoc bez nutnosti si je zobrazovat v HTML podobě) a pak se i ocení, když to vypadá pěkně bez JavaDoc nástroje. Dle mého názoru se nemá cenu snažit o správně formátované HTML (tedy používání ukončovacích tagů), protože JavaDoc nástroj generuje HTML ve verzi 3.2 (i když hlavičku stránek dává pro HTML 4.0).


Psát správné (krátké, jasné s vypovídající hodnotou) JavaDoc komentáře není vůbec jednoduché a sám se občas nachytám, když se po nějakém čase vracím ke svému kódu. Pro ty, kdo chtějí JavaDoc dotáhnout k dokonalosti, doporučuji referenční příručku k JavaDoc nástroji a dokument s popisem konvence psaní komentářů.

1. dubna 2009

Jakou verzi Javy používáte? - výsledky

V poslední anketce mě zajímalo, jakou verzi Javy používáte. Zajímalo mě to hlavně kvůli tomu, že ještě před 3 lety jsem pracoval na projektech v bankách, kde se používala Java 1.3. Tak mě zajímalo, zda je to jen výjimka a nebo zda je to normální.

Zde jsou výsledky (celkem hlasovalo 180 lidí):

  1. Java 6 (67%)
  2. Java 5 (40%)
  3. Java 1.4 (10%)
  4. Java 1.3 (1%)
  5. Java 1.2 (1%)

Já osobně pořád spíše používám Javu 5, ale nemám vlastně pro to žádné objektivní důvody, spíše jsem pohodlný a neměl jsem zatím důvod přecházet na Javu 6.

Výsledky asi nemá cenu ani komentovat, protože jsou dle očekávání. Sice si pořád myslím, že v bankách a jiných velkých institucích se jede na Jave 1.4 a starších ve větší míře, než jak ukazují výsledky, ale je to jen má domněnka. Na závěr si neodpustím otázku - nedovedu si vůbec představit, proč se někde ještě dnes musí využívat Java 1.3 nebo 1.2? Aspoň doufám, že jde o nějaké staré projekty stále v údržbě.

15. dubna 2008

Výhody a nevýhody EJB

Dost často kolem sebe slyším při rozhovorech o vhodných technologiích pro určitý projekt, že použijeme EJB, tím se nedá nic zkazit. Je to prověřená technologie, je to dostatečně enterprise, je to standard, takže vlastně nejsou žádné důvody, proč to nepoužít.
Já si myslím, že těch nevýhod může být celkem hodně. V tomto článku bych rád některé nevýhody prezentoval:

  • Testovatelnost aplikace - pokud chci testovat EJB, tak potřebuji EJB kontejner. Sice existuje pěkná knihovna Jakarta Cactus, ale přeci jen to není tak přímočaré, jako když mám POJO. Nebo mohu použít Embedded EJB kontejner, popis zde.

  • Přenositelnost - myslím, že každý ocení, když někde vyvine aplikaci, kterou pak může nasadit na libovolný server tak jak je, bez nějaké další potřeby konfigurace aplikačního serveru. Obecně se dá říci, že kolečko develop-test-deploy je rychlejší u lightweight řešení než u řešení s EJB.

  • Rychlost spouštění - jakýkoliv server, který obsahuje něco více než čistý webový Java kontejner se mi bude spouštět pomaleji. A během vývoje takový server pouštím opravdu často. Ano, nepoužívané služby si mohu vypnout, ale pak je otázka, proč potřebuji plný J2EE server. Proto se mi moc líbí myšlenka profilů ve specifikaci J2EE 6.

  • Náklady na EJB server - samotný EJB server se sehnat nedá (nebo dá?) a pokud je tedy EJB (přesněji řečeno EJB kontejner) potřeba, člověk musí sáhnout po J2EE serveru. Jedna věc jsou náklady na pořízení serveru, druhá věc jsou náklady spojené s instalací a školením pro práci s J2EE serverem. Přeci jen vše je složitější než Tomcat :).


Některé nevýhody jsou více či méně významné, nutné je také brát velký posun od EJB 2.1 k EJB 3.0 (nevýhod EJB 2.1 je o dost více, ale ty zde neuvádím). Nechci, aby tento článek vyzněl, že nemám rád EJB, to není vůbec pravda. Já se jen snažím říci, že EJB ano, ale jen pro ten typ aplikací, kde je to opravdu potřeba, protože EJB je "heavyweight" technologie, což sebou přináší určité nevýhody. Typický příklad - pro webovou CRUD aplikaci nad jednou databází bych EJB nepoužíval.

Kromě nevýhod má řešení s EJB i spoustu výhod:
  • EJB je řešení pro distribuované aplikace, tj. aplikační logika nebo aplikační komponenty jsou umístěny na více serverech (nemyslím cluster) nebo aplikace má několik typů klientů včetně tlustého klienta.

  • EJB zjednodušuje psaní vícevláknových aplikací

  • EJB nabízí transakční kontejner, který umožňuje efektivní řešení transakcí přes více datových zdrojů

  • pokud je distribuovaná EJB aplikace dobře napsaná, tak lze docílit větší robustnosti a škálovatelnosti aplikace než když aplikace bude bez EJB umístěná na jednom serveru.


Výhod je tedy hodně, ale potřebuji nebo ocením toto vše pro mojí aplikaci? Pokud ne, tak EJB nepotřebuji a mohu využít výhod lightweight aplikací.

2. března 2008

Java applety a SSL

Jak jsem již dříve referoval, na jednom našem projektu používáme komponentu ImageUploader pro nahrávání dokumentů do systému. Komponenta se automaticky dle verze prohlížeče spouští jako ActiveX (pro IE) a nebo Java applet. Komunikace mezi komponentou a serverem je zabezpečena pomocí protokolu HTTPS.

Dále je důležité říci, že zákazník má vlastní certifikační autoritu, která není odvozena od žádné věhlasné věrohodné certifikační autority.

Pokud uživatel nechce, aby se mu pořád objevovala chyba, že cílová stránka má neplatný certifikát, tak je nutné importovat kořenový certifikát do lokálního úložiště důvěryhodných certifikátů na počítači daného uživatele. Tento postup je asi následující:

  1. Stáhnu si kořenový certifikát zákazníka vystavený na webu
  2. Kliknu na něj a průvodce mě provede instalací certifikátu

Postup velice jednoduchý a pro uživatele nijak komplikovaný.

Jenže je tu velké ALE - takto jednoduché je to pouze pro prohlížeč Internet Explorer. Pro Firefox je to složitější, protože má vlastní úložiště důvěryhodných certifikátů, takže je potřeba import kořenového certifikátu udělat ještě jednou zvlášť pro Firefox.

Pokud chceme používat Java Applety se zabezpečenou komunikací, tak musíme jít ještě dále, protože Java má také svoje úložiště důvěryhodných certifikátů a proto musíme kořenový certifikát vložit i sem. K tomu má Java nástroj keytool, který je sice celkem mocný, ale bez šance, že by s ním dělal normální uživatel internetu.

Co s tím? Řešením by bylo, kdyby kořenový certifikát zákazníka byl odvozen od nějaké světově věrohodné společnosti jako třeba VeriSign, Thawte. Tyto věrohodné firmy jsou již automaticky v úložištích důvěryhodných certifikačních autorit, takže by úplně odpadl import certifikátů. Jenže za to se platí a na to zákazník nemá peníze.
Dalším řešením by bylo, kdyby bylo jedno úložiště důvěryhodných certifikátů. To nevím, jak je moc reálné, takže to nemohu posoudit. Co mě ale nejvíce překvapuje, že Java resp. Java applet není schopen sdílet informace o certifikátech s prohlížečem, ve kterém běží?

Přijde mi tento postup natolik uživatelsky nepřívětivý (navíc ještě ve srovnání s technologií ActiveX), že se spíše ptám sám sebe, kde jsem udělal chybu já. Z mého pohledu je to další důvod pro mé tvrzení, že Java applety se moc nepovedly a už se nemůžu dočkat až bude něco lepšího, snad JavaFX.

Pokud mi můžete v tomto směru poradit, tak budu moc rád.

31. srpna 2007

Třídění kolekcí podle českých pravidel

Narazil jsem včera na zajímavé možnosti třídění kolekcí v Javě. Můj problém byl následující - z LDAP serveru načítám uživatele a potřebuji je pak setřídit dle jejich příjmení. Vzhledem k tomu, že ne všechny LDAP servery mají zabudovanou funkcionalitu třídění, tak jsem toto musel vyřešit přímo v Javě.

První řešení, které asi každého hned napadne je následující:

  public static final Comparator SURNAME_COMPARATOR_ASC = new Comparator() {
public int compare(Object o1, Object o2) {
return ((User) o1).getSurname().compareTo(((User) o2).getSurname());
}
};
...
// sort users by surname
Collections.sort(users, SURNAME_COMPARATOR_ASC);
Nadefinuji si standardní komparátor a pak použiji metodu z Collections pro třídění. A zde jsem narazil na problém s řazením v češtině - příjmení začínající diakritikou se seřadily až na úplný konec seznamu, což je špatně. Je to tím, že používáme standardní komparátor Stringu, který řadí řetězce lexikograficky.

Java umí zde parádně pomoci třídou Collator. Tato třída bere v potaz pravidla pro jednotlivé národní znaky, pomocí RuleBasedCollator je možné si dokonce nadefinovat úplně vlastní pravidla pro třídění. A aby toho nebylo málo, tak je tu ještě třída CollationKey pro efektivnější třídění řetězců.

Nová implementace komparátoru bude tedy vypadat takto:
  private static Collator czechCollator = Collator.getInstance(new Locale("cs"));

public static final Comparator SURNAME_COMPARATOR_ASC = new Comparator() {
public int compare(Object o1, Object o2) {
return czechCollator.compare(((User) o1).getSurname(), ((User) o2).getSurname());
}
};