Native Compilation in Quarkus - warum es wichtig ist

Hallo alle zusammen! Dies ist der zweite Beitrag aus unserer Quarkus-Reihe - heute werden wir über native Kompilierung sprechen. (Übrigens, registrieren Sie sich und besuchen Sie unser Webinar „ Dies ist das native Java-Framework von Quarkus - Kubernetes “, das am 27. Mai stattfinden wird. Wir werden zeigen, wie Sie bei



Null anfangen oder vorgefertigte Lösungen übertragen können.) Quarkus ist ein auf Kubernetes zugeschnittener Java-Stack. Und obwohl hier natürlich noch viel zu tun bleibt, haben wir viele Aspekte gut ausgearbeitet, einschließlich der Optimierung der JVM und einer Reihe von Frameworks. Eine der Funktionen von Quarkus, die das Interesse der Entwickler geweckt hat, war ein umfassender nahtloser Ansatz, um Java-Code in ausführbare Dateien für ein bestimmtes Betriebssystem (die sogenannte "native Kompilierung") umzuwandeln, ähnlich wie in C und C ++, wo eine solche Kompilierung normalerweise stattfindet am Ende eines Zyklus von Montage, Test und Bereitstellung.

Obwohl die native Kompilierung, wie unten gezeigt, wichtig ist, sollte beachtet werden, dass Quarkus dank der Leistungsverbesserungen, die wir im gesamten Stack implementiert haben, auf dem gängigsten OpenJDK Hotspot Java-Computer wirklich gut funktioniert. Daher sollte die native Kompilierung als zusätzlicher Bonus betrachtet werden, der nach Belieben oder Bedarf verwendet werden kann. In Bezug auf native Bilder verlässt sich Quarkus stark auf OpenJDK. Der Dev-Modus, der von Entwicklern sehr positiv aufgenommen wurde, bietet aufgrund der in Hotspot implementierten Funktionen für die dynamische Codeausführung ein fast sofortiges Testen von Änderungen. Darüber hinaus werden beim Erstellen nativer GraalVM-Images die OpenJDK-Klassenbibliothek und die HotSpot-Funktionen verwendet.

Warum brauchen Sie dann eine native Kompilierung, wenn bereits alles perfekt optimiert ist? Wir werden versuchen, diese Frage unten zu beantworten.

Beginnen wir mit dem Offensichtlichen: Red Hat verfügt über umfangreiche Erfahrung in der Optimierung von JVMs, Stacks und Frameworks während der Entwicklung des JBoss- Projekts , einschließlich:

• Die erste Cloud-Server-Anwendung, die auf der Red Hat OpenShift- Plattform ausgeführt wird .
• Der erste Anwendungsserver, der auf Plug-PC-Computern ausgeführt wird .
• Der erste Anwendungsserver, der auf dem Raspberry Pi ausgeführt wird .
• Eine Reihe von Projekten, die auf Android- Geräten ausgeführt werden .

Wir beschäftigen uns seit vielen Jahren mit den Problemen beim Ausführen von Java-Anwendungen in der Cloud und auf Geräten mit begrenzten Ressourcen (Lesen, IoT) und haben gelernt, das Maximum aus der JVM in Bezug auf Leistung und Speicheroptimierung herauszuholen. Wie viele andere arbeiten wir seit langem mit der nativen Kompilierung von Java-Anwendungen über GCJ , Avian , Excelsior JET und sogar Dalvik und sind uns der Vor- und Nachteile dieses Ansatzes bewusst (zum Beispiel des Dilemmas bei der Wahl zwischen Vielseitigkeit "einmal erstellen - überall ausführen" und dass kompilierte Anwendungen kleiner sind und schneller laufen).

Warum ist es wichtig, diese Vor- und Nachteile zu berücksichtigen? Denn in einigen Situationen wird ihr Verhältnis entscheidend:

• , serverless/ , ( ) , . , . JVM , , , 5 . , Java- ( , , OpenWhisk Knative), JVM . , , .
• , , . , JVM , , Linux’ – . Java-. , JVM, . , .
• , - , . 12 , Kubernetes Java- . , , , , . , dead-code elimination, ( JDK), . Quarkus .

Tatsächlich reichen die obigen Argumente bereits aus, um die Rechtfertigung der nativen Zusammenstellung aus Sicht der Quarkus-Projektteilnehmer zu verstehen. Es gibt jedoch noch einen weiteren, nicht technischen, sondern auch wichtigen Grund: In den letzten Jahren haben viele Programmierer und Entwicklungsunternehmen Java zugunsten neuer Programmiersprachen aufgegeben, da sie der Ansicht sind, dass Java zusammen mit seiner JVM, seinen Stapeln und Frameworks in Bezug auf den Speicher zu unersättlich geworden ist. zu langsam etc.

Die Gewohnheit, zur Lösung von Problemen dasselbe Tool zu verwenden, ist jedoch nicht immer richtig. Manchmal ist es besser, einen Schritt zurückzutreten und nach etwas anderem zu suchen. Und wenn Quarkus die Leute innehalten und nachdenken lässt, ist dies gut für das gesamte Java-Ökosystem. Quarkus verkörpert eine innovative Perspektive für die Erstellung effizienterer Anwendungen, wodurch Java für neue Anwendungsarchitekturen wie serverlos relevanter wird. Darüber hinaus wird Quarkus aufgrund seiner Erweiterbarkeit hoffentlich ein ganzes Ökosystem von Java-Erweiterungen erwerben, wodurch die Anzahl der Frameworks, die standardmäßig die native Kompilierung als Teil von Anwendungen unterstützen, erheblich erhöht wird.