Chapter 2. Using the Library

This chapter contains advanced material on the application programming interface (API) of XJBC. On first reading feel free to skip it and return later on, if you're interested in using XJBC in your own programs.

If you're interested in using the assembler and disassembler of XJBC directly in your own free applications, you can include the library. Beware of the license, please. If you're interested in using the library in a commercial application, please contact the author to get a valid commercial license. He will appreciate your interest in XJBC and will give you timely support in case of difficulties with this product.

ERklären, warum SAX2 und nicht DOM: über "ContentHandler" ist Austauschbarkeit gewährleistet: a) XMLSerializer (der übernimmt die korrekte Bildung der serialisierten Form der XML-Datei b) DOM-Builder, der eine Repräsentation im Hauptspeicher baut. c) XSLT-Filter, der eine Transformation des XML-Dokumentes durchführen kann, und dabei eine eigene spezielle Repräsentation des Dokumentes erstellt und braucht d) JBCSerializer, der eine ClassDatei erzeugen kann. Man hätte auch DOM direkt nehmen können, aber dann wäre im Hauptspeicher *immer* eine relative große Datenstktur erzeugt worden, obwohl dies nicht für alle Fälle nötig gewesen wäre (z.B. Punkte (a),(c) und (d)). Dies wäre ein Aufwand gewesen, der den Prozeß unnötig verlangsamt hätte. Auf Parserseite kann es a) den JBCReader bzw. b) einen XMLReader (XSLT-Filter *ist* ein XMLReader) geben, so daß dort eine Austauchmöglichkeit auch gegeben ist. Ebenfalls möglich wäre der Einsatz einer "bytecode" Repräsentation der SAX-Events: statt immer in das Standard-XML Dateiformat hin- und her zu transformieren, kann man die SAX2-Events auch in einer direkt serialisierten Form speichern und jederzeit wieder abspielen. Dann braucht man auch keinen Parser bzw. Reader-schritt mehr durchführen und wäre noch effizienter. Dies wäre z.B. bei "Remote SAX" sehr nützlich.

Warum ist der Generator so generös in seiner Ignoranz fehlerhafter Struktur? Weil er auf die effizienteste Umsetzung von *konsistenten* XJBC ausgelegt ist. Warum? Nicht jede Eingabe in den Generator kommt von Menschen und ist damit fehleranfällig. Sollte man den Generator als klassischen Assembler verwenden, so ist sicherlich eine Überprüfung der Konsistenz der Eingabe erforderlich. Da der Generator aber auch als Endstufe eines Transformationsprozesses genutzt werden kann, in dem ausschließlich automatische und als konsistenzerhaltend angenommene Transformationen beteiligt sind, so wird aus einem konsistenten Code mittels Konsistenzerhaltender Transformationen wiederum konsistenter Code erzeugt. Eine Konsistenzprüfung wäre demnach vollkommen überflüssig und würde den gesamten Transformationsprozess unnötig verlangsamen. Demnach überprüft der Generator als "Endstufe" die Konsistenz *nicht*.