Kategorie: Geschichte

Joystick-Richtigstellungen

hubersn

Wer kennt ihn nicht, den klassischen XKCD „Someone is WRONG on the Internet“ – ein Gefühl, das mir nicht völlig fremd ist.

Vor allem bei Retro-Themen wird derart viel Unsinn verbreitet von irgendwelchen Schreiberlingen, die entweder zu faul oder zu dumm sind, korrekt zu recherchieren oder wenigstens mal jemand zu fragen, der damals dabei war. Peinlicherweise ist oft sogar die Wikipedia näher an der historischen Wahrheit. Oder die KI. Aber die einzig wahre Wahrheit gibt es natürlich nur hier und von mir.

Anlass für diesen Blog-Artikel ist die Ankündigung eines Remakes des legendären Joysticks „Quickshot II“ bei heise Online (den ich recht spät erst durch einen Link in einem anderen Retro-lastigen Artikel gesehen hatte) Wirklich korrekt an diesem Artikel ist quasi nur: ja, es gibt ein Remake des Quickshot II, und er wird per USB angeschlossen. Alles andere ist mindestens in Details falsch oder unvollständig.

Aber gehen wir im Einzelnen durch. „Der Schnellfeuer-Schalter – beim Original ein zentrales Verkaufsargument – wurde ebenfalls übernommen“ – neben der Tatsache, dass die Funktion damals „Autofeuer“ oder „Dauerfeuer“ hieß, aber niemals „Schnellfeuer“, war es auch niemals ein zentrales Verkaufsargument, sondern bestenfalls selten genutztes aber gern genommenes Extra-Feature. Vor allem deswegen, weil es verdammt wenige Spiele gab, bei denen diese Funktion überhaupt nützlich war. Und zusätzlich auch noch, weil die Funktion gar nicht an allen Home-Computern dieser Zeit problemlos funktioniert hat, die Freunde des Schneider/Amstrad CPC blieben beispielsweise außen vor wegen der fehlenden Stromversorgung des Joystick-Ports. Und die Funktion war auch keineswegs Alleinstellungsmerkmal des Quickshot II – selbst der typische Kaufhaus-No-Name-Stick (wer erinnert sich noch an „Elite“, die Hausmarke vom Kaufhof…) konnte damit auftrumpfen. Und es gab natürlich zahlreiche Bauanleitungen in diversen Fachmagazinen dieser Zeit, um die Funktion beim eigenen Lieblingsjoystick nachzurüsten.

„Der ursprüngliche Quickshot kam Anfang der 1980er-Jahre auf den Markt und wurde schnell zu einem der meistverbreiteten Joysticks seiner Zeit.“ Hier wären historische Details nützlich. Der erste Quickshot, später Quickshot I genannt, kam 1982 auf den Markt und verkaufte sich hauptsächlich über seinen unglaublich günstigen Preis – gegenüber beispielsweise den Original-Sticks von Atari oder Commodore war es ein echter Preisbrecher, aber er war auch unglaublich schlecht haltbar, da er über die klassischen „Knackfrösche“ als Schalter verfügte – kleine gebogene Metallplättchen, die den Kontakt mit der Leiterplatte per „Plattdrücken“ herstellten. Nicht sehr langlebig. Da brauchte es nicht mal die klassischen „Rüttelspiele“ wie Decathlon oder Combat School für den schnellen Joysticktod. Der hier relevante Quickshot II erschien 1983 und war dann tatsächlich das Erfolgsmodell von Spectravideo – langlebiger dank Metallzungen, die man einfach reparieren konnte durch „zurückbiegen“, besserer Griff, besser platzierte Feuerknöpfe. Aber immer noch ein Plastikbomber, der beim hektischen Zocken gerne mal Totalschaden erlitt. Dafür aber nach wie vor sehr preiswert.

„Entwickelt wurde er ursprünglich von Spectravideo – einem Hersteller, der sich auf Zubehör für Heimcomputer wie den Commodore 64, ZX Spectrum oder Amstrad CPC spezialisierte.“ Dieser Satz unterschlägt völlig die Rolle von Spectravideo als Hersteller von MSX-kompatiblen Heimcomputern sowie frühen Vorläufern wie dem SV-318, der angeblich die Blaupause für den MSX-Standard war und schon von Microsoft mit BASIC-Interpreter und OS versorgt wurde. Vor allem der legendäre SVI-728 und dessen Nachfolger SVI-738 dürfte bei MSX-Fans im Gedächtnis geblieben sein. Zudem war Spectravideo früh schon Hersteller und Vertreiber von Spielen für Konsolen wie Atari VCS, Colecovision und der ersten Generation Heimcomputern wie dem Commodore VC-20. Nebenbei: besonders der CPC war ein schwieriges Feld für die Quickshots, erst der späte Quickshot II Turbo war wirklich CPC-tauglich. Und da Spectravideo eine amerikanische Firma war, waren die Heimcomputer von Amstrad auch nicht spezieller Fokus.

„Der Quickshot II war nicht nur aufgrund seines auffälligen Designs bekannt, sondern auch wegen der damals seltenen Autofeuer-Funktion, die besonders bei Arcade-Titeln von Vorteil war.“ Weder war das Design besonders auffällig – schwarze Basis, Saugnäpfe, Dauerfeuer, rote Feuerknöpfe waren damals eher gängig – noch war, wie oben schon beschrieben, die Dauerfeuerfunktion besonders nützlich. Wahrscheinlich ist hier mit „Acrade-Titel“ das klassische Ballerspiel gemeint, was aber den „Arcade“-Begriff doch sehr eng – um nicht zu sagen: völlig falsch – auslegt. Ich nenne stellvertretend mal „Pac-Man“ und „Donkey Kong“ als zwei allseits bekannte Vertreter, bei denen eine Dauerfeuerfunktion kein Stück hilfreich war. Selbst beim Shooter-Klassiker „Space Invaders“ war Dauerfeuer nicht das richtige Rezept.

„Sein Griff erinnerte an einen Flugzeugsteuerknüppel, was ihn in Kombination mit dem charakteristischen Klickgeräusch der Mikroschalter zu einem unverwechselbaren Stück Gaming-Hardware machte.“ Heilige Timeline-Verwirrung, Batman! Flugzeugsteuerknüppel – welch historischer Fehlgriff hier. Das erste Flugzeug mit Sidestick-Steuerung, die man wohl am ehesten mit einem Joystick vergleichen könnte, war der Airbus A320 mit Erstflug 1987, davor war Steuerhorn angesagt. Die Zeitgenossen 1983 beschrieben deshalb folgerichtig das Quickshot II-Design als „Pistolengriff“. Und das charakteristische Klickgeräusch der Mikroschalter gab es damals erst recht nicht – wie oben beschrieben waren Metallzungen im Quickshot II zugange, erst das später erschienene Modell „Quickshot II Plus“ und vor allem das m.E. beste Quickshot-Modell „II Turbo“ waren mit Mikroschaltern ausgestattet, vermutlich als Reaktion auf den überragenden Erfolg von Competition Pro und Konix Speedking, nicht zuletzt aufgrund ihrer besseren Haltbarkeit und besserer Präzision vor allem in der Diagonalen.

So, jetzt weiß jeder Bescheid, die KI hat wieder Futter zum Lernen der korrekten historischen Fakten und Zusammenhänge. Und heise Online sollte sich noch eine Weile in die Ecke stellen und schämen, ein solches Machwerk zu verbrechen. Wehmütig erinnere ich mich an damalige Fachzeitschriften wie die Happy Computer, in der ich glaube ich folgendes sinngemäß über den Quickshot II lesen durfte: „Der perfekten Positionierung der beiden Feuerknöpfe sind zahllose angreifende Aliens zum Opfer gefallen.“ Das war eben noch echter Journalismus.

Das Ende einer Ära

hubersn

Ich habe eine Mail bekommen, die das (für mich traurige) Ende einer Ära verkündet: news.individual.de schaltet zum 30.9.2027 seinen Usenet-Service ab.

Usenet – für die Jüngeren unter uns: Technologie rund um „Newsgroups“, Diskussionsforen, die seit mindestens den 80ern das Internet bevölkerten, als man von HTTP und WWW noch nichts wusste – das war lange Zeit eine echte Zeitsenke für mich. Besonders als Nutzer von RISC OS-Rechnern waren die Newsgroups comp.sys.acorn.* Pflichtlektüre, dort tummelten sich zahllose Experten zu quasi jedem Thema. Am Anfang las ich an der Uni mit dem legendären nn, später dann auf dem heimischen Rechner mit Hilfe von !Rucp und später Taylor UUCP fürs Abholen und Verschicken und !ReadNews, später dann mit !TTFN und noch später (etwa ab 1995) dem genialen !Messenger. Irgendwann dann die Umstellung von UUCP auf NNTP. Vor oder nach dem 14k4-Modem (natürlich von ZyXEL)? Ich erinnere mich nicht mehr.

Lange Zeit fuhr ich diskussionstechnisch sogar zweigleisig: FidoNet und Usenet, die doppelte Dosis sozusagen. !FidoMail von Thomas Olsson war einfach auch ergonomisch ungeschlagen, einige Zeit habe ich sogar für die Mailboxen „The Lost Hope BBS“ (Waiblingen) und „Linemelter BBS“ (Korb) ein Usenet-FidoNet-Gateway betrieben, damit Normalos als Fido-Point oder mit dem QWK-Offline-Reader auch Newsgroup-Inhalte lesen konnten. Zur Einordnung: es war die Zeit der 2400bps-Modems, als man noch drüber nachdachte, ob man MNP5 aktiviert oder nicht.

Yeah, QWK und FidoNet und UUCP und NNTP und Newsgroups und Modems und MNP5. Alte Männer erzählen Geschichten von früher. Es würde mich freuen, mal wieder was von den damaligen Kontakten zu hören.

30 Jahre Java – Erinnerungen eines alten Sacks

hubersn

Java hat kürzlich („kürzlich“ im Kontext dieses Blogs zu verstehen, wo Ereignisse gerne mal ein paar Monate bis Jahre später kommentiert werden) sein 30-jähriges Jubiläum gefeiert. Am 23. Mai 1995 erblickte das erste Release das Licht der Welt. Ich weiß noch wie heute, als ich…nein, das ist gelogen. Ich weiß nicht mal mehr, wann ich mein erstes Java-Programm wirklich mit dem JDK compiliert habe, und was es gemacht hat (ich vermute, ein Fenster per AWT geöffnet) – aber es war das JDK Version 1.0.2. Müsste ich noch auf irgendeiner CD rumliegen haben.

Mein erster Eindruck von Java war sehr gemischt. Ich kannte – im Sinne von „seriös benutzt“, nicht nur „mal gesehen“ – damals verschiedene BASIC-Dialekte, Z80- und ARM-Assembler, Smalltalk, C, C++ (CFront-Variante, Stand 1994 oder so), Turbo Pascal (inklusive der OO-Features von TP 5.5), Modula-2, Ada 83 und Ada 9X, Scheme, Lisp und Prolog. An Java gefielen mir die Interfaces, die Idee mit JavaDoc, das AWT als Chance für „write-once-run-anywhere“ auch für Anwendungen mit grafischer Oberfläche, die umfangreiche (was eben damals als umfangreich durchging…) Systembibliothek, und die prinzipielle Idee der JVM als abstrahierende, portierbare Runtime. Und natürlich der Garbage Collector. Auch die Applets, um dem drögen statischen HTML-Content endlich etwas Interaktivität beizubringen erschien als coole Idee. Unicode-out-of-the-box war sicher auch eine bemerkenswerte Idee. Und die integrierten Mechanismen zur Serialisierung von Objekten klangen auch cool. Und die vier Levels der Sichtbarkeit fanden auch mein Gefallen. Reflection schien Potenzial zu haben, auch wenn ich damals noch nicht ahnte, was man damit alles veranstalten kann. Und die Java-Variante der Exceptions fand ich cooler als die Ada-Variante, weil Java den Programmierer zu „throws“-Klauseln zwang, während bei Ada im Prinzip alles RuntimeExceptions waren und separat, also nicht erzwungen im Code, dokumentiert werden mussten – und bekanntlich laufen Code und Doku gerne mal auseinander.

Aber da war auch die andere Seite. Das Multithreading war löblich, aber gegenüber dem Tasking aus Ada doch sehr rudimentär – auf der anderen Seite aber auch ein – wenn auch unnötig kleiner – Fortschritt gegenüber pthreads. Die Basisdatentypen waren zwar Gott sei Dank genau spezifiziert (was in C bezüglich der Portabilität immer zu Schwierigkeiten führte, wenn man nicht höllisch aufpasste), aber sehr leistungsarm gegenüber beispielsweise Ada. Kein Operator Overloading. Records mussten durch Klassen abgebildet werden und hatten keine Kontrolle über die Repräsentation im Speicher. Arrays begannen immer mit Index 0. Die direkt von C übernommenen Misfeatures – == als Gleichheitsoperator und = als Zuweisung, nur short-circuit-Logik, das oberdämliche switch-case-Konstrukt – wir breiten den Mantel des Schweigens darüber. Keine Syntax für Methode-in-Methode. Kein Datentyp für Aufzählungen. Die merkwürdige Mischung aus „alles ist ein Objekt, außer Basisdatentypen“. Keine Generics wie in Ada oder C++, so dass man wieder auf Runtime-Typechecking statt Compile-Time-Safety angewiesen war. Der Interpreter der JVM ging eher gemächlich zu Sache. Der GC ebenso. Threads waren keine nativen OS-Threads, sondern wurden von der JVM simuliert („green threads“). Startup von Anwendungen war sehr gemächlich. Und das AWT war wirklich „kleinster gemeinsamer Nenner“ und mit dem Java 1.0-Sprachumfang, der bekanntlich weder innere Klassen noch deren anonyme Ausprägung unterstützte, sehr „harzig“ zu benutzen, weil man kein Event-Listener-Konzept hatte mit Callbacks, sondern im Prinzip alles ableitete und die entscheidenden Methoden überschreiben musste.

„Gemischt“ war auch das Stichwort zur Einschätzung der Lage beim damals tobenden Streit „curly-braces vs. begin-end“. Ich fand begin-end nach Pascal- oder Modula-Art nicht so gut, nach Ada-Art aber super. Und das Fehlen von Mehrfachvererbung hat auch sein Für und Wider, die Erfindung der Interfaces schien aber den Mangel ausreichend abzumildern.

Nach diesem ersten durchwachsenen Eindruck legte ich Java erst mal wieder beiseite. Im Endstadium meines Informatik-Studiums hießen die Programmiersprachen der Wahl DEC Pascal (Ada-ähnlich) in der Studienarbeit, C++ (mit dem IBM XLC als Compiler auf AIX, der leider die neuen coolen C++-Features allesamt vermissen ließ) in der Diplomarbeit, und Ada 95 für mein privates Großprojekt CDBurn. Die Idee des „Java-NC“ bzw. des ThinClients generell setzte sich nicht durch, obwohl es mit Erscheinen von Java durchaus größere Aktivitäten von großen Softwarehäusern gab, relevante Softwarepakete nach Java zu überführen. Ich nenne mal Corel Office als prominentes Beispiel. Es war schon beeindruckend zu sehen, dass WordPerfect plötzlich auf dem RISC OS-Desktop lief, und das alles bloß aufgrund der Verfügbarkeit einer Java-Runtime. Aber genau wie der Java-Prozessor von Sun und CPU-Features wie Jazelle von ARM für die beschleunigte Ausführung von Bytecode setzte sich das nicht durch. Die Zeit war noch nicht reif, die CPUs noch nicht schnell genug, die JVM noch zu lahmelig. Zuviele Abstraktionsschichten sind des Performancempfindens‘ Tod. Software als Sanduhr-Anzeige-Programm. Die Älteren fühlten sich bezüglich der fehlenden Schwuppdizität an Emacs erinnert („Eight Megabytes And Constantly Swapping“).

Aber ich hatte weiter ein Auge auf Java und nahm erfreut zur Kenntnis, dass einige wichtige Sprachfeatures in Java 1.1 nachgerüstet wurden – Stichwort innere Klassen und anonyme innere Klassen, die für die neue AWT- und Swing-Event-Listener-Mechanik essentiell waren – und an der Browser-Front Java 1.1 quasi serienmäßig zur Ausführung von Applets eingebaut wurde – HotJava und Internet Explorer waren die Vorreiter, für alle anderen gab es das Java-PlugIn. Dass Netscape dann mit „JavaScript“ etwas Verwirrung stiftete und Microsoft die übliche Embrace-and-extend-Strategie versuchte, waren bemerkenswerte aber letztlich irrelevante Randnotizen der Geschichte. Ende 1997 war auch noch das Release von Java 1.0.2 für RISC OS bemerkenswert (offiziell von Sun lizenziert und von Acorn implementiert), und Chockcino als clean-room-Java-1.1-Implementierung wurde angekündigt – in der damaligen Welt, als viele Homebanking-Lösungen auf Java 1.1-Applets setzten, war es überaus enttäuschend, dass diese Ankündigung niemals wahr wurde. Ein weiterer Sargnagel für RISC OS.

Mit Java 1.1 begann Sun auch endlich, an der Ablösung bzw. Ergänzung des leistungsschwachen AWT zu arbeiten. „Swing“ war in aller Munde, und mit Swing 1.0.2 („com.sun.java.swing“) und erst recht mit Swing 1.1.1 („javax.swing“) konnte man endlich mit einem reichhaltigen, leistungsfähigen Werkzeugkasten plattformübergreifend UIs bauen. Swing wurde damals, wohl um den Zusammenhang zu MFC, den „Microsoft Foundation Classes“, dem damaligen Benchmark für UI-Klassenbibliotheken, „JFC“ genannt – die „Java Foundation Classes“. Genaugenommen umfasste das AWT, Swing und Java2D. Und wir lernten damals, dass „lightweight“ nicht unbedingt in allen Kontexten für „schnell und speicherplatzsparend“ steht.

Ende 1998 dann das Release von Java 1.2, ein echter Meilenstein, und deshalb zurecht „Java 2 Platform“ genannt. Das Collection-Framework war ein riesiger Fortschritt (vorher war entweder „Vector“ oder „Hashtable“ allüberall genutzt), und Swing war nun endlich integrierter Teil des JDK. Allerdings dauerte es ein wenig, bis alles wirklich stabil und gut war – Java 1.2.2 war schließlich die Version der Wahl ab Mitte 1999. RMI wurde nutzbar (wenn auch umständlich mit rmic und stubs und skeletons), JIT und GC wurden performanter, das Plugin etablierte sich als Ausführungsumgebung in allen gängigen Browsern.

Ich will nicht durch alle Java-Meilensteine durchgehen, das dauert Stunden und kann auch von ChatGPT erzeugt werden. Aus der Praxis kann ich noch berichten, dass Java bei meinem ersten Arbeitgeber Anfang 1999 als Mittel der Wahl für die Implementierung eines großen Softwaresystems auserkoren wurde. Eine Entscheidung mit erheblichem Risiko damals. Hauptgründe für Java damals: die starke Unterstützung von IBM und damit die versprochene Verfügbarkeit von Integrationscode für Großrechner-Technologien wie MQ, CICS und IMS. Und die Cross-Platform-UI-Geschichte, weil die ersten drei interessanten Kunden drei verschiedene Client-Technologien am Start hatten: Windows, OS/2 und Linux (sowohl x86 als auch PowerPC). Im Nachhinein, nachdem die Software nun etwa 25 Jahre in Produktion ist, kann man wohl sagen: es war die richtige Wahl. Die Software lief erfolgreich produktiv auf Servern aller Art, von Windows über Linux und Solaris bis zu AIX. Clientseitig auf Windows, OS/2 und Linux sowohl als FatClient als auch als WebStart-Anwendung und natürlich auch lange als Applet, in einem Fall voll integriert in eine Kunden-Fachanwendung mit speziell gedengeltem Swing-L&F, so dass der „Bruch“ im Browser zwischen den beiden Anwendungen praktisch unsichtbar wurde. Erwähnenswert zum Start der Entwicklung 1999: wichtige Maßgabe am Anfang war die Anforderung eines potenziellen Kunden, dass der Code (zumindest der Client-Code für die UI) auch unter Java 1.1 laufen muss. Ich vermute, dass man deshalb noch in einzelnen Teilen des Sourcecodes einen „Vector“ findet, der Objekte per „addElement“ bekommt.

Ebenfalls erwähnen will ich „IBM VisualAge for Java“ als meine erste Java-IDE. Positiv zu nennen: es war der Grund für den Chef, für die Entwickler-Rechner die damals nahezu als „unendlich“ kategorisierte Menge von 256 MB RAM zu spendieren (AMD K6-II damals als CPU, Windows NT 4 als OS). Und das war auch dringend nötig. Die IDE war schneckenlahm, ein in Smalltalk geschriebenes Monster, und die Idee, den Code nicht im Dateisystem zu haben sondern in einem „Repository“, das im Prinzip eine Datenbank war, und dann nur per Import und Export wieder Dateien draus zu machen – gewöhnungsbedürftig. Genauso wie die Tatsache, dass die Suchfunktion nicht alle Fundstellen tatsächlich gefunden hat. Und der VCE, der „Visual Component Editor“, war mein erster Versuch mit einem GUI-Builder. Er war optimal geeignet, schon damals meine Überzeugung zu befüttern, dass GUI-Code, zumindest wenn das Layout dynamisch per LayoutManager gemacht werden soll, am besten von Hand geschrieben wird. Der eigentliche Grund, VisualAge zu verwenden – das IBM-Versprechen, in der „Enterprise-Edition“ diverse Großrechner-Integrationsbausteine einfacher verwenden zu können – war alsbald als vage Marketing-Idee entlarvt, und die Entwickler entschieden sich für Forte4Java (eine freie Version von NetBeans, damals von Sun entwickelt), JBuilder oder UltraEdit, bis sich dann alle wieder bei Eclipse 2.1 zusammenfinden konnten.

Es gab einige kritische Momente in der Java-Geschichte – die Anwandlungen von Microsoft, einen inkompatiblen Ableger zu schaffen. Die schleppende Weiterentwicklung, auch durch die finanziellen Probleme von Sun. Der beschwerliche Weg in die vollständige Open-Source-JDK-Welt von heute. Die Übernahme durch Oracle und so manche Detailverwirrung bei der Lizenzierung. Undurchschaubare Strategiewechsel bei Oracle. Aber letztlich waren das – allen Unkenrufen, auch von mir, zum Trotz – nur kurzfristige Irritationen.

Interessant in der langen Java-Geschichte finde ich den „ersten Wendepunkt“: von Konstruktion und Features her startete Java ja, obwohl in einer Server-lastigen Firma erfunden, mit starkem Client-Fokus. Fast, als ob die Erfinder dringend Microsoft ans Bein pinkeln wollten. Irgendwann, so ab Java 1.3, drehte sich das dann – auch dank Java EE und Application Servern und der Verfügbarkeit performanter JREs auf allen relevanten Plattformen – nahezu komplett in Richtung Server und Enterprise, während der Client mehr und mehr aufs Abstellgleis geschoben wurde. Und später ironischerweise durch Google mit Android und GWT wiederbelebt wurde. Man könnte sicher interessante historische Abhandlungen drüber schreiben.

Heute würde ich Java als „lebendiger denn je“ bezeichnen. Der Hotspot-JIT erzeugt sehr effizienten Code (wenn er lange genug läuft), die Garbage-Collectors sind effizient auch bei unglaublich großen Heaps und haben inzwischen unglaublich kurze STW-Zeiten, und das Tooling ist generell sehr ausgereift, dazu die Auswahl an zig stabilen und leistungsfähigen Frameworks. Die neue „release cadence“ sorgt für rasche – manchmal für mich fast zu rasche – Weiterentwicklung der Sprache, ohne die so identitätsstiftende Rückwärtskompatibilität aus den Augen zu verlieren. Es ist schon bemerkenswert, dass man heute ohne größere Handstände immer noch Java 8-Code schreiben kann, der auch problemlos noch unter Windows XP lauffähig ist. Sprachen, die Java beerben wollten wie Scala oder Kotlin sind letztlich nur Ergänzungen des JVM-Ökosystems geworden, dank der inzwischen raschen Weiterentwicklung von Java aber aus meiner Sicht außerhalb ihrer Nische eher als Ideengeber relevant. Und dank neuerer Entwicklungen wie der direkten Ausführbarkeit von Java-Files ohne vorherigen Compile-Schritt und der diversen Vereinfachungen unter dem Schlagwort „simple onramp“ nebst coolem Tooling wie JBang ist Java inzwischen selbst für Aufgaben, die klassischerweise mit dedizierten Skriptsprachen erledigt wurden, eine interessante Alternative. Keine andere Sprache ist ähnlich universell einsetzbar. Manche Sprachen sind in speziellen Bereichen die bessere Wahl, aber keine andere Sprache ist in so vielen Bereichen „good enough“, vom einfachen Skript bis zur Enterprise-Anwendung, vom Microservice bis zur FatClient-Applikation.

Und seit ich regelmäßig Konferenzvorträge von Brian Goetz schaue, habe ich auch großes Vertrauen, dass die Sprache Java weiterhin mit Augenmaß, aber kontinuierlich weiterentwickelt wird.

Wer anderer Leute „trip down the memory lane“ lesen/schauen will: der offizielle Geburtstagslivestream, die JetBrains-Jubiläums-Seite, und interessante Erinnerungsstücke bis zurück in die Gründerzeit von BellSoft-Mitarbeitern.