Właśnie ukończyłem lekturę specyfikacji JSR-299: Contexts and Dependency Injection for the Java EE platform. Jeśliby spojrzeć na nią pod kątem liczby stron, to nie należy ona do najbardziej rozległych i jedynie 92 stron można przeczytać w jeden wieczór. Co jednak mnie spowalniało w tym zamiarze, to niezwykle suche podawanie pojęć i zasad działania specyfikacji, której zrozumienie zabrało mi bodajże 2 tygodnie.
Zacząłem od wpisu Nauka Java EE 6 CDI (JSR-299) - relacja z lektury pierwszych dwóch rozdziałów specyfikacji, w którym przedstawiłem pierwszy rozdział z dwóch zakładanych. Miałem wrażenie, że możnaby opisać jednym wpisem całość, a wyszło jak wyszło - przydługi wpis dotyczący jedynie pierwszego rozdziału 1. Architecture.
W tym samym czasie, kiedy ukończyłem czytanie specyfikacji CDI, pojawiła się kolejna wersja NetBeans 6.9 RC1, która udostępnia jej wsparcie. Niewiele jeszcze mogę napisać na ten temat, ale sądzę, że lepiej będzie, jeśli moje próby zrelacjonuję w postaci skrinkastów. W tym tygodniu nie ma co się ich spodziewać, a z kolei w przyszłym jestem na urlopie, więc pewnie dopiero w czwartek, 10 czerwca. Możecie już regulować kalendarze (parafrazując powiedzenie o regulowaniu zegarków).
Sprawę środowiska programistycznego mam więc za sobą i NetBeans IDE 6.9 RC1 będzie moim podstawowym narzędziem, a środowisko uruchomieniowe to GlassFish 3.0.1 (dostarczany z NetBeans IDE), a docelowo IBM WebSphere Application Server V8.0 Alpha.
Co przykuło moją uwagę dzisiaj, to specyfikacja JSR-330 Dependency Injection for Java, która, przynajmniej z nazwy, przypomina CDI. Zaczęło się od wizyty na stronie Apache OpenWebBeans, gdzie w menu po lewej pojawiają się obie specyfikacje JSR299 oraz JSR330. Trochę mnie to zastanowiło, jaka jest różnica między nimi, więc zajrzałem na stronę tej drugiej. Z nazwy wyglądają łudząco podobnie, a prowadzącym specyfikację JSR-330 jest Rod Johnson (z projektu Spring Framework) oraz Bob Lee (z Google Guice), a za JSR-299 odpowiada Gavin King (z JBoss Seam i Hibernate). Mam wrażenie, jakby obie specyfikacje oferowały podobne funkcjonalności?! Poszukując dalej, ciekawe jest zestawienie implementacji JSR-330 na stronie Technology Compatibility Kit (TCK) - atinject:
Jak widać są wszyscy - Guice, OpenWebBeans, Spring Framework i Weld, z nieznanym mi piątym KouInject. Zdaje się, że pora na to, abym zabrał się za lekturę The Java EE 6 Tutorial, Volume I, bo inaczej pogubię się w gąszczu specyfikacji Korporacyjnej 6tki. Coś mi jednak mówi, że do zrozumienia całości, nie ma innego sposobu, jak po prostu zajrzeć do samej specyfikacji JSR 316: Java Platform, Enterprise Edition 6 (Java EE 6), bo inaczej się pogubię. Tak też zrobię, bo w specyfikacji JSR299 pełno wzmianek o specyfikacjach i o wielu nie mam bladego pojęcia (albo określa się je nowymi terminami), np. "The Managed Beans specification" (strona 2) - jakby o JSF, ale później pojawia się oddzielna sekcja 1.2.6. Relationship to JSF, więc to raczej nie JSF - i wspomniana "The Dependency Injection for Java specification" (strona 3). Ach, teraz jasne po co DI for Java! :-) Przecież wyraźnie napisano w sekcji 1.2.4. Relationship to Dependency Injection for Java (w wolnym tłumaczeniu):
"Specyfikacja Dependency Injection for Java określa zbiór adnotacji, którymi oznacza się pola, metody i konstruktory ziaren (ang. bean), które podlegają mechanizmowi DI. Usługa DI [w CDI - mój przypisek] korzysta z tychże."
Na zakończenie chciałbym przywołać opis JSR-299 Contexts and Dependency Injection for the Java EE platform ze strony Apache OpenWebBeans (w wolnym tłumaczeniu):
"Celem specyfikacji CDI [dawniej WebBeans - mój przypisek] jest ujednolicenie modeli komponentowych JSF i EJB, aby znacząco uprościć model programowania aplikacji webowych."
Bardzo trafne podsumowanie specyfikacji CDI, aczkolwiek dotyczy to szerszego spektrum technologicznego i wykracza poza JSF i EJB, gdzie POJO gra również pierwsze skrzypce. Mimo tych niedomówień, wydaje się być bardziej przystępne niż to w samej specyfikacji.
Późno już, ale na przykładzik z servlecikiem z przekazanym ziarnem CDI jeszcze się znajdzie chwilka. Zdecydowanie zbyt wiele teorii, a za mało praktyki. Odmóżdża mnie to.
Fakt istnienia obu tych specyfikacji byl bardzo kontrowersyjny od poczatku, czytalem ze wiele podmiotow bioracych udzial w glosownaiu uzaleznialo poparcie 299 od tego czy ladnie sie zintegruje z 330. Miedzy czlonkami obu expert group byly wielkie rozbieznosci. Jak komus zalezy to mozna znalezc tematy na forach / blogach gdzie GKing i BLee zararcie dyskutuja nad wadami i zaletami CDI vs Guice (o Springu obaj maja bardz podobne, niskie zdanie, szczegolnie GKing nie przebiera w slowach). Bardzo polityczne byly to specyfikacje, dodatkowo 330 bylo robione na szybko (zdaje sie ze 330 trwalo raptem 5 miechow, a wynik jaki jest kazdy widzi) bo poparcie dla 299 bylo od niej zalezne, cuda niewidy.
OdpowiedzUsuń