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臋 馃槈