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.
