Einen Vorschlag XML nativ in Java aufzunehmen, hat Mark Reinhold auf der JavaOne 2006 gemacht. Die Folien können über sein Blog geladen werden.

Reinhold fragt

Reinhold stellt am Ende des Vortrags zwei Fragen. Ein lautet: Ist das was für Dolphin JDK 7 und welche Syntax wird als besser empfungen.

Ich antworte

Meine Antwort auf die erste Frage bedingt, dass ich mir über die Syntax keine Gedanken mehr machen muss Ich halte eine XML Unterstützung auf ebene der Sprachsyntax für keine gute Idee. XML ist nur ein weiteres Dokumentenformat. Ebenso kann argumentiert werden ASN.1, SQL oder Word Doc müssen in den Sprachkern aufgenommen werden. Für eine universelle Sprache wie Java ist dies nicht nötig.

Java ist keine Skriptsprache

Reinholds Argumentation für die Aufnahme ist die schlechte XML Unterstützung für ad hoc Code. Das stimmt sogar. Java ist keine sehr gute Sprache zum skripten. Mit Java können grosse Enterprise-Applikationen erstellt werden. Für Skriptingaufgaben nehmen Entwickler dann eher Perl oder ich neuerdings Groovy. In diesen Sprachen ist eine native XML Unterstützung durchaus denkbar und wird dort auch praktiziert - XPath in Groovy. Der eventuelle Einwand, dass der Entwickler dann nicht noch eine Sprache lernen muss zählt nicht. Entwickler beherschen immer mehr als eine Sprache. Seien es eben Perl, SQL oder einen Teil des XML Universums.

XML und Typsicherheit

Grösster Kritikpunkt meinerseits ist allerdings die Typsicherheit. XML ist nur durch den Aufsatz einer Schema-Definition typsicher. Bei den Schemadefinitionen konkurieren allerdings mehrer Ansätze um die Gunst der Benutzer - z.B. XSD oder RELAX-NG. Welche Technik ist vorzuziehen? Ich selbst empfinde RELAX-NG von der Syntax her einfacher. XSD ist zu komplex und hat eine Horror-Syntax.

Die Typsicherheit wird bei Reinholds Vorschlag aufgeproft und ist eben nicht nativ im Sprachkern verankert. Vielmehr wird sie in Bibliothken ausgelagert - was durchaus sinnvoll ist. Dadurch wirkt die Lösung allerdings halbgar und unausgereift.

Datenmengen

Ein weiteres Problem sind die potenziellen Datenmengen in XML. In meinem Job habe ich es regelmässig mit XML Dateien zu tun die 30 und mehr Megabyte gross sind. Diese lassen sich nur effektiv mit einem SAX-Parser verarbeiten. Effektiv im Sinne von schnell und ressourcenschonend. Bei dem von Reinhold vorgeschlagenen Verfahren müsste erst das gesamte Dokument in den Speicher gelesen werden, bevor es verarbeitet werden kann. Viel zu langsam.

Fazit

Da noch immer kein JSR im JCP eingebracht wurde, ist zu hoffen, dass er auch nicht mehr kommt. Kommt er doch, hoffe ich, dass er sich nicht durchsetzt.