JAVA Developer

Często w Javie operuje się na strumieniach danych. Operacje na nich są analogiczne do poniższej metody:

public static void checkedException() throws IOException {
    try {
        System.out.println("1");
        throw new IOException("Exception 1");
    } catch (FileNotFoundException e) {
        System.out.println("2");
        throw new IOException("Exception 2");
    } catch (IOException e) {
        System.out.println("3");
        throw e;
    } finally {
        System.out.println("4");
        throw new IOException("Exception 4");
    }
}

W bloku finally strumienie są zamykane, lecz metoda close() może wyrzucić wyjątek IOException.  Wywołanie poniższej metody:

try {
    checkedException();
} catch (IOException e) {
    System.out.println(e.getMessage());
}

wypisze na konsoli:

1
3
4
Exception 4

Można by przypuszczać, że wypisany zostanie “Exception 1″, jednak jako ostatni wyrzucony zostaje wyjątek w bloku finally i to on jest przekazywany dalej. Podobna sytuacja dotyczy zwracania wartości w bloku finally.

Bezpieczeństwo typów dla kolekcji i tablic w Javie.

public class A {
    public String getName() { return "A"; }
 
    public static void main(String[] args) {
        Set<B> bSet = new LinkedHashSet<B>();
        Set<A> aSet = bSet; // THIS WILL NOT COMPILE
        aSet.add(new C());
 
        B[] bTable = new B[2];
        A[] aTable = bTable;
        aTable[0] = new B();
        aTable[1] = new C(); //ArrayStoreException
    }
}
 
public class B extends A {
    @Override
    public String getName() { return "B"; }
}
 
public class C extends A {
    @Override
    public String getName() { return "C"; }
}

Załóżmy, że istnieje możliwość przypisania obiektu LinkedHashSet<B> do zmiennej referencyjnej Set<A>. Na nowej referencji można wywołać metodę aSet.add(new C()), czego skutkiem tego jest dodanie obiektu C (podtypu klasy A) do trzymanego na stercie obiektu LinkedHashSet<B>, co jest błędne. Należy jednocześnie pamiętać, że typy genetyczne są zapominane podczas kompilacji i w rzeczywistości w pamięci istnieje obiekt Map. W związku z powyższym przy próbie rzutowania obiektu LinkedHashSet<B> na Set<A> otrzymujemy błąd kompilacji.

Mając analogiczną sytuację dla tablic nie otrzymujemy żadnego powiadomienia o błędzie od kompilatora podczas rzutowania. Dopiero po uruchomieniu dostajemy wyjątek: ArrayStoreException. Jest on związany z próbą dodania do tablicy niezgodnego typu obiektu. Należy pamiętać, że w momencie tworzenia tablic zapamiętują one swój typ.

Z powyższego przykładu widać, że korzystanie z kolekcji jest bezpieczniejsze niż z tablic.

W dniach 13-14 maja odbyła się konferencja GeeCON 2010 poświęcona technologii JAVA.  Wykłady w których miałem okazję uczestniczyć:

13 maja

• Object Teams: The Next Dimension of Modularity, Stephan Herrman
• Easy to Use Highly Available Java Database Access, Craig L Russell
• The High Availability Non-Stop, Fault-Tolerant Services Tutorial, Eugene Ciurana
• Java in high-performance computing, Dawid Weiss
• Gradle – A Better Way To Build, Hans Dockter
• Get ‘em before they get you, Vaclav Pech

14 maja

• Let it crash: using Actors for fault-tolerance, scalability and concurrency, Jonas Bonér
• JDK 7 Update, Dalibor Topic
• Squeezing Java Performance: When you need a little more, Thomas Enebo
• Beyond Agile, Andrea Provaglio
• Apache Camel as a DSL for system integration, Roman Kalukiewicz
• Object Oriented for nonbelievers, Bruno Bossola
• JSR-299 Context and Dependency Injection, Mark Struberg

Najciekawsze wykłady poprowadzili: Eugene Ciurana,  Dawid Weiss, Hans Dockter, Dalibor Topic, Roman Kalukiewicz, Bruno Bossola. Konferencja zakończyła się powodzeniem, choć część tematów traktowana była zbyt ogólnie. Najbardziej interesującym tematem okazał się dla mnie Apache Camel, narzędzie pozwalające na integracje wielu serwisów, oparte na EIP (Enterprise Integration Patterns). Dzięki DSL (Domain Specific Language) przykłady pokazane podczas prezentacji okazały się bardzo zwięzłe i proste do analizy.