Ich möchte diese Funktion nicht nutzen

Ich bleibe dabei:

Kinder, lernt einen ordentlichen Beruf!

Ich weiß, ich habe das schon mal erwähnt und ich werde auch nicht müde das weiterhin standhaft zu vertreten.

Es gibt einfach Dinge zwischen Entwickler und Software, die kann man nicht erklären. Ich kann sie nicht einmal sinnvoll nachvollziehen. Zeit rauben sie einem trotzdem und das meistens nicht gerade wenig.

Im Grunde ist die Geschichte mit Java eine ganz einfache:

Nimm Objekt und führe davon eine Funktion aus und erfreue dich der Dinge, die dort hinten rauspurzeln. Im Grunde kann einem beim Ergebnis nicht überraschen, statische Typisierung sei dank. Der schlimmste Fall ist, dass es sich ab „Object“ ausgibt und man erstmal rausfinden muss, welche Instanz von „Object“ das Ding denn jetzt eigentlich ist. Auch das ist noch kein Beinbruch sondern einfach nur ein bisschen lästig.

Nervig wird es dann wenn irgendwas nicht so läuft wie man sich das denkt, weil es in der kleinen Java-Welt eigentlich so nicht vorkommen darf, soll und kann. Na gut, das „kann“ kann ich streichen: Es kann eben doch.

Wir spielen also das lustige Spiel

String newText = Helper.convertString(inputString.getXmlStringA, laenge)

Nichts weiter also, als aus einem XML-Element den Inhalt raussuchen, auf eine definierte Länge X aufblasen und dann eine String-Variable packen. Kindergarten, Pillepalle, Dinge die ich notfalls angetrunken mitten in der Nacht blind hinbekomme.

Umso überraschter war ich von einer freundlichen Null-Pointer-Exception begrüsst zu werden.

Überrascht, weil ich mir sowas schon gedacht habe. Immerhin arbeite ich nicht das erste Mal mit per JaxB automatisch aus einem Schema generierten Code. Der hat so seine Tücken, vor allem wenn nicht ganz sauber im Schema definiert ist, was der Gegenpart jetzt mitschicken muss oder nicht.

Deshalb war convertString schon

if(input != null){
//Setze einen Default-Wert
}else{
//Nimm den Wert aus dem Input-String
}

Gebranntes Kind. Theoretisch kann also da nie null. Theoretisch…

Die Wege des Java sind aber manchmal etwas unergründlich und so treffen mein Freund, der Debug-Modus, und ich wieder aufeinander.

Wie oben schon erwähnt, lernt man im Java-Kindergarten schon, dass man eine Funktion aufruft und was bestimmtes zurückbekommt.

Meinem Compiler oder JaxB war das zu öde.

Statt wie gewollt die Funktion, so wie ich es im Quelltext beschrieben habe,

getXmlStringA

aufzurufen und zu verwenden, hat irgendwo das Programm, Kraft eigener Arroganz entschieden, dass es jetzt aber viel passender fände die Funktion

getXmlIntegerB

zu verwenden. Dummerweise sind String und Integer zwei vollkommen unterschiedliche Datentypen und wenn ich einen String verarbeiten möchte ist es doof wenn ich einen Integer zurückbekomme. So viel also zu statischer Typisierung.

Warum?

Weiß kein Mensch… da hilft kein Clean und Recompile. Und letztlich blieb nur eine Frage offen:

Will Java mich verarschen?

Scheinbar.

Aber dem Entwickler ist da ein mächtiges Werkzeug gegeben worden:

Die Lösch-Funktion.

Es ist im virtuellen eben wie im realen:
Niemand ist unersetzlich. Schon gar nicht, wenn es sich um generierten Code handelt. Und schon erst Recht nicht, wenn es so billig generierter Code von JaxB ist, dass ich nicht einmal ein künstlerisch wertvolles Binding-File einsetzen kann weil das Schema schon so mies ist dazu brauche.

Zwei Serverabstürze und ein vergessenes Depolyment später war klar: Irgendwas war wohl beim ersten generieren gewaltig schief gelaufen.

Auf einmal war Java wieder lammfromm und ich um eine Einsicht reicher:

Kaum ruft sich die richtige Klasse auf funktionierts.

(Ich bin übrigens gespannt, ob solches Verhalten auch in meinem Uni-Kurs behandelt wird… wenn nicht, wäre das wieder ein Beispiel wie weit die Theorie an der Uni von den wahren Problemen der Praxis entfernt ist 😉 )