In den vergangenen 30 Jahren hat sich eine rege Community im Java-Umfeld gebildet. Ich habe im Laufe des Jahres einige deutschsprachige Vertreter zu ihren Erfahrungen befragt. Die Resonanz war überwältigend. Vielen Dank an alle, die mitgemacht haben. In diesem ersten Teil kommen Alexander Culum (Organisator JUG Frankfurt), Birgit Kratz (Co-Organisatorin der Softwerkskammern Köln und Düsseldorf sowie der SoCraTes), Simon Martinelli (Java Champion, Co-Organisator JUG Schweiz), Dierk König (Java Champion und Professor Fachhochschule Nordwestschweiz) und Christian Stein (Open Source Committer und Mitglied Java Platform Group) zu Wort.

Java prägt viele Entwicklerinnen und Entwickler seit ihren ersten Schritten in der IT – und hat in dieser Zeit Höhen, Tiefen und mehrere Neuerfindungen erlebt. Die folgenden Antworten spiegeln persönliche Anfänge, prägende Erlebnisse, kritische Momente und eine Einordnung von Javas Rolle in der heutigen Softwareentwicklung wider. Abschließend wagen sie einen Blick nach vorn: mit Tipps für die eigene Weiterentwicklung und Erwartungen an Java in den kommenden Jahren.

Wann und mit welcher Version bist du erstmals mit Java in Berührung gekommen?

Alexander Culum: Das war tatsächlich erst im Studium an der Uni Münster; der Professor (Achim Clausing) hatte damals (also tatsächlich schon 1997!) gerade seine komplette Grundstudiumsvorlesung von Ada auf die brandneue objektorientierte Sprache Java umgestellt, im Nachhinein zu diesem Zeitpunkt eine sehr mutige und weitblickende Entscheidung. Auch ein spannender Moment mit Professor Clausing war etwa 1999, als ich mit ihm zusammen saß und er mir Google gezeigt hat, eine neue Suchmaschine aus dem Forschungsbereich. Sie würde dank fortschrittlicher Algorithmen die damaligen Suchmaschinen (Altavista, Yahoo) ablösen. Ich habe das meinen Kommilitonen erzählt und wir haben viel gelacht. Nun ja.

Birgit Kratz: Ich habe dazu mal in meinem CV nachgeschaut. Anfang 2005 wurde dort erstmals ein Projekt erwähnt, bei dem ich mit Java entwickelt habe. Damals war gerade Java 5 herausgekommen. Aber im Projekt wurde noch Java 1.3 verwendet. Davor habe ich ziemlich viel mit C/C++ gearbeitet. Der Umstieg auf Java war für mich zwar nicht „easy peasy“, aber auch keine unüberwindbare Hürde. Nach nunmehr 20 Jahren finde ich Java immer noch spannend und lerne fast täglich neue Aspekte der Sprache kennen.

Simon Martinelli: Im Jahr 2000 bin ich während eines Nachdiplomstudiums zum ersten Mal mit Java in Berührung gekommen – damals war J2SE 1.3 gerade brandneu.

Dierk König: 1995 mit Java 1.0. Cool waren am Anfang Applets und JDBC.

Christian Stein: Mich hat Java seit 1997 gepackt, das muss dann wohl laut der kompletten JDK-Matrix eine der 1.1er-Versionen gewesen sein. Ich hatte bis dahin bereits einige Erfahrungen mit Basic, Pascal, Delphi und C vor allem in der Spieleentwicklung gemacht. Und mir war bereits trotz der damaligen Langsamkeit im direkten Vergleich der Sprachen klar, dass eine virtuelle Maschine in Zukunft besser und stabiler dastehen würde.

Was war rückblickend dein schönstes Erlebnis mit der Sprache oder dem Ökosystem Java?

Alexander Culum: Da gibt es eine Menge. Es war toll zu sehen, dass Java sich immer mehr durchsetzte, auch gegen starke Konkurrenten wie C#. Das Release Java 8 fand ich toll und auch die Tatsache, dass ich die Java User Group Frankfurt 2009 gründen konnte und es immer (manchmal gerade genug) Interessenten gab, sodass die JUGF sich bis heute gehalten hat und wir eine kleine, aber sehr feine Community sind. Generell war Spring, nachdem ich es endlich verstanden hatte (und da reden wir von Jahren), auch immer mein treues, manchmal zu magisches Werkzeug, welches ich sehr zu schätzen gelernt habe. Das Java-Ökosystem wäre heute ohne Spring und die tollen Entwickler dahinter sicher ein anderes.

Birgit Kratz: Am schönsten finde ich immer die Momente, in denen es bei mir in Bezug auf neue Sprachfeatures Klick macht. Es liegt wahrscheinlich daran, dass ich aus meiner Sicht manchmal sehr langsam lerne, fast schon begriffsstutzig bin. Ich hatte das damals beim Umstieg von prozeduraler auf OO-Programmierung. Dann kam Java 5 mit Annotationen. Gefühlt habe ich ewig gebraucht zu begreifen, wozu die da sind und was man damit machen kann. Heute sind Annotationen, speziell bei der Benutzung von Frameworks wie beispielsweise Spring Boot, nicht mehr wegzudenken. Mein nächster großer Kampf war die Einführung von Lambdas und damit der Schritt zu mehr funktionaler Programmierung. Auch da hat es für mich sehr lange gedauert, das zu erfassen und dann auch gezielt einzusetzen. Aber wenn es dann Klick gemacht hat, dann ist das ein sehr schönes Gefühl.

Simon Martinelli: Es gibt unzählige schöne Erlebnisse in meiner Karriere. Eines der spannendsten Projekte mit Java war der erste Online-Ticket-Shop der SBB in den Jahren 2002/2003 – mein erstes Mal als Entwickler in einem richtig großen Team. In jüngerer Zeit denke ich oft an die vielen inspirierenden Begegnungen als Speaker auf Java-Konferenzen und JUG-Meetups. Doch das absolute Highlight war zweifellos meine Ernennung zum Java Champion im Jahr 2024.

Dierk König: Ohne Zweifel die Java Community mit Events wie der JavaOne, als sie das Moscone Center noch alleine ausfüllte, und wir zehntausende Entwickler ansprechen konnten, zum Beispiel bei der Vorstellung von Groovy.

Christian Stein: Nur ein Erlebnis? Na gut, nur ein paar wenige aus so vielen schönen: ein in Java geschriebenes Spiel (iRoll) auf den Markt zu bringen, Teil des JUnit-Teams, der Java User Group Bonn und der Java Platform Group geworden zu sein.

Aber es ist nicht alles golden, was glänzt. Was hat dich negativ beeinflusst bzw. was war ein unschöner Moment im Java-Umfeld?

Alexander Culum: Auch da gibt es eine Menge: Am Anfang bin ich gar nicht mit der Sprache warm geworden (wie gesagt, ich bin mit Java 1.0 gestartet). Schrecklich langsam, fürchterlich overengineered (ja genau: Applets und EJB 1.0!). Nach Borlands Delphi ein wahres Grausen. Dann kam der Kauf von Sun durch Oracle, was in der Community als der letzte Sargnagel wahrgenommen wurde, zu einem Zeitpunkt, als die Konkurrenten sich viel dynamischer und schneller entwickelten. Interessant, dass es vielleicht genau andersherum war. Auch der unbedingte Fokus auf Abwärtskompatibilität wurde nicht immer gut aufgenommen und häufig kritisiert. Ohne diesen Fokus wäre aber Java heute vermutlich nur eine Sprache von vielen im Unternehmensumfeld.

Birgit Kratz: Es liegt wahrscheinlich auch wieder daran, dass sich manche Sachen sehr langsam erfassen und dann aber auch schnell wieder vergessen lassen. Ein ewiger Kampf ist für mich immer das Lesen von Dateiinhalten und die Verarbeitung der darin enthaltenen Daten. Files, InputStreams, OutputStreams, Reader, Writer, … – ein großes Wirrwarr in meinem Kopf. Ähnlich ist es beim Arbeiten mit Datum und Zeit: Date, Time, Instance, Zone, Clock, Temporal, Formatter, … – da hilft nur, jedes Mal aufs Neue, die Doku zu lesen. Leider macht es bei diesen Themen immer nur kurzzeitig Klick bei mir. Und leider schafft es dieses Wissen dann auch nie, sich in meinem Langzeitgedächtnis einzunisten

Simon Martinelli: Schon zu Beginn meiner „Java-Karriere“ hatte ich erste Berührungspunkte mit J2EE-Applikationsservern – eine durchaus spannende Erfahrung. Doch wenn ich an die langen Wartezeiten beim Serverstart zurückdenke, vermisse ich diese Zeiten ganz sicher nicht.

Dierk König: Der Untergang von Sun Microsystems war schmerzhaft.

Christian Stein: Bis heute vermisse ich den UI-Editor von Delphi! Es gab und gibt Nachahmer im Java-Umfeld, aber die reichen nicht an das Original, beziehungsweise an meine Erinnerung daran, heran. Damit verbunden stört es mich, dass das Java Development Kit seit 30 Jahren kein eigenes Build-Tool mitliefert. Zwar geben die einzelnen Tools wie javac, jar, jlink und jpackage einen normierten Ablauf vor, doch fehlt hier eine grundsätzliche Projektstruktur und eben ein Tool, das diese Struktur dann in Aufrufe der anderen Tools umsetzt. Was nicht ist, kann ja noch werden.

Glaubst du, dass Java auch nach 30 Jahren noch relevant ist? Welche Rolle spielt Java deiner Meinung nach in der modernen Softwareentwicklung, insbesondere im Vergleich zu anderen Sprachen und Technologien?

Alexander Culum: Ja, ich denke, Java wird auch in 30 Jahren noch relevant sein. Es wird, trotz unglaublich vieler toller Neuerungen, vermutlich nie die Sprache der „Early Adopter“ und Start-ups sein. Aber viele Rewrites der coolen, schicken JS-serverseitigen Anwendungen werden in Java sein. Und bei der aktuellen Entwicklung sieht man, dass Java mit Leichtigkeit Neuerungen aus anderen Sprachen adaptieren kann, wenn es will, sogar als „schwergewichtige“, statisch typisierte Programmiersprache.

Birgit Kratz: Auf jeden Fall ist Java auch nach 30 Jahren noch relevant. Sehr sogar. Ich denke, Java kommt jetzt gerade in die besten Jahre. Seit der Umstellung auf halbjährliche Releasezyklen gibt es kontinuierlich nützliche Entwicklungen, die einerseits die Sprache modern halten, andererseits aber auch sehr viel Kontinuität garantieren. Sicherlich sieht der Code, den man in Java entwickelt, heute nicht mehr so aus wie vor 30 Jahren. Und das ist auch gut so. Mal ehrlich, wer sieht heute noch so aus wie vor 30 Jahren, und – würde man das wollen? Heutzutage kann man in Java viel prägnanteren Code schreiben, der aber immer noch (oder vielmehr gerade deswegen) sehr gut lesbar ist. Natürlich gibt es andere, neuere Programmiersprachen, mit denen man Aufgaben vielleicht einfacher, kürzer oder „knackiger“ lösen kann. Oft genug sind solche Sprachen aber auch sehr spezialisiert auf die Lösung solcher Aufgaben. Java hingegen bietet ein sehr breites Fundament für die Lösung (fast) aller Probleme.

Simon Martinelli: Java ist nach wie vor äußerst relevant. In meinen aktuellen Softwaremodernisierungsprojekten erlebe ich immer wieder, dass bestehende Systeme einfach analysiert und teilweise sogar wiederverwendet werden können – ein großer Vorteil der statischen Typisierung und der einzigartigen Rückwärtskompatibilität von Java.

Dierk König: Java steht für Verlässlichkeit einer stabilen und weitverbreiteten Ausführungsumgebung.

Christian Stein: Ja, absolut relevant. Gerade weil Java als Plattform sowohl lange dabei und offen ist, weil Java „langweilig“ ist, und auch weil seit Java 9 im Jahr 2017 sich nicht nur durch zwei Releases pro Jahr neu aufgestellt hat: Innovationen erscheinen zuverlässig und planbar! „Lange dabei“: OpenJDK, große Open-Source-Szene, viele Java-User-Gruppen und Konferenzen; „langweilig“: 30 Jahre sind in der IT schon was, bezahlt die Brötchen, andere Sprachen testen Neuerungen aus – Java zieht nach; „Innovationen“: Projekte wie Loom, Valhalla, Babylon und nicht zuletzt Amber schließen Lücken zu anderen Sprachen und gehen manchmal sogar darüber hinaus.

Die beliebten Developer-Snapshots haben wir neu in leckere Häppchen verpackt. Inhaltlich bleibt alles beim Alten – ein kleiner Überblick über alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:

• Die Cloud Native Computing Foundation (CNCF) wirft einen Blick zurück und einen nach vorne: Kubernetes hat in diesem Jahr einige stabile Features hinzugewonnen, darunter Sidecar Containers in Version 1.33 und das Beschränken anonymer Anfragen auf spezifische Endpunkte in Version 1.34. Im kommenden Jahr sollen unter anderem User-Namespaces für HostNetwork-Pods, robuste Image-Pull-Autorisierung und Pod-Zertifikate für mTLS hinzukommen.
• Microsoft hat verkündet, dass die C++-Code-Editierungswerkzeuge für GitHub Copilot nun als öffentliche Preview vorliegen. Sie sind in der neuesten Insider-Version von Visual Studio 2026 verfügbar und bieten dem KI-Copiloten neue Möglichkeiten wie das Visualisieren von Klassenvererbungshierarchien oder das Verstehen von Metadaten wie Typ, Deklaration und Scope.
• Der State of HTML Report für 2025 ist erschienen und legt dieses Jahr einen Schwerpunkt auf die frei geschriebenen Antworten der Teilnehmerinnen und Teilnehmer, die sie „bei bestimmten Problembereichen“ abgegeben haben.
• Für TypeScript veröffentlicht Google ein Agent Development Kit, mit dem Entwicklerinnen und Entwickler Agenten in TypeScript entwerfen und orchestrieren. Darüber hinaus bietet es Tools für Debugging, Testing und Deployment im Ökosystem von Google.

• Kotlin 2.3 unterstützt nun Java 25 in der JVM, ist kompatibel zu Gradle 9, bietet einen Swift-Export, verbessert das Parsen von UUIDs und prüft den Code auf ungenutzte Returns.
• Embarcadero hat Delphi 13 und das zugehörige RAD Studio mit C++-Builder angekündigt. Dieser basiert auf Clang 20 und unterstützt C++ 23. Für Delphi gibt es einen kurzen Ternary Operator mit if … then …. Außerdem vervollständigt das RAD Studio die Unterstützung von Windows 64bit als Compiler-Ziel.

• Next.js 16.1 bringt ein Update für Turbopack und einen experimentellen Bundle Analyzer. Mit diesem interaktiven Tool optimieren Entwicklerinnen und Entwickler ihren Code. Eine Vereinfachung gibt es zudem für den Debugger, der sich mit next dev --inspect aufrufen lässt.
• Mit Version 18.7 integriert GitLab künstliche Intelligenz stärker in die Plattform, beispielsweise bei der Diagnose abgebrochener Pipelines oder beim statischen Testen. Die generelle Verfügbarkeit der Duo-Agenten-Plattform ist für den Januar mit Version 18.8 angekündigt.
• LangGrant (vormals Windocks) hat den LEDGE MCP-Server vorgestellt, der helfen soll, die Entwicklung agentenbasierter KI zu beschleunigen. Die Plattform soll es ermöglichen, das Reasoning von LLMs über mehrere Datenbanken wie Oracle, SQL Server, Postgres oder Snowflake hinweg zu skalieren und mehrstufige Analysepläne auszuführen – ohne dass dabei Daten an das LLM gesendet werden müssen.

Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail.

(mai)

Die rasante Entwicklung großer Sprachmodelle hat eine intensive Debatte über ihr Potenzial ausgelöst, künstliche allgemeine Intelligenz und letztlich künstliche Superintelligenz zu erreichen.

Obwohl diese Systeme bemerkenswerte Fähigkeiten in den Bereichen Sprachverarbeitung, Schlussfolgerungen und Wissenssynthese aufweisen, deuten grundlegende architektonische und theoretische Einschränkungen darauf hin, dass sie die Lücke zu echter allgemeiner Intelligenz nicht schließen können. Diese Analyse untersucht die zentralen technischen Hindernisse, die aktuelle LLM-Paradigmen daran hindern, AGI oder ASI zu erreichen.

Das Ziel verstehen: Definitionen von AGI und ASI

Künstliche allgemeine Intelligenz (AGI – Artificial General Intelligence) ist eine hypothetische Form der künstlichen Intelligenz, die die kognitiven Fähigkeiten des Menschen in allen Bereichen des Wissens und der Schlussfolgerungen erreicht oder übertrifft. Im Gegensatz zu schmalen KI-Systemen, die für bestimmte Aufgaben entwickelt wurden, würde AGI eine flexible Intelligenz aufweisen, die in der Lage ist, Wissen in jedem Bereich mit der gleichen Leichtigkeit wie die menschliche Intelligenz zu lernen, zu verstehen und anzuwenden. Zu den Hauptmerkmalen von AGI gehören autonomes Lernen anhand minimaler Beispiele, Wissenstransfer zwischen unterschiedlichen Bereichen, kreative Problemlösung in neuartigen Situationen und die Fähigkeit, abstrakte Konzepte mit echtem Verständnis und nicht nur durch Mustererkennung zu verstehen und zu manipulieren.

Künstliche Superintelligenz (ASI – Artificial Superintelligence) geht über AGI hinaus und steht für eine Intelligenz, die die kognitiven Fähigkeiten des Menschen in allen Bereichen, einschließlich Kreativität, allgemeiner Weisheit und Problemlösung, bei weitem übertrifft. ASI würde die menschliche Intelligenz nicht nur erreichen, sondern um ein Vielfaches übertreffen und möglicherweise Erkenntnisse und Fähigkeiten erreichen, die für den Menschen unvorstellbar sind. Die Unterscheidung zwischen AGI und ASI ist entscheidend, da AGI eine allgemeine Intelligenz auf menschlichem Niveau darstellt, während ASI eine grundlegend andere Kategorie von Intelligenz impliziert.

Große Sprachmodelle sind in ihrer derzeitigen Form statistische Systeme, die auf der Grundlage umfangreicher Textkorpora trainiert werden, um das wahrscheinlichste nächste Token in einer Sequenz vorherzusagen. Diese Modelle lernen, Muster aus ihren Trainingsdaten zu komprimieren und zu reproduzieren, wodurch sie in der Lage sind, kohärente und kontextuell angemessene Antworten zu generieren. Ihre Funktionsweise unterscheidet sich jedoch grundlegend von der flexiblen, adaptiven Intelligenz, die AGI auszeichnet.

Architektonische Einschränkungen von Transformer-basierten Systemen

Die Transformer-Architektur, die den meisten aktuellen LLMs zugrunde liegt, bringt mehrere grundlegende Einschränkungen mit sich, die ihr Potenzial für allgemeine Intelligenz begrenzen. Der Aufmerksamkeitsmechanismus ist zwar leistungsstark für die Verarbeitung von Sequenzen, arbeitet jedoch mit festen Gewichtungsmatrizen, die während des Trainings gelernt wurden. Diese Gewichte kodieren statistische Beziehungen zwischen Token, können sich jedoch ohne erneutes Training nicht dynamisch an völlig neue Konzepte oder Domänen anpassen. Diese statische Natur steht in starkem Kontrast zur biologischen Intelligenz, die ihre neuronalen Verbindungen auf der Grundlage neuer Erfahrungen kontinuierlich anpasst.

Die Feedforward-Verarbeitung von Transformatoren schafft eine weitere bedeutende Einschränkung. Informationen fließen in einer Richtung durch die Netzwerkschichten, wodurch die für die menschliche Kognition charakteristische iterative, zyklische Verarbeitung verhindert wird. Das menschliche Denken beinhaltet kontinuierliche Rückkopplungsschleifen, in denen Konzepte höherer Ebene die Verarbeitung auf niedrigerer Ebene beeinflussen und umgekehrt. Dieser bidirektionale Fluss ermöglicht es dem Menschen, sein Verständnis durch Reflexion und Neukonzeption zu verfeinern – Fähigkeiten, die in aktuellen LLM-Architekturen noch fehlen.

Darüber hinaus führt der diskrete Tokenisierungsprozess, der die kontinuierliche menschliche Sprache in diskrete Token umwandelt, zu Informationsverlusten und schränkt die Fähigkeit des Modells ein, subtile Nuancen und kontextabhängige Bedeutungen zu verstehen. Die Verarbeitung der menschlichen Sprache erfolgt gleichzeitig auf mehreren Ebenen, von der phonetischen und morphologischen bis zur semantischen und pragmatischen Ebene, mit einer kontinuierlichen Integration über diese Ebenen hinweg. Der Engpass der Tokenisierung hindert LLMs daran, auf dieses gesamte Spektrum der Sprachverarbeitung zuzugreifen.

Die Einschränkung des Trainingsparadigmas

Das Ziel der Vorhersage des nächsten Tokens, das das LLM-Training antreibt, schafft grundlegende Einschränkungen in der Art und Weise, wie diese Systeme Informationen verstehen und verarbeiten. Dieses Trainingsparadigma optimiert eher die statistische Korrelation als das kausale Verständnis, was zu einem ausgeklügelten Musterabgleich statt zu echtem Verständnis führt. Dieser Ansatz ermöglicht zwar beeindruckende Leistungen bei vielen Sprachaufgaben, versäumt es jedoch, die für allgemeine Intelligenz wesentlichen Fähigkeiten des kausalen Denkens und der Weltmodellierung zu entwickeln.

Der im LLM-Training verwendete Ansatz des überwachten Lernens stützt sich auf statische Datensätze, die eine Momentaufnahme des menschlichen Wissens zu einem bestimmten Zeitpunkt darstellen. Dies steht im Gegensatz zum menschlichen Lernen, das aktive Erkundung, Hypothesenbildung und -prüfung sowie die kontinuierliche Integration neuer Erfahrungen in das vorhandene Wissen umfasst. Menschen entwickeln Verständnis durch Interaktion mit ihrer Umgebung und bilden und verfeinern mentale Modelle auf der Grundlage von Rückmeldungen aus ihren Handlungen. LLMs fehlt diese interaktive Lernfähigkeit, und sie können kein echtes Verständnis durch Erfahrungslernen entwickeln.

Die Skalierungshypothese, die besagt, dass größere Modelle, deren Training mit immer mehr Daten erfolgt, letztendlich AGI erreichen, steht vor mehreren theoretischen Herausforderungen. Die einfache Vergrößerung des Modells und des Datensatzes berücksichtigt zwar die Quantität, aber nicht die qualitativen Unterschiede zwischen Mustererkennung und Verständnis. Das Entstehen neuer Fähigkeiten in größeren Modellen spiegelt oft eher eine ausgefeiltere Mustererkennung wider als grundlegende Veränderungen in der Form von Intelligenz. Ohne die zugrunde liegenden architektonischen und trainingsbezogenen Einschränkungen zu beseitigen, kann die Skalierung allein die Lücke zwischen statistischer Verarbeitung und echter Intelligenz nicht schließen.