Java ist keine Programmiersprache

Seit knapp einer Woche beschäftige ich mich jetzt mit Java. Formell ist es natürlich eine Programmiersprache, aber ich komme immer mehr zu der Überzeugung, dass es sich eher um einen OOP Proof-of-concept handelt, denn um eine echte Programmiersprache. Trotzdem ist meine ersten Android-App nicht weit davon entfernt, den Weg in den Google Play Store anzutreten.

Perl habe ich (anno 1997) gelernt, indem ich ein kleines existierendes Perl-Script immer weiter erweitert und damit rumexperimentiert habe. Java wollte ich mit Hilfe diverser Tutorials lernen, bin aber schnell wieder in mein altes Muster verfallen - das sich aber wieder bewährt hat.

Eine sehr große Hilfe ist Android Studio, die auf IntelliJ basierende, Entwicklungsumgebung. Sie ist zwar noch als "Beta" angegeben - wirkliche Probleme konnte ich aber noch nicht finden.

Java ist langsam und ressourcenintensiv und zwar in allen Belangen. Das komplette Android-Entwicklungssystem belegt 8,5 GB (ohne Gewähr, dass ich tatsächlich alle überall verstreuten Dateien und Verzeichnisse eingefangen habe) und es empfielt sich, den Emulator (AVD) gleich nach der IDE zu starten - denn er braucht einige Minuten, bis er betriebsbereit ist. Die Snapshot-Funktion führt bei mir übrigens konsequent zu einem nicht-reagierenden emulierten Android-Gerät.

Mein Laptop ist durchaus nicht schlecht bestückt, trotzdem wird der CPU-Lüfter bei nahezu jeder Aktion aktiv. Der Nachteil meiner Lernmethode ist ein großer Anteil von try-and-error, also Quellcode einfach auszuprobieren. Eine kurze App zu kompilieren und im Emulator zu starten dauert beim ersten Mal gut anderhalb Minuten, bei folgenden Aufrufen immernoch etwa 30 bis 40 Sekunden.

Was ist Java?

Ich habe Java in der Einleitung als Proof-of-concept für OOP bezeichnet: Für jede Funktion gibt es (mindestens) eine Klasse, die diese übernimmt. Die eigentliche "Programmierarbeit" besteht fast nur daraus, die richtigen Klassen zu finden und zusammenzusetzen. Alle Werte folgen einem sehr (sehr, sehr) striktem Typenmodell, das beispielsweise für das, was allgemein als "Text" bezeichnet wird, bereits (mindestens) drei verschiedene Datentypen kennt - die sich selbst mit den passenden Klassen nicht einfach untereinander konvertieren lassen. Das hält andere (System-)Klassen natürlich nicht davon ab, Zeichenketten als Array mit Integerwerten zurückzuliefern.

Mein erster App-Versuch ruft unter anderem JSON-Daten von einem Internet-Server per HTTP ab. Die einzelnen Schritte benötigen dabei sehr unterschiedliche Quellcodemengen:

• Datenabruf in einem eigenen Hintergrundthread inkl. Kommunikation mit dem Haupt-Thread: 6 Zeilen
• HTTP-Abruf der Daten: 2 Zeilen
• Daten vom Ausgabe-Datentyp der HTTP-Klase in Eingabe-Datentyp der JSON-Klasse konvertieren: 9 Zeilen
• JSON zerlegen: 1 Zeile

Ich hatte (viel) mehr Aufwand für den HTTP-Abruf erwartet, hätte aber nie damit gerechnet, einen halben Tag damit zu verbringen, die Datentypen zwischen beiden Klassen zu konvertieren. Mitschuld an dem großen Zeitaufwand hatte ein kleiner Logikfehler: Ich hatte zwar den HTTP-Abruf im Hintergrundthread laufen lassen, die Konvertierung (um Debug-Ausgaben einfacher implementieren zu können) dagegen im Vordergrund-Thread. Der AndroidHttpClient lieferte dadurch nur maximal 8192 Bytes im HttpResponse Objekt zurück - was ich fälschlicherweise lange Zeit als Fehler bzw. Problem der Konvertierung betrachtet hatte.

Zur wichtigsten Quelle wurde die Android-Referenz und deren Suchfunktion. Google bringt für passende Suchbegriffe ebenfalls sehr gute Tipps, meist von Stack Overflow oder ähnlichen Seiten. Leider hat mich die ganze Java-Spielerei von meinem Vorhaben abgehalten, mehr zu bloggen.