Když jsou deštivé dny, pracuji na novém (supertajném) projektu, který poběží na Google App Engine (Java) infrastruktuře (dále jen GAE). Toto běhové prostředí je trošku specifické a od tradičních J2EE webových serverů jako je Tomcat, Jetty, JBoss nebo Glassfish se liší tím, že aplikace z paměti odstraňuje. To J2EE servery normálně nedělají (i když by mohly), což způsobilo, že si programátoři (zejména tvůrci webových frameworků) s rychlostí startu aplikací hlavu nedělají.

V GAE je to problém – pokud určitou dobu nepřijde webové aplikaci nový požadavek, Google aplikaci „stáhne“ a ta pak musí znovu naběhnout. Pokud tedy používáte webový framework, kterému chvíli trvá, než se zinicializuje, je tu problém. Uživatelé pak mohou web opustit, protože čekat 20 vteřin na zobrazení stránky (další již servery vracejí rychle) prostě nechce. Nedejbože když použijete technologie jako jsou EJB nebo Spring.

Když jsem si vybíral webový framework, který bych pro svoji aplikaci použil, překvapil jsem možná sám sebe. Mojí hlavní podmínkou bylo, že to nesmí být AJAX UI (Google Web Toolkit, ZKoss a jiné) – povaha aplikace to nedovoluje. Potřeboval jsem tedy „klasický“ webový stack, který by byl flexibilní pro vývoj, ale zároveň mocný a zejména ryhchle startoval.

K mému velkému překvapení to nevyhrál můj původně hlavní favorit – Apache Wicket. Na diskuzních skupinách jsem si totiž mohl přečíst spoustu příspěvků na téma pomalého startu při provozu na GAE. Developeři se v podstatě spokojili s číslem kolem 7 sekund. Jakkoli je to stack přitažlivý, musel jsem hledat jinde.

Zkoušel jsem se mrknout na Grails. Jazyk Groovy jsem si kdysi prošel v tutoriálu, novým věcem se nebráním. Když jsem si ale přečetl, kolik problémů měli uživatelé s uploadem na GAE, dlouhou inicializací a celkovým výkonem. Jakkoli je to výborná technologie, o kterou se v budoucnu určitě budu zajímat (nejen já), pro můj účel se nehodila.

Při tom všem hledání jsem narazil na Play Framework, což je v podstatě obrovský posun zpět k tomu, jak se webové aplikace psaly dříve. Autoři záměrně porušují některé zažité zvyklosti ve světě serverové Javy (např. jména balíčků, zapouzdření) ve prospěch rychlejšího a elegantnějšího vývoje. A daří se jim to – framework na mě udělal velmi silný dojem. Start: asi 3 vteřiny (aktuální trunk z Bazaaru). Diskvalifikovala ho jediná věc – šablony se píší v Groovy a ačkoliv jsou pak kompilovány, rychlost tohoto jazyka není na JDK6 stále ideální. Každý bit a každá milisekunda se na GAE tvrdě platí, takže proč nehledat dál.

O stacku Stripes jsem slyšel už dříve, také jsem si v něm zkoušel Hello World. Musím říct, že je to ideální framework pro můj projekt. Knihovna má 490 kB, závislosti jen na commons-logging.jar a cos.jar, přičemž druhý jmenovaný (multipart encoder) je nepovinný a na GAE dokonce nepoužitelný (soubory se na GAE aplikace nahrávají trošku jinak). Celkem méně než 600 kB. Stripes je velmi snadný na naučení, přitom je elegantní, jednoduchý (anotace) a startuje bleskově – pod 1 vteřinu (jedno kolik máte Action tříd).

Stripes používá pro prezentační vrstvu JSP. Ano, Java Server Pages – technologii, která byla ve verzi 1.0 propadákem, ale poté (1.1) byla konsolidována, znovu oživena a představuje základ dalšímu stupni (JSF). Tato technologie je však mocná – díky JSP (a standardu/implementace JSTL – dva soubory o celkové velikosti 400 kB) lze bezproblémově a elegantně psát prezentační vrstvu. Stripes používá klasický MVC model, takže použití JSP se přímo nabízí. Lze jej ale integrovat s jinými prezentačními frameworky.

Na rozdíl od jiných prezentačních technologií má JSP obrovské výhody. Skoro všichni JSP umí (alespoň se s nimi setkali), programátorské nástroje mají špičkovou podporu JSP a vytvořené šablony jsou zkompilovány (JSP→Servlet→class). Jsou tedy výkonné. Už dávno jsou pryč doby, kdy JSP byla vlastně jen specifikace, ve které bylo vše rozdrobené a každý si to dělal jinak. Díky JSTL a také Stripes tagům je práce jednoduchá a jazyk EL byl v předposlední verzi JSP sjednocen.

Celé vývojové prostředí jsem měl nastavené během chvilky – není divu, je to přece J2EE. Nastavení web.xml mě nemohlo překvapit, stejně jako nahrání dvou „konfiguračních“ souborů do CLASSPATH. Pomocí nich jsem nastavil logování (commons-logging → JUL v GAE) a překladové zprávy (Resources). Ještě zbývala poslední věc – vytvoření dummy implementace pro Multipart Wrapper, který není v GAE povolen (používá temp soubor) a jeho nastavení. Sečteno a podtrženo: 5 minut a všemu rozumím. Ne když člověku pod rukama doslova „vyroste“ adresářová struktura, kde u 60 % souborů člověk pomalu neví, proč tam jsou. Celková velikost včetně knihovny a závislostí: 1 MB.

Člověk by si říkal, že použití JSP je krok zpátky. Udivilo mě, že to tak není. Krásně se s tím dělá. Lépe než kdy jindy.

Tento zápisek vznikl převodem z mého starého blogu. Ne všechny texty byly takto převedeny, kompletní archiv již není k dispozici.