JAVARSOVIA na chłodno.

Miało być na gorąco, ale jak zacząłem to już wiedziałem, że będzie na letnio. Teraz już nawet na letnio nie wypada bo od Javarsovi minęło już chyba dwa tygodnie (A gdybym się nie rozchorował skończyłbym z artykułem w lodach wiecznej zmarzliny).

A dwa tygodnie temu było tak: Gdybym nie umówił się z kolegą na samochód to by mi się nie chciało wstać z łóżka tak wcześnie, ale na szczęście wstałem z łóżka i pojechałem na javarsovię i nie żałuje było naprawdę super. Fajne ciekawe wykłady, niektóre na prawdę świetne, dobre jedzenie na after party, uścisk ręki "legendy" Jacka Laskowskiego :-). Konferencja całkowicie darmowa, nawet z dojazdem się udało bo kierowca dostał zwrot pieniędzy za podróż od swojej firmy.

Zacząłem od wykładu "Biblioteki Open Source – nie ma nic za darmo" e-point. Jak ktoś się spodziewał jakiegoś ataku na open source i wychwalaniu komercyjnych bibliotek to się raczej zawiódł. O komercyjnych bibliotekach prawie nic, tylko dość obiektywne zwrócenie uwagi m.in. na to, że wersje binarne bibliotek nie zawsze są skompilowane z tych samych źródeł co ściągamy. W przypadku gdy będzie trzeba poprawić błąd w takiej bibliotece możemy mocno się zdziwić jeśli nie będziemy mogli zbudować naszej biblioteki. Zdałem sobie sprawę, że w moim obecnym projekcie kilka naszych bibliotek to binarne wersje. Ja staram się raczej kompilować ze źródeł, ale raczej dlatego, że jest to bardziej cool & trendy niż z innych powodów.
Kilka bibliotek wymagało żebym napisał build.xml do nich, część było mi łatwiej skompilować jako projekt w eclipse, część nie kompilowała się w ogóle więc wziąłem binarki. Dodatkowo za żadnym razem nie wrzuciłem źródeł do svn-a! Mam na dysku, ale zawsze ryzyko jest że je stracę (akurat nie ma backupu :-)). Druga część prezentacji z tej firmy to "Problemy w dużych aplikacjach internetowych J2EE". Poprawnie i rzeczowo. Nomen omen prowadził wykład pan Błąd.

Potem ciasteczko, herbatka i wykład "Eclipse: Desktop/Web/Server-Side/Mobile". Przedstawiano tutaj Eclipse RCP czyli Rich Client Platform. Koncepcja tworzenia bogatych klientów kiedy mainstream robi klienty webowe to być może zaczątek rewolucji albo zwiastun nowego trendu. Choć o RCP ale w netbeans to już słyszałem parę lat temu. Na pewno technologia warta poznania ale przyznam, że aż tak bardzo na kolana mnie ta prezentacja nie rzuciła. Prelegenci pokazywali tą samą aplikację w RCP, RAP (webowe) i eRCP (mobilne) i przekonywali, że prawie nic nie dopisali a działa tak samo. Szkoda, że nie było pokazane co należy dopisać bo chyba to było właśnie najciekawsze.

Następnie był panel JUGowy o życiu i funkcjonowaniu JUGów, głównie warszawskiego choć byli też goście z Krakowa i Poznania. Można było przekonać się kto rządzi twardą ręką w warszawskim JUGu, dowiedzieć się kto i dlaczego angażuje się w JUGi i trochę dyskusji nt. prawnych aspektów. Mnie najbardziej interesowało to jak założyć łódzkiego JUGa i niespodziewanie gdy w końcu udało się mojemu koledze zadać to pytanie to okazało się, że ktoś JUGa już założył ... kilka dni temu. Tak więc połączymy siły i zobaczymy co z inicjatywy tej wyjdzie. Wiadomo, że zawsze na początku zapał i chęci są ogromne a potem poziom entuzjazmu weryfikuje życie. Dzięki panelowi JUGowemu przynajmniej dostaliśmy małego kopa adrenaliny na start a sam Jacek Laskowski obiecał przyglądać się jak łódzkiemu JUGowi będzie się powodzić i wspierać go w trudnych początkach.


Następny wykład to Profilowanie javy. Kolega który był ze mną stwierdził, że stracił czas na tym wykładzie. Ja do końca tak nie uważam. Rzeczywiście większość rzeczy gdzieś już kiedyś używałem, widziałem lub czytałem o nich. Najpierw było trochę teorii o działaniu GC, potem o
różnych przełącznikach maszyny wirtualnej i profilerach. Tak jak już napisałem to wszystko już gdzieś było ale tutaj przynajmniej w jednym miejscu.
Że java ma coś takiego jak java management extensions (JMX) który może być użyty do monitoringu i profilowania. Że jest przełącznik javaagent dzięki któremu możemy wpiąć się z profilerem.

Na koniec został mi wykład o Java SIP Servlet API.
O SIPie coś tam zaczyna być słychać od jakiegoś czasu ale coś nie mogę się doczekać klarownego wyjaśnienia co właściwie można osiągnąć przy uzyciu SIP. Ale na tym wykładzie odpowiedź częściowo się pojawiła. W oparciu o serwer SIP BEA (Weblogic + SIP dodatki o ile dobrze zrozumiałem) Waldemar Kot zbudował funkcjonalność małej centralki telefonicznej. Po kolei dodawał dodatkową funkcjonalność począwszy od hello world na INVITE przez skrócone wybieranie numerów do telekonferencji inicjowanej przez WWW. Zasłużone brawa na koniec. Ten wykład podobał mi się najbardziej bo było dużo kodu, live coding (z pomocą snippetów z notatnika) i pokazane na żywym sprzęcie. Dwa telefony IP (low end), płaska nokia (pewnie jakiś wypas) i emulatorowy telefon na PC. Ciekawi mnie jednakże jak to działa, że telefony dogadują się ze sobą tzn. tworzenie kanału transmisji, wybór kodeków i wysyłanie strumienia z dźwiękiem.

Podsumowując, bardzo się cieszę, że na konferencji byłem, zobaczyłem parę fajnych prezentacji, kilka nowych słów kluczowych o których więcej wiem, kilka rzeczy do zgłębienia na później. Fajnie też, że niedługo wystartuje łódzki JUG.

Crazy JPA Requirements

Ostatnio w pracy przenosimy DAO z bezpośredniego SQL + JDBC do JPA (hibernate).
Niestety zapytania są budowane dynamicznie (niektóre kolumny i różne kryteria - between, like, or) i chyba nawet w czystym SQLu byłoby to łatwiej zrobić.
Z drugiej strony JPA jest bardziej elastycznie i błyskawicznie mamy zapisywanie encji. Czas pokaże czy był to dobry wybór.

Gładko te przenosiny oczywiście nie poszły. Dzisiaj np. cały dzień walczyłem z wyjątkiem NPE rzucanym z metody o śmiesznej nazwie:

findIntendedAliasedFromElementBasedOnCrazyJPARequirements

java.lang.NullPointerException
at org.hibernate.hql.ast.tree.FromClause.findIntendedAliasedFromElementBasedOnCrazyJPARequirements(FromClause.java:120)
at org.hibernate.hql.ast.tree.FromClause.getFromElement(FromClause.java:107)

Cóż, widać, że programiści Hibernate mają poczucie humoru i pewnie w ten zabawny sposób wyrazili swoje niezadowolenie z wymagań JPA.
Sam błąd okazał się znany (wariant twierdzenia Defecińskiego) i nawet znaleziony dawno, bo w wersji 3.2.0 GA. Ja obecnie używam hibernate 3.2.5 GA ale nadal kod jest niepoprawiony.
Co i jak poprawić jest napisane w tym issue na JIRA hibernate.

Twierdzenie Defecińskiego (generic toString())

Przy pisaniu jUnit-ów nadpisałem sobie metodę assertEquals(MyObject expected, MyObject actual) dla moich obiektów (właściwie to używana jest assertEquals(Object, Object) a nadpisana jest metoda equals). Jeśli ta assercja jest nieprawdziwa to dostaje się coś w rodzaju expected: MyObject@23123 but got MyObject@323232Oczywiście dlatego, że używana jest metoda toString() z Object.

Napisanie własnej metody toString() jest dobrym rozwiązaniem, ale jeśli mamy kilka różnych obiektów a obiekty mają dużo parametrów to pisanie swoich toString może być męczące. Jeśli dodamy jeszcze do tego to, że podczas developmentu nasz obiekt ciągle się zmienia tj. dochodzą nowe pola, stare znikają to utrzymywanie toString() zsynchronizowanego ze stanem naszej klasy jest trudne.

Pogooglałem i znalazłem szybko ToStringHelper. Oparte o refleksję wypisuje klarownie nazwę i wartości wszystkich pól w obiekcie oraz klas nadrzędnych. Działało to fajnie dopóki jedna klasa nie zmieniła się i zyskała jedno pole wskazujące na swego rodzica (w sensie referencji). Powstała pętla obiektów i toString powodował StackOverflowError :-(.

Posiedziałem nad tym troszkę i napisałem wersję, która byłaby na to odporna. Spodobało mi się, że rozwiązałem problem i chciałem "sprzedać" mój pomysł koledze. Jak wysyłałem mu maila to jeszcze raz zagooglałem o "generic to string" żeby podać link do ToStringHelper ...

... a znalazłem ReflectionToStringBuilder z commons-lang, który robił dokładnie to samo co "mój" toString (nawet ten sam output!) i także nie powodował przeciążenia stosu. Zawsze twierdziłem, że cokolwiek nie wymyślę to istnieje ktoś w sieci kto już to napisał. Myślę, że nazwę to kiedyś twierdzeniem Defecińskiego :D (jak tylko przeprowadzę dowód).

SCJP

Udało się zdać SCJP na 91%. Niby dużo, ale znam takich co mieli więcej :-).

Teraz chyba mogę zacząć pisać blog programisty JAVA. Zawsze wydawało mi się, że trochę za mało wiem, żeby tytułować się programistą JAVY czy jakiegokolwiek innego języka. Tak na prawdę im więcej wiesz tym widzisz jak wiele jeszcze nie umiesz.

Jak kończyłem studia (Politechnika Łódzka/FTIMS) to wydawało mi się, że znam język dość dobrze. Potem dwa lata po studiach kiedy zacząłem przygotowania z SCJP okazało się, że bardzo się mylę. No ale przygotowałem się, zdałem (najsłabiej API contents ale kto tam pamięta metody z DateFormat ?) i ... nadal przede mną wiele tajemnic.

Co do przygotowywania się to może ktoś będzie zainteresowany z czego korzystałem:
książki i testów jqplus. Książkę warto przeczytać, ale najwięcej nauczyłem się rozwiązując testy z JQ+.

Testy robili Hindusi i mają one trochę błędów, ale raczej można to wychwycić i/lub sprawdzić z kompilatorem. JQ+ jest też 2x tańszy od innych pomocy naukowych (Whizlab, uCertify, Troytec) dlatego bym go polecił. Na egzaminie nie było praktycznie pytań identycznych (a z Troytec podobno 90%) ale przecież nie chodzi o naukę na pamięć tylko o zrozumienie tematu.

Powodzenia!