Xoft

Jeszcze się okaże, że będę musiał zmienić swoje sceptyczne nastawienie do JavaFX. JavaFX zostało wybrane jako technologia do wizualizacji danych o medalach na stronie Olimpiady Vancouver 2010.

Wygląda toto faktycznie dobrze, nie da się odróżnić od Flasha, można złośliwie powiedzieć. Jak Oracz zainwestuje w poprawienie narzędzi deweloperskich i sensowną bibliotekę komponentów, to może coś z tego będzie.

Ubawił mnie niezwykle wpis Bruce Eckela na Artima.com:

Last night I went to the Extreme Programming San Diego meeting (it should probably be called “Agile” but I suspect the group is old enough that XP was what started it). A reader knew that I was in San Diego visiting my folks so he suggested it. I thought I’d dip my toe in the water and see if programming was any more interesting to me than the last time I checked. Especially since Agile practices tend to be more focused on people issues, which is where I seem to continue to drift.

The first thing I noticed was the turnout. I’m guessing there are thousands of programmers in San Diego, but we got maybe 10 people to show up.

Chyba w San Diego już się połapali, że 90% Agile to wynalazek cwanych konsultantów… 10 osób to i tak niezły wynik.

No i stało się, firma Sun przeszła do historii. Oracle szumnie zapowiada, jak to będzie rozwijał i inwestował. Zapowiedzi mają niewielkie znaczenie, nawet pierwszy rzut oka wyglądają pięknie, ale parę nieprzyjemnych rzeczy z nich wynika. Nieprzyjemnych dla użytkowników produktów SUN-a.

Weźmy NetBeans. Oracle ogłosił:

Oracle will invest in the NetBeans IDE and NetBeans.org community, but it will be limited to Java Standard Edition, scripting languages, mobile Java, JavaFX and Solaris. Oracle’s own Java IDE, JDeveloper IDE, will be Oracle’s enterprise application development tool.

Czyli NetBeans będzie środowiskiem programistycznym do wszystkiego, tylko nie do Java EE. Ponieważ gro aplikacji Javowych jest pisanych właśnie w Java EE, to praktycznie oznacza utrupienie NetBeans na rzecz JDevelopera. Kto będzie chciał się wozić ze środowiskiem Javowym, w którym nie można napisać aplikacji JEE? Szkoda.

GlassFish ma być wspierany i rozwijany, ale jako serwer do aplikacji intranetowych:

WebLogic will be sold as the company’s enterprise application server, while the free and open source Glassfish server will be Oracle’s department-level application server.

Myślałem, że Oracle będzie chciał podgryzać GlassFishem JBoss-a, ale wygląda na to, że nie. W takim razie, kto będzie chciał się bawić w serwer, który w założeniu ma być “gorszy” od WebLogic-a. GlassFish, czyli tak na prawdę Sun GlassFish Enterprise Server (dawniej Sun ONE Application Server), jakoś szczególnie nie ustępuje WebLogicowi, co więc zamierza Oracle? Ma już dwa serwery aplikacyjne, teraz dochodzi trzeci; obawiam się, że GlassFish może szybo odejść w odstawkę pod pretekstem nie przynoszenia zysków. Chyba, że faktycznie Oracle ma jakiś dobry pomysł na niego.

Wygląda na to, że z kolei Oracle zamierza inwestować w JavaFX. To akurat mocno mnie dziwi, bo póki co na tle Silverlighta czy Flex-a JavaFX nie wygląda najlepiej, przynajmniej od strony potencjału bycia czymś równie popularnym, jak konkurenci. Technologicznie JavaFX jest bardzo fajnym pomysłem, ale funkcjonalność, dostępne komponenty są lata świetlne za innymi wynalazkami. Może tutaj Oracle ma jakiś ciekawy pomysł na biznes?

W poprzednim odcinku widzieliśmy, jak można sobie ułatwić życie wstrzykując zależności do klas przy pomocy Springa [reszta cyklu: część 1., część 2., część 3.]. Dzisiaj czas na coś prostszego i przyjemniejszego: Google Guice!
Czytaj resztę wpisu »

Jak widzieliśmy [część 1., część 2., część 3.] wstrzykiwanie zależności jest całkiem sympatycznym pomysłem (o ile się go poprawnie używa), ale można zapytać się, na ile jest to kosztowne? Przez koszty rozumiem tutaj nakład pracy, jaki trzeba włożyć w używanie architektury wykorzystującej DI.

Wyobraźmy sobie, że nasza aplikacja często wykorzystuje klasę NewsService. Co to oznacza w praktyce? Za każdym razem musimy wstrzykiwać do niej zależność, których potrzebuje. Nasz przykład jest dość prosty, zależności nie ma zbyt wiele, ale nawet tutaj powtarzanie przy każdym użyciu kodu

public class Client {
  public static void main(String[] args) {
    Authenticator authenticator = new UsernamePassAuthenticator("beer","beer");
    Driver driver = new SqlDbDriver();

    //inject dependency #1
    Storage storage = new DBStorage(driver);
    //inject dependency #2
    NewsService newsService = new NewsService(storage);
    //inject dependency #3
    newsService.setAuthenticator(authenticator);

    newsService.addNews("ble ble ble");
  }
}

nie jest zbyt zachęcające. Czy nie lepiej jest użyć jednak jakiego wzorca factory czy service locator, żeby jednak NewsService sam sobie znalazł potrzebne klasy?
Czytaj resztę wpisu »

Kontynuujemy dalej naszą przeprawę z DI [część 1., część 2.]. W tym odcinku postaramy się w końcu coś popsuć – radosny marsz ścieżką usłaną różami jest przyjemny ale nie zawsze pouczający.

Zastanówmy się na ile użycie wstrzykiwania zależności czyni nasze oprogramowanie odpornym na błędy przy projektowaniu architektury aplikacji. W końcu nawet najwspanialszy wzorzec projektowy nie zabroni nam popełniania błędów.

Przyjrzyjmy się nieco zmodyfikowanej klasie NewsService

public class NewsService {

  Storage storage;
  Authenticator authenticator;

  public NewsService(Driver driver) {
    storage = new DBStorage(driver);
  }

  public Authenticator getAuthenticator() {
    return authenticator;
  }

  public void setAuthenticator(Authenticator authenticator) {
    this.authenticator = authenticator;
  }

  public void login(String uname, String pass){
    ((UsernamePassAuthenticator)authenticator).setUname(uname);
    ((UsernamePassAuthenticator)authenticator).setPass(pass);
  }

  public void addNews(String news){
    if(authenticator != null){
      authenticator.authenticate();
    }
    storage.save(news.getBytes());
    System.out.println("News saved...");
  }
}

Różni się ona od poprzedniej wersji w jednym drobnym, ale bardzo istotnym szczególe. Klasa NewsService w konstruktorze pobiera jako parametr sterownik (obiekt Driver), a nie, jak poprzednio Storage. W rezultacie NewsService sam sobie musi utworzyć obiekt Storage.

Kod NewsService jest wówczas związany na sztywno z konkretną implementacją kontenera na dane DBStorage, co jest oczywiście niepożądane. Co się zatem stało, co zrobiliśmy nie tak – w końcu używamy DI? A no popełniliśmy błąd polegający na tym, że wstrzykujemy do NewsService nie ten obiekt, co trzeba!

NewsService nie potrzebuje do niczego informacji o użytym sterowniku, NewsService potrzebuje tylko konkretnej implementacji Storage i to ona już ma się martwić o sterownik.

Ok. tutaj przypadek był prosty i ewidentny. W większych aplikacjach łatwo popełnić błąd polegający na wstrzyknięciu nie tego obiektu, który tak na prawdę jest wymagany. Także jeżeli widzimy, że gdzieś inicjalizacja klasy wymaga tworzenia obiektów, albo przekazujemy klasie jako parametr obiekty, które, logicznie rzecz biorąc, nie są jej potrzebne, to znaczy, że gdzieś położyliśmy architekturę aplikacji i błędnie użyliśmy DI.

Użycie DI wcale nie uwalnia nas od dobrego zaprojektowania aplikacji!

W poprzednim wpisie znęcaliśmy się nad niezbyt gramotnie napisanym kawałkiem oprogramowania. Teraz przyszedł czas na napisanie wszystkiego tak, jak trzeba, w czym nam pomagać będzie właśnie wstrzykiwanie zależności.

Co nas najbardziej uwierało w poprzedniej wersji aplikacji? Tak na prawdę były to dwie rzeczy:

1. Powiązania między klasami były zrealizowane przy użyciu referencji do konkretnych klas: jeżeli NewsService potrzebował mechanizmu do przechowywania informacji, to dawaliśmy mu referencję do klasy, która potrafiła przechowywać dane w SQL-owej bazie danych. Zmiana sposobu przechowywania danych na inny wymagała zmian w wielu miejscach w kodzie.
2. Jeżeli klasa potrzebowała do pracy innej klasy, to sama musiała sobie utworzyć odpowiedni obiekt: NewsService potrzebując klasy do przechowywania danych sam sobie tworzył jej instancję.

Co w takim razie robi wstrzykiwanie zależności? Mówiąc ogólnie, w DI chodzi o to, żeby nie wiązać się z inną klasą poprzez użycie jej implementacji, tylko poprzez interfejs, pod który można podpiąć dowolną klasę go implementującą.

Dodatkowo, jeżeli nasza klasa potrzebuje konkretnej implementacji tego interfejsu, to nie powinna tej implementacji sama szukać czy jej tworzyć. Odpowiedni obiekt musi zostać do klasy “wstrzyknięty” w momencie inicjalizacji.

Zobaczmy, jak to wygląda w praktyce.
Czytaj resztę wpisu »

Gdzie się człowiek nie obejrzy tam się czai Dependency Injection (DI), czyli wstrzykiwanie zależności. Żeby jeszcze było tego mało, jak się zaczyna grzebać w internecie, to się co chwila można potknąć o jakiś framework, kontener czy coś takiego, co nam samo może zrobić Dependency Injection.

Co to w ogóle jest, po co takie coś komukolwiek, jak tego używać? Okazuje się, że sprawa jest prosta, wręcz banalna, a jednocześnie prowadzi do całkiem interesujących zastosowań. Za chwilę postaramy się zrozumieć jak DI działa, zrobimy to w sposób praktyczny, obdarty z krążących wokół DI ideologii i zupełnie zbędnego adżajlowego bełkotu.

Przekonamy się, że DI jest jednym z wielu możliwych sposobów budowania architektury aplikacji tak, by była łatwa w rozbudowie i testowaniu.

Będziemy chcieli zobaczyć coś więcej, niż zupełnie trywialny przykład (takich jest mnóstwo w internecie), po którym w zasadzie można wzruszyć ramionami, bo nie specjalnie widać tam jakiekolwiek zalety architektury wykorzystującej DI.

Naszym celem będzie zbudowanie bardzo prostej aplikacji służącej do przechowywania informacji, będzie składała się ona z trzech warstw (trójka jest nieprzypadkowa, sporo aplikacji Java EE jest rozbijane na tyle warstw) i tyluż komponentów.

Naszą aplikację napiszemy na kilka sposobów:

• naiwne podeście z paskudną architekturą;
• w miarę rozsądnie wyglądająca aplikacja, wykorzystująca wstrzykiwanie zależności;
• aplikacja wykorzystująca wstrzykiwanie zależności, ale zrobiona źle – warto wiedzieć, że wbrew wrażeniu, jakie można odnieść po ohah i ahah na temat DI, przy jego pomocy też można koncertowo skopać architekturę tworzonego oprogramowania.
• ta sama aplikacja, wykorzystująca wstrzykiwanie zależności i kontener Spring;
• jeszcze raz to samo, ale z wykorzystaniem Google Guice;
• następnie spróbujemy porównać działanie Spring i Google Guice;
• wreszcie, na końcu trochę “filozofii”, czy faktycznie DI jest potrzebne, czy jest potrzebne tylko Javie, jak to jest z innymi językami.

Zatem, do dzieła!
Czytaj resztę wpisu »

Naszym celem jest utworzenie prostej aplikacji szukającej plików na dysku, gotową aplikację można uruchomić przez Java WebStart, dostępny jest oczywiście kod źródłowy, powiedzmy, że na licencji BSD ;).

Wstęp
Swing Application Framework jest szkieletem aplikacyjnym, który ma uprościć tworzenie aplikacji desktopowych w Java Swing. SAF z założenia ma być rozwiązaniem prostym, rozwiązującym podstawowe problemy, na jakie napotykamy się tworząc programy z interfejsem użytkownika w Javie.

Czym więc zajmuje się SAF?

• Cyklem życia aplikacji od jej uruchomienia po zamknięcie
• Zarządzaniem zasobami: łańcuchami znaków, kolorami, ikonami, czcionkami itp. rzeczami, które występują w typowej aplikacji. Oczywiście wszystkie zasoby mogą być internacjonalizowane/lokalizowane.
• Obsługą zdarzeń (co ma się stać, gdy użytkownik naciśnie przycisk X). W szczególności SAF upraszcza znacząco obsługę długotrwałych zdarzeń, które powinny wykonywać się w wątkach roboczych, a nie głównym
• Pamiętaniem stanu aplikacji. Po zamknięciu aplikacji pamięta ona jaki był stan interfejsu użytkownika (rozmiar okien, ich położenie) przed zamknięciem.

Żeby nie przedłużać wstępu przejdźmy do rzeczy, czyli przyjrzyjmy się przykładowej aplikacji Szukacz. Szukacz jest kulawą i ubogą namiastką grep-a napisaną w Javie, ma za to graficzny interfejs użytkownika.

Aplikacja jest skonstruowana inaczej niż w większości tutoriali Swing Application Framework, które można znaleźć w Internecie. Problem z umieszczonymi tam przykładami jest taki, że w rzeczywistej sytuacji są one mało użyteczne. Przykłady te dzielą się na dwie grupy:

1. aplikacje wyklikane od początku do końca w środowisku NetBeans, korzystające z kreatorów kodu tam dostępnych
2. aplikacje napisane całkowicie ręcznie, włącznie z elementami GUI

Tak na prawdę żadna z tych sytuacji nie jest typowa.

Ad. 1. Nie każdy musi chcieć używać NetBeansa (fakt, jest bardzo dobry jeśli chodzi o tworzenie GUI), a nawet jeżeli używamy go, to istnieje duża szansa, że mamy już napisany jakiś spory kawał kodu, który nie używa SAF i chcielibyśmy jakoś gładko istniejący kod zintegrować z tym frameworkiem.

Ad. 2. Jeśli nie jesteśmy maniakalnymi zwolennikami ręcznego dziergania kodu GUI, co zazwyczaj kończy się mniejszą lub większą katastrofą połączoną z gromami rzucanymi na Swinga i Javę w ogóle, to pewnie chcemy użyć jakiegoś wizulanego narzędzi, które pozwoli nam wyklikać strukturę GUI. Narzędzie to na bank nie słyszało jeszcze o SAF, a my chcemy sobie klikać interfejs użytkownika i jednocześnie łatwo go zintegrować z SAF.

Tak więc chcę pokazać, jak tworzyć sobie GUI takim sposobem, jak nam się podoba i móc go w każdej chwili zintegrować z SAF. Zatem do dzieła. Czytaj resztę wpisu »

Wygląda na to, że są to dwaj najpopularniejsi gracze na rynku darmowych ajaksowych komponentów JSF, co zatem wybrać? Pierwsza rzecz: czy trzeba w ogóle wybierać? Niestety tak, obie biblioteki nie chcą ze sobą współpracować – każda z nich inaczej włącza się w cykl życia strony JSF i to powoduje różna zabawne problemy. Podobno w którejś tam wersji ma być możliwa koegzystencja obu produktów…

Porównanie obu bibliotek można znaleźć na stronie JSF Matrix, ale niewiele z niego wynika, jak to zazwyczaj bywa ze statystykami w rodzaju “liczba dostępnych komponentów”.

Kto i co robi
Zacznijmy od krótkiego przedstawienia obu bibliotek.

RichFaces. Biblioteka była produktem firmy Exadel, która połączyła się, albo została kupiona przez JBoss-a, czyli RedHata. Ehh, ten świat wielkich korporacji… Biblioteka jest dostępna na licencji Open Source, zawiera ponad 50 różnych komponentów JSF.

ICEFaces jest robiona przez firmę ICESoft i też jest opensorsowa.

Zalety RichFaces i wady ICE Faces
Dużą zaletą RichFaces jest pod-biblioteka Ajax4JSF, która pozwala “zajaksować” dowolny komponent JSF. Jest to bardzo wygodne, jeżeli mamy już napisany kawałek aplikacji i chcemy gdzieniegdzie ją upiększyć ajaksowymi wodotryskami.

Kolejną przyjemną cechą RichFaces jest możliwość określenia zachowania komponentów tak, żeby niekoniecznie za każdym razem łączyły się z serwerem (Ajaxa im można wyłączyć, innymi słowy). Można na przykład utworzyć stronę z zakładkami w ten sposób, że wszystkie są od razu ładowane i przy ich zmianie nie jest potrzebny kontakt z serwerem. Oczywiście można także skonfigurować sobie zachowanie ajaksowe, czyli zakładki będą doładowywane dynamicznie.

ICEFaces czegoś takiego nie potrafi, jego komponenty zawsze kontaktują się z serwerem, co jest trochę głupie w przypadku dajmy na to komponentu kalendarza – można go przecież zrobić łatwo po stronie klienta, każdorazowy kontakt z serwerem jest w 95% przypadków zbędny. Swoją drogą to jakaś obsesja, większość komponentów kalendarzowych ludzie robią ajaksem, tak przynajmniej mówi jsfmatrix.net.

ICEFaces pozwala używać JSF 1.2, ale wymaga używania trybu zgodności ze specyfikacją JSF 1.1. Trochę lipa.
W web.xml trzeba deklarować użycie starej wersji JavaServelts

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

a w faces-config.xml:

<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN" "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">

Przez to nie możemy wykorzystać różnych fajnych rzeczy, które wniosło JSF 1.2.

Łatwiej jest testować aplikacje, które używają RichFaces, bo JSFUnit wspiera właśnie to rozwiązanie – nic w tym dziwnego, gdyż JSFUnita robi RedHat.

Zalety ICE Faces i wady RichFaces
Ok, wygląda na to, że RichFaces wygląda lepiej, ale parę rzeczy w ICE też mi przypadło do gustu. Przede wszystkim wygląd, komponenty są na prawdę dopracowane, wyglądają perfekcyjnie.

Druga rzecz, to sposób odświeżania strony JSF. ICE robią aktualizację wszystkich elementów ajaksowych na całej stronie, dzięki czemu nie musimy się martwić o synchronizację obsługi różnych żądań ajaksowych. W RichFaces trzeba to robić ręcznie, co ma swoje wady.

ICEFaces mają lepiej działającą obsługę ajaksa w trybie “push”, RichFaces też to potrafią, ale stosunkowo od niedawna, więc ciężko stwierdzić, na ile ich implementacja działa niezawodnie.

No i wreszcie na koniec ICEFaces dobrze integrują się nie tylko z Eclipse, ale także z NetBeansem (dla mnie to ważne, bo coraz częściej używam tego drugiego).

Decyzja?
Póki co, zdecydowanie RichFaces.