Explicitní vs. implicitní API v J2EE
Ve včerejší poznámce o možných směrech vývoje Struts 2.0 jsem to naťukl a dnes jsem o tom spatřil rovnou celý příspěvek na Java.Net — Explicit vs. Implicit Programming Models for J2EE.
Richard Monson-Haefel si v něm dle mého zcela oprávněně stěžuje na složitost současných J2EE API. Každé zákoutí J2EE přináší spousty typů, metod, a kvanta knih, které vysvětlují, jak je vlastně správně používat.
Tento přístup nazývá "explicit programming model" — reflektuje složitost implementujících systémů a nabízí vývojářům silné a podrobné nástroje; za typický příklad mohou sloužit EJB, jejichž API je silně svázané s během v prostředí EJB kontejneru.
Výjimkou je oblast webových služeb, která umožňuje programátorům vyvíjet komponenty, které jsou de facto poctivá POJO — tedy normální třídy, které nejsou svázána kvanty rozhraní, callbacků, signatur, datových typů a výjimek.
Naprosto s tímto přístupem souhlasím. Kvůli čemu podle vás existuje něco jako J2EE? Cynik by řekl hlavně, že hlavně kvůli výdělkům poskytovatelům těchto služeb; cyniky teď ale ignorujme.
Měl jsem vždy za to, že motivací bylo usnadnit a zjednodušit vývoj komplexních podnikových aplikací, přičemž jako prostředek byla zvolena standardizace rozhraní popisujících typické dílčí úlohy, kterým jsou vývojáři podnikových aplikací vystaveni.
Věřím, že účelu bylo jistě do slušné míry dosaženo, nicméně vždy, když jsem se zahlédl inzerát nabízející J2EE programátorům stotisícové platy či studoval v tramvaji čtyřsetstránkovou specifikaci EJB 1.1, měl jsem matné tušení, že něco je špatně. Opravdu je tohle to "zjednodušení a usnadnění" vývoje?
Zdá se, že to pravé zjednodušení a usnadnění vývoje pomocí platformy J2EE nás teprve čeká. J2EE do každé rodiny, každý pohůnek J2EE programátorem.
Čím se ale budeme živit my, ostřílení implementátoři rozvleklých explicitních API? 
Struts 2.0 — co očekávat?
Ve vývojářské konferenci struts-dev@jakarta.apache.org se rozproudila debata o budoucnosti frameworku Struts. Release plan pro verzi 1.2 byl nedávno vydán, a nyní se vývojáři rozhodli nahlédnout ještě o kus dále.
Celkově ze zveřejnění záměrů pro Struts 2.0 jde vycítit ambice důkladného vyčištění a zobecněni architektury — od plánu definovat rozhraní pro všechny klíčové komponenty až po záměr odstínit programátora od Servlet API a umožnit mu vrátit se k POJO.
Mimochodem — POJO je trend, který se prolíná posledním vývojem J2EE — od taglibů v JSP 2.0 až po plány na EJB 3. A je to jedině dobře, je to logický důsledek rozporu mezi leností a požadavkem na čistotu: když teď kupříkladu vyvíjíte ve Struts, snažíte se v zájmu znovupoužitelnosti dávat většinu aplikační logiky do samostatných objektů a Strutsí akce používat jen jako můstek mezi Struts frameworkem a aplikační logikou. Vývoj pak logicky směřuje k možnosti vyhodit tyto Strutsí "meziakce" a vhodnou konfigurací "deploynout" třídy aplikační logiky přímo do Struts frameworku, aniž byste si jejich kód museli špinit záležitostmi specifickými pro Servlet API.
Další zajímavou myšlenkou je směřovat vývoj Struts k portálovému frameworku, čímž by vznikla buď konkurence či naopak možnost sloučení s jiným jakartím projektem — portálovým enginem Jetspeed (což je mimochodem základ, nad nímž je postaven Websphere Portal od IBM).
Soupis nápadů pro Struts 2.0 najdete v CVS pod contrib/struts-jericho/.
JBoss a moudra přímo od zdroje
Pánové z JBoss Group si zřídili další neformální komunikační kanál — blog The Evil JBoss Matrix. Píše převážně Nathalie Mason-Fleury, manželka pana zakladatele a ředitelka komunikace JG. Naštěstí kromě jejích více i méně zajímavých deníčkových zápisků zde najdete i záznamy od vývojářů.
Doporučit můžu zejména článek o tom, jak si hlavní architekt JBosse Bill Burke hrál s oficiálním benchmarkovátkem J2EE aplikací zvaným SPECjAppServer2002, a jaké poznatky si z toho odnesl.
JBoss 3.2 + Tomcat 5 snadno a rychle
Pokud používáte J2EE aplikační server JBoss a chcete ve svých neméně J2EE aplikacích používat vymožeností JSP 2.0, nemusíte čekat až někdy na jaře vyjde ostrá verze JBoss 4.
Počínaje verzí 3.2.3 vám standardní distribuce řady 3.2 umožňuje vytvořit si alternativní verzi, která jako web container používá právě Tomcat 5. Postup je jednoduchý:
- stáhněte si z Sourceforge distribuci JBoss 3.2.3
- pořádně to rozbalte (do adresáře, který budeme dále nazývat $JBOSS HOME)
- vlezte do adresáře $JBOSS HOME/docs/examples/tomcat
- spusťte
ant -buildfile docs/examples/tomcat/build-tc5-config.xml(co je to ant doufám není třeba vysvětlovat) - výsledkem je nová konfigurace serveru s názvem tomcat5
"Nová konfigurace serveru" znamená, že JBoss pak nespouštíme pomocí samotného run.sh, který implicitně spouští konfiguraci default, ale musíme připojit parametr: run.sh -c tomcat5. Aplikace pak samozřejmě deployujeme pod $JBOSS HOME/server/tomcat5/deploy!.
(Převzato z blogu Wernera Ramaekerse).
K tématu:
JBoss vs. ASF — ASF odpovídá
Před časem jsem ve spotu JBoss vs. ASF — dopis od JBossích právníků zmínil, že JBoss Group LLC, firma zastřešující vývoj vynikajícího J2EE serveru JBoss, napadla nadaci Apache Software Foundation kvůli projektu Geronimo. (Ve zkratce: Geronimo je prozatímní jméno chystaného J2EE serveru vyvíjného pod křídly ASF. Na vývoji se ovšem podílí množství bývalých vývojářů JBosse; vlastní kód Geronima navíc obsahuje množství kódu přebraného z JBosse. Jádrem sporu pak je, zda tímto přebráním nebyla porušena open-source licence LGPL, pod níž je JBoss vyvíjen.
Vývojářský tým Geronima šel do sebe a probral napadané fragmenty kódu. Viceprezident ASF Geir Magnusson Jr. pak připravil 24. listopadu koncept odpovědi JBossím právníkům, který byl následně průběžně komentován a schvalován v konferenci geronimo-dev@incubator.apache.org.
Odpověď zejména diskutuje konkrétní případy zmíněné v původním dopise.
Ve stručnosti obsah odpovědi:
- Přiklad A — podobnost mezi třídami org.apache.geronimo.core.log.XLevel a org.jboss.logging.XLevel: podle ASF není co řešit, neboť v tomto případě JBossí kód vychází z kódu populárního projektu Log4J, jako na potvoru vyvíjeného pod ASF. Toto dokazuje zakladatel projektu Log4J Ceki Gülcü ve své analýze
- Příklad B — podobnost mezi třídami org.apache.geronimo.core.log.PatternParser a org.jboss.logging.layout.PatternParserEx — totéž jako předchozí případ
- Příklad C — podobnost mezi třídami org.apache.geronimo.common.InvocationType a org.jboss.invocation.InvocationType. Podle ASF tento kód pochází od bývalého vývojáře projektu JBoss Daina Sundstroma, který jej věnoval projektu Geronimo.
- Příklad D — podobnost mezi třídami org.apache.geronimo.common.Invocation a org.jboss.invocation.Invocation, obě definují klíčové konstanty "AsIs", "Transient" a "Marshalled". Tento soubor má navíc být základem architektury JBosse. Podle ASF byla základní idea z této třídy rázně odstraněna, navíc nemůže být základem architektury, když Geronimo i přes tento razantní zásah funguje
Zmíněná odpověď je pracovním materiálem a dosud nebyla schválena ASF či oficiálně zaslána JBossům.
Mírně mě zarazilo, že v původním dopise není nic označeno jako Příklad D, navíc příklad C začíná slovy
As demonstrated by the file portions displayed in this exhibit, the Geronimo code appears to be nearly idetical to the JBoss code"
a další povídání o Invocation a InvocationType je uvedeno slovy
Further, although not reproduceed as an exhibit".
Ale chápu, že k otázce interpretovatelné jako "nepřijde vám blbé zkopírovat celý náš kód" se ASF nechce vyjadřovat — jednak je nepříjemná a druhak právně irelevantní. Z charakteru sporu se domnívám, že vzhledem k přítomnosti mnoha bývalých klíčových vývojářů JBosse v týmu Geronima určitě k žádnému soudnímu sporu nedojde, ale pravděpodobně nás čeká pár dalších výtek, které ale budou fakticky fungovat jako obstrukce komplikující další vývoj Geronima než skutečná právní bitva.
Momentální vývojová verze JBosse 4 směřuje k funkcionalitě, o které zatím může leda snít přípravný výbor specifikace EJB3, zatímco Geronimo je založen na aktuální stabilní verzi JBoss 3.2. A vzhledem k probíhající právní přestřelce si JBoss pozici technologického lídra mezi (nejen) open source J2EE implementacemi ještě notný čas udrží.
A na okraj — v úvodu jsem napsal, že Geronimo je prozatímní název. Momentálně probíhá diskuse o případném přejmenování, důvodem jsou ohledy k Indiánům — existuje názor, že pojmenovat open source projekt po slavném indiánském náčelníkovi je tak trochu neuctivé braní jeho jména nadarmo. V hlasování převažuje názor, že jméno je dobré zachovat, alternativní návrhy a diskusi o přejmenování najdete stránce Why Apache Geronimo.
Robocode
Root.cz dnes přinesl milé připomenutí agresivnější varianty robota Karla — Robocode. Pokud vás tato hra (nebo výukový program?) zatím minula, vězte, že jde jednak o zábavný a akční úvod do jazyka Java a jednak o výzvu vašich algoritmizačních schopností, pokud už máte s Javou co do činění.
Vřele doporučuji k otestování. Už jen to API, které máte k dispozici:
turnGunRight(90); fire(3);
No není to nádhera?