Tomasz Nurkiewicz around Java and concurrency

Dzięki uprzejmości mojej firmy miałem w tym roku niewątpliwą przyjemność uczestniczyć w Java Developers' Day 2008 w Krakowie. Krótko o prelekcjach, których miałem możliwość wysłuchać: Na początek keynote w wykonaniu Teda Newarda . To, co miało być pogadanką o wszystkim i o niczym gościa z USA było pasjonującą podróżą po językach programowania od lat 60 do niedalekiej przyszłości. Ogromne pokłady humoru i kilka mniej lub bardziej kontrowersyjnych opinii o relacjach między światem akademickim i komercyjnym. Na koniec usłyszeliśmy tezę, że " God doesn't think in objects " z żartobliwym autoripostą " He thinks in Ruby " :-). Mnóstwo ciekawostek i humoru rodem z za oceanu. Słuchało się tego z przyjemnością.* Potem było JAIN SLEE ustami Jana Pieczykolana . To mógł być dobry i ciekawy wykład, ale... Niestety mam wrażenie, że gdyby prelegent nie skupił się tak mocno na promocji własnej firmy, starczyłoby mu czasu na ciekawą demonstrację. A tak - było po prostu nu

Począwszy od Javy 1.3 programistom (głównie frameworków) została udostępniona niezwykle użyteczna klasa Proxy . Zasadniczo klasa ta pomaga w implementacji wzorca projektowego o tej samej nazwie, jednak skupię się na przykładzie użycia samej klasy, reszta będzie już oczywista. Proxy jest swoistą warstwą pośredniczącą między obiektem docelowym a światem zewnętrznym. Wywołanie każdej metody obiektu docelowego "przechodzi" przez proxy, które ma pełen zestaw możliwości wpływania na to wywołanie (podejrzenie i zmiana parametrów, logowanie, a nawet całkowite zaniechanie wywołania właściwej metody). Jeśli znacie metody z grupy java.util.Collections.synchronized*() , to koncepcyjnie zwracają one właśnie takie proxy, które opakowuje wszystkie wywołania metod docelowej kolekcji. Rolą proxy jest w tym przykładzie zapewnienie synchronizacji na poziomie każdej metody i oczywiście wywołanie właściwej metody. Podobnie możemy sobie wyobrazić proxy zabezpieczające kolekcję przed modyfikacją, k

Często piszę króciutkie programy z samym mainem tylko po to, aby sprawdzić działania nieznanej funkcji API czy właśnie zaimplementowanego algorytmu. Ot taki proof-of-concept jeszcze przed napisaniem testów jednostkowych (wiem, wiem, testy piszemy najpierw, ale...) Aby zachować pewne standardy staram się nawet w takim testowym kodzie używać Log4j do pary z commons-logging zamiast klasycznego System.out.println() . Nie tylko lepiej wygląda, ale też Log4j zapewnia pewne dodatkowe informacje. Niestety kod: import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; class Main {   private static final Log log = LogFactory.getLog(Main.class);   public static void main(String[] args) {   log.info("Example message");   } }   spowoduje wyświetlenie co najwyżej znanego skądinąd błędu: log4j:WARN No appenders could be found for logger (Main). log4j:WARN Please initialize the log4j system properly. W takich sytuacjach z reguły kopiowałem p