OpenJDK läuft

Zuerst war ich ja etwas kritisch, außerdem lief bei einer alten Version der maven download nicht mehr, da die Zertifikate fehlten.

Aber nun mit der aktuellen 8er und 11er Version vom OpenJDK klappt es vorzüglich und gefühlt kompiliert der ganze Stapel richtig schnell durch. Sämtliche Unittests sind grün, alles compiliert, nichts klemmt. Perfekt!

Git rebase mit Handbremse

Wenn man sich wundert, warum eine einzige geänderte Datei beim rebase über Minuten den PC lahm legt (Windows natürlich). Wenn parallel Eclipse offen ist und bei jeder kleinen Änderung sofort neu compilieren will, dann bremst das natürlich ein wenig.
Dazu noch eine virtualisierte Umgebung und man kann erst mal Kaffee holen.

Java X-tool

Egal ob mal eben ein XML oder ein XLSX File zu parsen ist, mit Java kann auch das schnell von der Hand gehen. Dank Maven Unterstützung ist das ganze in einer Stunde schnell hingezaubert. An manchen tagen läuft es einfach.

Mit dem Gummihammer

Ist zwar nicht üblich, aber heute war der Entwickler in mir mit echtem Gummihammer unterwegs zur Problemlösung.

Hat funktioniert, die Racks sind nun zusammen gebaut.

An echter Entwicklung gab es danach als Absacker die Verbindung von C++, Google Test, Jenkins und Testlink.

Namen von Variablen

Viel zu schnell hat man sich mal vertippt bei der Referenz zu einer Variablen. Wenn dann eine andere Variable fast genauso benannt wurde, ist der Fehler kaum zu finden:

for (TestMap testMap : this.testMaps)
{
    System.out.println(testMaps.toString());
}

Das eine gemeine Plural s hat sich also reingemogelt. Dem Compiler ist das egal. Gemeint war aber eher dieser Aufruf:

for (TestMap testMap : this.testMaps)
{
    System.out.println(testMap.toString());
}

Der Unterschied ist kaum merklich. Also hätte man besser etwas längere Namen genutzt, die sich gleich in mehr Zeichen unterscheiden:

for (TestMap oneTestMap : this.allTestMaps)
{
    System.out.println(oneTestMap.toString());
}

So sollte es besser lesbar sein.

Java 11 Migration

So ein Sprung von Java 1.8 zu Java 11 macht schon einige kleinere Probleme. Die eigene Programmierung ist da noch das kleinste Problem, aber der CI Stack mit Code Coverage und Änderungen im Bytecode bringt einen Haufen zu aktualisierender Maven Pakete mit sich. Und da kaum jemand an einen Änderungsarmen Updatepfad denkt, muss man sich erst durch viele Changelogs arbeiten.

Aber nun läuft das JaStaCry Projekt wieder stabil, alles im grünen Bereich und Java 11 schnuckelt selbst im Jenkins ohne Probleme.

Unvollständige Include Abhängigkeiten

Ein weiteres NoGo Beispiel aus C-Land:

Man will in einem Modul eine bestehende header Datei einbinden und fügt das passende #include hinzu. Schon hagelt es aus der eingebetteten Datei unbekannte Identifier und mehr. Was ist passiert?

Die neue header Datei nimmt stillschweigend an bestimmte weitere header files schon im aufrufenden Code eingebettet zu haben. Besser ist es aber, wenn jede header Datei alles selber einbettet was sie zu nutzen gedenkt. Dann sind die Einbindungen zwar vielfach vorhanden, aber das abzufangen ist ja schon lange ein Must Have, dank #ifdef in jeder header Datei.