Coś się chyba Helionowi pomyliło

Dziś o czymś troszeczkę innym niż Grails. Odwiedziłem stronę wydawnictwa Helion, coby przepatrzyć jakieś promocje czy nowości. Jakie było moje zdziwienie, kiedy na stronie głównej pośród nowości zobaczyłem tę oto książkę.

Jasno i wyraźnie stoi napisane, iż jest to TOM 2. Hmmm, a gdzie tom pierwszy? W swojej naiwności liczyłem na to, że może chodzi o książkę o JSF, którą miałem okazję zakupić i leży u mnie na półce. Rzeczywistość okazała się jednakże inna – nasze cudowne wydawnictwo przetłumaczyło i wydrukowało tylko drugi tom! Z ciekawości zajrzałem do googla i co się okazuje? Że tom pierwszy tejże książki można sobie spokojnie ściągnąć z internetu spod tego adresu. Wiadomo, jest też jakieś “ale” – w treści książki mamy materiały reklamowe (niezbyt dokuczliwe), a także nie da się ściągnąć wersji all-in-one. Jednakże i to jest świetna gratka dla każdego, kto chciałby poznać tę technologię bliżej. Do tej pory pozostawało tylko “Head First”, a niekoniecznie każdemu forma tej serii wydawniczej pasuje. Jak widać i z pomyłek mogą narodzić się konkretne korzyści :)

Swinguj z nami czyli piszemy aplikację cz.2

Po kilku miesiącach od pierwszego wydania przyszła kolej na krok dalej – oto druga wersja klienta do gry w Arkadię, opartego na Swingu i mojej niedostatecznej znajomości Javy :)

Przyznaję, że wydanie to mogłoby pojawić się wcześniej. Jednakże wpierw mały romans z JEE, a potem wypadki losowe odwlekły ten fakt w czasie. Przez kilkanaście ostatnich dni przysiadłem fałdów i oto jest – druga wersja ChlebikClient. Wiele jeszcze jej brakuje do optymalnego funkcjonowania jako wymarzony klient, jednakże widać już pewne zarysy jak mogłaby wyglądać taka aplikacja, kiedy bierze się za nią newbies. Jednakże postanowiłem, że wydanie drugie będzie również i ostatnim – gdyż kolejne wydania byłyby po prostu dokładaniem bardzo podobnych do obecnych cegiełek. Czyli kolejny JInternalFrame, kolejny plik XMLa i tak dalej – ani to wiele już nie rozwija, a i sensowności dalszej w tym nie ma zbyt wiele.

Popracowałem z NetBeansem używając jego pomocy do tworzenia GUI, mam mniej więcej pojęcie o wątkach aplikacji pisanej w Swingu (choć i tak niewiele jak znam życie), operowanie podstawowe na plikach XML, poszczególne komponenty też obejrzałem sobie z kilku stron. Na dzień dzisiejszy dalsze prace zostają wstrzymane i odłożone na czasy obfitujące w wolny czas (może kiedyś nadejdą). Póki co zapraszam na podstronę projektu, gdzie można przeczytać listę zmian oraz ściągnąć najnowszą wersję.

Co zaś do przyszłości – zmierzam w kierunku JEE. Dla nauki rozpoczynam pisanie aplikacji internetowej. Wstępnie technologie użyte to JSP, Hibernate/JDBC, wszystko zapakowane w Tomcata. Być może tym razem spróbuję użyć do pracy Eclipse’a wraz z jego rozszerzeniem WTP.

JSF i dlaczego jestem zdumiony

Jak wspomniałem w jednym z poprzednich wpisów nabyłem trochę ciekawych książek o wiadomym temacie. No i po tym jak ‘prześlizgnąłem się’ po Head-First JSP i Servlety zabrałem się od razu za Core JSF. I ZONK! Po raz kolejny podejście wzięte z PHP sprawiło, że uderzyłem o ścianę. Ale tym razem cholera miało być inaczej.

Tok mego rozumowania był prosty – mamy JSP i serwlety. Służy to do pisania aplikacji webowych dla platformy JEE (nie całych, ale na pewno widoku i kontrolera). Znaczy się może służyć, bo wiadomym jest, że dzisiaj raczej w czystych językach nikt nie pisze – używa się różnych bibliotek i komponentów, których połączenie często okazuje się na tyle fajne, że powstaje framework. I takie coś mamy w PHP – język językiem, no ale w okolicy wersji 5.1 kiedy to OOP przestało być czymś na papierze, a stało się rzeczywistością pojawiły się pierwsze frameworki. Kiedy rozpoczynałem pracę jako koder PHP dostałem się w szpony Zend Frameworka i wciąż w nich tkwię. Po drodze bawiłem się trochę Symphony, a także RORem (choć to inny język). Dla mnie zatem framework to zestaw przynajmniej gotowych komponentów, które rutynowe czynności w budowie aplikacji sprowadzają do inicjalizacji kilku obiektów i wywołania ich metod. To co potrafi momentami Symphony czy ROR to już w ogóle kosmos i nic dziwnego, że ludzie tego używają.

Wracając do Javy – myślałem, że JSP to takie PHP, no a JSF to framework, czyli liznę tego pierwszego na razie byle się tylko orientować, przepatrzę książkę o JSFie i wezmę się za pisanie projektu łączącego tę wiedzę w jednym. Może to wina książki, albo i samego narzędzia. Jednakże załamało mnie to, iż po lekturze 100 stron to wiem na pewno, że wszystko o czym czytam zostanie omówione w następnych rozdziałach. No nic, przepatruję z ciekawości spis treści. Przerobiłem na chwilę obecną wstęp, coś o beansach, rozdzialik o nawigacji (XML rządzi) i zacząłem znaczniki standardowe. Zostaje mi rozdział o znacznikach niestandardowych, weryfikacji danych, obsłudze zdarzeń i… w sumie nic. Bo następne rozdziały to niestandardowe elementy, potem JDBC/LDAP, AJAX no i omówienie bardzo pokrótkie inych frameworków!!! Na koniec mam rozdział zatytułowany ‘Jak to zrobić?’. Mam pomysł by na tym pytaniu oprzeć ćwiczeniowy projekt pisany w JSP (aplikacji internetowej) zatem przerzuciłem te 400 stron i wziąłem się za szybkie przeglądanie rozdziału. ZONK!

Rozbiło mnie już pytanie trzecie (sic!) na łącznie około 35. Jak zaimplementować obsługę wysyłania plików na serwer?. O nareszcie coś z bliskich mi klimatów. Dla niezorientowanych w temacie PHP wyjaśniam – w tym języku jest to kwestia sprawdzenia czy przesłano element “file” z formularza, po czym sprawdza się czy plik doszedł i zapisuje się go w docelowym katalogu. W wersji spartańskiej robi się to może 5 linijkami kodu (wliczając po nawiasach klamrowych na linię). W Zend Frameworku mam do tego jego element w postaci Zend_File, a w nim cuda niewidy – walidatory, filtry, plus adaptery dla wysyłania plików. Można to łatwo zobaczyć – kilka linii kodu i działamy.

A co mamy w JSF? Chwilka, już liczę… Serwlet filtrujący (109 linii kodu) plus klasa renderująca (89 linii) plus klasa dla znacznika ( 28 linii ) plus sam plik JSP ( 18 linii ), ale to można pominąć. Szybkie dodawanie i okazuje się, że by wysłać plik na serwer i wiedzieć, że dotarł cały i bezpieczny muszę sklepać ponad 200 linii kodu!!! Cholera no to jest framework czy jakiś #$@#@%^^%? Jak można nazywać taką technologię frameworkiem, skoro zamiast usprawniać tworzenie aplikacji niewiele ona w sobie zawiera? No niby co poza jasno określonym MVC (ale przecież JSP też to ma, a tu jeszcze od cholery XMLa na ścieżki nawigacji), pomocą z renderowaniem widoku (View) czy w końcu znacznikami JSF technologia ta może zaoferować?

Ufff, przepraszam, uniosłem się, to był przedostatni raz. Naprawdę zaczynam rozumieć, dlaczego w ogłoszeniach o pracę dla javowców wymienia się po 4 elementy z każdej dziedziny (Struts, Spring, JSF, Ant, Maven, Hiberante, TopLink, iBATIS, JBoss, WebSphere, Tomcat). Nie wiem, ja generalnie młody jestem, zaczynam bawić się w te klocki, ale błagam, niech ktoś mi powie: “potem będzie lepiej”. Framework będzie frameworkiem z zapleczem, a nie tylko ulepszonymi grabiami czy łopatą. Proszę niech ktoś powie: “młody jesteś, ucz się dalej”. Jak już poznasz to zrozumiesz.

Proszę :)

Christmasing-Holidaying

Te słowotwórcze potworki w tytule tego wpisu doskonale oddają mój stan od kilku dni, a co więcej, będą dalej go uosabiać do 7 stycznia kiedy to po dłuuuuugiej przerwie pojawię się w pracy. Okazuje się, że nawał pracy przed świętami jest dobry, bo wyrobione wówczas nadgodziny można spożytkować w bardzo przyjemny sposób – na przykład mając możliwość pójścia na długi urlop. Na blogu nie piszę zasadniczo o niczym innym jak Java i pokrewne technologie, ale święta i urlopy to wyjątek.

Zatem zacznijmy od najważniejszego – życzę wszystkim czytelnikom mojego bloga (oj a naprawdę jest ich całkiem sporo, co mnie cieszy niepomiernie) spokojnych świąt i szczęśliwego nowego roku. Wiem, że podobne słowa krzyczą obecnie z każdego miejsca (nawet w lodówce :), ale pragnę zapewnić, że są to życzenia szczere i płynące z dobrego serca. Obyście mogli w spokoju wypocząć i nacieszyć się życiem, niezależnie czy uznajecie te święta czy nie. To raz.

Dwa, że znowu znikam na jakiś czas. Konkretnie – na czas urlopu. Wizyta w domu rodzinnym, a potem zapakunek do samochodu i wyprawa w kierunku Świeradowa-Zdrój, gdzie wraz z przyjaciółmi wybieram się w okresie sylwestrowo-noworocznym na narty. Czyli znowu góry, podobnie zresztą jak latem, ale kilka kilometrów na zachód od Szklarskiej Poręby. Na nartach ostatni raz jeździłem w liceum (tzw. zielone szkoły), czas zatem sobie po tych 6 latach przypomnieć o co w tym sporcie chodzi. Mam nadzieję, że nic się nie stanie, tym bardziej, że biorę żonę, która na nartach jeszcze nigdy nie jeździła :) Do Warszawy wrócę 6 stycznia – i w okolicach tego dnia należy spodziewać się kolejnych wpisów.

Co do przyszłości – rysuje się ona w dość ciekawych kolorach. Jak tylko znajdę chwilkę czasu by wydać wersję 0.2 ChlebikClient zaczną się wpisy na temat J2EE, póki co głównie o JSP i servletach, z czasem pójdziemy dalej. Przy poprzednim urlopie zapowiadałem, że zacznę cykl o pisaniu systemu blogowego w JSP, ale czas i okoliczności zrewidowały te zamierzenia na rzecz Swinga i klienta do Arkadia MUD. Jednakże może to i dobrze? Zobaczymy co czas przyniesie, póki co kiełkuje u mnie powoli ciekawy pomysł na cykl artykułów, a także będący ich rezultatem portal.

Trzymajcie się ciepło.

Wierzchołek góry lodowej czyli Java i XML

O tym, że XML w świecie internetu odgrywa rolę fundamentalną nie muszę chyba nikogo przekonywać. O tym, że podobna sytuacja ma miejsce w przypadku Javy wiedziałem już wcześniej, choć dopiero lektura opisywanej ostatnio książki pokazała, że XML jest de facto standardem przyjętym w świecie Javy jeśli chodzi o konfigurację oraz przesyłanie danych. W kolejnej wersji ChlebikClient konfiguracja będzie w związku z tym oparta na plikach XML. Są one o tyle fajne, że ich edycja jest banalna, zaś jeśli chodzi o obsługę programową to mnogość narzędzi jest przytłaczająca.

W swojej aplikacji postanowiłem użyć powszechnie znanej biblioteki Dom4j. Umożliwia ona operowanie na plikach XML oferując API, które jest cokolwiek bardziej użyteczne niż te oferowane przez SAX, który jest niskopoziomowym API dla XMLa w Javie opartym na sterowaniu zdarzeniami. Odczyt pliku XMLa w przypadku dom4j jest banalny.

Podstawowym obiektem, na którym przyjdzie nam operować to org.dom4j.Element – jest to interfejs, który implementuje sporo klas z tego pakietu.

Załóżmy, że mamy plik XML z 2 elementami, w ktorych do tego mamy 2 potomków. Czyli np. element “wyszukiwarki” z dwoma potomkami (onet i google), a do tego też element “portale” z znów dwoma potomkami (interia i gazeta). Odczytanie tego pliku i zapisanie węzłów do LinkedHashSet można zrealizować tak (obiekt document jest instancją klasy org.dom4j.document, która reprezentuje cały wczytany plik XML):

org.dom4j.Element root = document.getRootElement();
LinkedHashSet listaWartosci = new LinkedHashSet();

for ( Iterator i = root.elementIterator(); i.hasNext(); ) {
DefaultElement element = (DefaultElement) i.next();
listaWartosci.add(element);
}


Proste? A pewnie, że proste. Choć to oczywiście wierzchołek góry lodowej jak mówi tytuł wpisu – o XMLu i Javie z pewnością jeszcze napiszę.

W końcu dobra książka

Ano to prawda. Nareszcie w Polsce ukazała się pozycja, która nie jest głębokim opisem języka, ale też nie jest szczegółowym opisem jednej z dostępnych technologii. Mowa o “Eclipse Web Tools Platform”, którą to dziś przez zupełny przypadek znalazłem w Empiku. Zdziwienie moje było tym większe, iż z ofertą wydawnictwa Helion staram się być w miarę na bieżąco, a o tej pozycji jakoś nic nie wiedziałem. Powód mej niewiedzy był prozaiczny – ktoś tę cenną pozycję wrzucił do działu ‘JavaScript’… Pozostawię bez komentarza.

No ale do rzeczy. Książka kosztuje jak typowa pozycja dotycząca Javy, czyli sporo (okrągłe 99 zł). Ale już po pobieżnym przejrzeniu wiedziałem, że na pewno nie będzie to chybiona inwestycja. O czym traktuje ta książeczka? Ano kilka osób tworzących WTP, czyli rozszerzenie Eclipse’a wspomagające budowanie aplikacji webowych i EE, wzięło się za napisanie na ten temat książki. I trafili w dziesiątkę (przynajmniej według mnie), gdyż do tej pory w naszym kraju nie było równie fajnej pozycji, która pokazywałaby proces tworzenia aplikacji tego typu od podstaw i z użyciem konkretnego narzędzia. Co więcej – poruszone są wszystkie zagadnienia szeroko pojętego J2EE – servlety, bazy, XML, webservices. Cud, miód i orzeszki. Wracam do lektury – mam nadzieję, że zaowocuje ona kilkoma wpisami na blogu.

Java API tak na sam początek

Standardowo książki poświęcone PHP szczegółowo opisują większość możliwości tego języka. Czyli wpierw mamy słowa kluczowe, przepływ sterowania, potem coś o tablicach, stringach, plikach, itd. W Javie niestety – rzecz ma się zupełnie inaczej.

A by się o tym przekonać wystarczy spojrzeć na spis treści książek poświęconych temu językowi. Taka Thinking in Java to ponad tysiąc stron czystego tekstu (wraz z kodem), a nie omawia nawet połowy tych funkcjonalności języka, które w każdej książce o PHP są szczegółowo omówione. Podobnie z Java Core, choć tutaj jest trochę lepiej. Dlaczego o tym piszę? Bynajmniej nie zamierzam płakać, że nie jestem prowadzony za rączkę, co to, to nie! Pragnę tylko zaznaczyć, iż czasy kiedy po przeczytaniu książki można było spokojnie klepać jakieś proste aplikacje się skończyły. API Javy to ponad 3 tyś. klas!!! To znaczy, że w tych klasach mamy jeszcze najczęściej parę metod, które wyczyniają cuda, których nie powstydziłby się Pan McGyver z Chuckiem Norrisem razem wziętymi. Zapamiętać to jest niemożliwością, omawianie tego w książce również.

Dlatego też trzeba przysiąść fałdów i zajrzeć samemu do specyfikacji języka. Można ją odnaleźć tutaj, ale te sterty HTMLa niekoniecznie wyglądają zachęcająco. Postanowiłem zatem poszukać czegoś w bardziej przystępnej formie, co zaowocowało wizytą na stronie KickJava.com Od zwykłego opisania API na stronach Suna odróżniają tę stronę dwie rzeczy – bardziej przyjazny design (tak, wiem, że strony Suna czyta się lepiej pod linksem czy innym konsolowym ustrojostwem), a także przykłady kodu. Jest to bardzo istotna rzecz dla newbiesów w Javie, gdyż często wrzucenie samej deklaracji metody z listą parametrów nie załatwia sprawy. Tutaj zaś każda klasa jest opatrzona bardzo konkretnym kawałkiem kodu. Dla przykładu kod dla javax.servlet.http opisuje zarówno tworzenie obiektu jak i procesowanie żądania – kliknij tutaj.

Jak zatem widać jest to obowiązkowa strona dla wszystkich. Pozostając zaś w tematyce ciekawych serwisów poświęconych Javie należy wskazać na JavaBlackBelt.com. Serwis ten umożliwia sprawdzenie swojej wiedzy na temat Javy (oraz całości platformy) w formie testów. Kolejne stopnie wtajemniczenia są opisywane poprzez kolory pasów (podobnie jak w sztukach walki). Dla początkujących polecam podstawowe zestawy pytań dotyczące Javy SE, servletów oraz OO. Co prawda jeszcze nie zarejestrowałem się w serwisie (nastąpi to pewnie po powrocie z nadchodzącego urlopu), ale na pewno nie odpuszczę możliwości podrasowania sobie ego zdobywając kolejne kyu. Niech moc będzie z Wami!

Java Server Pages i servletowe podwórko

Wspomniałem już przy okazji poprzedniego wpisu o serwletach oraz o technologii Java Server Pages. W dużym skrócie – serwlety to po prostu aplikacje Javy wykonywane po stronie serwera, zaś JSP to technologia umożliwiająca dynamiczne generowanie dokumentów (X)HTML poprzez osadzenie w kodzie HTMLa wstawek z języka Java (za Wikipedią). Dodatkowo rzecz z automatu jest realizowana we wzorcu MVC (Model-View-Controller), co można ostatecznie podsumować stwierdzeniem, że mamy bardzo przyjemne narzędzie do tworzenia aplikacji internetowych.

Dlaczego o tym piszę? Albowiem jako programista PHP pracujący nad projektami o bardzo pojemnej nazwie ‘webdevelopment’ automatycznie kieruję się w stronę znanych mi rozwiązań, a za takowe JSP (i potem Java Server Faces – to framework) można uznać. Jednoczesne poznawanie Javy (za pomocą Bruce’a Eckela i jego ‘Thinking in Java’) oraz JSP (książka ‘Head First JSP’) póki co okazało się dość obiecującym rozwiązaniem, gdyż zamiast klepać standardowe do bólu System.out.println i zachwycać się rozbudowaną konwersacją z konsolą, można tworzyć kod wypełniając znany sobie szkielet aplikacji (np. tworząc system blogowy).

Do rozpoczęcia zabawy z JSP potrzebujemy jednej rzeczy – kontenera na serwlety. Rolę tę pełni świetnie Apache, kiedy doinstaluje się do niego odpowiedni moduł, albo też kiedy zainstaluje się Apache Tomcat jako samodzielny serwer (www + jsp w jednym). Zasadniczo wyszedłem od tej koncepcji (czy wspominałem już, że jestem leniwy jeśli chodzi o babranie się z administracją?), a następnie spróbowałem jakoś to wrzucić (pluginem oczywiście) pod Eclipse’a. Po strawieniu 3h nad konfigiem oraz próbą zmuszenia tej aplikacji by w końcu zobaczyła mój plugin do Tomcata dałem za wygraną i postanowiłem ściągnąć NetBeans. Downloaded, zainstaluj, uruchom, ściągnij update i viola!!! Nagle okazało się, że wystarczy stworzyć nowy projekt i nacisnąć ‘Build all’ – wszystko pięknie śmiga. Jako, że była gdzieś 3 nad ranem porzuciłem zabawę, ale wróciłem do niej zaraz następnego dnia.

NetBeans ma to do siebie, że można go ściągnąć w kilku wersjach. Bardzo ważne jest to, że możemy również wybrać wersję niejako ‘out of the box’, gdyż razem z IDE dostarczany jest też Tomcat oraz GlassFish (to serwer aplikacji J2EE firmy Sun). Po zainstalowaniu otrzymujemy (pod Windowsem oczywiście) w pełni skonfigurowane narzędzie. Tutaj właśnie uwaga – opiszę co i jak by skonfigurować pierwszy projekt i uruchomić go. W książce ‘Head First JSP’ przedstawiono podział na 2 środowiska – developerskie oraz aplikacyjne (czyli produkcyjne). Jest to rozwiązanie poniekąd słuszne, jednakże na czas nauki, kiedy człowiek musi przypominać sobie czasem składnię podstawowych funkcji, jakoś nie widzę ku temu sensu.

W NetBeans zatem skonfigurujemy projekt tak, aby dało się w obrębie jednego katalogu jednocześnie posiadać kod źródłowy, jak i widzieć go (po kompilacji oczywiście) z poziomu przeglądarki. Oto co trzeba zrobić:

1. Okienko z projektami -> prawy przycisk myszy i oczywiście New Project
2. Pokazuje się lista do wyboru, nas interesuje Web, a potem Web Application
3. Nadajemy projektowi nazwę, NetBeans automatycznie poda domyślną ścieżkę do niego (czyli katalog webapps w katalogu gdzie zainstalowano Tomcata).
4. Pojawią się informacje o używanej wersji serwera i takich tam – wybieramy oczywiście to, co zainstalowane (najprawdopodobniej Tomcat 6.0, Java EE 5).
5. W następnym kroku mamy możliwość wyboru używanego frameworka. Jako, że nic takiego na razie nie ma miejsca, to klikamy Finish i mamy gotowy szkielet projektu.

By przetestować działanie całości należy prawym przyciskiem myszy kliknąć na nasz projekt (w okienku projektów) i wybrać Build. NetBeans nam pokompiluje co trzeba i następnie znowu pod prawym przyciskiem wybieramy Run i po paru sekundach mielenia otwiera się nam przeglądarka i pojawia się śliczne ‘Hello wordl!’ (adres to http://localhost:8084/TWOJANAZWAAPLIKACJI/).

Teraz kiedy już mamy działający projekt trzeba objaśnić trochę strukturę katalogów. Różni się ona od przyjętej w ‘Head First’, zatem dla jasności napiszę co i gdzie. Struktura katalogów w folderze naszej aplikacji wygląda tak:

1. Katalog nbproject to internalsy NetBeans i nie należy tego na razie dotykać.
2. Podobnie rzecz ma się ze znajdującym się w katalogu aplikacji plikiem build.xml oraz katalogiem dist – to informacje na temat sposobu budowania projektu, a w katalogu z kolei umieszcza się ostatecznie przygotowaną paczkę z kodem (w formie pliku *.war).
3. Katalog test służy zgodnie z nazwą do testów (testów jednostkowych opartych na JUnit)
4. W katalogu build zgodnie z nazwą budowany jest cała aplikacja
5. W katalog src znajduje się nasz kod źródłowy
6. I na sam koniec w folderze web znajdują się nasze pliki *.jsp i *.html (wraz z plikiem web.xml).

Oczywiście normalnie nikt nie będzie grzebał bezpośrednio w plikach w tym folderze – od tego jest IDE. Jednakże dobrze wiedzieć co i z czym, zwłaszcza dla początkujących informacja ta może być dość istotna. Nasz projekt póki co nie zawiera kodu Javy, ale jest w pełni gotowy na jego przyjęcie. Na razie rzut oka na okienko IDE:

Aplikacja na razie jest dla nas interesująca w dwóch miejscach. Pierwszym z nich jest katalog Source Packages. Tutaj należy dodawać kolejne pakiety, a w nich klasy (np. com.wordpress.chlebik.TestowaKlasa.java). Umieszczone tutaj zostaną w procesie budowania projektu skompilowane i przerobione na postać strawną dla serwera. Drugim ważnym katalogiem jest katalog web, gdzie znajduje się cały HTMLowy lub JSPowy kod. Dla przykładu – znajdź w tymże folderze plik index.jsp i zmień jego nazwę na np. index2.jsp. Teraz w przeglądarkę wrzuć adres http://localhost:8084/WebApplication1/. I co? Ano nic, błąd. Ale z kolei wpisanie http://localhost:8084/WebApplication1/index2.jsp już jak najbardziej działa. Na prostym przykładzie widać, co gdzie i z czym jeśli chodzi o HTML i JSP. W katalogu tym można również odnaleźć podkatalog WEB-INF gdzie znajduje się plik web.xml, który służy do (powiedzmy uogólniając) kierowania routingiem w naszej aplikacji. Jednakże to uczący się JSP już raczej wiedzą i nie potrzeba tego tematu rozwijać.

Mam nadzieję, że to krótkie i pewnie trochę chaotyczne wypociny jednakże komuś pomogą, a i może skłonią do sięgnięcia po NetBeans.

Java – czyli co z czym i dlaczego

Pamiętam jak dziś podziw w jaki wpadłem kiedy za czasów dalece prehistorycznych zainstalowałem na kompie coś, co nazywało się Borland C++ Builder IDE (w wersji chyba 4.0) i zobaczyłem, że stworzenie okienkowej aplikacji działającej w Windows może być proste jak konstrukcja gwoździa. Oczywiście od tamtego czasu (jakiś 1997 rok) minęło trochę czasu, ale i tak równie nabożny lęk ogarniał mnie wówczas, kiedy stykałem się (głównie przypadkiem) z możliwościami platformy Javy. Kiedy w końcu postanowiłem zgłębić to zagadnienie okazało się, że nie jest to wcale takie proste.

By jednakże nie komplikować za wiele – Java jest silnie typowanym językiem programowania stworzonym pierwotnie przez firmę Sun. Kod źródłowy programów jest kompilowany do tzw. byte-codu, a następnie uruchamiany za pomocą tzw. wirtualnej maszyny Javy (JVM). Odrębne dystrybucje tejże maszyny zostały napisane dla niemal wszystkich będących w użyciu systemów operacyjnych, co sprawia, że programy napisane w Javie mogą być uruchamiane na niemalże każdej platformie systemowej.

Oczywiście sam język Java to dopiero podstawa całej platformy. Istnieje kilka tzw. edycji tego języka, które są używane w zależności od potrzeby. To właśnie ich istnienie było dla mnie na początek zastanawiające – oto lista:

• Java SE – jest to ‘podstawowa’ wersja języka Java. Zawiera ona także JRE (Java Runtime Environment), czyli mówiąc inaczej jest to implementacja wirtualnej maszyny. Jest to wersja ogólnego przeznaczenia – zarówno dla tworzenia aplikacji desktopowych jak i internetowych. Obecnie wersja ta nosi numer 1.6 zaś suffix SE jest dodawany po to, aby odróżnić tę wersję od pozostałych (o tych dalej). Należy także wspomnieć o numeracji – wersja 1.2 języka Java przyniosła tak duże zmiany, że zaczęto nazywać tę wersję (i późniejsze również) wersją numer 2. Znalazło to nawet nazewnictwo w książkach – jak choćby “Core 2 Java” (2 tomy). Jednakże od wersji 1.6 zrezygnowano z tego i dziś należy mówić o Javie SE (Standard Edition) w wersji 1.6.
• Java ME – jest to wersja Javy przeznaczona dla urządzeń w domyśle małych (ME to inaczej Micro Edition). Tutaj mowa przede wszystkim o komórkach, ale też o wszystkich innych urządzeniach mobilnych, w których potrzebna jest funkcjonalność Javy.
• Java EE – to jest to co tygrysy lubią najbardziej. Jest to Enterprise Edition, czyli rozwiązanie przeznaczone na potężne serwery internetowe. Zawiera w sobie wszystko to, co posiada wersja SE, ale też masę innych bibliotek, które umożliwiają tworzenie oprogramowania dla serwerów.

Sam język programowania Java nie zdziała nic wielkiego (no może poza konsolowymi wprawkami). To co przesądza o jego potędze to technologie, które zostały na nim oparte, a dziś są one podstawą dla tworzenia aplikacji zarówno desktopowych, jak i serwerowych. Przedstawię pokrótce ich przegląd:

• Standardowe aplikacje desktopowe – myślę, że każdemu programiście wystarczy dać na przykład Eclipse IDE by łatwo pojął istotę tychże aplikacji. Język Java jest tutaj podstawą, zaś do konstruowania wymyślnego GUI używa się bibliotek graficznych, np. SWT, czy Swing. Dzięki tym bibliotekom można tworzyć bardzo rozbudowane aplikacje uruchamiane niezależnie od platformy.
• Aplety – aplet to taka ‘przeglądarkojavascriptowa’ konstrukcja języka Java. By jednakże być bardziej konkretnym wystarczy wspomnieć, iż applet jest kodem języka Java, który jest najczęściej osadzany na stronach WWW, skąd jest pobierany do klienta i wykonywany po jego stronie. Przypomina to technologię Flash i zasadniczo niewiele się od niej różni. By uruchomić aplet na komputerze klienta musi być zainstalowana wirtualna maszyna. Najczęstszym użyciem apletów jest osadzanie na stronach WWW małych, ale jednocześnie dość skomplikowanych aplikacji (np. czaty czy klienty IRCa).
• Servlety – w odróżnieniu od apletów są to porcje kodu Javy wykonywane po stronie serwera. Są one podstawą dla technologii Java Server Pages (czegoś na kształt PHP). O technologii tej będę jeszcze pewnie nie raz pisał, gdyż naukę Javy przeprowadzam równolegle z klepaniem kodu w JSP. Tutaj tylko pragnę zaznaczyć, że nie można utożsamiać serwletów z JSP! Są to dwie oddzielne rzeczy, które choć występują razem, po części (przynajmniej serwlet) mogą istnieć niezależnie.

Wiemy już zatem co i jak z wersjami Javy, wiemy w jakich postaciach pisze się programy w tym języku, teraz czas na rozjaśnienie kilku magicznych słów, które przewijają się na stronach poświęconych Javie, a na poczatku niekoniecznie muszą być zrozumiałe dla noobów:

• Serwery aplikacji – podobnie jak kod PHP nie da się uruchomić ot tak na zawołanie, również i w większości przypadków kod Javy wykonywany po stronie serwera, musi być uruchomiony pod auspicjami przeznaczonego do tego serwera aplikacji. Tutaj można wyróżnić dwie kategorie – pierwszą z nich są tzw. kontenery serwletów. Służą one zgodnie z nazwą do uruchamiania serwletów. Innymi zaś słowy – jest to serwer WWW, który umożliwia dostęp do aplikacji napisanych w formie serwletów lub opartej na JSP. Najpopularniejszym tego typu rozwiązaniem jest Apache Tomcat. Drugą kategorią są serwery aplikacji ‘pełną gębą’, takie jak JBoss, lub też WebSphere (płatny). Dają one dostęp do pełnej funkcjonalności platformy Java EE, ale też umożliwiają uruchamianie serwletów.
• JavaServerPages – o tej technologii wspomniałem już wcześniej przy okazji omawiania serwletów. Otóż JSP jest technologią, która opiera się na wzorcu MVC, gdzie kontrolerem są serwlety, modele to zwykłe klasy języka Java, zaś za tworzenie widoku odpowiada właśnie JSP. Można powiedzieć, że kiedy używa się PHP z Symfony czy Zend Framework to zasadniczo robi się to samo co JSP tylko w troszkę innej technologii. W przypadku JSP jednakże, jest to zaledwie podstawa – działanie wspierające tworzenie aplikacji internetowych w tej technologii dają frameworki języka Java – Java Server Faces lub Struts (by wymienić te najpopularniejsze).
• Enterpreise JavaBeans – ‘fasolki’ lub ‘ziarna’ jak się o nich mówi to zasadniczo coś na kształt serwletów, z tym tylko, że do uruchomienia potrzebują pełnego serwera aplikacji (kontenera EJB). Są one jednym z elementów składowych (jeśli tak to można nazwać) korporacyjnej wersji Javy. Alternatywą dla tej technologii jest jej podobna – Spring Framework, który jest mniej rygorystyczny oraz o wiele ‘lżejszy’ od ziarenek.
• Ant, Maven – są to narzędzia do zautomatyzowanego budowania projektów. Dają dużo możliwości konfiguracji, a według opinii na necie dzięki temu javowcy wciąż mają włosy na głowach. Póki co nie miałem okazji korzystać, gdyż od tego mam IDE NetBeans, ale pewnikiem zaniedługo trzeba się będzie ogarnąć w tym temacie.

Mam nadzieję, że powyższe informacje pozwolą na systematyzację wiedzy dotyczącą języka Java, a co za tym idzie dadzą zarys planu nauki oraz kierunku rozwoju.