Im Grunde bin ich mit Java als Sprache und als Plattform ganz zufrieden. Hier und da kann es Verbesserungen geben. Beispielsweise in der Abschottung von Subsystemen. Dies hätte ich gerne in Form eines Modulsystems und nicht als OSGi-System aufgepfropft. Bei Generics hätte einiges besser laufen können. Mit Java 7 wird jetzt immerhin der Diamond-Operator eingeführt. Autoboxing ist leider vollkommen verunglückt.

Womit ich inzwischen nicht mehr zufrieden bin ist das Schlüsselwort final und seine Semantik. Mit final wird eine Klasse oder Methode vor überschreiben geschützt. Ein Feld wird vor erneuter Zuweisung geschützt. Das Feld ist dementsprechend mehr eine Konstante als eine Variable. Langjährige Erfahrung hat allerdings gezeigt: überschreiben oder neu zuweisen wird überbewertet. Vererbt wird selten wirklich sinnvoll und echte Variablen gibt es auch eher selten.

Inzwischen halte ich es für eine bessere Idee statt final ein var zu verwenden. Also Verbung und neu zuweisen nicht explizit zu verbieten, sondern explizit zu erlauben. Code würde dadurch robuster werden. Einige sich immer wieder einschleichender Fehler würden beseitigt. Überkomplexe Vererbungshierarchien mehr durchdacht, bevor sie in Code gegossen werden. Einige der neuen Sprachen, die auf der JVM aufsetzten, implementieren var. Leider nicht die Hauptsprache Java. Schade, dass der Zug dafür abgefahren ist.

Für internationalisierte (I10N) Implementierungen verwende ich gerne das CAL10N API. Das API erreicht eine Compiler Assisted Localization durch den Einsatz von Java enums. Der Name des Enumerationsfeldes ist der Schlüssel in einer entsprechenden Properties Datei. Hierdurch wird der Schlüssel innerhalb des Java-Code nicht mehr als String hinterlegt. Durch ein Maven Plugin können die Properties-Dateien überprüft werden. Ich empfehle jedem Java Entwickler sich das API einmal anzuschauen.

Ich habe den Ansatz für den Einsatz in meinen privaten Projekten und bei bei Zimory erweitert. Durch den Einsatz von enums können auch Annotationen zum Einsatz kommen. Zwei Annotationen habe ich definiert. Eine für den enum Typen und eine für die enum Felder. Beide haben als einzigen Wert einen String:

    @Target(TYPE)
    @Retention(RUNTIME)
    public @interface SystemId {
        String value();
    }


    @Target(FIELD)
    @Retention(RUNTIME)
    public @interface MessageId {
        String value();
    }

@SystemId definiert grobgranular das Modul/Subsystem – oder wie auch immer die Systemunterteilung namentlich genannt wird – für die Messages. @MessageId definiert eine spezielle feingranulare ID für z.B. einen Fehlerzustand innerhalb eines Moduls. Der Sourcecode einer Message enum sieht dann in etwa so aus:

    import ch.qos.cal10n.LocaleData;
    import ch.qos.cal10n.Locale;
    import ch.qos.cal10n.BaseName;

    @SystemId("RT")
    @BaseName("messages")
    @LocaleData({@Locale("en")})
    public enum Messages {
        /** Indicates a login failure. */
        @MessageId("001001") LOGIN_VALIDATION_FAILED;
    }

Für die Auswertung haben ich einen eigenen MessageProducer geschrieben. Dieser kapselt eine Implementierung des CAL10Ns IMessageConveyor Interface. Ausserdem analyisert er per Reflection die Annotationen und baut aus den Werten eine ID zusammen. Diese ID wird vor die internationalisierte Nachricht gestellt. Daneben übernimmt die Implementierung noch einige Dinge wie Caching usw. Eine erzeugte Nachricht sieht in etwa wie die Folgende aus:

    RT-001001: Login failed for user "foobar".

Solche IDs sind nicht nur für die Analyse von Fehlermeldungen sinnvoll. Sie bieten auch einen einfachen Ansatz für die Fehlerpropagierung in Systemen, in denen bisher kein durchgängiges Exceptionframework existierte. Damit auch nicht Entwickler die Fehlermeldungen verstehen, haben ich eine Doclet-Implementierung geschrieben. Diese analyisert alle enum Klassen mit @SystemId und generiert aus dem Wert der Annotation, der Javadoc Klassendokumentation, dem Wert von @MessageId und der Javadoc Felddokumentation eine XML Datei mit einer Zusammenfassung der Daten. Durch einfache XSLT Skripte wird das XML Dokument in Docbook und Xdoc umgewandelt und kann somit für die Anwenderdokumentation weiter verarbeitet werden. Da alles aus einer Quelle kommt, werden Fehler durch cut 'n paste reduziert.

Voll reingelaufen. Priorität: low, no workaround. Und ich muss jetzt eine Lösung finden

Money Quote:

Introspecting returns incorrect PropertyDescriptor for overriden getter in case when child getter has more specific return type. In this case PropertyDescriptor of parent class is returned instead.

Bis Java 1.6.0_18 kein Fix. In Java 7 (b80) gefixt. Leider kann ich mir dafür gar nichts kaufen.

Für meinen Job bei Zimory habe ein wenig mit Weld SE gespielt. Weld ist die CDI Referenz­implementierung und Weld SE eine Anpassung für die Java SE Welt.

Die eigentliche Implementierung war recht einfach. Allerdings wurde beim Ausführen immer eine UnsatisfiedResolutionException geworfen. Die Nachricht war WELD-001308 Unable to resolve managed beans for…. Nach kurzer Suche war klar, dass Weld eine leere "META-INF/beans.xml" Datei benötigt. Nachdem die Datei angelegt war, funktionierte das Beispiel problemlos.

Es lässt sich streiten, ob die CDI Referenzdokument in Kapitel 12.1 eine solche Datei zwingend vorschreibt. Ich habe es dort nicht heraus gelesen.

Download: Sourcecode (7.897 Bytes)

javac scheint bei package Annotationen nicht zu überprüfen, ob die Annotationen den deklarierten Regeln folgen. Eben habe ich einer solchen Annotation den default Wert weggenommen. Die Verwendung auf type Ebene warf Compiler Fehler. Ist der Wert in der package-info.java Datei nicht vorhanden, läuft der compile Prozess ohne Probleme durch. Die falsche Verwendung auf package Ebene wurde durch nicht angepassten Unit-Test entdeckt. Eine IncompleteAnnotationException wird geworfen, wenn ich den Wert über das Reflection API auslese.

Vorher:

    @Documented
    @Retention(RUNTIME)
    @Target({PACKAGE, TYPE})
    public @interface CommandHolder {
        String value() default  "";
    }

Nacher:

    @Documented
    @Retention(RUNTIME)
    @Target({PACKAGE, TYPE})
    public @interface CommandHolder {
        String value();
    }

Verhalten tritt auf mit javac 1.6.0_16 und javac 1.7.0-ea (b80) auf einem aktuellen AMD64 Ubuntu 9.10.

Vielleicht wühle ich mich später mal durch die Spezifikationen.

Ich implementiere gerade privat ein REST API. In dem API werden XML Daten mittels JAXB gewandelt. Dabei habe ich einfach POJOs verwendet und mit den JAXB Annotationen versehen. Eigentlich ganz einfach. Eigentlich… Bis zu dem Zeitpunkt an denen Collections ins Spiel kommen. Naiv wie ich war – he, wer liesst schon Spezifikationen – habe ich Collection Properties einfach annotiert. Und weil ich ein pfiffiger Entwickler bin, habe ich bei den Gettern eine leere Collection (Collections.emptyXyz()) zurück gegeben, wenn die Referenz null war. Ergebniss: unmarshall(…) warf eine UnsupportedOperationException. Das Problem: JAXB erwartet eine mutable Collection. Collections.emptyXyz() liefert aber immutable Objekte. JAXB ruft darauf dann clean() auf und füllt die Collection neu – die Refernzimplementierung mittels add(E). Eine null Referenz wird auch nicht akzeptiert und führt ebenfalls zu einer Ausnahme.

Ich habe mir dann doch mal die JAXB 2.2 Spezifikation von 2009-12-10 durchgelesen. Unter Punkt 5.5.2.2 wird das Verhalten spezifiziert. Mit einer Einschränkung: sie gilt nur für Collections vom Typ List. Die JAXB 2.2 Referenzimplementierung kommt aber auch mit Sets und dem Collection Interface selbst zurecht.

Der Code sieht jetzt so aus:

    @Valid
    @NotNull
    @Size(min=0, max=5)
    @OneToMany(fetch=EAGER)
    @XmlElement(name=ANSWER_XML_NAME)
    @XmlElementWrapper(name=POSSIBLE_ANSWERS_XML_NAME)
    public List<Answer> getPossibleAnswers() {
        if (this.possibleAnswers != null) {
            return this.possibleAnswers;
        }
        return new ArrayList();
    }

Wem JAD nicht mehr genügt, weil er nur bis Java 1.4 sinnvoll decompiliert (kein Generics Support), mag sich JD anschauen. Kein Problem mit inneren Klassen, synthetischen oder Brigde-Methoden/Typen. Annotationen werden aufgelöst und enum Typen decompiliert. Der erzeugte Quellcode ist gut lesbar - ist ja der kniffelige Part bei Decompilern. Wird bei mir JAD ablösen.

Und ich frage mich, warum die Decompiler Jungs immer C++ verwenden.

Manchmal muss es ein grober Klotz sein. Ein Klasse die ich entwickelt hatte, hatte eine bestimmte Signatur. Nix wildes, beispielsweise war die Klasse final. Wenn eine Klasse final ist, muss ich mich nicht um die Probleme kümmern, die Vererbung mit sich bringen kann. Das final war plötzlich verschwunden. Grund: in einem Test wurde eine abgeleitete Version benötigt. Leider wurde nur das final entfernt. Die Klasse aber nicht hinsichtlich Vererbung angepasst. Z.B. habe ich in der equals Methode noch den instanceof Operator verwendet. Geht bei final Klassen. Bei Klassen, die nicht final sind ist das grob fahrlässig.

Ich habe den Test umgeschrieben – es geht auch einfach ohne Vererbung mit nur einer Zeile Code mehr und dann die Tests erweitert. Bisher habe ich immer nur die Erzeugung eines Exemplars über den Konstruktor getestet. Jetzt teste ich auch die Signatur. Den Test habe ich mit einem Kommentar versehen. Hoffentlich hilft es.

    @Test
    public void creation() {
        // If you must change these tests go into yourself and check:
        // are the changes are really needed?
        new Notifier();

        final Constructor[] cons = Notifier.class.getDeclaredConstructors();
        assertThat(cons.length, is(equalTo(1)));
        assertThat(Modifier.isPublic(cons[0].getModifiers()), is(equalTo(true)));

        final int modifiers = Notifier.class.getModifiers();
        assertThat(Modifier.isPublic(modifiers), is(equalTo(false)));
        // Implementation safe for inheritance?
        assertThat(Modifier.isFinal(modifiers), is(equalTo(true)));
    }

Vorher sah der Test so aus:

    @Test
    public void creation() {
        new Notifier();
    }

In Beispielen für Datenübertragungen findet sich häufig eine Serialisierung der Daten in eine XML Applikation. Dieser Eintrag soll zeigen, dass XML nicht immer die erste Wahl sein muss. Es soll das Bewusstsein erweitern nicht immer das Erstbeste zu verwenden, was einem in den Sinn kommt.

Für das Sportics Realtime Telemetry API wurde bewusst auf XML verzichtet. Der Grund: Realtime Telemetry Clients arbeiten auf reduzierter Hardware wie z.B. Mobiltelefonen und haben eine instabile Funkanbindung des Netzwerkes (z.B. Sportics J2ME Applikation). In solchen Umgebungen ist XML nicht die erste Wahl. Die Daten werden nicht kompakt genug repräsentiert.

Ein Realtime Telemetry Datensatz besteht aus einer Menge von Messwerten zu einem bestimmten Zeitpunkt. Ein Messwert hat immer auch eine beschreibende Kennung. Mehrere solcher Datensätze werden zu einem Snap zusammengeführt. Ein Realtime Telemetry Client schickt einen solchen Snap z.B. alle 2 Minuten an den Realtime Telemetry Server.

In XML kann ein solcher Datensatz wie folgt dargestellt werden:

  <data>
      <measurements>
          <measurement type='longitude'>12.5675256</measurement>
          <measurement type='time'>123456789</measurement>
          <measurement type='heartrate'>78</measurement>
      </measurements>
      <measurements>
          <measurement type='longitude'>12.5675456</measurement>
          <measurement type='time'>123457813</measurement>
          <measurement type='heartrate'>79</measurement>
      </measurements>
      ...
  </data>

Es fällt auf, dass ein solches Format sehr viel redundanten Overhead produziert. Dieser kann durch kürzere Namen reduziert werden. Dabei geht allerdings die sprachliche Wiedererkennung verloren.

  <data>
      <ms>
          <m t='lon'>12.5675256</m>
          <m t='tme'>123456789</m>
          <m t='hrt'>78</m>
      </ms>
      <ms>
          <m t='lon'>12.5675456</m>
          <m t='tme'>123457813</m>
          <m t='hrt'>79</m>
      </ms>
      ...
  </data>

Kompakter, aber auch schwieriger zu lesen. Es ist im Übrigen ein Irrglaube, dass das JSON Format kompakter ist. In der obigen Notation ist es grösser.

Eine weitere Möglichkeit der Reduktion ist auf allgemeine Namen für XML Elemente zu verzichten. An deren Stelle wird der Wert des t-Attributes verwendet:

  <data>
      <ms>
          <lon>12.5675256</lon>
          <tme>123456789</tme>
          <hrt>78</hrt>
      </ms>
      ...
  </data>

Ein ungewöhnliche Schreibweise, aber durchaus machbar. Bei diesem Aufbau wird ein entsprechendes JSON Dokument im Übrigen kleiner als sein XML Pendant. Hierzu folgt weiter unten eine Grafik aus realen Messwerten.

Es geht noch kompakter. Bei Sportics wurde bei der Realtime Telemetry API bewusst gegen SOAP Webservices entscheiden. Der Grund ist einfach: nicht alle Zielgeräte verfügen über SOAP Webservices Support. SOAP Webservices von Hand nachzuprogrammieren ist keine Kleinigkeit. Stattdessen haben wir uns für ein REST API entschieden. Dies vereinfachte die Kommunikationsschnittstelle und auch den Aufwand für die Implementierung auf Clientseite. Zwar wird auch in der REST Literatur viel mit JSON und XML gearbeitet, aber dies muss nicht sein.

Bei den Messwerten setzen wir statt dessen auf das CSV-Format nach RFC 4180. Im CSV-Format wird der oben beschriebene Datensatz wie folgt notiert:

    tme,lon,hrt
    123456789,12.5675256,78
    123457813,12.5675456,79

Noch kompakter ist kaum möglich. Das API schreibt noch einige Dinge vor, beispielsweise muss ein Header vorhanden sein und jede Zeile nach der Headerzeile muss so viele Spalten haben wie die Headerzeile. Ansonsten verwirft der Server die Daten und liefert eine Fehlermeldung.

Die abschliessende Frage lautet: Um wieviel kleiner ist die CSV-Notation?

Aus den realen Daten von einigen tausend Datensätzen lässt sich folgendes Bild gegenüber der CSV Notation ermitteln:

• die XML Notation ist um ca. den Faktor 2 grösser
• die JSON Notation ist um den Faktor 1,5 grösser

In absoluten Zahlen:

Ein Bild beschreibt mehr als 500 Worte:

Dieser Inhalt wurde aus einer weiteren Quelle zusammengefügt. Mehr...

• Cost cutter - süchtig machender Tetris Clone.
  via Petronella
• Weiss gar nicht wieso sich die Sozialverbände und -anbieter so über die geplante Reduzierung der Wehrdienstzeit aufregen. Zivis sollen keine Arbeitsplätze wegnehmen dürfen, also nur Jobs machen, auf die verzichtet werden kann. Wie schlimm steht es eigentlich ums Pflegesystem?
• Android Icons für die Entwicklung unter Creative Commons Attribution Share Alike Lizenz.
• Some Java Concurrency Tips