Java

Threads sind eine tolle Sache... wenn man richtig damit umgeht. Nicht nur, dass Fehler auf Grund von Race Conditions nicht jedes mal auftreten, nein, ab und an helfen einem auch die Exceptions nicht viel weiter, wenn es um das Lokalisieren der Fehlerquelle geht:

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException
    at javax.swing.LayoutComparator.compare(Unknown Source)
    at java.util.Arrays.mergeSort(Unknown Source)
    at java.util.Arrays.mergeSort(Unknown Source)
    at java.util.Arrays.mergeSort(Unknown Source)
    at java.util.Arrays.mergeSort(Unknown Source)
    at java.util.Arrays.mergeSort(Unknown Source)
    at java.util.Arrays.mergeSort(Unknown Source)
    at java.util.Arrays.sort(Unknown Source)
    at java.util.Collections.sort(Unknown Source)
    at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle(Unknown Source)
    at javax.swing.SortingFocusTraversalPolicy.getFirstComponent(Unknown Source)
    at javax.swing.LayoutFocusTraversalPolicy.getFirstComponent(Unknown Source)
    at javax.swing.SortingFocusTraversalPolicy.getDefaultComponent(Unknown Source)
    at java.awt.FocusTraversalPolicy.getInitialComponent(Unknown Source)
    at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Window.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.SequencedEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)

Dieser Fehler war bei uns in der Arbeit gelegentlich beim Programmstart aufgetreten. Er hat den Programmfunktion nicht beeinschränkt, aber ärgerlich war es dennoch. Also sollte ich mir dem annehmen. Da sämtliche Aufrufe aus der Exception allerdings nicht in unserem Code waren, wusste ich natürlich erstmal nicht, wo ich anfangen soll. Aber wenigstens hilft hier Google ein wenig weiter. Nach ein wenig suchen, stieß ich dann auch recht bald, auf die Ursache: die single-thread rule wurde nicht beachtet.

Once a Swing component has been realized, all code that might affect or depend on the state of that component should be executed in the event-dispatching thread.

Bei uns wurde das ganze dadurch ausgelöst, dass in einem anderen Thread Components aus einem Panel entfernt wurden. Gleichtzeitig hat aber der event-dispatching thread versucht, diese Objekte zu zeichnen. Das das nicht gut gehen kann, sollte man sich recht leicht vorstellen können.

Der Fehler lässt sich auch recht leicht beheben. Man muss nur sämtlichen nebenläufigen Code nach Methoden-Aufrufen von Swing Components durchsuchen (um genau zu sein, muss es nicht jeder Aufruf sein. So sollte ein add() keine Exception verursachen. Der event-dispatching thread würde die Componenten im alten Zustand zeichnen, merken, dass etwas neues dazu gekommen ist und das ganze einfach noch mal zeichnen) und sie dann mit invokeLater() oder auch invokeAndWait() im event-dispatching thread ausführen lassen. Die mehrstündige Suche nach der Ursache wäre uns also erspart geblieben, wenn wir vorher einfach nachgelesen hätten, was man bei Threads und Swing zu beachten hat.

Gestern hatte eine Kollegin ein Problem, dass uns etwas Kopfzerbrechen bereitete. Sie hatte in ihrem Code eine ClassCastException, wo wir keine erwarteten.

Sie hatte eine mit Generics spezifizierte LinkedList (sagen wir mal mit Klasse A) und als sie eine Zuweisung der Art

LinkedList<A> liste = new LinkedList<A>(); 
 ...
A obj = liste.get(0);

ausführte, flog eine ClassCastException. Wir fragten uns dann natürlich, wie es sein kann, dass ein Objekt einer anderen Klasse in der Liste steckt. Schließlich sollten die Generics gerade das verhindern, so, dass der Fehler nicht zur Laufzeit, sondern schon zur Compilerzeit auftritt. Nunja, des Rätsels Lösung war dann recht einfach. Sie hatte an anderer Stelle eine Liste die ohne Generics spezifiert war und hatte sie prompt mit einem falschen Objekt gefüllt. Anschließend übergab sie diese nicht-generic Liste als Parameter der Methode addAll(Collection<? extends E> c). Auch wenn die Parameter-Deklaration eigentlich vermuten lässt, dass hier auch nur Collections mit entsprechendem Typ erlaubt sind, scheint das nicht der Fall zu sein. Die generic Liste schluckte die falschen Objekte ohne zu murren.

LinkedList<String> genericList = new LinkedList<String>();
LinkedList nonGenericList = new LinkedList();
nonGenericList.add(new Integer(1));
genericList.addAll(nonGenericList); // funktioniert, obwohl genericList nur Strings erlaubt
String result = genericList.get(0); // ClassCastException

Deshalb: benutzt eure Generics konsequent.

Der ein oder andere mag das Problem kennen: Man möchte ein Java Programm ausführen, aber auf dem Rechner ist keine JRE installiert und man kann auch nichts daran ändern, sei es nun, weil man nichts installieren darf oder einem schlicht die Rechte dazu fehlen. Im Berufsleben kann es auch dazu kommen, dass die Richtlinien eines potentiellen Kunden keine JRE vorsehen oder nur eine veraltete Version vorhanden ist, zu der das Programm inkompatibel ist.

Dafür gibt es aber eine einfache Lösung. Dazu benötigt man auch eine JRE, nur installiert man sie nicht, sondern man benötigt nur den Ordner und deren Inhalt. Dieser Ordner kann dann entweder auf den Rechner kopiert werden oder man behält ihn auf einem USB-Stick. Man kann hat dadurch also sozusagen immer eine portable JRE bei sich.

Anschließend muss man in dem Ordner, in dem sich das aufzurufende Programm befindet eine BAT-Datei erstellen mit beispielsweise diesem Inhalt:

start <Pfad zum JRE Verzeichnis>\bin\javaw.exe -jar DeinJar.jar

Jetzt reicht das Aufrufen der BAT-Datei und schon wird das Programm ohne eine installierte JRE gestartet. Natürlich kann man das Ganze auch für andere Zwecke nutzen und für ein Programm eine andere JRE als die installierte verwenden.