Hab gestern Abend um halb acht ein Packet für unsere Nachbarin angenommen. Als ich dann heute unseren Briefkasten gelehrt habe, entdeckte ich ihre Packetmitteilung. An sie adressiert und in unserem Kasten

Tja, auch die Post ist im Weihnachtsstress. Zum Glück kommt bald das Christkind und alles ist wieder vorbei.

Wie bindend ist es eigentlich, wenn Lizenzbedingungen für ein plattformübergreifendes API in drei Worddateien daherkommen und ich keine legalen Mittel habe, den Inhalt dieser Dateien zu lesen? Abgesehen davon, dass Worddateien eine Zumutung sind, wenn im gleichen Packet die Dokumentation als PDF kommt. So gesehen in der Spezifikation des StAX-API.

Eine weitere Zumutug des StAX-API ist die Verwendung eines Konstanteninterfaces. Da redet man sich den Mund fusselig, dass Konstanteninterfaces schlechtes Design sind, weil sie sich die Abhängigkeiten schneller ausbreiten als die Pest. Und dann bauen die von BEA bei der Definition der StAX-API einfach so ein Interface ein. Und die Entwickler von BEA müssen es ja wissen. Dagegen kann man nur argumentierem, dass die auch nur mit Wasser kochen. Das es auch anders geht beiweisen die XMLConstants in Java 5.

Mehr zum Thema im besten Java-Buch überhaupt, Effective Java von Joshua Bloch (ISBN 0-201-31005-8), Item 17.

Die nächste Zumutung folgt sogleich. Denn auf der Downloadseite des JSR 173 bekommt man nur die leere Hülle des API. Die Referenzimplementierung, die eigentlich über das übliche Fabrikkonstrukt angezogen werden soll, fehlt und es wird die folgende Fehlermeldung produziert:

    Exception in thread "main" javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found
            at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72)
            at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176)
            at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
            at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
            at de.brainmedia.playground.sk.xml.StaxTester.main(StaxTester.java:25)

Langsam fange ich an zu verstehen, wieso StAX nicht so richtig populär wird. Die Referenzimplementierung des JSR 173 wird direkt bei bei BEA angeboten. Ausserdem scheint es auch eine Implementierung bei Codehause zu geben, die sich aber noch im Entwicklungsstadium befindet.

Langsam wird das Spiel langweilig. Wir haben in den XML-Dateien, welche wir verarbeiten sogenannte Processing Instructions PI). Und der StAX Reader mault jetzt in einer Fehlermeldung rum, das diese PI (<?InsertOnlineDateLater?>) nicht korrekt ist. Kurzer Blick in die XML Spezifikation, kann ja sein, dass ich diesen falsch im Kopf habe… Nein, hier irrt der StAX-Parser

    Exception in thread "main" javax.xml.stream.XMLStreamException: ParseError at [row,col]:[63,45]
    Message: processing instruction must have PITarget name
            at com.bea.xml.stream.MXParser.parsePI(MXParser.java:2764)
            at com.bea.xml.stream.MXParser.nextImpl(MXParser.java:1587)
            at com.bea.xml.stream.MXParser.next(MXParser.java:1180)
            at de.brainmedia.playground.sk.xml.StaxTester.main(StaxTester.java:31)

Wird nach dem PITarget ein Leerzeichen eingefügt und erst dann folgend das Fragezeichen, welches das Ende der PI anzeigt, arbeitet der Parser fehlerfrei. Genau dieses Leerzeichen wird aber nur verlangt, wenn nach dem PITarget weitere Parameter angegeben werden sollen. Nicht, wenn es sich um eine leer PI handelt.

Ziemlich unschön, das alles und ich denke, ich werde die Experimente mit StAX an dieser Stelle vorerst abbrechen.

Nachtrag: Inzwischen ist der StAX Support erheblich besser geworden und der Tenor dieses Eintraes ist nicht mehr aufrecht zu halten.

Bloggen kann gefährlich sein. Ganz besonders gefährlich, wenn man aus einem Land wie China, Nordkorea oder dem Iran kommt. Dann kann es passieren, dass man mindestens sechs Monate nicht in die USA einreisen darf. Freies Land, wie, ihr Bushistenpack!

Via Schowckwellenreiter

Der Fellow Passenger macht uns heute darauf aufmerksam, das Werner Gruber von der Universität Wien, die Weltformel entdeckt hat.

DSL ist ja, wie berichtet, noch lange nicht DSL. Die Unterschiede liegen in der Geschwindigkeit des sogenanten Up- und Downstreams. Bei dem gängigen ADSL können diese beiden sehr unterschiedlich sein. Dies merken Filesharer daran, dass sie CDs oder Filme schnell aus dem Netz saugen können, das anbieten aber sehr langsam vonstatten geht, was die Contentindustrie vermutlich ganz in Ordnung findet.

Allerdings würde ich gerne diesen Server hier von zu Hause betreiben. Damit das einigermassen hinhaut und die Benutzer nicht, wie zu alten 14.4er Modemzeiten, ewig auf den Seitenaufbau warten müssen, muss es mindestens eine SDSL Leitung sein. Leider sind die sündhaft teuer. Bei einem Web-Server verhält es sich aber genau umgekehrt zum Clientrechner, auf dem nur ein Browser arbeitet. Die Anfragen sind gemeinhin sehr klein, die Antworten gross. Ein reverses ADSL, also hoher Upstream, niedriger Downstream, würde hier die Lücke schliessen. Anstatt via IP noch einen Kanal zur Verteilung von Filmen anzubieten (Stichwort IPTV), würde dies den Menschen ermöglichen ihr eigenes Informationssystem aufzubauen. Leider wird dies vermutlich ein Wunschtraum bleiben, solange die Carrier selbst zu Contentanbietern werden wollen, um ihre Überkapazitäten besser auszunutzen oder Serverhosting zu ihren Angeboten gehört.