28 Punkte von GN⁺ 2025-05-18 | 13 Kommentare | Auf WhatsApp teilen
  • James Gosling ist der Schöpfer von Java und gilt als pragmatisches Genie, das moderne Computertechnik seit 30 Jahren geprägt hat
  • Er wuchs in bescheidenen Verhältnissen auf und lernte Programmieren, indem er Computer aus Teilen vom Schrott zusammensetzte; dieses selbstgesteuerte Lernen prägte später auch seine Philosophie beim Sprachdesign
  • Seine Zeit bei Sun Microsystems, in der Schabernack und Innovation nebeneinander existierten, wurde zur Grundlage für Goslings besondere Kreativität und seinen Beitrag zur Technikkultur
  • Zuletzt äußerte er sich sehr skeptisch über generative AI-Tools und den AI-Boom und betonte, dass die Bedeutung von Programmierausbildung eher noch zugenommen habe
  • Das Erfolgsgeheimnis von Java war nicht Glamour, sondern eine pragmatische Designphilosophie, die konsequent auf Stabilität, Abwärtskompatibilität und Entwicklerproduktivität setzte

Java at 30: The Genius Behind the Code That Changed Tech

  • Java feiert am 23. Mai sein 30-jähriges Bestehen. Die universelle, hochsprachliche objektorientierte Sprache ist bis heute eine Schlüsseltechnologie, die Systeme unterschiedlichster Größenordnungen antreibt
  • Im Kern von Javas Existenz stehen James Goslings pragmatisches technisches Gespür und seine kreative Intuition
  • Gosling entwickelte sich von einem eigenständigen Teenager aus Kanada, der Computer aus Teilen aus dem Müll zusammensetzte, zu einem Programmierer von Weltrang
  • Die Philosophie „Write once, run anywhere“ ist das Symbol von Java und wurde zugleich zu einer Sprachphilosophie, die die Art der Softwareentwicklung grundlegend veränderte
  • Während seiner gesamten Laufbahn verband Gosling technische Exzellenz, Verspieltheit und ein klares ethisches Bewusstsein und verkörperte damit einen Entwicklertypus, der die moderne Computerkultur nachhaltig geprägt hat

James Gosling: The Brilliant Mind Behind Java

  • James Gosling ist nicht einfach nur der „Vater von Java“, sondern ein bescheidenes Genie, das komplexe Konzepte intuitiv erklären kann
  • 30 Jahre nach der Entwicklung von Java blickt er auf seine technologische Reise zurück und zeichnet dabei die Entwicklung von Sprache und Entwicklerkultur nach

The Path To Programming: Resourceful Beginnings

  • In einer von großer Armut geprägten Kindheit machte Gosling die Erfahrung, Fernseher aus dem Müll zu holen und so seine technische Kreativität zu entwickeln
  • Seinen ersten Computer baute er aus ausrangierten Relais-Racks der Telefongesellschaft zusammen – ein Symbol für sein früh erkennbares mechanisches Gespür und seine Fähigkeit zum Zusammenbau
  • Bei Besuchen im Computerzentrum der University of Calgary war er von Bildschirmen, blinkenden Lichtern und Bandlaufwerken fasziniert – dort begann seine lebenslange Neugier auf das Programmieren
  • Er brachte sich vieles selbst bei, indem er Lochkarten nach Passwörtern durchsuchte, und schrieb bereits als Highschool-Schüler in der universitären Physikabteilung Programme zur Analyse von Satellitendaten – eine frühe Phase, in der er fürs Programmieren bezahlt wurde und zugleich Freude daran hatte
  • Seine frühen Programmerfahrungen reichten von PL/1 auf IBM-Mainframes über Fortran und PDP-8-Assembler bis zu Code auf der CDC 6400. In seinem typisch zurückhaltenden Ton erwähnte er beiläufig, er habe „im Sommer als Nebenjob einen COBOL-Compiler entwickelt“ – eine Aufgabe, an der selbst viele erfahrene Programmierer scheitern würden

Academia to Industry: Finding His Way

  • Gosling beschrieb die Wissenschaft als „ein Forschungsinstitut, das Doktoranden als billige Arbeitskräfte nutzt“ und zeigte damit seine direkte, praxisorientierte Sichtweise statt theoretischer Verklärung
  • Schon während seiner Promotion an der Carnegie Mellon arbeitete er in einem Startup, sammelte praktische Erfahrung und vollendete später seinen Abschluss – eine flexible Laufbahn zwischen Industrie und Wissenschaft
  • Seine erste Stelle war bei IBM Research, doch er nannte das Unternehmen „einer Firma verpflichtet, sich selbst ins Bein zu schießen“ und bewahrte damit eine nüchterne Haltung gegenüber Unternehmensführung und Technologiestrategie
  • Diese frühen Erfahrungen wurden später zu einer praxisnahen Grundlage für sein Verständnis von Organisationskultur, die seine Arbeitsweise bei Sun Microsystems prägte

The Sun Days: Innovation and Pranks

  • Als schönste Erinnerung an Sun nennt Gosling die jährlichen groß angelegten Aprilscherz-Projekte und blickt damit auf eine Unternehmenskultur zurück, in der Kreativität und Humor zusammenfanden
  • Zu den typischen Streichen gehörte etwa, einen Ferrari auf einer Plattform im Teich schwimmen zu lassen – ein Beispiel für Humor, der technische Problemlösung und Teamarbeit nutzte
  • Auch ein Scherz, bei dem im Büro des CEO ein 1-Loch-Golfplatz mit Kunstrasen, Bunker und Wasserhindernis eingerichtet wurde, wird als origineller Versuch an der Schnittstelle von Technik und Spiel erwähnt
  • Gosling erinnert sich an Sun als seltene Umgebung, in der technische Exzellenz und verspielte Kreativität gleichzeitig erlaubt waren; sie wurde zur Grundlage seiner allgemeinen Problemlösungsansätze und seiner Haltung gegenüber Technologie

Java: Creating a Legacy That Changed Everything

  • Die 30-jährige Reise von Java ist für Gosling sein prägendster Erfolg und der entscheidende Wendepunkt seines technischen Lebens
  • Er spricht von der tiefen Zufriedenheit über seinen Einfluss auf das Entwickler-Ökosystem, wenn ihn Menschen auf der Straße ansprechen und sagen, Java habe ihnen eine Karriere ermöglicht
  • Features wie Lambdas und Generics wollte er von Anfang an einbauen, doch gemäß der Designphilosophie „ich werde sie nicht auf die falsche Weise einbauen“ wurde der Zeitpunkt ihrer Einführung bewusst gesteuert
  • Über Oracles Verwaltung von Java sagt er, das Unternehmen habe „es besser gemacht als erwartet“, betont aber zugleich, dass die kontinuierliche Beteiligung und der Beitrag der Community die entscheidende Rolle spielten
  • Java hat sich für Cloud-Umgebungen optimiert weiterentwickelt und bei Multicore-Unterstützung, Speicherverarbeitung und GC-Verbesserungen eine technische Reife erreicht, die er als „wirklich großartig“ beschreibt

Beyond Java: Ventures After Sun

  • Nach der Übernahme von Sun durch Oracle machte Gosling zunächst eine kurze Pause, ging dann zu Google und verließ das Unternehmen nach sechs Monaten wieder, um zu Liquid Robotics zu wechseln
  • Dort entwickelte er Steuerungssysteme für autonome Meeresroboter und erlebte ungewöhnliche Arbeitsbedingungen, in denen Technik und Natur zusammenkamen, etwa Aufgaben, für die man auf Hawaii schnorcheln musste
  • Er arbeitete an Projekten zur Überwachung von Meerestemperaturen in der Arktis und Antarktis, stieß aber darauf, dass Umweltforschung unterfinanziert war – ein Konflikt mit der VC-getriebenen Startup-Struktur
  • Als der Druck zunahm, in den Verteidigungsbereich zu wechseln, kündigte er aus ethischen Gründen und arbeitete später bei AWS an Greengrass und Entwicklerwerkzeugen weiter – eine Laufbahn, die technisches Interesse und ethische Maßstäbe gemeinsam berücksichtigte

On Open Source and Industry Trends: Cutting Through the Hype

  • Open Source wird nicht nur als Kollaborationswerkzeug beschrieben, sondern als komplexes Ökosystem aus Developer Relations, Marketingstrategie und Bottom-up-Adoptionsmodell
  • Zu Low-Code- und No-Code-Trends äußert er sich skeptisch und sagt, solche Behauptungen gebe es schon seit den COBOL-Zeiten; es handle sich um spezialisierte Ansätze mit Grenzen bei komplexen Domänen
  • Bei AI und Machine Learning sei weniger die Technik als vielmehr die Bezeichnung das Problem; er kritisiert die Terminologie und meint, „fortgeschrittene statistische Verfahren“ treffe das Wesen besser
  • AI sei nur ein Werkzeug und dürfe nicht als autonomes Wesen missverstanden werden; man solle sie eher als höherstufiges Hilfsmittel sehen, das menschliche Arbeit unterstützt statt bedroht

Developer Tools and Preferences: Embracing Progress

  • Gosling nutzt NetBeans IDE als zentrales Entwicklungswerkzeug und zeigt damit seine Unterstützung für Apache-lizenziertes Open Source und eine aktive Community
  • Gegenüber Entwicklern, die weiterhin an Vi oder Tools aus den 70er- und 80er-Jahren festhalten, äußert er sein Bedauern über die Verweigerung technologischen Fortschritts
  • Vi nutze er gelegentlich, weil es überall lauffähig sei, doch für ernsthafte Entwicklungsumgebungen befürwortet er nachdrücklich moderne IDEs

The JVM Vision: From Academic Concept to Global Standard

  • Das frühe Konzept der Java Virtual Machine (JVM) entstand aus Experimenten mit einem architekturunabhängigen Distributionsformat und Forschungen zur Befehlsübersetzung während Goslings Zeit im Graduiertenstudium
  • Daraus entwickelte sich später eine universelle Laufzeitplattform, auf der nicht nur Java, sondern viele Sprachen auf unterschiedlichster Hardware ausgeführt werden können
  • Die Philosophie „Write once, run anywhere“ wurde zunächst als Dissertationsthema abgelehnt, weil ihr angeblich die mathematische Grundlage fehlte, etablierte sich aber später als praktische Technologie, die die weltweite Softwareentwicklung veränderte

More Recent Work: Bridging IoT Gaps at AWS

  • Bei AWS arbeitete Gosling an Greengrass, einem IoT-Anwendungs-Framework, und setzte dabei einen technischen Ansatz um, der komplexe Probleme elegant vereinfacht
  • OTA-Updates, Fernsteuerung, Telemetrie, Netzwerkzuverlässigkeit, Sicherheit und Zertifikatsverwaltung abstrahieren dort die immer wiederkehrende Boilerplate zwischen Auslieferung und Betrieb
  • Der device-seitige Code wurde als Open Source veröffentlicht, um Community-getragene Portierungen auf von Amazon nicht priorisierte Plattformen wie RISC-V zu fördern
  • Ein weiteres Entwickler-Tool-Projekt, an dem er später beteiligt war, wurde vom AI-Boom erfasst und eingestellt – ein Hinweis auf Probleme einer von Trends statt technischer Substanz geprägten Entwicklung

AI Skepticism

  • In einem aktuellen Interview bezeichnete Gosling die AI-Revolution als „größtenteils Betrug“ und machte damit seine skeptische Sicht deutlich, AI als toxischen Marketingbegriff zu verstehen
  • Er erkennt den mathematisch beeindruckenden Charakter der Technik an, kritisiert jedoch, dass der Name AI das eigentliche technische Wesen als fortgeschrittene statistische Verfahren verschleiert
  • Den von Venture Capital getriebenen AI-Hype nennt er „einen Sammelplatz für Betrüger und Hype-Verkäufer“ und kritisiert damit scharf die Jagd nach kurzfristigen Exits statt nach wirklich nützlicher Technologie
  • Das meiste AI-Investmentkapital werde am Ende „in ein schwarzes Loch fallen“, warnt er, und verweist damit auf nicht nachhaltige, trendgetriebene Kapitalströme

Is It a Vibe? AI Coding Tools: Impressive Demos, Limited Utility

  • Generative AI-Code-Tools hinterlassen anfangs einen starken Eindruck, haben aber eine begrenzte Struktur, die schon bei etwas mehr Komplexität versagt
  • Diese Werkzeuge können nur bestehende Codebeispiele abschöpfen und wiederholen; wirklich interessante Probleme sind jedoch immer neu und passen daher nicht zu kopierbasierten Tools
  • In professionellen Entwicklungsumgebungen verdichtet sich Mustercode zu Bibliotheken, weshalb AI-Codegenerierung strukturell mit den realen Anforderungen der Softwareentwicklung kollidiert
  • Gosling definiert den eigentlichen Nutzen von AI als Suchwerkzeug für Dokumentationsarbeit, die niemand gern erledigt, und betont ihren Wert als Hilfsmittel speziell zur Erklärung der API-Nutzung

Java’s Evolution: Language Features and Runtime Improvements

  • Zu den jüngeren Änderungen der Java-Sprache zählen Typinferenz und Verbesserungen bei der Array-Deklaration, die als nützliche Erweiterungen für mehr Entwicklerkomfort bewertet werden
  • Gosling betont jedoch, die beeindruckendste Entwicklung von Java liege in der Qualitätssteigerung der JVM-Laufzeit und der Standardbibliotheken
  • Die moderne JVM erreicht bei Codequalität, Thread-Performance und Garbage Collection eine „erstaunliche“ Ausführungsleistung
  • Im Hinblick auf Speicherverwaltung und Vorhersagbarkeit der Performance sei sie effizienter als malloc-basiertes C; zudem erwähnt er die Möglichkeit, GC-Pausenzeiten auf wenige Millisekunden zu reduzieren
  • Die heutige JVM gilt als hochperformante Laufzeitumgebung, die selbst absurd große Speicherbereiche stabil verarbeiten kann

Programming Languages for Critical Infrastructure

  • Auf die Frage, in welcher Sprache man das Flugverkehrskontrollsystem der FAA neu schreiben sollte, weist Gosling die Prämisse zurück und sagt, das sei „als würde man ein Haus bauen, indem man zuerst den Hammer auswählt“
  • Zuerst müsse man die Eigenschaften der Problemdomäne verstehen – etwa Kommunikationssysteme, internationale Vorschriften, Flugrouten und Kollisionsvermeidung – und erst danach die Technik wählen
  • Für große Systeme mit hohen Zuverlässigkeitsanforderungen ergänzt er jedoch, dass Java ein starker Kandidat sein kann

The Future of Programming in an AI World

  • Auch wenn AI voranschreitet, bleibt Programmieren eine unverzichtbare Fähigkeit; Gosling sagt daher, wenn er Kinder hätte, würde er ihnen unbedingt das Coden beibringen
  • Behauptungen von Big-Tech-Managern, AI werde menschliche Entwickler ersetzen, kritisiert er als selbstschützende Drohung zur Erhöhung des Arbeitsdrucks
  • Um Systeme wirklich zu verstehen, brauche man Programmierkompetenz; selbst wenn Maschinen Aufgaben übernehmen, müsse das technische Verständnis des Menschen erhalten bleiben

Java’s Longevity Secret

  • Als Gründe dafür, dass Java mehr als 30 Jahre überleben konnte, nennt Gosling praktische Problemlösungsfähigkeit, Respekt vor den Nutzern, Abwärtskompatibilität, Produktivitätssteigerung und eine auf Zuverlässigkeit ausgerichtete Philosophie
  • Statt auf Sprachmoden setzte Java stets auf beständige Pragmatik; eine realitätsnahe Designphilosophie, die Ergebnisse über Stil stellte, erwies sich besonders im Enterprise-Umfeld als wirksam
  • Aus der Perspektive, dass Software „immer korrekt funktionieren muss“, bleibt Java ein ehrliches und pragmatisches Engineering-Werkzeug

Oracle’s Stewardship: Better Than Expected

  • Gosling sagt über Oracles Umgang mit Java nach der Übernahme von Sun Microsystems, das Unternehmen habe „es viel besser gemacht, als ich dachte“, und zeigt damit Überraschung über eine die Erwartungen übertreffende Leistung
  • Anfangs habe er wegen der früheren Historie „Plündern und Rauben“ befürchtet, tatsächlich habe Oracle das Java-Team jedoch nicht behindert, sondern geschützt – eine positive Bewertung von Unabhängigkeit und technikzentrierter Führung
  • Zwar kritisiert er fehlende finanzielle Unterstützung, vergibt aber hohe Anerkennung dafür, dass eine Struktur mit Autonomie des Technikteams ohne starke Eingriffe des Konzerns erhalten blieb

Crab Lovers Unite!

  • Gosling sagt seit Langem, er wolle mit Menschen arbeiten, mit denen er auch gern essen gehen würde, und zeigt damit eine menschenzentrierte Auffassung von Zusammenarbeit
  • Der Journalist begegnete Gosling zufällig im auf Krabbengerichte spezialisierten Restaurant Thanh Long in San Francisco und hielt damit einen Moment fest, in dem eine Tech-Größe im ganz normalen Alltag auftaucht
  • Später aßen die beiden gemeinsam Krabbe und unterhielten sich; die Verabredung zum nächsten Treffen am selben Ort vermittelt eine warme, menschliche Form des Austauschs, die über Technik hinausgeht

13 Kommentare

 
cosine20 2025-05-21

Ich finde auch, dass Java unter den statisch typisierten Sprachen die Sprache ist, mit der man am angenehmsten arbeiten kann.

Allerdings war es aus Sicht einer universellen, praxisorientierten Entwicklung keine besonders gute Wahl, endnutzerorientierte Apps mit GUI in Java zu schreiben. (Aus dieser Perspektive ist die Kombination aus C# + .NET am besten.)
Wenn man die Stärken von Java berücksichtigt, ist der Einsatz im Backend oder Middleware-Bereich aus praktischer Sicht wohl der beste Anwendungsfall.

Wie auch immer: Da ich es nur gelegentlich verwenden muss, ist es eine Sprache, mit der ich jedes Mal ohne große Hürde arbeiten kann, weshalb mir überwiegend gute Erfahrungen damit in Erinnerung geblieben sind.

 
mhj5730 2025-05-19

Die Geschichte, dass er auf dem Schrottplatz Fernseher zerlegt und so programmieren gelernt hat, wirkt einfach wie der Anfang einer Legende.

 
ndrgrd 2025-05-18

Es stimmt, dass sich Programmiersprachen seit Java stärker auf Produktivität konzentrieren.

Davor war das oft verwendete C++ — selbst heute ist schon das Lesen davon schrecklich. Vor allem, wenn man an langlaufenden Projekten arbeitet.

 
3ae3ae 2025-05-18

Ich finde es schwer, der Aussage zuzustimmen, dass Java großen Wert auf die Produktivität von Entwicklern gelegt hat.
Gibt es noch eine andere Sprache, die sich so entwickelt hat, dass man so stark von der IDE abhängig ist wie Java?

 
3ae3ae 2025-05-19

Ich habe wohl einen unbedachten Kommentar geschrieben.

 
sunrabbit 2025-05-19

Die starke Abhängigkeit von der IDE ist ein Problem des unnatürlich gewachsenen Java-Ökosystems
und kein Problem auf der Ebene des Sprachdesigns.

Salopp gesagt muss man für die Java-Entwicklung heute nicht unbedingt Produkte von JetBrains verwenden,
aber praktisch alle tun es trotzdem.

Und wenn man sich die Liste der Programmiersprachen ansieht, die es gab, als Java erschien, waren das viele Sprachen mit plattformabhängigen, also vom OS abhängigen Implementierungen.
Java hat damit die Richtung vorgezeichnet, die heute Sprachen wie Node, Python oder C# verfolgen: derselbe Code läuft auf verschiedenen Betriebssystemen.

Heutzutage ist diese Kompatibilität, dass derselbe Code auf verschiedenen Betriebssystemen läuft, selbstverständlich und geradezu „Common Sense“.

 
roxie 2025-05-26

> Mal ehrlich, auch wenn man heute Java entwickelt, muss man nicht unbedingt Produkte von JetBrains verwenden.

Diesem Punkt kann ich ... nur schwer zustimmen, seufz ...

 
kwj9211 2025-05-19

Das ist heute zwar ziemlich selbstverständlich geworden,
aber als Java herauskam, war es allein schon ein ziemlich großer Produktivitätsgewinn, mehrere Plattformen ohne neue Builds stabil zu unterstützen, oder nicht?

 
angrycoder 2025-05-18

Im Vergleich zu den Sprachen vor Java scheint die Produktivität höher zu sein.

 
ahwjdekf 2025-05-18

c++ > c# >= Java

 
cosine20 2025-05-21

C# >= Java > C++

 
GN⁺ 2025-05-18
Hacker-News-Kommentare
  • Java hat zwar nicht die absolute Spitzenleistung, gilt aber immer noch als etwa drittstärkste Sprache nach C/C++, also keineswegs schlecht, oft schneller als Go und mehr als zehnmal so schnell wie Python oder Ruby; die Syntax ist nicht perfekt, aber konsistent und vorhersehbar, und mit Tools wie Idea oder Eclipse muss man sich um Produktivität kaum Sorgen machen; das Speichermanagement folgt zwar nicht der Unix-Philosophie, wirkt aber als verständlicher Kompromiss; zufriedenstellend ist, dass man durch diese Trade-offs Geschwindigkeit und Speichersicherheit gewinnt und zugleich die praktischen Vorteile dynamischer Aufrufe und von Hotswap erhält
    • Man merkt, dass Tools wie IntelliJ für Java im Vergleich zu anderen Sprachen eine herausragende Umgebung bieten; es ist fraglich, warum die Go-Community so wenig Begeisterung für die Entwicklung nebenläufiger Datenstruktur-Container zeigt; bei Java ist die Kultur, hervorragende Container für Concurrent Programming zu empfehlen, beneidenswert, und java.util.concurrent oder JCTools werden manchmal vermisst
    • Direkt nach dem Studienabschluss hielt man Java zunächst für allmächtig, erkannte aber später, dass es eigentlich die JVM und das Tooling rund um Java App Server waren, die ihrer Zeit voraus waren; die Sprache selbst war vor den Produktivitätsverbesserungen von 2006–2007 eher enttäuschend; heute interessiert man sich für andere Sprachen auf der JVM wie JRuby, Clojure, Scala, Groovy und Kotlin; besonders JRuby ist spannend, weil es zwei ausgereifte Ökosysteme nutzen kann; dass Ruby-Fibers dank Project Loom nun auf der JVM möglich sind, ist für beide Seiten ein Gewinn, und Charles Nutters Leistung wird unterschätzt
    • Zwar heißt es, Java sei schneller als Go, in der Praxis ist Go aber oft schneller oder braucht 2- bis 10-mal weniger Speicher, daher liegen beide auf ähnlichem Niveau; dank der Value Types in Go lässt sich leichter optimieren; auffällig ist, dass Go überhaupt eigens erwähnt wird, und da C# schneller als Java sei, liege Java eher auf Platz 5 als auf Platz 3
    • Positiv hervorgehoben wird, dass sich die zuletzt in Java eingeführten sealed classes, switch expressions, Project Loom und records natürlich in die bestehende Syntax einfügen; auch Diagnosewerkzeuge wie Heap-Dump-Analysatoren und GC-Analysatoren gehören bei Java zur Spitzenklasse
    • Es wird darauf hingewiesen, dass Leistungsrankings von Programmiersprachen stark davon abhängen, was man überhaupt einbezieht und wie verglichen wird; dazu wurde ein Benchmark-Link geteilt
  • Java bzw. die JVM wurde nach Erfahrungen mit anderen, zeitweise hochgelobten Sprachen und Ökosystemen eher noch höher geschätzt; immer wieder stellte sich das Gefühl ein, dass das Gras auf der anderen Seite nur grüner wirke; nur Rust erschien wirklich als stark fortgeschrittene Sprache und machte Freude; bedauerlich ist, dass Java heute in Startups nicht als „coole“ Sprache gilt, obwohl die Produktivitätslücke fast verschwunden sei
    • Nach zwei Monaten Rust in Vollzeit ist zumindest im Serverbereich nicht nachvollziehbar, warum man im Vergleich zu Java von „Freude“ sprechen würde; Rust überrascht zu oft mit Lifetime-Problemen und kostet dadurch Produktivität; das Gefühl von Typsicherheit ist zwar klar vorhanden, insgesamt ist es aber schwer, von einer wirklich angenehmen Erfahrung zu sprechen
    • C# liege weit vor Java und unterscheide sich in bedeutsamen Punkten, etwa durch deutlich besser umgesetzte Generics, seit Langem vorhandene Value Types und bequemes FFI; außerhalb von Unity interessiere das aber kaum jemanden, und Microsoft habe es früher versäumt, genügend öffentliche Wahrnehmung aufzubauen
    • Dieses Gefühl liege wohl an der Projektgröße: Wenn man von einem zehn Jahre alten großen Java-Legacy-Projekt zu einem „neuen“ Hello-World-Niveau-Projekt wechselt, wirkt das natürlich besser; ein groß angelegtes Rewrite kann zwar auch für Sicherheitsprüfungen gut sein, aber die meisten Unternehmen haben dafür keinen Spielraum, Ausnahmen wie Google ausgenommen
    • Ganz ähnlich empfunden: Go war enttäuschend, versprach alles und lieferte am Ende etwas, das Java ähnlich oder durch Dinge wie Errors ohne Stacktrace sogar rückständiger wirkte
    • In fast 30 Berufsjahren waren die zwei Jahre, in denen ein Projekt außerhalb der JVM versucht wurde, die schlimmste Phase der Karriere
  • Dankbarkeit gegenüber James Gosling für seine Leistungen; durch die Java World Tour stand bei der Suche nach „Java consultant“ plötzlich ganz oben, was ein stabiles Leben im ländlichen Raum per Remote-Arbeit ermöglichte; es gibt zahllose Menschen, deren Leben Java positiv beeinflusst hat; ebenso bewundert wird, was das Clojure-Team auf Basis des JVM-Ökosystems aufgebaut hat
    • Auch hier Dank an James Gosling; 1995 arbeitete man bei Taligent mit C++, probierte dann erstmals Java aus und war von der Neuheit beeindruckt; nach der Auflösung von Taligent blieb man lange in Java-bezogener Software tätig
    • James Gosling (Java) und Rich Hickey (Clojure) werden als Schöpfer gesehen, die ihrer jeweiligen Epoche frischen Wind in die Welt des Programmierens brachten
  • Obwohl in den letzten Jahren mit .NET/C# gearbeitet wurde, wirkt die JVM bzw. Java insgesamt weiterhin als das beste Ökosystem unter allen selbst erlebten; Java habe deutlich mehr Probleme sauber gelöst; zum Beispiel habe Java mit dem fork/join pool die Aufteilung von Arbeit gelöst, während .NET einfach Work-Stealing in einen globalen Thread Pool gepackt habe, sodass sync-over-async-Code leicht zu Deadlocks im gesamten System führen könne; in großen Codebasen den gesamten synchronen Code auf async umzustellen, ist praktisch unmöglich; auf Java-Seite werden Fehler auf Bibliotheks- oder Framework-Ebene schneller überwunden, während Probleme in Standardbibliothek, Sprache oder Runtime bei .NET schwerer zu beheben seien; Java habe oft den besseren Standard gesetzt
    • Thread-Pool-Starvation in .NET sei extrem lästig, auch wenn die Auswirkungen zuletzt geringer geworden sein sollen; man hält es für unmöglich, eine Implementierung zu bauen, die gegen Fehlgebrauch des Thread Pools immun ist; man kann nur mehr Threads hinzufügen oder die Abarbeitungsreihenfolge klüger gestalten; sichere Aussagen dazu werden aber nicht beansprucht
    • Es fällt auf, dass .NET offenbar doch nicht einfach nur die erfolgreichen Ansätze des Java-Ökosystems kopiert hat, sondern in vieler Hinsicht anders ist
    • Es sei unfair, Deadlock-Probleme anzusprechen, ohne überhaupt .NET-Code zu schreiben, und sich dabei auf einen 13 Jahre alten Blogpost zu stützen, sei ebenfalls wenig überzeugend
  • Java gilt als großer Erfolg, aber James Gosling sei eher der Ausgangspunkt als der eigentliche Leiter gewesen; seit Java 1.1–1.2 habe Mark Reinhold federführend die Integration des JIT, die Entwicklung von HotSpot, den massiven Ausbau der Klassenbibliothek in 1.2 sowie später nach der Oracle-Übernahme die Unterstützung dynamischer Sprachen, die Open-Source-Freigabe, schnelle Release-Zyklen und die Grundlage moderner Sprachfeatures vorangetrieben; viele Stärken Javas seien der Führung von Mark Reinhold zu verdanken
    • Das gesamte Kernteam sei beeindruckend; Gosling wollte eine praktische Sprache, und danach hätten Leute wie Mark Reinhold und Brian Goetz die Sprache entwicklerfreundlich weiterentwickelt; Oracle werde zwar nicht besonders geschätzt, aber dafür, diese starke Gruppe vorangebracht zu haben, sei man dankbar
    • Es wird angemerkt, dass Kotlin wie Java statisch typisiert und keine dynamische Sprache ist
    • Selbst wenn Linus git nur in zwei Wochen zusammengehackt und damit lediglich den Funken geliefert hätte, hätte die Community es dennoch weiter ausgebaut; nur den Startpunkt zu bewerten, greift daher zu kurz
  • Als Softwareingenieur jenseits der 40 erscheint es realistisch und klug, einfach „Werkzeuge, die funktionieren“ zu wählen; heute erfüllen Java oder C# diese Rolle zuverlässig; persönlich wirkt C# etwas besser integriert als Ökosystem; für jeden Use Case könne man in einer Minute eine App in C# bauen, die Sprachentwicklung gehe schnell voran, Fachkräfte seien gut verfügbar, .NET sei ebenfalls plattformübergreifend, und die Eleganz sowie Effizienz der Sprache erleichterten die Arbeit
  • Es gab die Erfahrung, an der Universität Betriebssystem-Code in Java zu simulieren; für das Lernen abstrakter Algorithmen könne Java durch geringere Komplexität hilfreich sein, doch persönlich wäre Python wohl geeigneter gewesen; aus Einfluss der Industrie in der Anfängerausbildung an Hochschulen stur an Java festzuhalten, überzeugt nicht; da in der Schule bereits BASIC und C gelernt worden waren, fühlte sich die Simulation von OS-nahem Code in Java wie ein Rückschritt an
    • An der Universität lernte man Mikrocontroller mit C, Datenstrukturen/OOP mit Java und Systeme/OS/Nebenläufigkeitskonzepte mit C und MIPS-Assembler; bei Datenstrukturen und Algorithmen trenne Java abstrakte Typen und Strukturen klarer als Python und vermittle daher präzisere Konzepte; OS-Konzepte in Java zu lehren wirkt aber etwas überzogen
    • Es wird die Ansicht vertreten, dass die von Joel genannten Nachteile des Java-Unterrichts auch auf andere Hochsprachen wie Python zutreffen; ironischerweise wird betont, dass MapReduce, von Google in Java gebaut, Microsoft voraus war
  • Javas Erfolg wird anerkannt, aber aus verschiedenen Gründen bleibt eine tiefe Abneigung: vor allem wegen des Erbes aus langatmigem Code großer Unternehmen, komplexen Frameworks und qualitativ schwachem Code; verhasst war eine Kultur, in der Code „wie Kohle“ herausproduziert wird und Leidenschaft wie Individualität verloren gehen; die JVM erschien intern als Black Box, sodass Debugging mit Tools wie strace oder gdb schwierig sei, und durch Speicherüberallokation könne der Kernel Workloads schwer einschätzen; ohne Expertenhilfe könne der Einsatz der JVM leicht zu ernsten Problemen führen; dazu kommen Vorbehalte gegenüber Oracle, Lizenzen, JDK-Versionsmanagement, ein wenig attraktives Image im Jahr 2025 und Legacy-Code als Ballast; persönlich wurde die Karriere weitgehend aufgebaut, indem Java möglichst gemieden wurde; inzwischen gebe es viele hochperformante Sprachen mit statischer Kompilierung und kleinen Binaries, wodurch Lösungen wie die JVM oder die Python-VM operativ an Bedeutung verlören
    • Dem wird entgegnet, dass die JVM Debugging auf Weltklasseniveau biete, einschließlich Restart mit neuem Frame, Variablenänderung und Exception-Breakpoints; auch die Integration in IDEs wie Idea oder Eclipse sei mit anderen Sprachen kaum vergleichbar; dazu kommen vielfältige Diagnosewerkzeuge wie JMX/JConsole, Java Flight Recorder, jstack und HPROF; Lizenzen seien bei Open Source uneingeschränkt, und der Kauf einer Oracle-JVM sei reine Option; außerdem wird gefragt, was genau mit dem Legacy-Code-Problem gemeint sei
    • Die Behauptung, Java sei nicht „cool“, überzeuge nicht; statt strace/gdb seien die JDK-Tools und IDEs deutlich leistungsfähiger
    • Die Tools wirkten anfangs vielleicht einschüchternd, seien aber leicht zu erlernen; auch beim GC-Tuning könne man binnen einer Woche zum Experten werden; da GC im Anwendungskontext besser als der Kernel verwalten könne, habe das in der Praxis viele Vorteile, auch wenn etwas mehr Provisioning-Komplexität eingeräumt wird
    • Nach über 20 Jahren mit Java habe man strace oder gdb nie gebraucht; Debugging und IDE-Unterstützung seien äußerst stark, und es sei unpassend, Python und die JVM in Sachen Performance auf eine Stufe zu stellen
    • Wahrscheinlich kommt dieses Urteil daher, dass Java in der Praxis kaum verwendet wurde; erneut wird betont, dass Javas Debugging- und Diagnosewerkzeuge erstklassig sind
  • Als Gosling noch bei Sun war, war er Mitentwickler des Fenstersystems NeWS, das auf PostScript basierte und Clients Programme an den Server schicken ließ; bei Javas Entwurf seien Spuren dieser Vorstellung sichtbar, nämlich Webseiten als programmierbare Form zu sehen; als man ihn in einem vom Autor signierten Exemplar von „The Java Programming Language“ fragte, ob Java eine Rache für NeWS sei, habe Gosling mit einem Lächeln geantwortet
    • Wie X von Wayland und NeWS von Browsern plus JavaScript wie PWA oder Electron beerbt wurde, scheint sich die NeWS-Idee letztlich sogar im Microsoft-Umfeld durchgesetzt zu haben; man würde gerne wissen, was Gosling darüber denkt
    • Ähnlich gab es Display PostScript; auf Kombinationen aus SPARCStation und SPARCprinter wurde die gesamte Drucklogik serverseitig abgewickelt, sodass der Ausfall von Server oder Drucker das gesamte System lahmlegte; die Kopplung von Print-Server und Drucker wurde zum Albtraum und hinterließ letztlich nur Misstrauen gegenüber Druckern; SunOS und das SPARC-Ökosystem werden vermisst, Display PostScript jedoch keineswegs
  • Ein großer Teil der Karriere bestand aus Programmierung auf der JVM; zuletzt wurden statt Java eher Scala, Clojure (bevorzugt) und Kotlin verwendet; nach einem jüngsten Jobverlust wurde jedoch ein Python-Angebot angenommen; es ist spürbar, dass die Nachfrage nach JVM-Erfahrung sinkt; letztlich ist aber jede Sprache recht, solange das Gehalt kommt; das aktuelle Privatprojekt läuft in Scala
 
roxie 2025-05-26

Da versteckt sich zwischendurch wohl die C#-Fraktion.