1. Java, du Liebe. Java, es reicht
Zwei Briefe. Zwei Stimmen. Zwei unterschiedliche Sichtweisen auf eine Sprache, die seit Jahrzehnten begleitet, begeistert, herausfordert. Beide Texte sind Momentaufnahmen – entstanden zu verschiedenen Zeiten, in ganz eigenen Kontexten. Und doch sprechen sie über dasselbe: über Java. Über das, was war. Und das, was kommen könnte.
Zum 30. Geburtstag einer Sprache, die niemanden kalt lässt, lassen wir sie einfach mal sprechen – die Menschen, die mit ihr leben. Und manchmal auch von ihr lassen.
1.1 Wir müssen reden. Ich habe eine Neue
Christoph Landsky
Liebe Java,
wir kennen uns schon ewig. Haben viel gelacht und viel geweint. Ich weiß, wir haben viel zusammen erlebt. Vielleicht zu viel?
Ich kann mich immer noch an unser erstes, gemeinsames „Hello World“ erinnern. Wir waren beide so unendlich stolz. Allerdings war das auch der Tag, an dem ich feststellen musste, dass man stets um dich kämpfen muss. Du bist launisch, tadelnd, gängelnd und hast diese Art an dir, stets mein Bestes zu wollen, ohne zu berücksichtigen, was ich eigentlich will.
Wir beide sind komplizierte Wesen und vielleicht haben wir deshalb solange miteinander ausgehalten. Aber es wird Zeit, nach vorne zu blicken. Auch wenn wir uns gemeinsam verändert haben, glaube ich, dass es nicht reicht. Wir haben uns zusammen in funktionaler Programmierung versucht, haben die Welt der Streams erkundet und sind generisch geworden. Aber reicht es für unsere heutige Situation? Ich habe so viele Einschnitte machen müssen und das über Jahre hinweg. Habe mich dir angepasst und unterworfen. Habe mich mit der Lesbarkeit und den teils umständlichen Wegen abgefunden, die du gehen wolltest. Wenn wir mit unseren Mitteln nicht weiterkamen, haben wir uns Hilfe durch Fremdanbietersoftware geholt, die wir mühsam konfigurieren mussten.
Ja, du hast gelobt, dich weiter zu entwickeln und mit Altem zu brechen. Nur Java, es ist so. Auch wenn du jetzt versprichst, dass du String Interpolation einführen willst, so ist es bereits zu spät. 30 Jahre Java. Zu viel Zeit, in der du dich hättest verändern können. Doch es ist zu wenig geschehen. Meine Entscheidung steht fest. Ich bin jetzt mit deiner kleinen Schwester Kotlin zusammen. Sie gibt mir wieder das Gefühl produktiv zu sein. Sie inspiriert mich, wieder groß zu denken. Das habe ich bei dir lange vermisst. Kotlins Lesbarkeit ist schlicht der Hammer und so sehr du dich auch bemühst mit deinen vars, es wird verdammt schwer, an deine kleine Schwester heranzukommen. Sie ist einfach pragmatischer als du. Sie kennt sehr wohl meine Bedürfnisse, weiß, dass mich getter und setter einfach nicht mehr interessieren. Ja sie prüft sogar, ob meine Objekte null sein können. Ihr ist vollkommen egal, ob ich funktional oder objektorientiert entwickeln möchte. Sie bietet mir beides ohne Kompromisse an. Und was machst du? Functional Interfaces ... Ich bitte dich ...
Du kannst noch viel von Kotlin lernen. Zum Beispiel, dass es ein gutes Gefühl ist, eine Klasse um eine Methode zu erweitern, ohne von ihr erben zu müssen.
Oder dass Statements wie das If-Statement sehr wohl einen Wert zurückgeben können. Aber weißt du, was das Schärfste ist, Java? Ihr beide teilt euch auch noch die gleiche JVM. Also, was ist da so schwer Java? Ihr seid doch quasi im Herzen gleich. Ich kann sogar alles von dir weiter benutzen. Ohne Abstriche ... Selbst wenn das für dich alles wie Kinkerlitzchen klingt, weißt du, was Kotlin mir am meisten bringt? Sie bringt mir Zeit. Das ist das, was wir so wenig besitzen, Java. Zeit. Zeit, in der du auf deine Vergangenheit schaust und sagst: „Wir müssen kompatibel bleiben“. Ja, aber was ist mit mir? Deine Vergangenheit interessiert mich nicht. Versteh mich nicht falsch. Ich bin dir dankbar dafür, dass du da warst, und für alles, was du erreicht hast, aber leider reicht mir das nicht mehr ... Ich gehe jetzt mit deiner kleinen Schwester. Kotlin versteht mich und weiß, was ich will und was ich brauche. Vor allem: Zeit durch verständlichen und lesbaren Code!
Dein Christoph
© IKS GmbH, Fotograf Pio Mars
Christoph Landsky ist Shoshin der Softwareentwicklung, Kotlin- und Java-Bändiger sowie Berufsinteressierter für Mensch und Technik.
1.2. 25 Jahre Java-Treue. Auch das ein Anlass für einen Brief. Denn noch haben nicht alle Schluss gemacht
Reik Oberrath
Liebe Java,
ich bin jetzt seit 25 Jahren glückliches Mitglied in deinem Fanclub. Das möchte ich zum Anlass nehmen, dir herzlich für die Zeit zu danken. Ich will dir einmal erzählen, was ich vor dir und mit dir alles erlebt habe.
Ich erinnere mich noch gut an die Zeit, bevor ich dich kannte. Ich lernte Programmieren in einer Basic-Bar. In der Computerabteilung einer damals sehr bekannten Warenhauskette standen einige Commodore-Rechner nebeneinander. Vor ihnen standen Seite an Seite Jungspunde wie ich, um sich ein paar Kurze (Basic-Programme) hinter die Binde zu kippen. Selbstverliebt lautete mein erster Zweizeiler:
10 print "Reik"
20 goto 10
Irgendwann wurde ich auf eine Pascal-Party eingeladen. War das toll, ohne nummerierte Zeilen den Quellcode zu schreiben und Teile davon in Prozeduren auszulagern. Auf einer anderen Party lernte ich dann Turbo Pascal kennen. Wow! Programmieren wie Porschefahren. Und das mit einem alkoholfreien Cocktail aus Prozeduren und Modulen. So ließ sich Code sauber und handlich wiederverwenden.
Schließlich kam der Tag, an dem ich den Java-Jahrmarkt besuchte. Viele Java-Akrobaten zeigten dort ihre Künste und damit deine Vorzüge. Die Vorführungen waren toll anzusehen, doch die Nachahmung fiel mir zunächst sehr schwer. Mit deiner Objektorientiertheit, Polymorphie und Vererbung stelltest du meine prozedurale Welt völlig auf den Kopf. Nachdem ich mich aber an diese neue Normalität mit dir gewöhnt hatte, eröffneten sich wunderbare und vorher nicht vorstellbare Möglichkeiten. Als dann noch Test-First in Mode kam und du mit JUnit eingekleidet warst, war ich restlos begeistert von dir.
Ich muss allerdings gestehen, dass ich dir fast einmal untreu geworden wäre. In einer kleinen, aber feinen Ruby-Runde musste ich feststellen, dass junge und frische Programmiersprachen dich alt aussehen lassen. Jemand in der Runde hatte Lambdas mitgebracht. Damals für mich krass exotisch, weil es die bei dir noch nicht gab. Der kurze, aber ausdrucksstarke Code von Ruby beeindruckte mich sehr. Für die Möglichkeit, diese Sprache in meinen Projekten anwenden zu können, hätte ich dich und deinen Fanclub damals vielleicht sogar verlassen.
Doch ich blieb dir treu und habe es nicht bereut. Ich verfolgte teils skeptisch, teils erfreut, wie du generisch, funktional und modular wurdest. Alles bin ich interessiert mitgegangen und habe es schätzen gelernt. Doch wenn ich in die Zukunft blicke, dann habe ich doch ein mulmiges Gefühl.
Vor einiger Zeit besuchte ich ein Kotlin-Konzert. Dort hatte ich ein ähnliches Gefühl wie Jahre zuvor in der Ruby-Runde. Deine neue Konkurrenz besitzt klangvolle Instrumente wie Typinferenz, Typ-Aliasse, Null-Sicherheit und Klassenerweiterung. In deinem Orchester fehlen die. Es erstaunte mich, wie viele meiner Kollegen deinen Fanclub verließen und mit welch großer Begeisterung sie dem Kotlin-Club beitraten. Christoph schrieb dir anlässlich seines Clubwechsels sogar einen Trennungsbrief. Jörg, ein anderer Kollege, tauschte in seiner E-Mail „javacook“ gegen „kotlincook“ aus. Wohin soll dieser Trend nur führen? Wird Kotlin dich tatsächlich in die Ecke spielen?
Wenn ich in die Zukunft blicke – 5, 15 oder vielleicht sogar 25 Jahre – dann habe ich drei verschiedene Visionen. Die Erste ist sehr traurig. Darin bist du nicht mehr als ein Wikipedia-Link unter https://de.wikipedia.org/wiki/Zeittafel_der_Programmiersprachen. Vielleicht wird es – wie bei Basic und Pascal – noch kleine Nischen geben, in denen du dich rumtreiben darfst, aber mehr auch nicht. Die zweite Vision ist nicht viel besser. Darin bist du zwar noch im Einsatz, aber deine Fans betreuen deine Programme nur noch wie Palliativmediziner ihre Patienten.
Erst die dritte Version sieht freundlicher aus. Zusammen mit anderen Programmiersprachen hast du dich zu einem Alleskönner weiterentwickelt. Ob objektorientiert, deklarativ, strukturiert oder irgendetwas anderes – ein Alleskönner bietet seinen Anwendern verschiedenste Programmierparadigmen und sämtliche sprachliche Möglichkeiten an, die sich in der Programmierwelt bewährt haben. Programmierer wählen dann je nach Vorliebe oder Problem aus, wie der Quellcode gestrickt wird. Damit ist es nur noch Geschmacksfrage, welcher Programmierer welchen Alleskönner verwendet.
Würde die erste Vision bald wahr werden, sähe ich mich gezwungen, der johlenden Kotlin-Gemeinde zu folgen. Sollte die zweite Vision wahr werden, hätte ich immerhin eine realistische Chance, dir bis zu meiner Rente treu bleiben zu können. Cool wäre natürlich die dritte Vision, aber dafür musst du dich jetzt ranhalten. Du hast bereits gezeigt, dass du flexibel und veränderbar bist. Reck dich, streck dich, mach dich frisch. Ich hoffe, du fühlst dich nicht so alt, wie ich mit dir manchmal aussehe.
Auf die nächsten 25 Jahre!
Dein Reik
© IKS GmbH, Fotograf Pio Mars
Dr. Reik Oberrath entwickelt in Java seit Java 1.2 und seit 2008 für die IKS GmbH.
2. Java lernen auf die harte Tour
Ende der 90er-Jahre des letzten Jahrhunderts beschäftigte ich mich damit, ganze Systeme (von GUI bis Persistenz) in ANSI-C zu schreiben. Denn nur so war es unserer Meinung nach möglich, auch schnelle Antwortzeiten zu garantieren und nicht durch so neumodisches Zeug wie den Garbage Collector ausgebremst zu werden. Dieser war ja eh nur für Entwickler, die nicht wussten, wie viel Speicher sie alloziert hatten (und ihn deshalb auch nicht freigegeben haben). Außerdem – Java hatte weder einen Präprozessor noch Pointer!
Ich selbst hatte auch keinerlei praktische Berührung zum damals noch recht neuen Java [1] oder der Objektorientierung – warum auch? ANSI-C konnte alles, was man wollte, und mal ehrlich – das Ganze lief auch auf allen möglichen Betriebssystemen von Reliant Unix über HP-UX, AIX … Selbst auf dem neuen Linux – kein Problem. Und wenn doch was anders war, half ein kleines #ifdef im Code.
Eines Tages kam unser Vertrieb auf mich zu, da er für einen Kunden einen HTML-Entwickler suchte – das war interessant – schließlich konnte das nicht jeder! Dieser Entwickler sollte direkt bei dem Kunden zwei Wochen HTML-Entwicklung für eine neue Anwendung machen.
Da ich ein wenig HTML konnte (dies wurde damals noch komplett im Editor getippt), sagte ich zu und fuhr mit einem weiteren Kollegen zum Kunden. Als wir dort ankamen, war der Schreck groß – wir verstanden nämlich, dass der Kunde von uns eine Webanwendung (1999 sehr ungewöhnlich und garantiert nicht in zwei Wochen zu liefern) zur Archivierung von Dokumenten wollte, die nach dem Rational Unified Process [2] (hatte ich nie gehört) und komplett in Java geschrieben sein sollte.
Schnell war meine Euphorie verflogen und ich rief abends vom Hotelzimmer (ich hatte noch kein Handy) meinen Chef an und erzählte ihm meine Probleme: Ich kannte weder Java noch Objektorientierung noch den Rational Unified Process (RUP)!
Er beruhigte mich und wir fassten einen Plan: Ich bekomme ein eigenes Notebook (das hatte sonst nur die Geschäftsführung), das Buch „Java in a Nutshell“ von David Flanagan [3] und einen weiteren Kollegen, der Java kann. Im Gegenzug lerne ich abends auf dem Hotelzimmer Java, um im Projekt mitarbeiten zu können. Genauso haben wir es gemacht – jeden Abend nach der Arbeit lernte ich Java mit dem JDK 1.1, und als das System in Betrieb ging, konnte ich Java!
Und, was soll ich sagen – der Kunde war auch zufrieden – schließlich war ich durch meine „Abendkurse“ immer auf den nächsten Tag vorbereitet!
Literaturangaben
[1] J. Gosling, Java: an Overview, 1995, siehe: https://www.researchgate.net/publication/345758345_Java_an_Overview_the_original_Java_whitepaper/link/5facbbd1299bf18c5b6a0143/download
[2] I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1998
[3] D. Flanagan, Java in a Nutshell, O'Reilly & Associates, 2. Auflage, 1997
Thomas Ronzon arbeitet als Projektleiter und Senior Softwareentwickler bei der w3logistics AG in Dortmund. Dabei beschäftigt er sich vor allem mit der Modernisierung von unternehmenskritischen Logistikanwendungen. Darüber hinaus veröffentlicht Thomas Ronzon regelmäßig Fachartikel. E-Mail: ronzon@w3logistics.de
3. Am Anfang war ein Marienkäfer
Ich kann mich an meine ersten Schritte mit Java noch sehr gut erinnern. Diese fanden 2003 in der 11. Klasse im Informatikunterricht mit JavaKara und anschließend der Bibliothek „Stifte und Mäuse“ im Java-Editor mit Java 1.4 statt. Vor allem ist mir dabei in Erinnerung geblieben, dass wir damals nicht javac, sondern Jikes von IBM als Compiler genutzt haben.
Erst viele Jahre später hat mir ein Kollege erklärt, dass javac zu dieser Zeit beim Kompilieren für jede Klasse einen eigenen Prozess und damit eine JVM gestartet hat und deswegen, auch aufgrund der damaligen Hardware, sehr langsam war. Jikes hingegen startete damals schon nur einen Prozess und war deswegen schneller.
Die nächsten Berührungspunkte mit Java fanden dann im Studium statt, denn auch dort wurde Java als Sprache gelehrt. Aus dieser Zeit stammen meine Erfahrungen mit Java EE, damals noch als J2EE bekannt. Aus heutiger Sicht kann man sich fast nicht mehr vorstellen, dass dabei eigentlich alles durch eine Mischung aus Konfiguration in XML-Dateien und Vererbung gemacht wurde. Auch wenn es, dank XDoclet, bereits damals, auch ohne Annotationen, schon die Möglichkeit gab, einen Großteil der Konfigurationsdateien aus dem Java-Code zu generieren. Als Build-Tool wurde natürlich, das heute nicht mehr oft anzutreffende, Apache Ant genutzt. Jahre später durfte ich dann unseren riesigen Build, mit diversen Besonderheiten, auf Apache Maven umziehen und damit das Ende von im Versionskontrollsystem eingecheckten Bibliotheken einläuten.
Und auch große Applikationsserver waren zu dieser Zeit Stand der Technik. Hier kann ich mich noch an eine Migration von JBoss AS 4 auf 5 erinnern, die, auch dadurch, dass wir fast alle internen Komponenten ausgetauscht hatten, lange und schmerzhaft war. Und auch daran, dass mit einem JDK 8 Patch Update alle Komboboxen unseres Swing basierten UIs nicht mehr funktionierten, erinnere ich mich noch. Ob das ein Bug im JDK oder in unserem UI-Framework war, ist vermutlich bis heute nicht geklärt.
Schaue ich mir aktuelle, moderne Projekte an, dann ist der Unterschied zu damals schon erstaunlich. Keine großen Applikationsserver mehr, deutlich wenig Konfiguration außerhalb des Codes und anstelle von Vererbung werden häufig Annotationen verwendet. Und trotzdem helfen mir die damals gelegte Basis und erlernten Prinzipien bis heute. Deswegen freue ich mich auch heute noch auf die weitere Zukunft von Java und harre der Dinge die noch kommen.
Michael Vitz verfügt über mehr als zehn Jahre Erfahrung in der Entwicklung, Wartung und im Betrieb von Anwendungen auf der JVM. Als Senior Consultant bei INNOQ hilft er Kunden, wartbare und wertschaffende Software zu entwickeln und zu betreiben. Daneben bringt er sich in Open-Source-Projekten ein, schreibt Artikel, hält Vorträge und ist seit 2021 Java Champion.
