Tytuł wpisu jest po części niepoprawny, jednakże dostaję co i rusz mejle z mniej więcej tak sformułowanym pytaniem. Dlatego też by nie musieć odpisywać za każdym razem na to samo, a także by nie stosować brutalnego kopiowania postanowiłem swoje przemyślenia zamieścić na blogu.
Na samym początku mała uwaga do ludzi, którzy na Javie zjedli zęby i kawałek dziąseł – proszę o zachowanie komentarzy z cyklu ‘Tak naprawdę technologia/framework XX nie jest YY, albowiem Iksiński uważa inaczej i tak naprawdę realizuje się tam wzorzec ZZZ i z całą pewnością powinno się go poznawać przed/po OOO’ dla siebie. Wpis ma za zadanie choć oględnie pokazać o co chodzi w tej masie nazw i specyfikacji – mniejsza o detale i kłótnie ‘pro-programmersów’.
Czym tak naprawdę jest Java? To wcale nie jest głupie pytanie! Czym jest Java? Językiem programowania ktoś rzeknie. I będzie miał rację. Platformą do budowania aplikacji – też przyznam mu rację (pomińmy językowe wygibasy co jest platformą, a co nie). Specyfikacją, do której potem stosują się inni? Też racja. Więc co to tak naprawdę oznacza ‘nauczyć się Javy’?
Java jako taka miała być językiem wieloplatformowym, uruchamianym na różnych systemach i urządzeniach (mottem było „Write once, run everywhere”) dzięki użyciu maszyny wirtualnej. Dlatego też na samym początku Java poszła trzema różnymi drogami:
a) przeznaczona do pisania aplikacji desktopowych. Dziś przy tendencjach do przenoszenia wszystkiego do chmurek, lekkości i mobilności rozwiązań wydaje się być to pewnym przeżytkiem. Jednakże Java dalej posiada bibliotekę Swing oraz AWT/SWT, które umożliwiają tworzenie aplikacji desktopowych uruchamianych konkretnie na maszynach klienta. Nie wiem jak ten rynek wygląda obecnie – na pewno istnieje masa legacy-code, ale nie za bardzo jestem na bieżąco z rynkiem koderów w tych technologiach. Wiem za to na pewno, że na swoim kompie instalowałem Adobe AIR – choćby dla aplikacji do składania PITa przez internet, z tego co wiem np. Ipla dla linuxów jest w tym pisana. Czyli jakby Java tutaj oddawała pola.
b) lekka wersja przeznaczona na urządzenia mobilne (to w dużym uogólnieniu) – wersja Mobile Edition. Najczęściej kojarzona z telefonami komórkowymi, choć może i niesłusznie – bardziej chodziło o urządzenia z małą zdolnością obliczeniową. Z tego, co do mnie dociera z blogosfery wygląda na to, że jeśli chodzi o komórki to chyba też Java przegrała tę batalię (w pewnym sensie) - Objective-C dla iPhonów i pochodnych od Apple, Android bazuje na JVM, ale nie jest z nią w pełni kompatybilny, Symbian i Windows Phone to rodzina C++. Trochę kiepsko.
c) wersja korporacyjna (webowa) – póki co tutaj dzieje się magia. O tej wersji piszę na blogu najwięcej. Programistów wyznających się na tej magii pracodawcy poszukują najwięcej. I o tej też Javie skupię się w dalszej części wpisu.
Zanim jednakże przejdziemy do samego webdevelopmentu poruszę kilka okolicznych zagadnień. Zaczniemy od samej Javy jako języka programowania. Nie wiem drogi czytelniku czy posiadasz doświadczenie w tej dziedzinie. Może do tej pory kodowałeś desktopowe gierki na swoim wysłużonym blaszaku. Równie dobrze jak ja jakiś czas temu możesz pracować przy PHP czy innym Pytonie. Może jesteś frontendowcem, który musi dowiedzieć się czegoś o JSP, servletach i okolicach. Wiem jedno – nauczyć się podstaw Javy jako języka programowania nie jest zbyt trudno. Odradzałbym jednakże kanoniczną ‘Thinking in Java’ – o tym dlaczego opisałem kiedyś na blogu. Zwykłe tutoriale w internecie – taki jak choćby tutorial na stronach Oracle czy książeczki z serii ‘Core Java’ dostępne w Helionie absolutnie wystarczą.
Idziemy dalej. Przy nauce języka z całą pewnością będziemy korzystać z IDE – czy będzie to Eclipse, czy NetBeans czy jeszcze coś innego – nie ma znaczenia. Znaczenie ma to, iż wszystkie IDE ukrywają przed użytkownikiem magię, którą czynią pod spodem – budowanie aplikacji, kompilacja i w końcu uruchomienie. W przypadku prostych aplikacji do nauki języka nie jest to jeszcze tak mocno widoczne – z całą pewnością jednak stanie się kiedy przejdziemy do prawdziwego JEE. Konkretnie na sam początek mam na myśli narzędzia budujące projekty - konkretnie zaś Anta oraz Mavena. Znajomość (choćby ogólna i dość pobieżna) tych dwóch pozwala na zrozumienie co w ogóle się dzieje z kodem kiedy klikamy ‘Compile and run’ w IDE. Do poznania tych dwóch dobrze jest odwiedzić ich strony internetowe, albo zaopatrzyć się w tę oto książeczkę, w której można znaleźć opis szeregu innych ciekawych narzędzi przeznaczonych dla Javy. 
Przed rozpoczęciem pisania kodu zawadzimy o jeszcze dwie rzeczy. Pierwszą z nich jest baza danych. Jeżeli przychodzisz z miejsca, gdzie klucz główny tabeli oznacza to samo co kolumnę INTEGER z auto-increment to wiedz, że jeszcze bardzo dużo nie wiesz. Absolutnie nie twierdzę, że MySQL jest zły – chodzi mi tylko o to, iż w przypadku korporacyjnych aplikacji najczęściej używa się produktów, które są traktowane jako ‘poważne’, no i mają też niebagatelne możliwości – tutaj (z mojego doświadczenia) wynika, że graczy jest tak naprawdę dwóch – Oracle oraz MSSQL. Gdzieś tam ktoś słyszał o tym, iż w użyciu jest Sybase, DB2 czy jeszcze inne wynalazki – jednakże to mniejszość – znajomość tych dwóch pierwszych (nie ekspercka, nie da się nie będąc adminem lub zawodowo programistą PL/SQL stwierdzić, że się zna te bazy). Temat jest długi, materiałów w sieci nie brakuje, książek (po polsku) również nie. 
Zarówno Oracle jak i MSSQL posiadają wersje, które można za darmo pobrać i zainstalować na lokalnym kompie by się ich poduczyć. I nawet nie mówię o samym języku SQL (bo ten w podstawach jest taki sam wszędzie – w końcu po coś mamy standard ANSI), ale o takich rzeczach jak schematy, userzy, materializowane lub nie widoki, podstawy programowania bazy (PL/SQL czy T-SQL) – to się przydaje w codziennej pracy, choćby po to by wiedzieć co wpisać w konfigu cienkiego klienta.
Drugą rzeczą są serwery. W przypadku aplikacji desktopowych problemu nie ma – JVM jest odpalana na lokalnym komputerze i problemu nie ma. W przypadku JavaScriptu mamy przeglądarkę i tylko przeglądarkę. PHP czy Python wykonywane są na odpowiednio skonfigurowanym serwerze WWW (choćby poprzez FCGI). Wszystko jest dość oczywiste. Czym innym niestety są serwery do użycia Javy – możemy je bowiem podzielić na dwie kategorie - kontenery servletów oraz serwery aplikacyjne.
a) kontener servletów - jak sama nazwa wskazuje jest to serwer (aplikacja), która pozwala na wykonywanie kodu zawartego w servletach (klasach Javy, których kod może być wywoływany przez zdalnego klienta – nie musi to być np. protokół HTTP), a także kodu, do którego servlet się odwołuje. Najpopularniejsze to Apache Tomcat oraz Jetty.
b) serwer aplikacyjny - jest to serwer (aplikacja), która jest zgodna ze specyfikajcą korporacyjnej Javy – w związku z czym poza zwykłym hostowaniem aplikacji webowych (tak samo jak kontener servletów) udostępnia masę dodatków – jak choćby obsługę kolejek (JMS), obsługę bezpieczeństwa, współdzielonych zasobów JNDI i masę masę innych rzeczy. Jednakże w związku z tym jest o wiele bardziej zasobożerny. Najpopularniejsze serwery to BEA Weblogic, JBOSS Server, Websphere oraz Glassfish.
Większość IDE skonfigurowanych do pracy z Javą lub Javą EE przy instalacji pyta o jednoczesne zainstalowanie kontenera lub całego serwera ( np. NetBeans może nam zainstalować Glassfisha). Przy rozpoczynaniu przygody z Javą EE jest to dobra opcja – taka instalacja ma tę zaletę (przynajmniej powinna mieć), że działa po kliknięciu w IDE. Nie bawimy się w konfigurację, tworzenie domen i ustawianie źródeł danych – serwerek po prostu działa, a my możemy pisać kod. No właśnie, kod.
Podstawą do działania Javy w środowisku internetowym jest technologia servletów i w pewnym sensie automatycznie wiązana z nią technologia JavaServerPages (od obsługi widoku). Jest to realizacja wzorca MVC – servlet sprawuje w tym przypadku funkcję kontrolera, zaś strony (pliki) JSP są naszym widokiem. Dla zrozumienia podstaw tej technologii (poza tutorialami w internecie) najbardziej nadaje się książeczka z serii ‘Head First’. Zasadniczo niewiele więcej trzeba o tym pisać – poza tym, iż tworzenie kodu za pomocą czystych servletów i JSP to trochę hardkor i najczęściej dziś do tego stosuje się konkretne frameworki webowe. Co to jest framework? Ano jest to zbiór klas/bibliotek/pakietów, które czynią tworzenie aplikacji internetowych znacznie łatwiejszym. Za najbardziej kanoniczny ( w sensie pochodzenia, nie zastosowań czy znaczenia) uważa się JavaServerFaces - był to framework stworzony przez firmę Sun Microsystems (twórcę języka Java). Problem z nim był taki, iż miał dość pokręcony model przetwarzania requestów, potrzebne też były różne hacki na poprawne renderowanie widoku i masę różnych rzeczy. Jakiś czas temu pojawiła się druga wersja tego frameworku, do zabawy z nią można zapoznać się książeczką dostępną po polsku. Mimo szeregu zmian nie jest to jednakże często polecane rozwiązanie. O wiele bardziej zaawansowanym narzędziem jest webframework o nazwie SEAM. Bazuje on w podstawach na JSF, jednakże posiada masę dodatkowych ficzerów, które naprawdę wydają się być przydatne. Niestety nie miałem okazji przysiąść na dłużej z tym frameworkiem. Wiem jednakże na pewno, iż posiada świetnie wyglądającą dokumentację dostępną na oficjalnej stronie frameworka. Podobnym do powyższych jest również webframework Struts – jego pierwsze wersje pojawiły się naprawdę dawno temu – w związku z czym jego konstrukcja potrafiła cokolwiek odstraszyć. Druga wersja frameworka, która pojawiła się nie tak dawno temu skonstruowana jest o wiele lepiej – choć dalej nie bez zastrzeżeń.
To co wymieniłem powyżej to najbardziej popularne (moim zdaniem i jest to subiektywne odczucie) webframeworki w naszym kraju. I tutaj uwaga! To są frameworki, które częściowo wchodzą również w warstwę widoku. Mówiąc krótko – najczęściej widok to po prostu pliki JSP, wzbogacone o masę ekstra tagów, które umożliwiają rendering ciekawszych kontrolek. Jednakże istnieje możliwość zastąpienia tej części bardziej wyrafinowanymi możliwościami – ostatnio w tej roli (głównie przynajmniej z tego co widzę po ogłoszeniach o pracę) zaczyna dominować produkt od Googla – GoogleWebToolkit. Jest to biblioteka, która umożliwia tworzenie mocno zAJAXowanych aplikacji, które jednakże powstają tylko i wyłącznie z użyciem Javy. Cały kod JavaScriptu jest generowany za pomocą kodu pisanego w Javie, jednakże programista ma docelowo nie przejmować się istnieniem przeglądarki, standardów i różnic w silnikach JavaScriptu. Z moich pobieżnych zabaw z GWT skojarzenie z pisaniem w ActionScripcie nasuwa się samo. Tworzymy kontrolki, umieszczamy na stronie i to docelowo ma działać. Ostatnimi czasy więcej słyszy się o produkcie opartym na GWT o nazwie Vaadin, a najbardziej chyba dobrym miejscem by rozpocząć przygodę z tym rozwiązaniem jest strona Kozioła. Oprócz tychże mamy też szereg innych ciekawych projektów, jednakże jest ich tyle, że aż głowa mała – nie będę wskazywał konkretnych przykładów (no dobra - Richfaces dla przykładu), które ułatwiają tworzenie GUI – tutaj jednakże trzeba wybrać samemu rozwiązania, które nam podpasują.
W powyższych wywodach nie wymieniłem jednego magicznego słowa – Spring. Albowiem ten framework (a może to biblioteka?) jest tak naprawdę nie tylko frameworkiem, ale też zupełnie nowym podejściem do tworzenia aplikacji webowych. Spring bowiem rozwiązywał problemy, które pojawiły się w czasach, kiedy Java była niesamowicie kobylasta, a fajne tagi w JSF naprawdę były szczytem innowacji. Spring jest rozwiązaniem, które realizuje wzorzec Dependency Injection / Inversion of Control (nie wchodzę w dywagacje co jest elementem czego i takie tam – na uniwerkach mogą bo mają czas i za to im płacą). 
Co oznacza nie tylko ułatwienie tworzenia obiektów, zachowania czystości kodu oraz skalowalności, ale też wpływa tak naprawdę na wszystko. Wiem, że powyższe zdania wyglądają jak marketingowy bełkot, ale naprawdę nie potrafię w skrócie opisać Springa i całej jego zajebistości. Wiem tylko, że ostatnio dość często piszą/dzwonią do mnie rekruterzy i tak naprawdę z frameworków wymagają tylko tego Springa – ewentualnie z jego bardzo fajnym dodatkiem – Spring MVC, gdyż tak naprawdę dzięki temu combo nic więcej już nie potrzeba. No prawie…
Tym, co jest potrzebne to jakiś sposób implementacji logiki biznesowej, co jest dość często automatycznie powiązane z dostępem do bazy danych. Wiem, że to może dość radykalne stwierdzenie, ale nie piszę tu rozprawy doktorskiej – piszę do ‘wanna be Java programmer’. Zatem przyjmijmy na razie, że rzecz jest w dostępie do bazy danych. I tutaj mamy dwie możliwości:
a) JDBC - technologia stara jak świat, ale dalej dość mocno użytkowana. Dlaczego? Albowiem jest prosta do bólu i nie wymaga zaznajamiania się z ORMem, pisaniem masy XMLa, albo wpisywania masy adnotacji do kodu. Po prostu działa. Do swego działania wystarczy dostarczyć bibliotekę ze sterownikiem dla konkretnej bazy danych i piszemy kod. Jest również najbliższym do pisania czystego SQLa (w sumie to jest pisanie czystego SQLa tylko opakowanego w obsługę połączenia i wyjątków). Zawsze czysto, zawsze sucho i zawsze pewnie.
b) ORM - bazy danych obecnie używane w 99% to bazy relacyjne. Ergo – obiektowe języki programowania nie za bardzo do nich przystają – musimy napisać kod, który jakoś zamieni te proste rekordy z bazy na piękne obiekty z ich metodami dostępowymi, modyfikatorami dostępu oraz polimorfizmem. I tutaj ludzie wymyślili coś takiego jak ORM - Object Relational Mapping. Standardem stworzonym przez firmę Sun jest Java Persistence API, w skrócie JPA. W obecnej wersji jest to tak naprawdę synergia pomiędzy rozwiązaniami zaimplementowanymi uprzednio w najbardziej popularnym rozwiązaniu – Hibernate. Bibliotekę tę wymienia się zasadniczo w każdym ogłoszeniu o pracę, zatem jeśli chcesz zostać koderem Javy - poznanie Hibernate (a przez to i w dużej mierze JPA) jest po prostu warunkiem koniecznym. Co jest w ORMach niefajne? Konieczność klepania XMLa – choć ostatnio o wiele szybciej i wygodniej osiąga się cel poprzez adnotacje. Często jednak mam wrażenie, że kiedy przychodzi do czegoś bardziej skomplikowanego trzeba (mimo opakowania w np. criteria API Hibernate) wklepać fizycznie ‘SELECT * FROM’ i nic się z tym nie da zrobić.
Co nam teraz zostało? W sumie masa innych rzeczy, które jednakże na pewno dla ‘wannabe programersów’ znajdują się na bardzo wysokim poziomie. Wróć, może źle napisałem. Odległym poziomie – brzmi bardziej prawdziwie. Wymienię tylko nazwy – pisać już mi się nie chce, a kto chce znajdzie sobie informacje w Wiki i na pewno wujek Google dopomoże. Mamy zatem JMS, JMX, JaaS, ESB, WebServices (SOA), BPM, UML, ufff - zapewniam też, że możnaby tak jeszcze długo.
Powodzenia życzę ;)
