Der Artikel bezieht sich hauptsächlich auf Programme, die mit dem Benutzer interagieren. Er gilt aber auch für Programme, die ohne Aufsicht (im Hintergrund) ablaufen: Diese können in der Regel zwar keine Benutzereingaben anfordern, die eine Fehlerbehebung anbieten, jedoch haben sie Fehler in eine Logdatei (Protokolldatei, Windows-Ereignisanzeige) zu schreiben in der gleichen Qualität.

Qualitätsabstufungen: Wie melden Computerprogramme Fehler?

Die Qualität der Fehlermeldungen steigt mit jedem Aufzählungspunkt, den letzten Punkt sollten wir von Programmen einfordern, den vorletzten hat ein Programm mindestens einzuhalten.

• Keine Fehlermeldung bei Fehlern: Leider gibt es noch Programme, die Fehler nicht melden und ich habe unter Umständen nachzuschauen, ob das Programm die Arbeit richtig erledigte. Reagierte das Programm nicht wie beabsichtigt und ich habe Glück, schreibt es eine gute Fehlermeldung in eine Logdatei. Habe ich Pech, kann ich nur durch Intuition, Versuch und Irrtum das Programm zum Funktionieren überreden.
• "Es ist ein unbekannter Fehler aufgetreten": Hier weiß ich, etwas lief schief, aber nicht was. Vor zwei Tagen wollte ich Daten auf eine Blu-ray-Disc brennen und das Brennprogramm zeigte genau diesen Text an. Ursache war, dass im gleichen Verzeichnis der gleiche Dateiname einmal mit großem Anfangsbuchstaben stand und einmal mit kleinem (text.txt und Text.txt), was anscheinend die benutzte UDF-Version nicht erlaubt (prinzipiell ist dies möglich) bzw. das Brennprogramm nicht akzeptiert. Diese Ursache musste ich selbst herausfinden und das war nicht einfach, für ein Computerprogramm hingegen ist dies kein größeres Problem, beispielsweise kann es intern alle Dateinamen eines Verzeichnisses in Kleinbuchstaben umwandeln und zählen wie häufig jeder klein geschriebene vorkommt.
• Falsche Fehlermeldung: Die Fehlermeldung hat nichts zu tun mit der Ursache. Durch (Web-) Recherche habe ich herauszufinden, unter welchen Umständen diese Meldung bislang auftrat und alle Lösungsvorschläge der Reihe nach so lange durchzuführen, bis das Programm richtig läuft.
• Fehlernummern: Statt einer Beschreibung des Fehlers erscheint eine Meldung in der Art: "Es ist ein Fehler aufgetreten. Fehler-Code 0x47110815B2312". Durch (Web-) Recherche führt der Fehlercode zum tatsächlichen Fehler oder auch nicht. Die misslungenen automatischen Updates von Windows 7 lieferten mir bislang nur solche Fehlercodes, deren Erklärung ich dann auf dem Microsoft Website anschauen musste. Dort waren für den gleichen Code in der Regel mehrere mögliche Ursachen aufgelistet und ich durfte die Lösungsvorschläge je Ursache der Reihe nach durchprobieren. Das kostete sehr viel Zeit und führte selten zum Erfolg.
• Richtige Fehlermeldung: Nur in diesem Fall kann ich den Fehler ohne viel Stress beheben. Voraussetzung ist eine gute Formulierung, beispielsweise: "Die Datei abc.txt kann nicht in das Verzeichnis xyz geschrieben werden, da Sie keine Schreibrechte im Verzeichnis xyz besitzen".
• Richtige Fehlermeldung inklusive Lösungsvorschlag: Um beim letzten Beispiel zu bleiben, könnte ergänzend erklärt werden, wie ich Schreibrechte erhalte. Eigentlich sollte eine Schaltfläche "Schreibrechte erlangen" auf der Fehlermeldung existieren mit guter Usability, keine kruden Dialoge, bei denen ich mehrfach auf weitere Schaltflächen zu klicken habe, die erneut Dialoge öffnen, wie beispielsweise bei der Rechtevergabe über den Windows-Explorer.

Fazit: Kann das Programm den Fehler nicht beheben, hat es zumindest eine präzise Beschreibung der Ursache zu liefern, damit ich ohne Zeitverschwendung weiß, ob ich etwas tun kann und was ich tun sollte. Kann es den Fehler beheben, sollte die Fehlermeldung eine Schaltfläche enthalten, die dies durchführt ohne dass ich hierbei unnötig viel zu unternehmen habe (gute Usability/Gebrauchstauglichkeit), im besten Fall ist das ein (einziger) Mausklick oder Eintippen eines Buchstabens auf der Kommandozeile.

Wir schreiben das Jahr 2012 und noch immer halte ich diesen Artikel für nötig aufgrund täglichen Herumärgerns mit schlechten Fehlermeldungen. Weshalb sollen viele Benutzer enorme Zeit aufwenden und Fehlerursachen häufig erraten anstelle dass sich wenige Programmierer etwas mehr Zeit nehmen beim Programmieren?

Programmiertechnik grob angerissen

Ein Programmierer sollte es als “Ehrensache” betrachten, gute Fehlermeldungen zu liefern. Darüber freuen sich nicht nur die Benutzer, auch der Programmierer kann so Bugs schneller beheben.

Oft entstehen Fehler in “unteren Schichten”, in Methoden (Funktionen, Prozeduren, Subroutinen) die durch Methoden aufgerufen werden, die durch Methoden aufgerufen werden usw. Falls die Programmiersprache Ausnahmen (Exceptions) werfen kann wie beispielsweise C++ und Java, sollte eine Methode davon bei Bedarf Gebrauch machen.

Ein Fehler, über den ich mich häufig an dieser Stelle ärgerte, ist, der Exception nicht alle verfügbaren Daten zu geben, die helfen können, den Fehler möglichst genau zu identifizieren und zu beheben. Das sind neben dem Wortlaut des Fehlers (Fehlernachricht, Error Message) unter anderem die Methodenparameter und die präzise Systemzeit (Millisekunden oder genauer). Ich warf in einem C++-Programm eine Exception, falls beim Öffnen einer Datei das Dateiformat ungültig war, vergaß jedoch den Dateinamen in die Meldung zu schreiben. Da die Datei nicht durch Benutzerauswahl geöffnet wurde, hatte ich bei Fehlern immer viel Arbeit, den Benutzern zu erklären, wo er sie finden kann.

Kann eine Methode eine Exception nicht beheben, reicht sie diese weiter oder wirft eine Exception mit dem Exception-Objekt als Ursache und mit zusätzlichen dienlichen Informationen. Das geht so weiter bis hin in die oberste Schicht, die den Fehler protokolliert und die Fehlermeldung anzeigt.

Die Meldung richtet sich nach der Aufgabe der obersten Schicht, sie lautet beispielsweise "Die Datei Blafasel.txt konnte nicht geöffnet werden!". In einem Detailabschnitt stehen dann alle Meldungen vorheriger Exceptions wie beispielsweise "Die Datei Blafasel.txt existiert nicht" oder "Im Verzeichnis xyz fehlen Leserechte" oder "Die Datei Blafasel.xml hat ein ungültiges Dateiformat: Zeile 25 hat ein schließendes Tag </blubb> ohne dass vorher ein öffnendes Tag <blubb> existiert".

Falls es möglich ist, sollte in der Logdatei der gesamte Callstack stehen, so weiß der Programmierer, von wo aus es im Quellcode zum Fehler ging wo genau er auftrat und kann Bugs manchmal sekundenschnell beheben.

Ich integriere in Fehlermeldungen eine Schaltfläche zum Schicken einer E-Mail, das Benutzen eines Bugtracking-Systems führt garantiert zu viel weniger Feedback, da es wissenden Programmbenutzern eine Menge Arbeit aufbürdet und die unwissenden ausschließt.

Hat eines meiner Programme Bugs, stehe ich in der “Schuld”, diese zu beheben und ich finde es unschön, falls der Benutzer neben dem negativen Erlebnis auch noch viel Arbeit hat, Fehler zu melden. In der Regel werden Benutzer diese Arbeit unterlassen, sofern sie für das Programm nicht Geld bezahlten und statt dessen ein anderes benutzen, falls es Alternativen gibt.

Ein solches Lookup benutzen NetBeans Platform-Anwendungen, es kann in Nicht-Platform-Anwendungen eingesetzt werden. Die Projekte integrieren dazu das JAR org-openide-util-lookup.jar, es ist unterhalb des NetBeans-Installationsverzeichnisses im Verzeichnis platform/lib.

Zugrunde liegende Idee

• Ein Anwendungsmodul hat einen oder mehrere Lookups
• Wird im GUI etwas ausgewählt oder abgewählt, gelangen relevante Daten, die das GUI-Element repräsentiert, in eines der Lookups
• Die Actions beobachten das Lookup: Ist es leer, sind sie deaktiviert, enthält es Elemente, sind sie aktiviert. In actionPerformed() benutzen Actions die Elemente des Lookups.

Das NetBeans-Lookup benachrichtigt Beobachter nur, falls Daten eine bestimmten Typs im Lookup sind: Eine Action, die Personen in eine Datenbank speichert, will in der Regel nicht wissen, ob und wieviele Bücher im Lookup sind.

Beispiels-Implementierung

Ich habe ein Beispiels-Projekt implementiert und in ein ZIP-Archiv gepackt. Nach dem Entpacken kann es mit NetBeans geöffnet werden. Das Kontextemenü des Projects-Window bietet Run oder Debug an (auf die Klasse Main mit der rechten Maustaste klicken).

(Nur) Der Übersichtlichkeit wegen verzichtete ich bei den Beispielen auf Parameterüberprüfung, in “Produktions-Code” sollten die Parameter überprüft werden, beispielsweise eine NullPointerException geworfen, falls null überreicht wird anstelle einer erwarteten Objektreferenz.

LookupAction

Die LookupAction habe ich kopiert aus dem Projekt JPhotoTagger. LookupActions beobachten einen Lookup. Bei Aufruf von actionPerformed() ruft die LookupAction bei den spezialisierten Actions die abstrakte Methode actionPerformed(Collection<? extends T> lookupContent) auf, mit isEnabled(Collection<? extends T> lookupContent) können sie entscheiden, ob sie aktiviert sein sollen, in der Regel werden sie true liefern, falls der Lookup-Content Elemente enthält.

public abstract class LookupAction<T> extends AbstractAction implements LookupListener {

    private final Class<? extends T> lookupResultClass;
    private final Lookup lookup;
    private Lookup.Result<? extends T> lookupResult;

    protected LookupAction(Class<? extends T> lookupResultClass, Lookup lookup) {
        this.lookupResultClass = lookupResultClass;
        this.lookup = lookup;
        setLookupResult();
    }

    protected abstract boolean isEnabled(Collection<? extends T> lookupContent);

    protected abstract void actionPerformed(Collection<? extends T> lookupContent);

    private void setLookupResult() {
        if (lookupResult == null) {
            lookupResult = lookup.lookupResult(lookupResultClass);
            lookupResult.addLookupListener(this);
            resultChanged(null);
        }
    }

    @Override
    public void resultChanged(LookupEvent evt) {
        setEnabledInDispatchThread();
    }

    private void setEnabledInDispatchThread() {
        final boolean isEnabled = isEnabled(lookupResult.allInstances());

        if (EventQueue.isDispatchThread()) {
            setEnabled(isEnabled);
        } else {
            EventQueue.invokeLater(new Runnable() {

                @Override
                public void run() {
                    setEnabled(isEnabled);
                }
            });
        }
    }

    protected Collection<? extends T> getLookupContent() {
        return (lookupResult == null)
                ? Collections.<T>emptyList()
                : lookupResult.allInstances();
    }

    @Override
    public void actionPerformed(ActionEvent e) {
        setLookupResult();
        actionPerformed(lookupResult.allInstances());
    }
}

Eigenes Lookup

Die Klasse ModifiableLookup liefert ein Lookup und bietet Methoden an, dessen Inhalt zu modifizieren.

public final class ModifiableLookup implements Lookup.Provider {

    private final InstanceContent content = new InstanceContent();
    private final Lookup lookup = new AbstractLookup(content);

    @Override
    public Lookup getLookup() {
        return lookup;
    }

    public void add(Object content) {
        this.content.add(content);
    }

    public void remove(Object content) {
        this.content.remove(content);
    }

    public void set(Collection<?> content) {
        this.content.set(content, null);
    }
}

Beispiel: Ausgewählte Listenelemente in das Lookup einfügen

Will ich ausgewählte Items einer JList in das Lookup einfügen, kann ich folgende Klasse benutzen:

public final class LookupListSelectionListener implements ListSelectionListener {

    private final ModifiableLookup lookup;

    public LookupListSelectionListener(ModifiableLookup lookup) {
        this.lookup = lookup;
    }

    @Override
    public void valueChanged(ListSelectionEvent e) {
        if (!e.getValueIsAdjusting()) {
            JList list = (JList) e.getSource();
            List<Object> selectedValues = Arrays.asList(list.getSelectedValues());
            lookup.set(selectedValues);
        }
    }
}

Beispielsklassen, die in das Lookup sollen

public final class Human {

    private final String name;

    public Human(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    @Override
    public String toString() {
        return name;
    }
}

public class Dog {

    private final String name;

    public Dog(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return name + " (Wuff)";
    }
}

public final class CreatureListModel extends DefaultListModel {

    private static final long serialVersionUID = 1L;

    public CreatureListModel() {
        addElement(new Human("Anton"));
        addElement(new Human("Berta"));
        addElement(new Human("Cäsar"));
        addElement(new Human("Dora"));
        addElement(new Human("Emil"));
        addElement(new Dog("Fiffi"));
        addElement(new Dog("Waldi"));
    }
}

Kommunikation über ein zentrales Lookup

Ein Anwendungsmodul kann Lookups beispielsweise so bereitstellen:

public final class Lookups {

    public static final Lookups INSTANCE = new Lookups();
    private final ModifiableLookup humansLookup = new ModifiableLookup();

    public ModifiableLookup getHumansLookup() {
        return humansLookup;
    }

    private Lookups() {
    }
}

Erweiterte LookupAction

Die erweiterte LookupAction interessiert sich (nur) für Instanzen von Human

public final class ShowHumansInLookupAction extends LookupAction<Human> {

    private static final long serialVersionUID = 1L;

    public ShowHumansInLookupAction() {
        super(Human.class, Lookups.INSTANCE.getHumansLookup().getLookup());
        putValue(Action.NAME, "Zeige ausgewählte Menschen");
    }

    @Override
    protected boolean isEnabled(Collection<? extends Human> humans) {
        return !humans.isEmpty();
    }

    @Override
    protected void actionPerformed(final Collection<? extends Human> humans) {
        JOptionPane.showMessageDialog(null, humans);
    }
}

In einem GUI benutzen

Die entscheidenden Zeilen in einem GUI, die Action ist einem Button zugeordnet, Model und ListSelectionListener der Liste:

    list.setModel(new CreatureListModel());
    list.addListSelectionListener(new LookupListSelectionListener(Lookups.INSTANCE.getHumansLookup()));
    button.setAction(new ShowHumansInLookupAction());

Worauf achten beim Ausführen der Beispielsanwendung

• Ist nicht ausgewählt, setzt sich die Action automatisch auf deaktiviert, der Button mit der Action ist deaktiviert (“ausgegraut”)
• Werden ein oder mehrere Menschen ausgewählt, ist die Action aktiviert, der Button reagiert auf Klicks (Betätigung)
• Sind nur Hunde ausgewählt, ist der Button deaktiviert
• Die Action erhält nur Menschen: Sind Hunde und Menschen ausgewählt, zeigt bei Klick auf den Button die Action den Lookup-Content an – es sind nur die erwarteten Objekte darin

Vorteile

• Die Action ist nicht an ein GUI gebunden (sie benötigt nur ein Lookup). Sie ist nicht anzupassen, falls später beispielsweise ein JTree die Geschöpfe anzeigt (getrennt nach Mensch und Tier). Es könnte auch ein Dialog zum Ändern der Daten eines Menschen benutzt werden: Der “Mensch im Dialog” gelangt in das Lookup, das die Action benutzt.
• Die Action fragt nicht nach den benötigten Daten, sie erhält sie
• Die Action aktiviert und deaktiviert sich automatisch
• Das Lookup könnte über Modulgrenzen hinweg benutzt werden, beispielsweise über das Java-Service Provider Interface (SPI) oder ein globales Lookup, wie es die NetBeans-Platform anbietet. Die Actions anderer Module sind nur mit dem passenden Lookup zu verknüpfen, sie müssen nicht wissen, woher die Daten kommen (wie sie an diese gelangen).
• Actions sind nur ein Beispiel, es können beliebige Klassen LookupListener sein

• Die Ersatz-EventQueue benutzt das Logging-System und loggt die Ausnahme mit dem Level SEVERE
• Ein Handler – ein erweiterter java.util.logging.Handler – reagiert auf bestimmte Loglevel, zeigt beispielsweise einen “Fehlerindikator” an, bei Klick darauf erhält der Benutzer nähere Informationen über den Fehler

Modifizierte EventQueue

public final class AppEventQueue extends java.awt.EventQueue {

    @Override
    protected void dispatchEvent(AWTEvent event) {
        try {
            super.dispatchEvent(event);
        } catch (Throwable t) {
            Logger.getLogger(AppEventQueue.class.getName()).log(Level.SEVERE, null, t);
        }
    }
}

Handler

public final class ErrorLogHandler extends Handler {

    private static final int MIN_LOG_LEVEL_VALUE = Level.WARNING.intValue();

    public ErrorLogHandler() {
        Logger.getLogger("").addHandler(this);
    }

    @Override
    public void publish(LogRecord record) {
        int recordLevelValue = record.getLevel().intValue();
        boolean isError = recordLevelValue >= MIN_LOG_LEVEL_VALUE;

        if (isError) {
            // Hier den Fehler visualisieren
        }
    }

    @Override
    public void flush() {
        // ignorieren
    }

    @Override
    public void close() throws SecurityException {
        // ignorieren
    }
}

Der Handler fügt sich dem root Logger hinzu, der root Logger ruft die Handler-Methode publish() auf. Jeden Loglevel ab WARNING betrachtet der Handler als Fehler (isError). Bei Fehlern kann er beispielsweise über die setIcon()-Methode eines Labels ein Fehler-Icon setzen und bei Klick auf das Label die Fehlerinformationen anzeigen, beispielsweise anhand Fehler-LogRecords, die er temporär speichert.

EventQueue ersetzen

Die EventQueue ersetze ich “rechtzeitig” durch folgende Codezeile (im Projekt JPhotoTagger unmittelbar nach Erzeugen des Programmfenster-Frames):

Toolkit.getDefaultToolkit().getSystemEventQueue().push(new AppEventQueue());

Die folgenden Abbildungen zeigen die Auswirkungen: In NetBeans setzte ich einen Haltepunkt in die Zeile 127 der Klasse AppInit, Methode setJptEventQueue(), das ist die Zeile mit dem push()-Afuruf. Gelb unterlegt ist der Thread AWT-EventQueue-0. Nach Aufruf ist zu sehen, dass nun Thread AWT-EventQueue-1 läuft, die Namen lassen sich nicht ändern, es wird nur die Nummer hochgezählt.

JPhotoTagger: AWT-EventQueue ersetzen, Debugger-Ansicht vor Ersetzen

JPhotoTagger: AWT-EventQueue ersetzen, Debugger-Ansicht nach Ersetzen.

Fehleranzeige durch einen Log-Handler in JPhotoTagger am unteren Programmfensterrand.

Außerhalb der AWT-EventQueue

In anderen Threads kann ich nicht gefangene Ausnahmen loggen mit java.lang.Thread#setDefaultUncaughtExceptionHandler() – der Handler wird nicht aufgerufen im AWT-Event Dispatch Thread. Beispiel:

public final class UncaughtExceptionLogger implements Thread.UncaughtExceptionHandler {
    @Override
    public void uncaughtException(Thread t, Throwable e) {
         Logger.getLogger(UncaughtExceptionLogger.class.getName()).log(Level.SEVERE, null, e);
    }
}

Benutzung:

Thread.setDefaultUncaughtExceptionHandler(new UncaughtExceptionLogger());

Zusammenfassung (mit Erweiterung um FileHandler)

• Nicht gefangene Ausnahmen sollen dem Benutzer unaufdringlich angezeigt werden und in einer Logdatei stehen
• Ein erweiterter java.util.logging.Handler zeigt dem Benutzer Probleme an ab dem Loglevel WARNING, ein java.util.logging.FileHandler schreibt die LogRecords in eine Logdatei. Diese Handler füge ich dem root Logger hinzu.
• Je ein Logger loggt ungefangene Ausnahmen mit dem Level SEVERE
  • im AWT-EventDispatchThread in einer eigenen EventQueue, die die “Standard”-EventQueue ersetzt
  • in (allen) anderen Threads in einem java.lang.Thread.UncaughtExceptionHandler, den ich setze mit Thread#setDefaultUncaughtExceptionHandler()

Falls ich mich nicht einarbeiten will, ist der ServiceLoader nach meinen aktuellen Kenntnissen am geeignetsten, dieser lässt sich auch in einem Framework benutzen.

Dazu definiere ich in einem oder mehreren Projekten Interfaces (Services). Diese implementiere ich in anderen Projekten.

Beispielsweise könnte ich entscheiden, das Programmfenster hat drei Bereiche, in die andere Module (Projekte) “Fenster” einfügen können. Die Interface-Definition sähe z.B. so aus:

public interface WindowSystem {
    void dockIntoSelectView(Component component);
    void dockIntoEditView(Component component);
    void dockIntoPropertiesView(Component component);
}

In irgend einem Projekt implementiere ich dies und publiziere diese Implementierung gemäß der JavaDoc des ServiceLoader im META-INF/services-Verzeichnis:

public final class ApplicationFrame implements WindowSystem {

    @Override
    public void dockIntoSelectView(Component component) {
        tabbedSelectViewPane.add(component);
    }

    @Override
    public void dockIntoEditView(Component component) {
        tabbedPaneEditView.add(component);
    }

    @Override
    public void dockIntoPropertiesView(Component component) {
        tabbedPanePropertiesView.add(component);
    }
}

Will ich in einem anderen Projekt der Select-View des Anwendungsfensters etwas hinzufügen, benutze ich den ServiceLoader. Ich vereinfache mir die Arbeit mit der Klasse ServiceLookup eines Projekts, das alle anderen Projekte nutzen dürfen und das keine Abhängigkeit zu einem anderen Projekt hat, siehe Implementierung weiter unten:

public final class ImageFileBrowser implements Module {

    private JTree fileSystemTree;

    @Override
    public void initModule() {
        java.awt.EventQueue.invokeLater(new Runnable() {
            @Override
            public void run() {
                createFileSystemTree();
                addFileSystemTree();
            }
        );
    }

    private void createFileSystemTree() {
        FileFilter directoryFilter = FileSystemUtil.getDirectoriesOnlyFileFilter();
        TreeModel fileSystemTreeModel = FileSystemUtil.createFileSystemTreeModel(directoryFilter);

        fileSystemTree = new JTree(fileSystemTreeModel);
        fileSystemTree.setCellRenderer(new FileSystemTreeCellRenderer());
        fileSystemTree.addTreeSelectionListener(new ImageDisplayTreeSelectionListener());
    }

    private void addFileSystemTree() {
        WindowSystem windowSystem = ServiceLookup.lookup(WindowSystem.class);

        windowSystem.dockIntoSelectView(fileSystemTree);
    }
}

Klasse ServiceLookup eines “Utility”-Projekts, das keine Abhängigkeiten zu anderen Projekten hat und das alle anderen Projekte benutzen dürfen:

public final class ServiceLookup {

    public static <T> T lookup(Class<T> serviceClass) {
        if (serviceClass == null) {
            throw new NullPointerException("serviceClass == null");
        }

        ServiceLoader<T> serviceLoader = ServiceLoader.load(serviceClass);
        Iterator<T> serviceImplementations = serviceLoader.iterator();

        return serviceImplementations.hasNext()
                ? serviceImplementations.next()
                : null;
    }

    public static <T> Collection<? extends T> lookupAll(Class<T> serviceClass) {
        if (serviceClass == null) {
            throw new NullPointerException("serviceClass == null");
        }

        Collection<T> serviceImplementations = new ArrayList<T>();
        ServiceLoader<T> serviceLoader = ServiceLoader.load(serviceClass);

        for (T service : serviceLoader) {
            serviceImplementations.add(service);
        }

        return serviceImplementations;
    }

    private ServiceLookup() {}
}

Prinzip einer modularen Anwendung mit Hilfe des ServiceLoader:

• Die Anwendung besteht aus unterschiedlichen Projekten, jedes hat eine bestimmte Aufgabe (“Zuständigkeit”)
• Einige Projekte deklarieren verschiedene Services als Interface
• Andere Projekte implementieren diese Services und veröffentlichen die Implementierungen im META-INF/services-Verzeichnis
• Projekte benutzen die Services und fügen so der Anwendung weitere Fähigkeiten hinzu
• Ein “Sammelprojekt” enthält die JARs aller Teilprojekte und den “Startcode”, der eine von allen Teilprojekten zu implementierende “init”-Methode aufruft (im Beispiel oben die Methode initModule() des Services Module, “Abholen” der Implementierungen mit ServiceLookup.lookupAll())

Will ich die Anwendung erweitern, eröffne ich ein neues Projekt, benutze die Services und füge das Projekt-JAR dem Sammelprojekt hinzu. Ich brauche nicht die bisherigen Projekte anzupassen.

Das Beispiel oben könnte ich erweitern: Ein neues Projekt implementiert analog zu ImageFileBrowser über die Module-Schnittstelle beispielsweise eine Klasse Mp3FileBrowser, ein weiteres VideoFileBrowser. Diese Projekte müssen nichts voneinander wissen ebensowenig wie das Fenstersystem wissen muss, welche Fenster mit welcher Funktion ihm hinzugefügt werden.

Eine Aktion ist Code, der beim Eintreten bestimmter Ereignisse ausgeführt wird. Die Basisklasse ist Action, in der Regel wird eine Klasse abgeleitet von AbstractAction. Der Code wird in actionPerformed() ausgeführt.

1. Aktion auslösen anhand Tastatureingabe

In früheren Java-Versionen (vor 1.3) war die Aktion ein KeyListener bei einer Component. Aktuelles Vorgehen:

1. String-Schlüssel definieren, der beschreibt, was geschieht, z.B. “Kopieren in die Zwischenablage” (der Schlüsselname wird dann vielleicht COPY_TO_CLIPBOARD heißen). Dieser Schlüssel ist nicht Attribut (Field) der Aktion: Die Aktionen sollen ausgetauscht werden können (z.B. spezielles Kopieren in die Zwischenablage über eine andere Aktion), ebenso die Auslöser (z.B. unter Macintosh-Rechnern die Command-Taste anstelle der Strg-Taste oder frei definierbar durch die Benutzer) oder die Aktion soll entfernt werden können (keine Reaktion mehr auf diese Tastatureingabe).
2. Tastatureingabe, die Aktion auslösen soll, diesem Schlüssel zuweisen über die InputMap der JComponent
3. Aktion diesem Schlüssel zuweisen über die ActionMap der JComponent

Anmerkung: Eine JComponent hat 3 InputMaps, die in folgender Reihenfolge so lange abgearbeitet werden, bis für die Tastatureingabe ein Eintrag gefunden wurde: 1. Eine, sofern die JComponent fokussiert ist, 2. eine, falls die JComponent Vorgänger (Elterncontainer) einer fokussierten ist und 3. eine, falls das Window der JComponent fokussiert ist. 2./3. werden benutzt, falls eine Aktion ausgelöst werden soll unabhängig von der gerade fokussierten Komponente.

Weitere Informationen: How to Use Key Bindings.

2. Aktion Buttons und Menüs zuweisen

Die gleichen Aktionen können z.B. JMenuItems und JButtons über deren Konstruktoren zugewiesen werden (z.B. aus der ActionMap über deren Schlüssel holen).

3. Wie wird die Aktion aktiviert und deaktiviert?

Ist die Aktion von AbstractAction abgeleitet, ruft man setEnabled() auf. JButtons und JMenuItems sind PropertyChangeListener bei der Aktion, werden vom Aktivieren/Deaktivieren benachrichtigt und sind anschließend (wieder) aktiv oder nicht (mehr aktiv; “schwarz” oder “ausgegraut”).

4. Offene Probleme

4.1 Wie gelangt die Aktion an die zu verarbeitenden Daten?

Ich gehe davon aus, die Aktion soll nicht lediglich z.B. einen Dialog anzeigen, sondern ausgewählte Daten verarbeiten, z.B. eine ausgewählte Datei löschen.

Manchmal erhält man die Daten – z.B. visualisiert als Knoten eines JTrees – über die Quelle der Aktion (Eigenschaft source des ActionEvents in actionPerformed(), im speziellen Fall des JTree) . Bei Menüaufrufen nutzt das nichts, da die Aktionsquelle das JMenuItem ist. Gleiches trifft zu, falls die Aktion an eine Vorfahren-Komponente gebunden ist, die nicht fokussiert ist, Aktionsquelle ist dann die Vorfahren-Komponente, nicht die fokussierte.

Wird von einem GUI-Builder eine Aktion erzeugt, ist diese oft eine anonyme innere Klasse eines GUIs, die Zugriff hat auf alle Attribute (Fields) des GUIs. Das ist nicht wiederverwendbar.

Man könnte alle Daten in der Aktion als Attribute speichern, was ich weniger gut finde (die vielseitigen Gründe sind hier nicht beschrieben, der vermutlich wichtigste: Die Aktion kann nicht “universell” eingesetzt werden, sondern ist fest gekoppelt an eine spezialisierte JComponent).

In den oben aufgeführten Fällen wird man wiederholt Code schreiben, der die Daten mehr oder weniger aufwändig ermittelt, z.B. alle ausgewählten Knoten eines Baums herausfindet und anhand dieser die Daten, beispielsweise Dateisystemordner oder in einer Datenbank gespeicherte Werte.

4.2 Wie werden die Bedingungen festgestellt, unter denen die Aktion aktiviert/deaktiviert wird?

Ist in einem Baum kein Knoten selektiert, soll die Entf-Taste nichts löschen und das Kontextmenü soll keinen oder einen deaktivierten “Löschen”-Menüpunkt anzeigen.

Es sollte nicht Aufgabe der Aktion sein, jedes mal zu prüfen, ob sie ausgeführt werden soll.

4.3 Lösungsansatz

Aktuell favorisiere ich den Ansatz der NetBeans-Platform (der in dieser Form selbst zu implementierende spezialisierte Aktionen erfordert): Es gibt Container mit Objekten, sogenannte Lookups. Beobachter melden sich bei den Lookups an und ändert sich der Inhalt der Lookups, werden die Beobachter benachrichtigt (nur falls Klassen betroffen sind, die den Beobachter interessieren). Es gibt einen (“globalen”) Lookup, der den Inhalt der gerade ausgewählten spezialisierten JComponent enthält.

Die Aktion ist ein Beobachter des (globalen) Lookups: Ist “interessanter” Inhalt im Lookup, aktiviert sie sich und sie deaktiviert sich, ist das beobachtete Lookup leer. Wird die Aktion ausgeführt, benutzt sie den Inhalt des Lookups.

Aktionen interessieren sich nur für bestimmte Objekte: Eine, die Dateien umbenennt, benötigt nur die File-Objekte der umzubenennenden Dateien. Wäre sie an einen JTree, einer JList oder anderen JComponents gebunden, müsste sie jedesmal mehr oder weniger umständlich die Dateien daraus ermitteln und wäre begrenzt auf die spezialisierte JComponent.

Das Lookup löst beide Probleme (4.1 und 4.2): Die Aktionen sind nur aktiv, falls sinnvoll und sie haben die Daten, mit denen sie arbeiten wollen.

“Außerhalb” der NetBeans-Platform sind folgende Probleme zu lösen (wie, zeigt der Artikel nicht auf):

• Ein “globales” Lookup definieren, bei dem die Aktionen als Beobachter angemeldet werden
• In dieses Lookup sind bei Selektion die selektierten Objekte einzufügen; das Lookup enthält nichts (nichts ausgewählt) oder alle ausgewählten Objekte (nicht die “Low-Level”-Objekte wie TreeNodes, sondern die Daten, mit denen ein Programm arbeiten will) der aktiven (fokussierten) JComponent

5. Temporäre Selektionen

Auch hierfür bietet dieser Artikel keine Lösung (und auch nicht die NetBeans-Platform, diese ändert einfach die Auswahl): Wird mit der rechten Maustaste geklickt, während der Mauszeiger über einem “Item” einer JComponent ist, z.B. einem Tree- oder List-Item, das nicht ausgewählt ist, erwartet der Benutzer:

• Dieses Item wird nicht ausgewählt (Ist das Item z.B. ein Verzeichnis, werden nicht dessen Dateien angezeigt)
• Dieses Item wird hervorgehoben
• Die aktuelle Auswahl geht nicht verloren
• Ein Popupmenü erscheint an der Item-Position
• Alle Aktionen des Menüs beziehen sich auf das Item
• Wird das Menü geschlossen, wird die Hervorhebung zurückgenommen

Eine Lösung wäre ein globales Lookup für temporäre Auswahlen, das mit dem globalen Lookup für Auswahlen verbunden ist und temporär, solange das Popupmenü geöffnet ist, dessen Inhalt ersetzt.

Siehe hierzu folgenden neueren Artikel, dieser beschreibt die Benutzung eines Lookups und enthält zum Download ein Beispielsprojekt.

C

• Kernighan/Ritchie: Programmieren in C. Mit dem C-Reference Manual in deutscher Sprache. Zweite Ausgabe. ANSI C. Carl Hanser Verlag.

C++

• Bjarne Stroustrup: Die C++ Programmiersprache. Addison-Wesley-Longman.
• Scott Meyers: Effektiv C++ programmieren. 50 Wege zur Verbesserung Ihrer Programme und Entwürfe. Addison-Wesley-Longman.

Java

• Joshua Bloch: Effective Java. Second Edition. Addison-Wesley.

Perl

• Damian Conway: Perl Best Practices. Standards für guten Perl-Code. O’Reilly.

Entwurf

• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software. Addison-Wesley.

Techniken

• Martin Fowler: Refactoring. Improving the Design of existing code. Addison Wesley Longman.
• Robert C. Martin: Clean Code. Refactoring, Patterns, Testen und Techniken für sauberen Code. 1. Auflage. mitp.
• Andrew Hunt, David Thomas: The Pragmatic Programmer. From journeyman to master. Addison-Wesley.
• Bernd Oestereich: Objektorientierte Softwareentwicklung. Analyse und Design mit der Unified Modeling Language. R. Oldenbourg.

• Druckertreiber einstellen: Treiber-Dialog aufrufen, dort mehrere Mausklicks
• Überprüfen, ob das Farbmanagement in Photoshop richtig eingestellt ist (Übernahme dieses, ICC-Profil, Rendering Intents – siehe Artikel Farben umrechnen zwischen Farbräumen), korrigieren, wenn nicht
• Größe des Ausdrucks einstellen (Druckauflösung und damit Bildskalierung)
• Bild für den Ausdruck schärfen anhand der Druckauflösung

Im Treiberdialog lassen sich Einstellungen speichern. Dort (Treiber für Epson R2400) darf der Bezeichner nur etwa 12 Buchstaben enthalten, was zu kryptischen Namen führt und mir so nicht die Kontrolle aller Einstellungen erspart.

In Lightroom ist das so gelöst: Alle Einstellungen kann ich als Vorlage speichern unter einem mir bedeutungsvollen Namen:

• Sämtliche Druckertreiber-Einstellungen, insbesondere: Papiersorte, Papiergröße, Druckqualität, Farbmanagement deaktiviert
• Farbmanagement in Lightroom: ICC-Profil für den Ausdruck und Rendering Intents
• Auflösung für den Ausdruck (Skalierung des Bilds)
• Größe des Rands
• Größe der längsten Bildseite
• Schärfung

Ich wähle die Vorlage aus (bei Wechsel von Papiersorte und -Größe), das ist ein Mausklick und klicke der Reihe nach alle Bilder an, die ich ausdrucken will. Hoch- und Querformat werden automatisch ermittelt, ebenso die Größe der Bilder. Was noch fehlt, ist Softproofing – hoffentlich hat das die nächste Version von Lightroom.

Ausschnitt: Einige meiner Druckvorlagen in Lightroom.

Eine weitere schöne Eigenschaft von Lightroom: Die Bilder (Originale) werden für den Ausdruck nicht modifiziert. Wollte ich in Photoshop die Druckeinstellungen nicht verlieren, müsste ich für jede unterschiedliche Druckgröße eine extra Datei (-version/-variante) speichern (Schärfung und Druckauflösung).