Wir haben in der letzten Ausgabe unserer Kolumne die Aufzählungstypen vorgestellt, die als neues Sprachmittel in Java 5.0 zur Sprache hinzugekommen sind.  Dieses Mal wollen wir einige Erfahrungen aus der praktischen Verwendung von Aufzählungstypen hernehmen, um einige Fallstricke zu erläutern.
 

Unliebsame Überraschungen

Das folgende Beispiel stammt aus einer konkreten Anwendung, bei der wir einen Aufzählungstyp mit 2 möglichen Werten benötigen, der die verschiedenen Arten der Kommunikation in der Anwendung abbilden soll: entweder unverschlüsselt oder über SSL. Bei SSL (= Secure Socket Layer, offiziell TLS = Transport Layer Security) werden die übertragen Daten verschlüsselt, damit sie nicht abgehört werden können. (Mehr zu SSL und TLS ist unter / SSL / zu finden.) Unser Aufzählungstyp sieht im ersten Ansatz zunächst so aus:

enum ConnectionType {
  NOENCODE, SSL
}

enum ConnectionType {
  NOENCODE, SSL;

  public static Connection createConnection(
                ConnectionType ct,
                SelectionKey key,
                int idx) {
    …
  }
}

enum ConnectionType {
  NOENCODE(SimpleConnection.class),
  SSL(SslConnection.class);

  public static Connection createConnection(
                ConnectionType ct,
                SelectionKey key,
                int idx) {
    Object[] params = { key, idx };
    return conCtors.get(ct.name()).newInstance(params);
  }

  private static final
    Map<ConnectionType,
        Constructor<? extends Connection>> conCtors
    = new HashMap<ConnectionType,
                  Constructor<? extends Connection>>();
  …
}

Nun ist noch offen, wann und wie diese Map mit Inhalt gefüllt wird.  Man könnte alle Key-Value-Paare in einem static-Initializer auf einmal eintragen.  Das hätte aber den Nachteil, daß dieser static-Initializer immer dann angepaßt werden müßte, wenn ein neuer Subtyp von ConnectionType dazukommt.  Wir wollen eine wartungsfreundlichere und flexiblere Lösung. Unsere Überlegung ist: jeder Enum-Wert fügt seine eigenes Key-Value-Paar in die statische Map ein, nämlich sich selbst zusammen mit dem zugehörigen Konstruktor.  Die einzelnen Enum-Werte registrieren sich sozusagen zusammen mit dem Konstruktor der zugehörigen Connection-Klasse in der Map. Diese Registrierung wird am sinnvollsten während der Konstruktion der jeweiligen Enum-Werte gemacht, damit sie nicht vergessen wird.

Unser Enum-Typ benötigt also einen Konstruktor.  Diesem Konstruktor wird die Typrepräsentation, d.h. das Class-Objekt, der zum ConnectionType gehörenden Connection-Klasse angegeben. Der Konstruktor des übergebenen Typs wird dann in der Map abgelegt. Unser Enum-Typ sieht dann wie folgt aus:

enum ConnectionType {
  NOENCODE(SimpleConnection.class),
  SSL(SslConnection.class);

  public static Connection createConnection(
                ConnectionType ct,
                SelectionKey key,
                int idx) {
    Object[] params = { key, idx };
    return conCtors.get(ct.name()).newInstance(params);
  }

  private static final
    Map<ConnectionType,
        Constructor<? extends Connection>> conCtors
    = new HashMap<ConnectionType,
                  Constructor<? extends Connection>>();

  private ConnectionType(Class<? extends Connection> c) {
    Class[] params = { java.nio.channels.SelectionKey.class,
                       java.lang.Integer.class };
    conCtors.put(this, c.getConstructor(params));
  }
}

Connection.java:31: illegal reference to static field from initializer
                conCtors.put(this, c.getConstructor(params));
                ^
1 error

class ConnectionType extends Enum<ConnectionType> {
  public static final ConnectionType NOENCODE;
  public static final ConnectionType SSL;
  private static final Map conCtors = new HashMap();
  private static final ConnectionType ENUM$VALUES[];
  static {
    NOENCODE = new ConnectionType("NOENCODE",0,SimpleConnection);
    SSL = new ConnectionType("SSL",1,SslConnection);
    ENUM$VALUES = (new ConnectionType[] {NOENCODE, SSL});
  }
  private ConnectionType(String s, int i, Class c) {
    super(s, i);
    Class params[] = {java/nio/channels/SelectionKey,
                      java/lang/Integer};
    conCtors.put(this, c.getConstructor(params));
  }
  ...
}

Zwar könnte ein intelligenter Compiler prinzipiell den Sourcecode auf Initialisierungsabhängigkeiten hin analysieren und die jeweils korrekte Initialisierungsreihenfolge zu generieren versuchen.  In unserem einfachen Beispiel wäre das sicher möglich gewesen.  Aber ganz im Allgemeinen ist eine solche Analyse zu komplex, als dass man sie von einem Compiler in allen Fällen erwarten könnte.  Die uns bekannten Compiler (z.B. der Compiler in der Java Standard Edition von Sun oder der Compiler im Eclipse IDE) machen keine aufwendige Analyse, sondern bemühen sich, eventuelle Probleme durch entsprechende Fehlermeldungen zu verhindern. Deshalb führen Enum-Typen mit statischen Feldern gelegentlich zu prophylaktischen und unter Umständen überraschenden Fehlermeldungen, wie der gezeigten.

Was macht man nun in einer solchen Situation? Wir müssen irgendwie erreichen, daß die Map bereits konstruiert ist, ehe auf sie zugegriffen wird. Das Problem läßt sich mit Hilfe einer zusätzlichen Klasse lösen.  Die fragliche Map haben wir als privates statisches Feld in eine separate Hilfsklasse eingepackt.  Der Zugriff auf die Map erfolgt daher stets über die umgebende Hilfsklasse.   Der Compiler muß, ehe er auf die Map zugreift, die Hilfsklasse laden und wird dabei die Klasseninitialisierung machen, d.h. alle statischen Felder initialisieren und alle static-Initializer der Hilfsklasse ausführen.

Diese Technik garantiert, daß die Hilfsklasse - und damit auch ihr statisches Feld - vor dem ersten Zugriff initialisiert wird.  Das ist unabhängig von den Initialisierungen, die der Compiler für die synthetische Enum-Klasse und ihre statischen Teile generiert, und funktioniert immer. Hier unsere Lösung:

enum ConnectionType {
  NOENCODE(SimpleConnection.class), SSL(SslConnection.class);

  private static class StaticMapHelper {
    private static final
      Map<ConnectionType,
          Constructor<? extends Connection>> conCtors
      = new HashMap<ConnectionType,
                    Constructor<? extends Connection>>();
  }
  ...
  private ConnectionType(Class<? extends Connection> c) {
    Class[] params = { java.nio.channels.SelectionKey.class,
                       java.lang.Integer.class };
    StaticMapHelper.conCtors.put(this, c.getConstructor(params));
  }
}

Mehr Überraschungen

In dem oben gezeigten Beispiel hatten wir eine Map verwendet, deren Key-Typ ein Enum-Typ ist, nämlich unser ConnectionType.  Für solche Maps gibt es eine effizientere Implementierung, die sogenannte EnumMap.  In dieser EnumMap wird ausgenutzt, daß es nur eine beschränkte Anzahl von Werten des Key-Typs gibt.  Der Key-Typ kann deshalb effizient auf Bits abgebildet werden und die EnumMap ist in solch einer Situation performanter als die normale HashMap oder TreeMap.

public static enum ConnectionType {
        NOENCODE(SimpleConnection.class), SSL(SslConnection.class);

        private static class StaticMapHelper {

            private static final Map<ConnectionType, Constructor<? extends Connection>>
              conCtors = new EnumMap<ConnectionType,
                                     Constructor<? extends Connection>>(ConnectionType.class);
        }

        public static Connection createConnection(ConnectionType ct,
                SelectionKey key, int idx) {
            try {
                Object[] params = { key, idx };
                return StaticMapHelper.conCtors.get(ct).newInstance(params);
            } catch (Exception e) {
                System.err.println("ERROR " + e
                        + " cannot create connection for: " + ct.name());
                return null;
            }
        }

        private ConnectionType(Class< ? extends Connection> c) {
            try {
                Class[] params = { java.nio.channels.SelectionKey.class,
                        java.lang.Integer.class };
                StaticMapHelper.conCtors.put(this, c.getConstructor(params));
            } catch (Exception e) {
                System.err.println("ERROR " + e
                        + "cannot create connection constructor for: "
                        + this.name());
            }

        }
    }
}

Exception in thread "main" java.lang.ExceptionInInitializerError
 at Connection$ConnectionType.<init>(Connection.java:37)
 at Connection$ConnectionType.<clinit>(Connection.java:12)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at java.lang.Class.getEnumConstants(Unknown Source)
 at java.lang.Class.enumConstantDirectory(Unknown Source)
 at java.lang.Enum.valueOf(Unknown Source)
 at Test.parseServerconfig(Test.java:9)
 at Test.main(Test.java:25)
Caused by: java.lang.NullPointerException
 at java.util.EnumMap.<init>(Unknown Source)
 at Connection$ConnectionType$StaticMapHelper.<clinit>(Connection.java:17)
 ... 11 more

Auslöser dieses Initialisierungsfehlers ist eine NullPointerException von der new-Expression, in der die EnumMap erzeugt wird.  Aus ungeklärten Gründen wirft der Konstruktor der EnumMap eine unerwartete NullPointerException.

Das Initialisierungsproblem wird verursacht durch die Implementierung der EnumMap.  In der EnumMap werden nämlich die Keys in einem Cache gehalten.   Hier die relevanten Details aus der Implementierung der EnumMap im JDK von Sun Version 1.5.0_05:

class EnumMap<K extends Enum<K>,V>  {
  public EnumMap(Class<K> keyType) {
   this.keyType = keyType;
   keyUniverse = keyType.getEnumConstants();
   vals = new Object[keyUniverse.length];
  }
  ...
}

Zusammenfassung

Das dargestellte Beispiel hat gezeigt, wie verzwickt der Umgang mit Enum-Typen sein kann.  Als Implementierer eines Enum-Typs, der statische Felder hat, muß man sehr genau auf die Reihenfolge der statischen Initialisierungen achten und mit unliebsamen Überraschungen rechnen.  Unserer Erfahrung nach sind statische Felder in Enum-Typen aber keineswegs selten.  Da praktisch alles in einem Enum-Typ statisch ist, ist die Verwendung von weiteren statischen Elementen sogar relativ naheliegend und natürlich.

In unserem Beispiel haben wir das Problem mit der statischen Map durch eine Hilfsklasse lösen können.  Gewiß wäre es auch möglich gewesen, auf die statische Map ganz zu verzichten, so wie wir auch auf die Verwendung der EnumMap verzichtet haben.  Ganz generell bleibt aber die Erkenntnis, daß die Verwendung von statischen Feldern in Aufzählungstypen naheliegend und gleichzeitig fehleranfällig ist.  Das ist aber auch der einzige Bereich, in denen Aufzählungstypen Kopfschmerzen bereiten - ganz im Gegensatz zu den Generics, denen wir in den nächsten Beiträgen dieser Kolumne widmen werden.

Literaturverweise und weitere Informationsquellen

Die gesamte Serie über Enum-Typen:

Leserzuschrift

Ja, der Code ist korrekt und Herr Sahnwaldt hat völlig Recht. Wenn man auf die statische Map komplett verzichten kann, dann ist es deutlich eleganter.  Unser Beispiel stammt aus einem in der Praxis aufgetretenem Fall, den wir zum Zwecke der Erläuterung in unserem Artikel drastisch vereinfacht haben.  Im Originalkontext enthielt die Map noch eine ganze Menge anderer Informationen, so dass man um die statische Map leider nicht ohne Weiteres herum kam.

Es bleibt also festzuhalten:  wenn man statische Felder in Enum-Typen vermeiden kann, dann ist es sicher eine gute Idee, es zu tun; wenn man sie nicht vermeiden kann oder will, dann kann man den etwaigen Problemen mit den oben geschilderten Techniken begegnen.
 
 

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   Effective Java - Java best practice programming techniques, common pitfalls, and off-the-beaten-path language features 4 day seminar ( open enrollment and on-site)