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 nudno.Na szc…

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ą, któr…

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 plik log4j.xml z jakiegokolw…