Frameworków webowych dla Javy jest mnóstwo, a wybór najlepszego to temat na wielodniowy "flame". Wicket jest na topie, w GWT nie trzeba pisać HTML-a, JSF to standard, a Struts 2 to prawie że potomek legendarnych Strutsów. Istnieje jednak framework webowy, który może nie jest aż tak bardzo popularny jak wyżej wymienione, ale warto go poznać, bo w pełni na to zasługuje. Mowa oczywiście o tytułowym Stripes Framework.

Używałem już paru szkieletów webowych, ale przy ostatnim projekcie, w którym decydowałem o wyborze technologii, moje rozważania zakończyły się wyborem tandemu Spring + Stripes. Z perspektywy czasu widzę, że akurat w tym wypadku był to bardzo dobry traf, pomimo braku wcześniejszych doświadczeń ze Stripesami (chociaż parę mądrych osób wcześniej mi mówiło, że ten framework ma właściwie wszystko, czego się wymaga od javowego frameworka webowego - i mieli oni rację).

Nie będę tutaj opisywał, jak napisać "Hello world", bo to już zrobili inni. Napiszę za to, dlaczego lubię Stripesy i dlaczego właśnie je warto użyć zamiast chociażby takiego Struts 2. Nieprzypadkowo wspominam tutaj o S2, gdyż w założeniach są to biblioteki bardzo podobne, oba frameworki są bowiem zdecydowanie akcyjne, nie komponentowe. Niektórym może się ta cecha podobać, innym mniej, ale ponoć "de gustibus non est disputandum", zresztą nie chcemy tu wspomnianego flejma.

Jedną z miłych rzeczy, które spotkamy w Stripes Framework, jest wbudowany bardzo prosty mechanizm do powtórnego wykorzystywania layoutów. Dzięki trzem prostym tagom odpada nam konieczność używania zewnętrznych rozwiązań jak Tiles czy SiteMesh. O ile ten drugi jest przyjemny w użyciu, o tyle ilość xml-a koniecznego do wyprodukowania w Tilesach przy braku konwencji skutecznie do tej biblioteki zniechęca.

Kolejną sympatyczną niespodzianką jest tag do zrobienia kontrolki wyboru z javowych enumów. Standardowo w JSTL czegoś takiego nie znajdziemy, Struts 2 też nie oferuje w tym wypadku jakiegoś gotowego rozwiązania, a jest to chyba dość popularne użycie enumów w aplikacjach internetowych. W Stripesach możemy użyć taga <stripes:options-enumeration/>, a o tym, w jaki sposób to zrobić, można doczytać w dokumentacji.

Na dokładkę zostają nam sprawy konfiguracji. Nie mamy ani kawałka xml-a poza standardowym web.xml, żadnych dodatkowych stripes.xml czy pluginów do obsługi adnotacji bądź włączenia konwencji, jeśli takowe w ogóle istnieją i nam zadziałają (tak, nieco piję tutaj do S2). Wszystko dostajemy od razu, a dzięki adnotacji @UrlBinding bardzo łatwo przyjdzie nam zrobić "ładne" URL-e. Być może są to szczegóły, ale z takich właśnie szczegółów składa się praca programisty. Zresztą pozytywnych niespodzianek jest w Stripes Framework o wiele więcej.

Ok, czy ten framework jest "świętym Graalem" wśród innych rozwiązań? Oczywiście nie, aczkolwiek trudno mi tutaj wytknąć jakiekolwiek jego niedoskonałości. Rzecz jasna nie każdemu mogą odpowiadać jsp (aczkolwiek można użyć Velocity czy FreeMaker) jako szablony, no ale to kwestia gustu. To, co mogłoby być nieco lepiej rozwiązane, to integracja ze Springiem, tzn. użycie go do tworzenia akcji tak, jak to robi Struts 2. Obecnie mamy adnotację @SpringBean (swoją drogą to już chyba jakaś konwencja nazewnicza, w Wickecie nazwa adnotacji do wstrzykiwania beanów Springa jest taka sama), natomiast nie mamy dostępu do np. @Value ze Springa 3. No ale to drobny szczegół (zresztą istnieją projekty, które pozwalają Springowi stać się zarządcą akcji stripesowych, tylko że mają one swoje wady), poza tym w wersji 1.6 (a kiedy piszę te słowa, najnowszą jest 1.5.1) możemy się i rozwiązania tej kwestii spodziewać. W każdym razie polecam przynajmniej spojrzeć przez chwilę na ten projekt, a nuż okaże się on dla Ciebie technologicznym strzałem nie w stopę, lecz w dziesiątkę.

Temat lazy loadingu (leniwego ładowania?) przewijał się ostatnio na polskich blogach javowych. Pisał o nim Mateusz Zięba, o wydajności takiego rozwiązania wspominał też w świetnym wpisie Sławek Sobótka. Czy można coś jeszcze dodać? Myślę, że niewiele, ale spróbujmy skupić się na jednej rzeczy, a mianowicie na zamkniętej sesji JPA i sposobie, jak sobie w takim wypadku radzić gdy mamy jeszcze w naszych zależnościach Spring Framework oraz działamy w środowisku webowym.

Problem jest dość częsty (przykładowy "stack trace" poniżej) i jako taki ma też rozwiązanie, opisane zresztą w artykule Open Session in View na stronach naszego ulubionego ORM-a. W skrócie całe zamieszanie związane jest z tym, że nie zawsze w naszej warstwie logiki biznesowej operujemy na obiektach, które potem chcemy wyświetlić, a zatem ORM bardzo słusznie nie pobiera ich z bazy danych. Jednak gdy dochodzi do wyświetlenia listy w widoku, zamiast np. listy ulubionych kolorów użytkownika dostajemy błąd numer 500, a w logach straszy nas LazyInitializationException (oczywiście w przypadku H., bo specyfikacja JPA o takiej sytuacji w ogóle nie wspomina). Sesja jest już bowiem zamknięta i nie wiadomo, skąd te kolory wziąć, a całej bazy przecież nie pociągnęliśmy wcześniej, prawda? :). Z przyczyn oczywistych zmiana fetch na FetchType.EAGER raczej nie wchodzi w grę.

org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: net.miracki.Test.categories, no session or session was closed
    at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationException (AbstractPersistentCollection.java:380)
    at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected (AbstractPersistentCollection.java:372)
    at org.hibernate.collection.AbstractPersistentCollection.readSize (AbstractPersistentCollection.java:119)
    at org.hibernate.collection.PersistentSet.size (PersistentSet.java:162)
    ...

Problem jest, rozwiązanie dla Hibernate'a też. Niestety niewielki kłopot pojawia się, kiedy chcemy być standardowi i używamy Hibernate (albo czegokolwiek innego) poprzez właśnie JPA. Jak to zazwyczaj bywa, Spring Framework ma na takie zachowanie gotową i prostą receptę. W zasadzie wpis mógłby się kończyć na poniższym kawałku pliku web.xml:

    
        JpaFilter
        org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter
    
    
        JpaFilter
        /*
    

Dzięki temu filtrowi nie powinniśmy więcej spotkać wyjątku związanego z "lazy loadingiem". Powyższy filtr istnieje zresztą też w wersji dla zwykłego Hibernate (jako klasa OpenSessionInViewFilter).

Abstrahując już od głównego tematu, ORM-y to narzędzia, które przed użyciem wypada przynajmniej choć trochę poznać, a do tego tutorial jak zrobić "Hello World" nie wystarczy. Brałem udział w projekcie, który z dobrodziejstw opisanych filtrów nie korzystał, przez co niektóre metody w warstwie logiki biznesowej posiadały argumenty typu boolean o nazwach attachCategories, attachCountries itp. Nie wiem, czy byłbym jednak w stanie wymienić wszystkie zasady dobrego kodowania, które w ten sposób zostały złamane ;). Ale jeśli chodzi o ORM-y, to prawie na samej górze mojej prywatnej listy idiotycznych rozwiązań jest adnotacja @Transient dla obiektów połączona z mapowaniem kluczy obcych do Longów z @Column, bo "pociągniesz całą bazę, ORM-y to zło, ale niech już zostaną". Na całe szczęście takie podejście bardzo szybko minęło wraz z lekturą manuala...

Krótki urlop (który upłynął pod znakiem słońca, koloru różowego i Panthenolu w sprayu) szybko się skończył, wypada więc w tym gorącym czasie (chociaż bardziej ze względu na kupno Spring Source przez VMware aniżeli przez aktualną pogodę) powrócić do świata Javy. Na tapetę wędrują zatem płynne interfejsy.

Mam nadzieję, że za tytułowe tłumaczenie "fluent interfaces" nikt mnie na stosie palił nie będzie, chodzi wszakże o całkiem fajny styl programowania, który dodatkowo ostatnio jakby staje się coraz popularniejszy. Określenia "fluent interface" użył chyba po raz pierwszy sam Martin Fowler, a obecnie dorobiło się ono nawet swojego wpisu w Wikipedii. Rzecz nie jest w żadnym stopniu nowa ani rewolucyjna, w dodatku od razu widać powiązanie z "method chaining". Na pewno każdy używał cout z C++, a zatem mniej lub bardziej świadomie korzystał też ze wspomnianej techniki, która teraz wraz ze spopularyzowaniem DSL-i przeżywa swoją drugą młodość, przynajmniej jeśli chodzi o świat Javy.

Odbiegając na chwilę lekko od tematu można czy nawet wypada wspomnieć o opisanych w Effective Java builderach (budowniczych). Przy klasie, która ma bardzo wiele atrybutów, bezpośrednie używanie konstruktorów z tymi parametrami nie jest najlepszym pomysłem. W pewnym momencie bowiem możemy stracić orientację, czy true na dwudziestej szóstej pozycji odnosi się do zablokowania użytkownika, czy do faktu posiadania uprawnień administracyjnych. Trzydzieści setterów jest natomiast obarczone ryzykiem, że gdzieś około piętnastej pozycji ktoś wywoła nam kod, który będzie potrzebował już w pełni stworzonego obiektu. Buildery takie są lekarstwem na wspomniane właśnie problemy, a wykorzystują one "method chaining". Do ich generowania pod Eclipse istnieje odpowiednia wtyczka, całkiem zresztą znośna w użyciu, choć do ideału jej nieco brakuje.

Ok, co z tymi płynnymi interfejsami i czemu warto tracić na coś takiego w ogóle czas? Otóż jest tak, że większość czasu spędzamy czytając kod, więc powinno nam zależeć, aby ten kod był po prostu czytelny. A teraz weźmy na przykład standardowe API Javy do obsługi dat - czy poniższy kod (wzięty zresztą z opisu biblioteki Time and Money Erica Evansa) jest przejrzysty i łatwo zrozumiały na pierwszy rzut oka?

Calendar calendar = Calendar.getInstance();
calendar.setTimeZone(TimeZone.getTimeZone("Universal");
calendar.set(Calendar.DATE, 5);
calendar.set(Calendar.MONTH, 3 - 1);
calendar.set(Calendar.YEAR, 2004);
Date march5_2004 = calendar.getTime();

Na całe szczęście w przypadku dat możemy użyć chociażby Joda Time, natomiast płynne interfejsy znalazły swój przyczółek w bibliotekach do mockowania, w tym w mojej ulubionej, czyli w Mockito (w poniższym przykładzie w parze z projektem Fest). Czy ktoś odważy się powiedzieć, że taki test nie jest naprawdę piękny? ;)

    @Test
    public void shouldGenerateValidLoginFromEmailForUser() {
        // given
        String name = "test";
        User user = new User.Builder().mail(name + "@example.com").build();
        given(userDAO.update(user)).willReturn(user);

        // when
        userLogicBean.generateLoginAndSave(user);

        // then
        assertThat(user.getLogin()).hasSize(User.Length.LOGIN).startsWith(name);
    }

Ale mocki i asercje to nie jedyne miejsce dla płynnych interfejsów. Wykorzystano je projektując chociażby Google Collections (warto popatrzeć na przykład na klasę MapMaker), a biblioteka Lambdaj pozwala pozbyć się niewiele mówiących pętli połączonych z mnóstwem ifów na rzecz tego typu konstrukcji:

List<Person> oldFriends = filter(having(on(Person.class).getAge(), greaterThan(30)), meAndMyFriends);

Albo weźmy kolejny przykład - JPA. O ile JPA w pierwszej wersji było nieco wybrakowane, o tyle warto poczytać, co pisze o języku zapytań w JPA 2.0 Linda DeMichiel. Swoją drogą nawet Doctrine ORM w php było szybsze, jeśli chodzi o wykorzystanie "method chainingu" w zapytaniach.

Widać więc, że nawet świat Javy ewoluuje, starając się niwelować niedostatki samego języka bądź też niedoskonałego API. Oczywiście wszystkiego zrobić się nie da, problemem są metody zwracające void, nie można też wykryć w czasie wykonywania typu sparametryzowanej kolekcji. Są to jednak jedynie szczegóły, które można spróbować obejść (np. w Mockito dla metod zwracających void jest szereg metod do*, które zwykle pozwalają nam osiągnąć to, co chcemy).