Wir präsentieren Ihnen ein Interview mit Simon Ritter, dem Mann, der von Anfang an an Java gearbeitet hat und dies auch weiterhin als stellvertretender technischer Direktor von Azul, dem Unternehmen, das an der virtuellen Maschine Zing JVM arbeitet, und einem der besten Müllsammler, C4 (Continuously Concurrent Compacting Collector), tut.
- Ein Leben lang mit Java;
- Wie Sie als CTO auf dem neuesten Stand von Fortschritt und Code bleiben;
- Beste und schlechteste JDK-Funktionen;
- Mitglied des Java Community Process Executive Committee;
- Ist es nicht beängstigend, etwas global zu brechen?
- Übergang zu JDK 11/12;
- Unterstützungspreis für OpenJDKs eigene Gabel;
- C4 & Falcon gegen Shenandoah & Graal;
- Benötigen Sie einen leistungsstarken Sammler in der Welt der Microservices?
- Das Schicksal der Anwendungsserver Java EE / Jakarta EE und JavaFx;
- Reise nach Russland und ein neuer Bericht über JPoint.
LegendeSimon - Simon Ritter, stellvertretender CTO von Azul Systems;
Eugene - Eugene
Phillennium Trifonov, Journalist bei der JUG.ru Group;
Oleg - Oleg
olegchir Chirukhin, Journalist bei der JUG.ru Group;
Eugene: Können Sie uns etwas über Ihre Karriere erzählen, bevor Sie Azul's stellvertretender CEO wurden? Insbesondere frage ich mich, wie Sie zu Sun Microsystems gekommen sind.
Simon: Ich habe bereits eine sehr lange Karriere - ich habe 1987 die Universität abgeschlossen. Zuerst war ich in einer kleinen Firma hier in Großbritannien an UNIX beteiligt. Dann arbeitete er an dem Ort, an dem UNIX tatsächlich erfunden wurde - bei Bell Labs. Vier Jahre später wurde Bell Labs von Novell übernommen und ich wurde UNIX-Berater bei Novell. Zwei Jahre später wurde dieser Teil ihres UNIX-Geschäfts von Santa Cruz Operations gekauft, und zu diesem Zeitpunkt entschied ich, dass ich etwas anderes tun wollte. 1996 kam ich zu Sun Microsystems. Nur zwei Wochen später, im Februar 1996, wurde JDK 1.0 veröffentlicht. Zuerst arbeitete ich an Dingen, die mit Solaris und UNIX zu tun hatten, stellte jedoch schnell fest, dass Java das Neueste und Interessanteste war. Ich war Entwickler und Berater, und 1999 wurde ich IT-Evangelist, mit anderen Worten - Developer Advocate, und das seit 20 Jahren. Im Jahr 2010 kaufte Oracle Sun und in den nächsten 5 Jahren war ich der Leiter des evangelischen Teams. Im Jahr 2015 entschied Oracle, dass keine Entwickleranwälte mehr benötigt werden, und ich wurde entlassen. Zu dieser Zeit war die vernünftigste Entscheidung, nach Azul zu kommen, was ich auch tat. Seitdem habe ich meine Entscheidung nicht bereut, weil ich weiterhin das tue, was mir am besten gefällt - Menschen über Java erzählen, reisen, interessante Menschen treffen und neue Technologien ausprobieren. Wenn Sie nicht auf Details eingehen, sieht meine Karriere so aus.
Eugene: Das klingt beeindruckend. Von den Leuten, die ich kenne, sind Sie wahrscheinlich der einzige, der seit Version 1.0 an der Entwicklung von Java teilgenommen hat. Ich frage mich, wie sie damals ausgesehen hat. Soweit ich weiß, galt es damals als Sprache für Mikrowellen und dergleichen. Es stimmt?
Simon: Jetzt ist es wirklich interessant, sich an den Anfang der Geschichte von Java zu erinnern. Dann konzentrierten sich die Entwickler hauptsächlich auf Desktop-Anwendungen, Applets und Dinge, die in einem Browser ausgeführt werden können. Dann kam die Idee, eine Version für Mobiltelefone zu entwickeln, und Java ME entstand. Die Bedeutung von Java Enterprise Edition hat im Laufe der Jahre zugenommen. Mit ihm können Sie komplexere Websites mit Online-Einkaufswagen und Kreditkartenzahlungen schreiben.
In den ersten Versionen von Java waren die Bibliotheken sehr begrenzt, und eine der wichtigsten Änderungen im Zuge des Projektwachstums war das Auftreten großer Basisbibliotheken. Ich spreche oft in meinen Präsentationen über diese Entwicklung. In JDK 1.0 standen Entwicklern 211 öffentliche Klassen zur Verfügung, und in rt.jar von JDK 8 gab es 4,5 Tausend öffentliche Klassen. Dies ist einer der Gründe für die Beliebtheit von Java: Der Programmierer muss ArrayList oder Semaphore schreiben, und es ist einfach, über JDBC eine Verbindung zu Datenbanken herzustellen.
Eugene: Java ist sicherlich eine ausgezeichnete Sprache, aber Fehler sind unvermeidlich, wenn ein Projekt dieser Größe entwickelt wird. Manchmal kann man das Bedauern von Java-Entwicklern hören, dass diese oder jene Funktion anders implementiert werden musste. Haben Sie diese Art von Bedauern?
Simon: Dies ist keine einfache Frage, aber Sie können hier wahrscheinlich über die Abwärtskompatibilitätsrichtlinien von Sun und Oracle sprechen. Jede Java-Anwendung kann mit einer späteren Version von Java ohne Neukompilierung gestartet werden. An sich ist dieser Ansatz durchaus sinnvoll: Wenn die Anwendung bereits ausgeführt wird, zwingen Sie die Benutzer nicht dazu, zusätzliche Anstrengungen zu unternehmen. Aber hier ist es wichtig, nicht zu weit zu gehen. Erinnern Sie sich daran, wie Generika in Java SE 5 hinzugefügt wurden. Ohne Typlöschung konnte keine Abwärtskompatibilität festgestellt werden, sodass alte Typen in Form von Rohtypen in der Klassendatei verbleiben konnten. Eine Alternative dazu waren reifizierte Generika, mit denen zur Laufzeit Parameter wie Generika verfügbar sind. Aus meinen Gesprächen mit Brian Goetz weiß ich, dass er kein großer Befürworter dieses Ansatzes ist, obwohl ich seine Worte vielleicht nicht ganz richtig interpretiere. Auf die eine oder andere Weise glaube ich, dass dies genau die Situation ist, in der ein Verstoß gegen die Abwärtskompatibilität hätte erfolgen müssen. Dann könnten Generika vertrauter eingesetzt werden.
Auch einige weniger wichtige Entscheidungen waren meines Erachtens nicht ganz erfolgreich. Wir haben begonnen, veraltete APIs nur in JDK 9 zu entfernen - ich denke, es war zu spät. Es war notwendig, kontrollierte Reinigungen mit einem Minimum an Störungen des bestehenden Codes durchzuführen. Im Allgemeinen könnten einige Dinge wirklich etwas anders gemacht werden. Aber insgesamt haben die Java-Entwickler natürlich eine großartige Sprache entwickelt.
Eugene: Viele stimmen Ihnen hinsichtlich der Abwärtskompatibilität und ihrer Einschränkungen zu. Java wird manchmal als zu konservativ angesehen.
Oleg: Übrigens, wenn die Änderungen bei Generika wirklich radikaler wären, müssten alle Anwendungen im Ökosystem an einem Tag neu kompiliert oder sogar geändert werden. Dies wäre wahrscheinlich nicht die vernünftigste Entscheidung.
Simon: Meiner Meinung nach ist das Neukompilieren des Codes keine sehr strenge Anforderung. Wenn es notwendig ist, komplexe Änderungen vorzunehmen, ist dies natürlich eine ganz andere Sache. Ich denke, man kann endlos darüber streiten, welcher Ansatz besser ist.
Oleg: Unsere Abonnenten wissen bereits viel über Interviews und Reden auf Konferenzen von Ihnen. Es ist jedoch wenig darüber bekannt, was Sie gerade in Azul tun. Können Sie uns etwas über Ihre aktuellen Aktivitäten erzählen?
Simon: Der Titel meines Postens ist der stellvertretende Generaldirektor, aber dies beschreibt nicht ganz genau, was ich tue. Wie zuvor in Oracle und Sun erkläre ich den Leuten genau, wie mein Unternehmen und Java im Allgemeinen ihnen helfen können. Ich muss sagen, dass Azul neben Java nichts mehr tut. Wir haben ein Zulu OpenJDK und eine kommerzielle Zing JVM mit einer alternativen Garbage Collection-Methode und unserem eigenen JIT-Compiler. Im Allgemeinen fördere ich die Verbreitung von Java und bevorzuge unsere Version. Zu diesem Zweck spreche ich häufig auf Konferenzen. Aber beim Azul-Ansatz gefällt mir, dass sie der Förderung von Java im Allgemeinen und nicht nur ihrem Produkt große Aufmerksamkeit widmen. Dank dessen kann ich Kurse zu Lambda-Ausdrücken und -Streams geben, in meinen Reden über neue Funktionen von JDK 11 sprechen, wie man lokale Typinferenz verwendet und so weiter.
Wenn wir über die Unterschiede zu früheren Aktivitäten sprechen, dann schreibe ich jetzt erstens viel mehr Artikel und Beiträge als zuvor. Zweitens kommuniziere ich viel mehr mit Kunden. Dies ist jedoch hauptsächlich eine Diskussion über technische Probleme. Ich helfe ihnen zu verstehen, wie Zing, der C4-Garbage Collector oder der Falcon JIT-Compiler funktionieren. Ich mache keine Verkäufe.
Oleg: Es versteht sich von selbst, dass Sie nicht Ihre ganze Zeit der Programmierung widmen können. Wie schaffen Sie es, mit der Entwicklungswelt in Kontakt zu bleiben? Schreiben Sie überhaupt, lesen Sie technische Artikel?
Simon: Natürlich, und für mich ist es sehr wichtig, über die neuesten Änderungen auf dem Laufenden zu bleiben. Die Tatsache, dass Azul Mitglied der JCP ist, hilft mir sehr und ich vertrete Azul im Exekutivkomitee. Dort kommuniziere ich mit anderen Vertretern und sehe, in welche Richtung sich Java entwickelt. Außerdem bin ich Teil der Java SE-Expertengruppe für JSRs, die erstellt werden. Dies hilft auch, die laufenden Änderungen zu verstehen. Als nächstes ist Azul aktiv an OpenJDK beteiligt, was mir zusätzliche Sichtbarkeit gibt. Außerdem lese ich technische Artikel und spreche viel mit Bekannten von Oracle, um mir ein Bild davon zu machen, was im Unternehmen passiert.
Und natürlich schreibe ich Code und versuche es jeden Tag. Das funktioniert zwar nicht immer, aber ich glaube, wenn Sie mit Leuten über Programmierung kommunizieren, müssen Sie selbst schreiben. Normalerweise arbeite ich an Projekten mit Funktionen, die wir in Betracht ziehen, beispielsweise mit Modulen. Vor einiger Zeit schrieb ich einen Beitrag darüber, wie man mit jlink Anwendungslaufzeiten ohne Module in der Anwendung erstellt. Dazu musste ich natürlich jlink herausfinden und es selbst im Code verwenden. Das Programmieren hat also immer noch einen sehr wichtigen Platz in meiner Arbeit.
Oleg: Stellen wir uns vor, Sie haben eine Supermacht, mit der Sie eine Funktion aus Java entfernen und eine andere hinzufügen können. Was würdest du wählen?
Simon: Das ist eine schwierige Frage. Es ist einfacher zu sagen, welche Funktion mein Favorit sind Lambda-Ausdrücke und Streams, dank derer Sie in einem funktionaleren Stil schreiben können. Mit dieser Funktion haben Brian Goetz, Stuart Marx und ihr gesamtes Team hervorragende Arbeit geleistet. Zwar klingt hier manchmal auch Kritik, insbesondere für Optionals, aber dies sind bereits Details.
Es ist viel schwieriger zu sagen, was mir an Java am wenigsten gefällt. Es scheint mir, dass die Ausnahmebehandlung nicht auf einfachste Weise organisiert ist. Streitigkeiten über sie und ihre Implementierung in Java haben lange gedauert und sie verursachen wirklich einige Schwierigkeiten. Wenn zum Beispiel eine Ausnahme in einem Lambda-Ausdruck auf Sie geworfen wird, können Sie sie nicht außerhalb des Streams abfangen - das ist es normalerweise wert, getan zu werden. Sie müssen auf jeden Fall die Ausnahme innerhalb des Lambda-Ausdrucks abfangen. Daher sind Lambdas selbst meine Lieblingsfunktion in Java, und die Behandlung von Ausnahmen in ihnen verursacht im Gegenteil die negativsten Emotionen.
Oleg: Sie haben das JCP-Exekutivkomitee erwähnt. Wie genau verläuft die Aktivität? Haben Sie ein eigenes Versammlungsgebäude, eine Art „Weißes Haus“ wie eine echte Regierung?
Simon: (lacht) Ich denke, wir sind eher wie ein Normungsausschuss. Wir halten regelmäßige Treffen ab, aber meistens finden sie in Form von Telefonkonferenzen statt. Drei- oder viermal im Jahr versammeln wir uns im selben Raum und besprechen ein oder zwei Tage lang Dinge wie JSR. Wir haben kein ständiges Büro, alle Treffen werden von verschiedenen Unternehmen auf freiwilliger Basis organisiert. In Großbritannien wurden sie von IBM, in Bulgarien - von SAP - gehostet, und in naher Zukunft wird es ein von Fujitsu organisiertes Treffen in Japan geben. Dieses System ist großartig für uns und die Veranstaltungen selbst sind normalerweise sehr freundlich. Natürlich gibt es Streitigkeiten, aber im Großen und Ganzen besteht das Komitee aus großartigen Menschen.
Oleg: Und Sie als Mitglied der Expertengruppe haben keine Angst, neue Funktionen hinzuzufügen? Immerhin ist Java ein sehr komplexes System, man kann versehentlich alles kaputt machen.
Simon: In den letzten zwei bis drei Jahren hat sich die Funktionsweise der Expertengruppe erheblich verändert. Früher hat Sun den Quellcode geöffnet und OpenJDK erstellt. Jetzt leitet es zunehmend die Entwicklung von Java als Ganzes. Spezifische Funktionen werden über JEP (JDK Enhancement Proposal) angeboten. Manchmal kommen diese Angebote von außen - von Azul, Red Hat, IBM und sogar Google. Letztendlich gehört die Kontrolle jedoch immer noch Oracle: Sie erledigen den größten Teil der Arbeit und bestimmen die Entwicklungsrichtung. Oracle besitzt die Funktion einer Art Treuhänder, Sprachverwalter. Dank ihnen erfolgt die Einführung neuer Funktionen in geordneter Weise, sie versuchen, nicht unnötig zu hetzen. Jetzt wird alle sechs Monate eine neue Version veröffentlicht, und ich stelle fest, dass die Entwickler keine Angst haben, die Funktion auf die nächste Version zu verschieben, wenn sie noch nicht in den Sinn gekommen ist. Ich mag diesen verantwortungsvollen Ansatz sehr. Ein gutes Beispiel dafür ist JDK 12, das nächsten Monat herauskommt. Anfangs wollten sie String-Literale aufnehmen, entschieden dann aber, dass sie weiterentwickelt werden mussten.
Simon und ich haben vor einem Jahr JBreak Java-Konferenzen besucht
Oleg: Haben Sie und Ihr Unternehmen bereits auf Java 11 oder 12 umgestellt?
Simon: In meinen Projekten verwende ich oft Java 11, aber dieser Code ist normalerweise nicht für die Produktion gedacht, sondern eher experimentell. Durch meine Gespräche mit Entwicklern auf der ganzen Welt habe ich den Eindruck, dass die Leute allmählich zu JDK 11 wechseln, da dies eine Veröffentlichung mit langfristiger Unterstützung ist. Natürlich müssen wir bedenken, dass diese Unterstützung jetzt unter anderen Bedingungen als zuvor bereitgestellt wird. Für die kommerzielle Nutzung müssen Sie jetzt bezahlen. Es gibt Unternehmen, die denselben Release-Zeitplan wie Oracle verwenden. Dies ist Azul, AdoptOpenJDK, Amazon Coretto. Sie erwarten, dass JDK 11 langfristig unterstützt wird und JDK 17 die nächste langfristige Version sein wird. In der Regel sind die Benutzer nicht bereit, alle sechs Monate ein Upgrade auf eine neue Version durchzuführen, insbesondere in der Produktion. Startups können dies möglicherweise, aber die meisten kommerziellen Benutzer benötigen Stabilität. Zumindest ist es jetzt so.
Oleg: Soweit ich weiß, verwendet AdoptOpenJDK übrigens keine TCK-Tests . Da Tests immer noch notwendig sind, bieten sie andere Ansätze an, über die sie auf der letzten FOSDEM-Konferenz gesprochen haben, verschiedene verrückte Dinge wie maschinelles Lernen . Zu diesen Ansätzen gehörten radikale Dinge wie maschinelles Lernen. Haben Sie große Anstrengungen unternommen, um Ihre OpenJDK-Gabel zu warten?
Simon: Eigentlich ist es nicht so schwierig. Es stimmt, sowohl Zeit als auch Infrastruktur werden benötigt. AdoptOpenJDK wird von verschiedenen Sponsoren gesponsert, darunter Azul. Das Erstellen eines eigenen JDK ist einfach genug, Build-Skripte funktionieren gut. In dieser Hinsicht hat sich die Situation im Vergleich zu der Zeit, als OpenJDK gerade geboren wurde, erheblich geändert. Als Nächstes müssen Sie entscheiden, ob Sie den Java SE-Standard einhalten müssen. Dafür brauchen wir nur TCK. Sie können Oracle TCK kostenlos erhalten, wenn Sie nur Ihr OpenJDK erstellen möchten. Ich weiß nicht genau, warum AdoptOpenJDK keine TCK-Lizenz besitzt. Ich denke, das liegt daran, dass sie gleichzeitig ein OpenJ9-Projekt für IBM erstellen. Ein Projekt kann TCK nur erhalten, wenn es hauptsächlich auf OpenJDK basiert. Dies ist meine Vermutung, aber wenn Sie sicher wissen wollen, müssen Sie die Entwickler von AdoptOpenJDK selbst fragen. Auf die eine oder andere Weise können sie jetzt nicht mehr sicherstellen, dass ihr Design dem Java SE-Standard entspricht. Da der Code, auf dem sie basieren, eine Referenzimplementierung ist, entspricht er höchstwahrscheinlich diesem Standard, aber ohne TCK haben wir kein genaues Vertrauen. Aber AdoptOpenJDK hat viele andere Tests, die im Grunde überprüfen, wie Anwendungen auf dem JDK ausgeführt werden. Das heißt, dies ist ein Test auf hoher Ebene und nicht nur die Überprüfung der Einhaltung des Standards.
Oleg: Azul hat eine eigene OpenJDK-Distribution, Zulu. Kannst du etwas über ihn erzählen? Ist es Open Source? Was ist der Unterschied zwischen ihm und allen anderen?
Simon: Zulu hat zwei Versionen - Community Edition und Enterprise Edition. Im Großen und Ganzen ist dies der gleiche Ansatz wie bei Red Hat. Community Edition ist eine offene Version, die von unserer Website heruntergeladen werden kann. Es ist unter GPLv2 mit Classpath Exception lizenziert, d. H. Wie OpenJDK, sodass Sie es nach Belieben verwenden können. Diese Version bietet jedoch keine kommerzielle Unterstützung. Die Zulu Enterprise Edition richtet sich an große Unternehmen, die kostenpflichtigen Produktsupport benötigen. Es gibt einen Unterschied zwischen diesen Versionen, wie Updates durchgeführt werden. Für die Enterprise Edition führen wir selbst Backports durch. Wenn Oracle ein Update für die nächste Version des JDK veröffentlicht, z. B. 12 oder 13, stellen wir es sehr schnell für die Versionen 8, 7 und sogar 6 von Zulu Enterprise zur Verfügung. In der Community Edition nehmen wir einfach den OpenJDK-Quellcode und kompilieren ihn. Wenn die Korrekturen bereits in diesem Code enthalten sind, befinden sie sich in der Community Edition. Wenn jedoch niemand anderes Backports erstellt hat, sind sie auch nicht in der Community Edition enthalten. Meiner Meinung nach ist dies ein vernünftiger Ansatz.
Oleg: In letzter Zeit haben einige Unternehmen Produkte in der Nähe von Azul. Zum Beispiel gibt es jetzt mehrere Low-Pit-Garbage-Collectors, und der Graal JIT-Compiler, ähnlich wie Azul's Falcon, wurde in Oracle Labs erstellt. Können Sie uns sagen, was genau C4 und Falcon sind und was sie von ähnlichen Produkten anderer Unternehmen unterscheiden?
Simon: Beginnen wir mit den Müllsammlern. C4 ist ein Garbage Collector, der im Gegensatz zu herkömmlichen Garbage Collectors wie CMS, G1 usw. nicht die Welt aufhält. Wir arbeiten seit über zehn Jahren an C4. Jetzt funktioniert es sehr stabil und wir verwenden es viel wo. In dieser Zeit sind jedoch tatsächlich mehrere ähnliche Müllsammler unserer Konkurrenten aufgetaucht. Einer dieser Garbage Collectors ist Oracle ZGC, das kürzlich geöffnet wurde und Teil von OpenJDK ist. ZGC hat viele ähnliche Lösungen wie C4. Beispielsweise werden Lesebarrieren anstelle von Schreibbarrieren verwendet, um auf Objekte zuzugreifen. Es funktioniert fast so gut wie bei uns. Das Problem ist jedoch, dass dies ein Open Source-Projekt ist und Oracle es nicht aktiv entwickelt. Soweit ich weiß, planen sie nicht, es in ihre kommerziellen Produkte aufzunehmen, es ist eher experimenteller Natur. Bevor er Open Source wurde, arbeiteten nur zwei Programmierer aus Schweden daran. Hier müssen Sie also vorsichtig sein, da nicht ganz klar ist, wie stabil dieses Projekt ist. Ich habe mit einigen Leuten gesprochen, die ZGC verwendet haben, und es gibt gute Ergebnisse, aber Stabilität lässt zu wünschen übrig - zumindest würden sie es nicht in einer kommerziellen Anwendung verwenden.
Shenandoah ist ein Red Hat Müllsammler. Es konzentriert sich auf Anwendungen mit großen Heaps, mindestens 20 Gigabyte, während Zing eine minimale Heap-Größe von einem Gigabyte hat. Shenandoah befindet sich noch in der Entwicklung und ist schon lange in Betrieb. Christine Flood und Alexei Shipilev arbeiten daran, beide kennen sich auf ihrem Gebiet gut aus. Soweit ich weiß, verwendet Shenandoah derzeit einen Stapel mit einer einzigen Generation. Die aktuellen Ergebnisse zeigen, dass ein traditioneller Ansatz erfolgreicher wäre, d.h. mehrere Generationen. Höchstwahrscheinlich gibt es noch etwas zu tun. Shenandoah ist jetzt Teil von OpenJDK 12 als experimentelles Feature, was großartig ist, da es den Benutzern die Wahl lässt. Von unseren Kunden hat bisher niemand zu Shenandoah oder ZGC gewechselt. Vielleicht möchte jemand dies in Zukunft tun.
Bei den JIT-Compilern wollten wir den von ihnen generierten Code verbessern und konzentrierten uns zunächst auf den C2-Compiler. Aber C2 ist bereits mehr als 20 Jahre alt und es ist ziemlich schwierig geschrieben, es wird schwierig sein, es zu modifizieren. Wir haben uns auch LLVM angesehen, ein Open-Source-Projekt, das sich mit Compilern befasst. Wir haben ihren Quellcode genommen und in die JVM integriert. LLVM führt hauptsächlich eine statische AOT-Kompilierung durch. Wir haben diese Technologie für die JIT-Kompilierung verwendet. Da wir angesehene Mitglieder der Open Source-Community sind, haben wir diese Änderungen dem LLVM-Projekt hinzugefügt. Wir haben eine sehr elegante modulare Struktur, dank der es einfach ist, neue Funktionen hinzuzufügen, so dass Sie neue Eigenheiten, neue Module usw. hinzufügen können. Darüber hinaus arbeiten Mitarbeiter von Intel, Sony und Microsoft an LLVM, was uns natürlich sehr hilft. Jedes Mal, wenn wir unseren Quellcode aktualisieren, erhalten wir Leistungsverbesserungen von anderen Personen.
Gehen wir weiter zu Graal. Dies ist ein experimenteller JIT-Compiler, der in Java geschrieben wurde und als Alternative zu C2 konzipiert wurde. In den meisten Fällen liefert Falcon signifikant bessere Ergebnisse als Graal. Der Graal-Compiler ist Teil eines größeren Konzepts, GraalVM. Sie versuchen, einen alternativen Ansatz zu finden, wie Anwendungen darin ausgeführt werden. Es wird nicht nur Java geben, sondern auch andere Sprachen. Generell bin ich froh, dass in dieser Richtung viel geforscht wird und es viele alternative Projekte gibt. Ich denke, niemand möchte, dass wir nur eine Möglichkeit haben, Müll oder JIT-Kompilierung zu sammeln. Die Menschen haben zu Recht die Wahl.
Oleg: Ehrlich gesagt habe ich keine so umfassende Antwort erwartet. Vielen Dank! Jetzt werden viele Berichte über Microservices, Mikroinstanzen in Cloud-Umgebungen und sogar über einfache Cloud-Funktionen erstellt. Ein Viertel von JPoint ist der Jet-Technologie gewidmet. Immer mehr Menschen raten, keine großen Dienste, sondern kleine Instanzen zu erstellen. Für eine kleine Instanz mit einem kleinen Haufen wird jedoch kein leistungsstarker Garbage Collector benötigt. Sie können sogar ultraschnelle Müllsammler verwenden, wie sie von Golang verwendet werden. Was ist die Zukunft von Smart Garbage Collectors und Smart JIT-Compilern? Behalten sie ihre Relevanz?
Simon: Auf jeden Fall. Microservices sind ein interessanter Begriff und meiner Meinung nach nicht ganz richtig. Es wäre richtiger, sie einfach als Dienste zu bezeichnen. — , . , -, . , . Cassandra. — , . . , , .
, , . , . , . , , , . , . , , . , .
, , , , , Golang. JDK 11 Epsilon, . : , , , — ? , , , . , . , — , .
: , ? GlassFish Eclipse. , ?
: , . , , . , , , . , . Kubernetes — , . .
: Eclipse Jakarta EE , — , .. Docker, Kubernetes .. Java ? ? Falcon Arm64?
: , Falcon , . - , LLVM , ARM. , . , .
: , Java Enterprise JavaFX OpenJDK. , ? , , Java EE JavaFX?
: C JavaFX , . , JavaFX 2004 . UI. JavaFX, . , Swing AWT, style sheets, layouts . , JavaFX Java SE, . Oracle , , . , JDK, . JavaFX, , , Gluon. Azul JavaFX Zulu. , .
Java EE, , , JDK 11 java.se.ee — , . JAX-B CORBA, , . JAX-WS . , -, , JDK. . . Maven Central. , Oracle Java. , , , . Java 24 , , . OpenJDK, , . , , .
: , JPoint, , ? ?
: , JPoint. JBreak , . , . , , .
. , . , , 10 , . . , 10 , , - . , , , , , - . , .
, . , , . .
: ?
: , Java , . 9 12, . — Valhalla value types reified generics, Loom fibers. Loom . . Amber, Java . , .
, . , , , LTS . , , - . , . , , , .
JPoint 2019: «JDK 12: Pitfalls for the unwary» «Local variable type inference: Friend or foe?» . , . GraalVM (Thomas Wuerthinger ), Liberica JDK ( ), Excelsior JET ( ), .. JPoint 2019 5-6 , .