Java

Weil es immer wieder Missverständnisse um Java 7 in Bezug auf Hibiscus gibt sowie ein schon fast panikhaftes Verhalten wegen den in letzter Zeit veröffentlichten Sicherheitslücken in Java, habe ich im Wiki mal eine FAQ speziell zu Java-Fragen angelegt. Ich hoffe, das hilft.

Sehr, sehr schade. Berlios - die Opensource-Hosting-Plattform, auf der ich den Quellcode von Jameica und Hibiscus sowie die Wikis habe - wird am 31.12. dicht machen. Den Quellcode kann ich zwar auch bei Sourceforge oder auf meinem eigenen Server hosten. Problematisch sind aber die beiden Wikis von Jameica und Hibiscus. Im ganzen Web verstreut finden sich Links zu den Tutorials und FAQs der Wikis, die dann allesamt ins Leere zeigen werden. Wenn die bei Berlios die Server runterfahren, hab ich noch nichtmal die Möglichkeit, Redirects einzurichten. Daher werde ich sowohl Quellcode als auch die Wikis künftig voraussichtlich auf meinem eigenen Server hosten. Denn wenn ich das jetzt alles zu Sourceforge schiebe, machen die in 'nem Jahr bestimmt auch zu ;)

Wenn ihr Hibiscus verwendet, aktualisiert bitte noch nicht auf das neue Java 7. Unter Umständen wird dann beim Aufbau der Verbindung zur Bank die Fehlermeldung "Certificates does not conform to algorithm constraints" auftreten. Thomas hat das Problem in seinem Blog mal analysiert und ist zu dem Schluss gekommen, dass es durch SSL-Zertifikate ausgelöst wird, die veraltete Algorithmen verwenden. Leider sind solche aber noch bei vielen Banken im Einsatz. Da mir derzeit kein anderer Workaround bekannt ist, bleibt im Moment nur (falls eure Bank hiervon betroffen ist): Installiert nicht Java 7 sondern nutzt erstmal weiter Java 6.

Das CVS-History-Fenster unter "Compare with>History..." war plötzlich leer. Wo sind die alten Versionen hin? "cvs log" in der Shell funktioniert. Projekt geschlossen, neu geöffnet. Eclipse beendet, neu gestartet. Nichts half. Keinerlei Fehlermeldungen. Och nö, ich will den Eclipse-Workspace nicht wegwerfen. Also etwas googlen. Im Eclipse-Forum werde ich fündig. Das Löschen der Datei

.metadata/.plugins/org.eclipse.team.cvs.ui/dialog _settings.xml

im Workspace half. Und es war tatsächlich ein Bug in Eclipse - #293551 / #313480.

Wir sind gerade mit einer Navision-Anbindung beschäftigt (ich weiss, das Ding heisst jetzt wohl "Dynamics NAV" - ist mir aber egal). Unter anderem auch via SOAP. Und das ist alles so furchtbar - ich weiss gar nicht, wo ich anfangen soll. Nachdem ich funktionierende WSDL-URLs gekriegt hab (was eine ganze Weile gedauert hat), dachte ich, dass der Rest nur noch Fleissarbeit ist. Pustekuchen.

Notiz für mich, damit ich beim nächsten Mal nicht wieder rumprobieren muss ("Service" ist eine beliebige Klasse, von dem der Service abgeleitet sein muss):

public <T extends Service> T create(Class<? extends Service> c)
  throws Exception
{
  T s = (T) c.newInstance();
  // init stuff
  return s;
}

Versucht mal, ein SUN JDK 5.0 herunterzuladen. Aussichtslos. Entweder man wird auf eine Zwangsregistrierungsseite weitergeleitet, wo man eine eMail-Adresse angeben muss. Angeblich kriegt man darüber dann den Download-Link (vorher muss man vermutlich schriftlich begründen, wofür man diese alte Version denn brauche). Bis heute ist keine Mail eingetroffen. Oder aber der Server ist - wie bei SUN nicht unüblich - mal wieder nicht zu erreichen. Ich hab Projekte, in denen Java5-Features genutzt werden und beim Kunden ist nun mal diese Version installiert. Also will ich damit auch testen können. Wenigstens hab ich auf https://jdk-distros.dev.java.net/developer.html direkte Download-Links gefunden. Obwohl die eigentlich für Distributoren sind.

Was soll dieser Unsinn?

Update: dct.sun.com liefert nach wie vor ein Timeout. Und in der Distributor-Version fehlt die tools.jar. Eine Glanzleistung, SUN. Ich lade mir die Java-Version jetzt via scp vom Kundenserver. Und komm mir vor wie ein Schwarzkopierer. Muss man sich veraltete Java-Versionen jetzt von Rapidshare holen?

Wie archiviert man Messwerte (Temperaturen, Zugriffszahlen, System-Auslastung) ohne dabei im Laufe der Zeit die Datenbank zu fluten? Bei meinem aktuellen Bastelprojekt werden die Temperatur-Messungen von 13 Sensoren im 5-Minuten-Takt gespeichert. Das ergibt 3.744 Messwerte. Täglich. Bereits nach einem Jahr enthielte die Datenbank über 1,3 Mio. Datensätze. Die Daten sollen aber über mehrere Jahre gespeichert werden, um auch grosse Zeiträume miteinander vergleichen zu können. War der letzte Winter beispielsweise strenger als der aktuelle? Falls noch weitere Sensoren hinzukommen, könnte mein Stubenserver schnell an seine Leistungsgrenzen stossen.

Gegeben sei ein Schema "schema.xsd":

<?xml version="1.0" encoding="ISO-8859-1" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="test">
    <xsd:complexType>
      <xsd:attribute name="value" type="xsd:integer" use="optional"/>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Wir generieren nun mit "xjc" (SUN Java 1.6) die passenden JAXB(2.0)-Beans:

xjc -d src -p generated schema.xsd

Die folgende Datei "test.xml" soll eingelesen werden:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<test value=""></test>

Das Attribut "value" besitzt einen Leerstring als Wert. Das ist eigentlich nicht korrekt - aber leider nicht änderbar, da das Backend die Daten so liefert. Die Deklaration 'use="optional"' im Schema bedeutet lediglich, dass das Attribut fehlen darf. Wenn es jedoch vorhanden ist, muss es einen gültigen Wert haben. Wir wollen das Attribut auch nicht als "xsd:string" deklarieren, weil wir sonst ein unschönes "Integer.parseInt(String)" machen müssten. Nützt also nichts. Das müssen wir so hinnehmen.

Wir lesen die Test-Datei ein:

JAXBContext ctx = JAXBContext.newInstance(generated.ObjectFactory.class);
Unmarshaller m  = ctx.createUnmarshaller();
generated.Test t = (generated.Test) m.unmarshal(new File("test.xml"));
System.out.println(t.getValue());

Der Vorgang schlägt fehl mit:

java.lang.NumberFormatException: Zero length BigInteger

Mein Güte, war das ein Kampf. Die meisten Probleme hat unerwartet javax.comm (das ist die Java-API für den Zugriff auf serielle Schnittstellen) gemacht. Das Ding warf mir dauernd die tolle IOException "Not all params are supported by kernel" um die Ohren. Das Problem ist offensichtlich bekannt. Die dort im Forum geposteten Workarounds riechen allesamt nach gruseligen Race-Conditions in der SUN-Implementierung. Ohnehin scheint sich SUN nicht mehr um diese Bibliothek kümmern zu wollen. Nach einiger Recherche bin ich auf die Alternative RXTX gestossen. Und entgegen der Aussage auf der jamod-Webseite liess sich das modbus-Teil auch damit compilieren (Parameter "build.serial.gnu=true" in build.properties gesetzt und den ganzen Forrest-Kram aus build.xml entfernt). Der Zugriff auf die serielle Schnittstelle funktionierte - die Anlage lieferte Daten zurück. Einen anonymen Byte-Strom. Abgesehen vom aktuellen Datum konnte ich darin nichts erkennen. Mehr oder weniger zufällig hab ich die Daten dann mal mit DataInputStream#readFloat() beackert - in der Hoffnung, dabei Werte zu finden, die wie Temperaturen aussehen. Und tatsächlich tauchten ab Byte 56 eine Hand voll Zahlen zwischen 20 und 50 auf. Schnell ausgedruckt, in den Heizungsraum gerannt und mit den Werten vom Display verglichen. Volltreffer. Die 13 wichtigsten Temperatur-Werte der Anlage. Mehr wollte ich gar nicht ;)

Inzwischen hab ich mir eine erste Version mit Webfrontend gebastelt, die im 5-Minutentakt aktuelle Werte von der Anlage holt und anzeigt. Als nächstes kommt noch eine Seite zum Konfigurieren des seriellen Ports (Device, Baudrate, Parity, etc.). Und dann natürlich ein Archiv-Service, der die Messwerte in eine Datenbank schreibt sowie ein Chart-Renderer, um den zeitlichen Verlauf der Werte grafisch im Webfrontend anzuzeigen.

Ich werd's dann hier auf der Webseite veröffentlichen. Achso - ist natürlich ein Jameica-Plugin ;)

Gar nicht so einfach, hierfür 'nen passenden Titel zu finden. Problemstellung: In einer XML-Schema-Datei sei ein abstrakter complexType definiert:

<xsd:complexType name="abstractSearch" abstract="true">
  <xsd:sequence>
    <xsd:element name="date" ... />
    <xsd:element name="operator"  .. />
  </xsd:sequence>
  ...
</xsd:complexType>

Weiterhin existiert ein konkreter Typ, der davon abgeleitet ist:

<xsd:complexType name="search">
  <xsd:complexContent>
    <xsd:extension base="abstractSearch">
      <xsd:all>
        <xsd:element name="combi" ... />
      </xsd:all>
      <xsd:attribute name="itc" ... />
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

Beim Erzeugen der zugehörigen JAXB-Klassen mittels xjc-Compiler wird diese unverständliche Fehlermeldung entstehen:

cos-all-limited.1.2: An all model group must appear in a particle with
{min occurs} = {max occurs} = 1, and that particle must be part 
of a pair which constitutes the {content type} of a complex type 
definition.

Aja. Nachdem ich stundenlang vergeblich an den "minOccurs"- und "maxOccurs"-Attributen rumgedreht hab, kam mir spontan die Erleuchtung. Im Basis-Typ "abstractSearch" ist eine "sequence" definiert, im abgeleiteten Typ "search" jedoch eine "all"-Gruppe. Der Compiler versucht nun offensichtlich, beide Element-Gruppen zu mergen. Pro Element darf nur eine existieren. Und da es sich um zwei verschiedene Arten handelt, kriegt er genau das nicht auf die Reihe.

Die einfache Lösung lautet daher: Sowohl in "abstractSearch" als auch in "search" die gleiche Art von Gruppe verwenden. Also entweder nur "sequence" oder nur "all". Aber nicht beides.

Dass die ZIP-Implementierung in java.util.zip nicht mit Umlauten umgehen kann, schrieb ich ja schonmal. In Java 1.7 wird das Problem endlich gefixt sein. Der Bug-Report bei SUN stammt übrigens vom 07. Juni 1999! Hatte also gerade 10. Geburtstag. Weil das einfach nur peinlich ist, nehm ich jetzt jazzlib. Das 60k-Jar-File in den Classpath werfen und die Klassen aus "net.sf.jazzlib" (statt "java.util.zip") verwenden. Fertig. Die API ist identisch zu der von SUN.

Eigentlich wollte ich Jameica und Hibiscus endlich mal ausführlich mit OpenJDK testen. Aber nachdem ich 1 Stunde an mir selbst verzweifelte, fiel mir das hier auf.
Test 1: Debugger läuft bis zum Breakpoint in Zeile 118 durch. Der String "s" hat den Wert "1.7+" (obwohl ich in der Zeile drüber alles ausser Zahlen und Punkt entfernt habe).
Test 2: Zusätzlicher Breakpoint in Zeile 117. In dem warte ich ein paar Sekunden und steppe erst dann weiter. Das "+" ist entfernt worden.

WTF?! Ein und der selbe Code liefert unterschiedliche Ergebnisse, wenn man nur ein paar Sekunden wartet? Kein Wunder, dass der gesuchte Bug nur dann auftrat, wenn ich keinen Breakpoint im verdächtigen Code hatte. Natürlich tritt der Effekt in einer einfachen Testklasse mit main()-Methode nicht auf.

Ich weiss nicht, ob ich weiterhin an mir selbst zweifeln soll oder OpenJDK einfach in die Ecke werfe. Für heute jedenfalls letzteres.

Bei meinem letzten Test musste ich mich ja echt zusammenreißen, keinen Rant zu schreiben. Mit Release 1.5 ist die JCR-Implementierung aber tatsächlich out-of-the-box benutzbar. Einfach jackrabbit-standalone-1.5.0.jar herunterladen. Starten. Fertig. Ein Repository mit dem Namen "default" wird automatisch angelegt und ist via RMI und WebDAV ansprechbar. Geht doch ;)

"fn:lastIndexOf" gibts leider nicht. Workaround:

<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>

<c:set var="text" value="${fn:split('de.foo.bar.Dings','.')}" />
${text[fn:length(text)-1]}

Ausgabe:

Dings