Kierunek Babilon pt.3 – jak wygląda development w Javie ?

Dewelopment w Javie fundamentalnie różni się od flow do którego jesteśmy przyzwyczajeni w przypadku aplikacji Pehapowych. Wynika to przede wszystkim z samej „natury” obu platform – PHP jest językiem interpretowanym, natomiast Java kompilowanym. Wobec tego, tworzenie, czy zmiana kodu wygląda zupełnie inaczej.

Jeżeli bym miał podsumować jednym słowem tworzenie kodu w PHP, to tym słowem było by „var_dump”. Pisząc jakiś kod, jesteśmy przyzwyczajeni do tego, że możemy go w każdej chwili zmodyfikować a potem sprawdzić efekty jego działania przy pomocy przywołanej wcześniej metody. Oczywiście są osoby, które w tym celu używają debuggera, jednakże jak wszyscy wiemy, są problemy z jego integracją z różnorakimi IDE i generalnie „var_dump” wydaje się być dość uniwersalnym narzędziem.

Pisząc w Javie, var_dump jest pierwszym z naszych pehapowych przyzwyczajeń, które powinniśmy schować do szuflady. Po pierwsze dlatego, że nie ma odpowiednika takiej funkcji w Javie, a po drugie dlatego, że var_dump driven development nie ma tam żadnych sensownych racji bytu. Dzieje się tak ze względu na czas jaki zajmuje deployment kodu – każda zmiana, jaką wprowadzimy w kodzie Javowym wymaga rekompilacji zmienionych klas i restartu serwera, co może trwać dość długo (np. w moim projekcie taka operacja trwa mniej więcej około 5 minut). Powstały oczywiście pewne solucje by temu zaradzić, takie jak np. podmienianie klas w trakcie działania serwera (Hot Swap), jednakże nie działają one we wszystkich przypadkach (jak dodanie, bądź usunięcie metody jakieś klasy).

Jak więc sobie radzić w takich warunkach ? Po pierwsze, musimy się zaprzyjaźnić z debuggerem. Wkrótce stanie się on naszym najlepszym przyjacielem, na którym będziemy polegać w każdej sytuacji. Debugger jest standardowo wbudowany w każde Javowe IDE, więc nie będziemy mieli żadnych problemów w korzystaniu z niego. Możliwości debuggera są naprawdę potężne i zaczynają się od przechodzenia kodu krok po kroku i podglądania wartości zmiennych, aż po zmianę ich wartości w locie oraz „cofanie się wstecz” w wykonaniu kodu.

Debuggera oczywiście najczęściej będziemy używać przy okazji poprawiania błędów. Jak natomiast sprawa się ma przy tworzeniu nowego kodu ? Tutaj z pomocą przychodzi nam dobrze znana, również z świata PHP technika Test Driven Development. Stosując TDD w kombinacji z debuggerem możemy dość skutecznie i szybko rozwijać nasz kod. Przy czym generalnie obowiązuje zasada, by raczej napisać jak najwięcej kodu przed jego testowaniem – nawet kompilacja testu, mimo, że jest to bardzo mała ilość kodu w porównaniu do całej aplikacji, którą depoloyujemy na serwerze nie jest natychmiastowa i chwilkę trwa. Jeżeli w tej chwili wyobraziliście sobie, że kompilujecie test tylko po to, żeby okazało się, że z jakiś głupich powodów nie działa, to mam dla Was dobrą informacje – dzięki statycznej naturze Javy, wszystkie „głupie” błędy zwykle podkreśli Wam na czerwono Wasz edytor, albo ostatecznie kompilator w momencie kompilacji.

Na koniec jeszcze taka mała uwaga odnośnie plików Javascriptowych. Zwykle bywa tak, że pliki źródłowe JS są częścią naszego Javowego projektu, w konsekwencji one również deployowane są na serwer wraz ze skompilowanymi klasamy Javy. W rezultacie, każda zmiana plików JS wymaga ponownego deployu projektu oraz restartu serwera co jak już wiemy – trwa dość długo. Na szczęście jak zwykle są na to sposoby ;). Po pierwsze, jeżeli tylko chcemy zmienić coś w JS do celów testowych, to wieść gminna niesie, że narzędzia deweloperskie Chrome’a  pozwalają zmieniać Javascript „w locie”. Po drugie, w przypadku InteliJ Idea, istnieje opcja „update resources”, która podmienia tylko obrazki, js i inne tego typu pliki dość szybko, bez potrzeby restartu serwera.

Tym radosnym akcentem kończę ten artykuł i ogłaszam, że jest to już ostatni wpis z serii „Kierunek Babilon”, oczywiście dalej zamierzam pisać o PHP i Javie, ale już w trochę innym kontekście.

  1. ZuluS pisze:

    Mam zły dzień i się przyczepię. 😛

    1. Java nie jest językiem kompilowanym, tylko prekompilowanym do bytecodu dla specjalnego środowiska uruchomieniowego (JRE).
    2. var_dump to zło i trzeba tępić, nie ważne czy to PHP, console.log w JS gdzie popadnie, System.out.println() w Javie, czy cokolwiek innego pisane na pałę, na szybko próbując się usprawiedliwić że niema czasu.
    3. PHP ma debugger – XDebug, bardzo fajnie spięty z popularnymi IDE
    4. Jeżeli ktoś robi ctrl+r po każdej linijce w PHP to… pozostawię to bez komentarza. Porządne IDE dla PHP podkreśli błędy syntaktyczne podczas pisania. Sporo semantycznych również.
    5. Co do deploy to porządne IDE dla Javy będzie miało autodeploy do tomcata (np netbeans, eclipse), który w przypadku zmiany resources nie wymaga restartu aplikacji.

    A trochę poza tym to polecam poczytanie na temat OSGi / GWT jeśli przeszkadza Ci kompilacja częsta. Pierwszy umożliwia podziała aplikacji na dynamiczne moduły które mogą być ładowane i odinstalowywane na działającej aplikacji (bez restartu) a drugi chyba nie trzeba przedstawiać 😉

    Przepraszam 😉

  2. ZuluS

    1. Bez znaczenia
    2. Bez znaczenia
    3. Nigdzie nie napisałem, że nie ma, co więcej napisałem, że debuggery są, tylko ciężko je skomunikować z IDE
    4. Nie chodzi mi o błędy syntaktyczne a raczej o błędy spowodowane automatyczną konwersją typów etc
    5. O tym również napisałem

    Co do OSGi, to nie mam na to wpływu czy będzie użyte czy nie więc to pominę

  3. ZuluS pisze:

    3. Nie rozumiem jak ciężko? W netbeansie klikasz ctrl+f5/cmd+f5 i już jest skomunikowany. Nie wiem jak na windowsie, ja zawsze pracowałem na linux/mac to niema problemu.
    4. Fakt ale i tu można się naciąć na np Integer / integer 😉

    Co do 1 i 2 dla mnie znaczenie zasadnicze
    1 – powoduje problemy i narzut przy uruchomieniu (ale mi się zrymowało)
    2 – jak spędzisz trochę czasu na wyłapywaniu var_dump/echo/print_r po ftp poumieszczanych w najmniej odpowiednich miejscach (czyt. bezpieczeństwo i print za komentarzem html) to dojdziesz do wniosku że to zło. Inny problem to zabawa z XHR 😉

  4. 2. Miałem na to własną solucją via funkcja „dumpe”, jest nawet gdzieś tutaj na blogu 😉
    3. No właśnie na Windowsie jest problem ze zmuszeniem debuggera do działania

    W każdym razie, you made some good points 😉

  5. Theq pisze:

    @1. Oczywiście, że Java jest językiem kompilowanym. Kompilacja to transformacja kodu napisanego w jednym języku programowania do kodu w innym języku programowania. Prekompilacje to robi preprocesor.

    @”powoduje problemy i narzut przy uruchomieniu”, bardziej ogólnie się nie dało? To ja napisze, że rozwiązuje problemy 😉 A narzut to mogą różne rzeczy powodować.

    btw http://www.zeroturnaround.com/jrebel/ ?

  6. ZuluS pisze:

    Fajna funkcja ale to i tak rozwiązanie połowiczne.
    Dla PHP/Javy każdy szanujący się framework (nie ważny czy zamknięty wewnętrzny czy otwarty jak symfony, zend, spring). Ma mechanizmy do logowania i debuggowania które nie trzeba co chwila usuwać i dodawać. W trybie debuggowania jest zostawiasz. I masz pełną wiedzę na przyszłość. Przydatna zwłaszcza przy krytycznych elementach systemu.

    Tamte funkcje i tak nie rozwiązują problemy z XHR czy z requestami po których wysyłasz „Location:” aby zatrzeć POST/PUT. Np praca z Ext JS czy innym interfejsie stricte JSowym. Wtedy się przydają takie projekty a FirePHP np.

    Co do javy to ma podstawowy plus, czyli wbudowany logger. Rozwiązanie jest tak proste że aż genialne, no i jest sporo bibliotek zmieniające działanie wbudowanych klas, bądź je rozszerzające. Wtedy Ci var_dump’a nie trzeba no i nie musisz usuwać, ustawiasz tylko poziom logowania i jedziesz dalej. A w razie awarii, logi są wbudowane, a nie znowu spisywanie System.out.println() na dziko który niestety jest mankamentem w wielu Javowych aplikacjach :/

    No i żeby nie było nie jestem orędownikiem ani PHP ani Javy ani niczego innego. Wszystko ma swoje wady i zalety. Java jest niespójna, PHP dzikie :P, ale i tak lubię oba rozwiązania 😉

    @Theq
    Co do preprocessing vs precompilation to inna bajka i proponuję poczytać czym się różnią i dlaczego nie należy używać zamiennie tych pojęć. To temat na ciekawą dyskusję akademicką.

    @Wojciech Soczyński
    W pierwszym komentarzu zapomniałem napisać, że poza czepianiem się, artykuł czytało się bardzo przyjemnie i czekam na kolejne wpisy z cyklu PHP vs Java vs What Ever;)

  7. @Tomasz Kowalczyk: dzięki 😉
    @Zulus: masz rację wbudowany logger w Javie to świetna rzecz, mam zamiar też coś o nim w przyszłości napisać :), btw. dzieki za uznanie :)

  8. batman pisze:

    @Wojciech Soczyński
    Na Windowsie nie ma żadnego problemu z Xdebug. Korzystałem z tego z Eclipse, a teraz korzystam z tego w PHPStorm. Jeśli miałem jakieś problemy, to wynikały z „paczki”. Wróciłem do WAMP-a i nie mam żadnych problemów z debuggowaniem kodu przy użyciu Xdebug.

  9. Ja próbowałem to kiedyś ustawić z NetBeansem ale się nie udało. Natomiast później już nie próbowałem, bo nie było mi to w sumie potrzebne 😛

  10. Theq pisze:

    @ZuluS Gdzie mogę o tym poczytać, bo niestety google milczy na ten temat?

  11. @theq: sprawa jest prosta – w przypadku Javy, kod kompilowany jest do bytecodu, który wykonywany jest (interpretowany) przez JVM. Wystarczy, że poczytasz sobie o Javowym bytekodzie 😉

  12. Theq pisze:

    No wai 😉 Chodziło mi o „preprocessing vs precompilation”.

    Z twojego opisu wychodzi na to, że Java jest językiem kompilowanym i interpretowanym, a nie jakimś prekompilowanym o czym wspominał ZuluS w pierwszym komentarzu. Nawet jakby przyjąć jego uproszczoną definicję, że kompilacja to tylko tłumaczenie kodu żródłowego języka do postaci kodu maszynowego, to koledzy chyba nie wiecie, że są procesory wykonujące natywnie bytecode http://en.wikipedia.org/wiki/Java_processor

  13. Kompilacja jest zawsze tłumaczeniem jednego kodu na drugi (istnieją w końcu crosscompilatory np GWT: java -> js), nie jest ważne, czy ten drugi kod jest maszynowy czy jakikolwiek inny. Co do interpretowania i prekompilacji, to wygląda to tak, że oczywiście, można wykonywać go bezpośrednio na procesorze, który go rozumie. Co do JVM to jest to wirtualna maszyna – wirtualny procesor, który właśnie taki kod wykonuje. Jako, że przy okazji dokonuje dynamicznie jego optymalizacji i ogólnie sobie w nim miesza wg uznania to można powiedzieć, że jest to kod interpretowany.

  14. Theq pisze:

    Ja wiem co to jest JVM, skończyłem studia i znam budowę kompilatora, maszyny wirtualnej i nawet maszyny Turinga ;). Pytałem się tylko o definicję prekompilacji, najlepiej ze żródłem. I co to ma wspólnego z Javą.

  15. Theq pisze:

    A i jeszcze dlaczego Java nie jest językiem kompilowanym 😛

  16. @theq: Java nie jest językiem kompilowanym, ponieważ bytecode jest interpretowany na JVM. Chyba, że będziemy go bezpośrednio wykonywać na procesorze (takim jak podlinkowałeś) to wtedy będzie można powiedzieć, że jest kompilowany :> (wg. mnie)

  17. Rodzyn pisze:

    Java KOMPILUJE się do bytecode’u, tylko ma inne środowisko uruchomieniowe (interpretujące ten bytecode). Więc można stwierdzić, że jest językiem kompilowanym (co również stwierdza wikipedia).

    Jeżeli jak piszesz, „obowiązuje zasada aby napisać jak najwięcej kodu przed testowaniem” to nie jest to w żadnym wypadku TDD. W TDD najpierw piszemy testy jednostkowe/integracyjne a następnie według nich piszemy kod aż wszystkie testy przechodzą :)

  18. @Rodzyn – to taki skrót myślowy trochę, miałem na myśli – „napisać jak najwięcej kodu, przed manualnym testowaniem (czyli klikaniem po stronie)”

  19. Catlin pisze:

    1. Java nie jest językiem kompilowanym, tylko prekompilowanym do bytecodu dla specjalnego środowiska uruchomieniowego (JRE).
    2. var_dump to zło i trzeba tępić, nie ważne czy to PHP, console.log w JS gdzie popadnie, System.out.println() w Javie, czy cokolwiek innego pisane na pałę, na szybko próbując się usprawiedliwić że niema czasu.
    3. PHP ma debugger – XDebug, bardzo fajnie spięty z popularnymi IDE
    4. Jeżeli ktoś robi ctrl+r po każdej linijce w PHP to… pozostawię to bez komentarza. Porządne IDE dla PHP podkreśli błędy syntaktyczne podczas pisania. Sporo semantycznych również.
    5. Co do deploy to porządne IDE dla Javy będzie miało autodeploy do tomcata (np netbeans, eclipse), który w przypadku zmiany resources nie wymaga restartu aplikacji.

    +1

  20. Why visitors still make use of to read news papers when in this
    technological world everything is available on web?

  21. It’s really a nice and helpful piece of info. I’m satisfied that you just shared
    this useful information with us. Please stay us up to date like this.
    Thanks for sharing.

  1. There are no trackbacks for this post yet.

Leave a Reply

Informuj mnie o odpowiedziach poprzez e-mail. Możesz również subskrybować wpis bez zostawiania komentarza.