Helidon

Helidon ist ein Framework für die Entwicklung von Microservices. Helidon ist schnell, leichtgewichtig und einfach zu bedienen. Es kombiniert die Portabilität von Microprofile mit der Leistungsfähigkeit reaktiver APIs und möchte dabei völlig neue Maßstäbe bei der Erstellung von Microservices setzen.

Helidon stammt aus dem Griechischen und bedeutet Schwalbe. Sie ist ein Vogel aus der Gattung der Sperlingsvögel mit langen, scharfen Flügeln und dem charakteristischen Doppelschwanz. Der Flug und die Anmut dieser Vögel ist bewundernswert. Die Art und Weise, wie sie in Schwärmen leben, erinnert ein wenig an die Welt der Microservices.

Helidon ist ein Vertreter der MicroProfile-basierten Frameworks und besteht aus einer Reihe von Bibliotheken, die hauptsächlich für die Entwicklung von Microservices konzipiert wurden. Helidon ist vollständig Open-Source. Der Code ist auf Github und unter der Apache 2.0 Lizenz veröffentlicht.

MicroProfile ist vielen Entwicklern bereits als eine Reihe von Spezifikationen für den Aufbau von Microservices bekannt. Nachdem die Entwicklung im Jahr 2016 mit nur drei Spezifikationen begonnen wurde – CDI, JAX-RS und JSON-P – und sogar dann aus Java EE übernommen wurde, handelt es sich bis Ende 2020 in Version 3.3 um 12 Spezifikationen, die sich ausschließlich auf die Erstellung von Microservices konzentrieren:

MicroProfile 3.3. In gelb mit Änderungen, in blau ohne (Abb. 1)

Major-Releases erfolgen jährlich, kleinere Veröffentlichungen finden einmal im Quartal statt. Wie man (Abb. 1) entnehmen kann, kann sich jede Spezifikation in einem anderen Tempo entwickeln. Einige Spezifikationen ändern sich möglicherweise nicht von Release zu Release.

Es gibt mehrere andere Spezifikationen, die nicht Teil der offiziellen Version von MicroProfile sind, z. B. die für GraphQL-Unterstützung, langlaufende Aktionen, Parallelität, Reactive-Messaging, Ereignisdaten und Reactive-DB-Access.

MicroProfile ist eine Spezifikation der Eclipse Foundation und ist keine vorgefertigte Implementierung, sondern eine Reihe allgemein anerkannter Schnittstellen und Standards. Implementierungen dieser Schnittstellen werden von mehreren Anbietern wie Red Hat, IBM, Tomitribe, Payara und anderen erstellt. Die ursprünglichen Implementierungen der Standards waren in großen Server-Produkten wie OpenLiberty, TomEE usw. enthalten. Mit dem Aufkommen des DevOps-Konzepts und der allgemeinen Idee, dass ein Server eine Anwendung bedient und der Server selbst in der Produktverteilung verpackt ist, verschwindet in letzter Zeit allmählich der Bedarf an vollwertigen Server-Produkten zur Implementierung von Microservice-Architekturen. Die Plattformen selbst neigen dazu, sich selbst zu miniaturisieren. Für viele ist Spring Boot zur ideologischen Inspiration geworden. Eine kleine Menge Code und einige Annotationen sind ausreichend, um Fat-Jar-Anwendungen zu erstellen, die dann bequem in Docker-Containern verpackt und in den Clouds bereitgestellt werden können. MicroProfile bot eine solide Grundlage für die Entwicklung dieser Idee und führte die Konzepte der Standardisierung und Portabilität ein. Dies bedeutet, dass der in dieser Spezifikation geschriebene Code auf jeder Plattform funktioniert, die ihn unterstützt. Dem Endbenutzer steht es frei, eine Plattform nicht nur in Bezug auf Technologie, sondern auch in Bezug auf Lizenz, kommerziellen oder nichtkommerziellen Support, Zertifizierung und Gesetzgebung in verschiedenen Ländern usw. zu wählen. Und im Falle von Änderungen portiert man den Code mit dem geringsten Verlust. Der in dieser Spezifikation geschriebene Code funktioniert auf jeder Plattform, die ihn unterstützt.

Helidon strebt in dieser Entwicklungsphase nicht danach, ein Full-Stack-Entwicklungstool wie Spring Boot oder Dropwizard zu sein, sondern konzentriert sich auf Microservices. Ein typischer Microservice auf Helidon für JVM wiegt nicht mehr als 20 MB, was um ein Vielfaches weniger ist als beispielsweise Spring Boot. Nun, die vorab in Native-Image kompilierte Größe beträgt sogar weniger als 10 MB.

Das Beste ist, dass die API vollständig deklarativ und innerhalb der MicroProfile-Standards vollständig portierbar ist.

Wie sagt man? Talk is cheap, show me the code:

(Listing 1)

Nur ein paar Standard Annotationen – und man kann zur Produktion laufen.

Helidon 2.1.0

Was kann eigentlich Helidon 2.1.0? Helidon unterstützt alles, was in MicroProfile 3.3 plus CORS und gRPC (Server + Client) angegeben ist. (Abb. 2) Um mit der Entwicklung zu beginnen gibt es zwei Möglichkeiten – CLI herunterladen oder einfach eine Abhängigkeit in ein leeres Maven-Projekt einfügen (Listing 2)

.

Unterstützte Spezifikationen für Helidon MP 2.1.1 (Abb. 2)

(Listing 2)

Die obige Abhängigkeit fügt alle in MicroProfile verfügbaren Funktionen hinzu. Wenn man mit einem kleineren Kernsatz von Funktionen beginnen möchtet, könne man stattdessen das Kernpaket verwenden. Dieses Paket enthält grundlegende Funktionen in MicroProfile (wie JAX-RS, CDI, JSON-P / B und Config) und enthält keine zusätzlichen Funktionen wie Metriken und Ablaufverfolgung. Man kann diese Abhängigkeiten separat hinzufügen.

In (Listing 3) ist die Abhängigkeit nur für den grundlegenden Satz von MicroProfile-Funktionen abgebildet.

(Listing 3)

(Listing 4)

(Listing 5)

(Listing 6)

(Listing 7)

(Listing 8)

(Listing 9)

(Listing 10)

Das Projekt erstellt einen JAR-File für die Beispielanwendung und speichert alle Laufzeitabhängigkeiten im Verzeichnis target/libs. Dies bedeutet, dass man die Anwendung einfach starten kann, indem man den JAR-Spitznamen ausführt (Listing 11).

(Listing 11)

Ein Beispiel ist ein sehr einfacher Hello-World-Service. Es unterstützt GET-Anforderungen zum Erstellen einer Begrüßungsnachricht und PUT-Anforderungen zum Ändern der Begrüßung selbst. Die Antwort wird mit JSON codiert (Listing 12).

(Listing 12)

Darüber hinaus bietet man sofort MicroProfile-Extras wie Health-Check und Metrics an:

(Listing 13)

(Listing 14)

(Listing 15)

Als Teil dieses Artefakts wird auch eine Docker-File generiert, mit der man auf einfache Weise ein Docker-Image erstellen kann (Listing 16) und dieses auch sofort ausführen kann (Listing 17). Somit ist alles fertig für die Bereitstellung in Kubernetes (Listing 18). (Listing 19) prüft, wie es angefangen hat. Abhängig davon, auf welchem Port alles bereitgestellt wurde, kann getestet werden, ob der Service ausgeführt wird (Listing 20) . Zum Abschluss wird der Müll aufgeräumt (Listing 21).

(Listing 16)

(Listing 17)

(Listing 18)

(Listing 19)

(Listing 20)

(Listing 21)

Helidon ist sehr modern.

Dies bedeutet, dass es von Anfang an mindestens Java 11 benötigt und man damit Zugriff auf jlink-Befehle hat, die das Erstellen einer Reihe von Modulen und deren Abhängigkeiten in einem benutzerdefinierten Laufzeitabbild unterstützen. Das Helidon-Maven-Plugin unterstützt die einfache Erstellung eines solchen Laufzeit-Images für die Helidon-Anwendung. Dies führt zu einer geringeren Größe und einer besseren Leistung, da unnötige Dinge vermieden werden.

Man kann sein eigenes Laufzeit-Image auf zwei Arten erstellen:

  • Vor Ort auf einer Arbeitsmaschine
  • Docker verwenden

Vor Ort ist dies einfach, man muss nur das jlink-image-Profil verwenden

Dieses Profil verwendet das Helidon-Maven-Plugin, das ein benutzerdefiniertes Bild erstellt. Übrigens druckt das Plugin während der Regeneration viele nützliche Informationen darüber, wie sich die Bildgröße verringert hat.

Das Verzeichnis target/helidon-quickstart-mp ist ein eigenständiges benutzerdefiniertes Image der Helidon-Anwendung. Es enthält die Anwendung, außer Abhängigkeiten und die JDK-Module, von denen es abhängt. Man kann die Anwendung mit dem Befehl in (Listing 22) starten:

(Listing 22)

Das benutzerdefinierte Image enthält auch das CDS-Archiv (Class-Data-Sharing), dass die Startleistung der Anwendung verbessert und den speicherinternen Footprint optimiert.

Das CDS-Archiv vergrößert das Bild geringfügig, um die Leistung zu optimieren und kann möglicherweise zu einer signifikanten Größe mit zig MB heranwachsen. Die Größe des CDS-Archivs wird am Ende der Build-Ausgabe angegeben.

Wenn eine kleinere Build-Größe mit geringfügig längeren Startzeiten bevorzugt wird, kann das Erstellen des CDS-Archivs übersprungen werden (Listing 23).  Aber das Image kann auch direkt auf dem Docker und auch mit einem einfachen Befehl erstellt werden (Listing 24).

(Listing 23)

(Listing 24)

Dieser Befehl erstellt einen vollständigen Build im Docker-Container. Beim ersten Start dauert es eine Weile, da alle Maven-Abhängigkeiten auf Docker-Ebene heruntergeladen und zwischengespeichert werden. Nachfolgende Builds sind viel schneller, wenn die pom.xml-Datei nicht geändert wird. Wenn der POM geändert wird, werden die Abhängigkeiten neu geladen.

Und voila, man kann die Anwendung direkt in Docker ausführen (Listing 25). Man kann es mit den vorherig genannten Quickstarter curl testen.

(Listing 25)

Benutzerdefinierte Laufzeitabbilder sind ideal für die Verwendung, wenn man die gesamte JDK-JVM-Leistung in einer relativ kompakten Form benötigt.

Was aber, wenn eine kompromisslos kleine Bildgröße und eine minimale Startzeit der Anwendung benötigt wird?

Dafür gibt es GraalVM-Native-Images. Native-Images sind vorab kompilierter Java-Code, der eine eigenständige ausführbare Datei erstellt. Infolgedessen wird die Anwendung fast sofort gestartet und hat zur Laufzeit weniger Speicheraufwand als auf der JVM.

Um alle Vorteile dieser Technologie zu nutzen, muss man GraalVM herunterladen und installieren sowie angeben, wo es installiert ist (Listing 26). Im Anschluss wird der Befehl native-image installiert (Listing 27).

(Listing 26)

(Listing 27)

Man kann ein natives Bild aus der Quickstarter-MP-Anwendung erstellen.

Dazu gibt zwei Arten:

  • auf lokaler GraalVM
  • und auf Docker

Auf dem lokalen Computer ist auch alles sehr einfach. Es gibt ein fertiges natives Bildprofil, welches dasselbe Helidon-Maven-Plugin verwendet und wird gebaut siehe (Listing 28).

(Listing 28)

Der Build wird länger als gewöhnlich dauern, da eine große Menge an vorzeitiger Kompilierung stattfindet. Am Ende wird man den nativen ausführbaren File bekommen. Ja, ein direkt ausführbarer File, eine separate JVM wird nicht mehr benötigt. Zum Starten führt man (Listing 29) aus.

(Listing 29)

Es ist unglaublich schnell und klein. Wie im Fall von jlink können alle Manipulationen am Build im nativen Image direkt im Docker durchgeführt werden (Listing 30).

(Listing 30)

Genau wie bei jlink dauert der erste Build länger, aber alle nachfolgenden Builds verwenden alle bereits heruntergeladenen Abhängigkeiten. Die Anwendung wird durch (Listing 31) durchgeführt und wie beim letzten Mal startet diese schnell und nimmt wenig Platz ein.

(Listing 31)

Native-Images sind ideal für Anwendungen mit hohen Anforderungen an die horizontale Skalierbarkeit, bei denen es wichtig ist, mehrere Instanzen schnell zu starten.

Auf einem lokalen Computer ist das native Image eine ausführbare Datei für die Plattform, auf der genau dieser Computer ausgeführt wird. Bisher werden nur Linux und Mac unterstützt. Windows wartet noch. Und in Docker jeweils nur Linux. Das heißt, man kann eine Linux-Binärdatei auf einem Mac erstellen.

Native-Images weisen jedoch einige Einschränkungen auf. Für Anwendungen mit langer Laufzeit, bei denen Start und Speicherbedarf weniger kritisch sind, ist die Java-SE HotSpot-VM möglicherweise besser geeignet.

Eine vollständige Liste der Module, die das native Image unterstützen, findet man hier.

Es ist zu beachten, dass die native Image-Unterstützung in der Voll-CDI-Version ohne Einschränkungen implementiert ist.

Helidon nutzt die heutigen Fortschritte in der Java-Architektur optimal und bietet alle Build-Optionen für die besten Ergebnisse.

Werkzeuge

Helidon 2 führt ein CLI ein, mit dem ein Entwicklungsprozess erstellt und beschleunigt werden kann.

Mit CLI-Helidon kann man ganz einfach ein Helidon-Projekt erstellen, indem man aus einer Reihe von Archetypen auswählt. Es unterstützt auch eine Entwicklerschleife, die die Anwendung kontinuierlich kompiliert und neu startet. Man kann einfach codieren, und die CLI erkennt alle von Ihnen vorgenommenen Änderungen und sieht sie sofort in Aktion.

Die CLI wird zur Vereinfachung der Installation als separate ausführbare Datei mit GraalVM kompiliert verteilt. Es steht derzeit zum Download für Linux und Mac zur Verfügung. Einfach die Binärdatei herunter laden, an einem Ort installieren, auf den über PATH zugegriffen wird, und fertig.

Anschließend kann man das erstellte Projekt in der bevorzugten IDE öffnen.

(Listing 32)

… und ein paar Fragen zu beantworten… und das ist es.

Öffnet man das erstellte Projekt in der bevorzugten IDE und beginnt mit dem Codieren.

Derzeit kann man mit dem Tool ein Beispielprojekt mit vollständiger MicroProfile-Unterstützung erstellen. Um maximale Leistung zu erzielen, kann auch ein Projekt erstellt werden, das vollständig auf den reaktiven APIs auf niedriger Ebene basiert.

Derzeit ist die dritte Version der Anwendung ein Beispiel für die Verwendung des DB-Clients.

Die CLI-Helidon-Funktionalität wird in Kürze erweitert. Das bereits Vorhandene reicht aber bereits für 80% der Fälle in der täglichen Entwicklung.

Helidon hat auch auf der Seite von Intellij-IDEA Unterstützung. Zweimal die Umschalttaste drücken, Endpunkte eingeben und IDEA zeigt es uns (Abb. 3).

Unterstützung in Intellij Idea (Abb. 3)

Willkommen in der Dangerzone

Wie man bereits gesehen hat, ist Helidon ein großartiges Entwicklungswerkzeug, das die Erstellung von Microservices erheblich vereinfacht. Mit ein paar Anmerkungen und einer minimalen Menge an Code kann man mit geringem oder keinem Aufwand eine vollständige Produktionsanwendung schreiben. Es ist zu beachten, dass Helidon auf MicroProfile-Basis die vollständige Portabilität von Programmen bietet, die im Rahmen von Spezifikationen darauf ausgeführt werden. Standardisierung ist die Hauptstärke und der Schwerpunkt von Helidon. Das alles kostet Leistung. Die Architektur von Helidon baut auf CDI-Erweiterungen auf, die eine Low-Level-API aufrufen. Die gesamte Wartung dieser CDI-Infrastruktur kostet Zeit.

Was ist diese Low-Level-API? Diese API heißt Helidon-SE. Im Wesentlichen ist Helidon-SE ein sehr kompaktes reaktives Toolkit, das auf Netty aufbaut und die neuesten Java-SE-Innovationen wie reaktive Streams, asynchrone und funktionale Programmierung sowie Fluent APIs verwendet (Abb. 4).

Helidon-Architektur (Abb. 4)

In gewisser Weise ist der weiche und flauschige Helidon eine Hülle über dem harten Helidon-SE.

Helidon-SE ist ein nicht blockierendes Mikroframework mit einem mikroskopischen Speicherbedarf, dessen Schwerpunkt auf Asynchronität und Leistung liegt. Es gibt keine Magie – keine Dependency-Injection, praktisch keine Annotationen, nur die neuesten Java-Funktionen ab Version 11. Helidon-SE bietet einen vollständigen Satz von APIs zum Erstellen reaktiver Anwendungen in einem funktionalen Stil. Der Code ist ausführlicher, ausdrucksvoller und ohne Annotationen.

In (Abb. 5) sind die von Helidon-SE unterstützten Spezifikationen abgebildet.

Von Helidon-SE unterstützte Module (Abb. 5)

Experimentelle Komponenten sind grün dargestellt. Experimentell bedeutet in Helidon, dass an der API ggf. noch Änderungen vorgenommen werden.

Wie schreibst du über dieses Biest? Es ist eigentlich auch ziemlich einfach. Der Code ist ausführlicher, ausdrucksvoller und ohne Annotationen.

(Listing 33)

Besondere Aufmerksamkeit sollte dem Helidon-DB-Client gewidmet werden. Es gelang, einen vollständig nicht blockierenden Datenbankzugriff zu implementieren, unabhängig davon, ob der zugrunde liegende JDBC-Treiber blockiert oder nicht. Standardmäßig werden relationale DBMS wie Postgres, MySQL, MariaDB, im Allgemeinen alles für das es einen JDBC-Treiber gibt, sowie nicht relationale DBMS wie MongoDB unterstützt.

Der Select-Aufruf in einer Transaktion ist in (Listing 34) abgebildet, der Update-Aufruf für MongoDb in (Listing 35).

(Listing 34)

(Listing 35)

Gleichzeitig erfolgt die Konfiguration zentral über Helidon Config (Listing 36).

(Listing 36)

Dadurch wird der Code teilweise portierbar und man kann die Datenbank ohne Neukompilierung ändern. Weitere Informationen und Beispiele in der offiziellen Dokumentation.

Helidon-SE bietet auch seinen reaktiven, nicht blockierenden Webclient an. Es unterstützt alle Beobachtbarkeitsfunktionen von Helidon-SE und ist vom Design her erweiterbar. Es ist sehr einfach zu bedienen (Listing 37).

(Listing 37)

Es kann über Helidon Config konfiguriert werden. Weitere Infos in exzellenter und detaillierter Dokumentation.

Erwähnenswert ist auch die Unterstützung von Reactive-Streams / Messaging in Helidon.

Helidon verfügt über eine eigene Gruppe von Jet-Betreibern, die außerhalb des Helidon-Ökosystems unabhängig sind. Diese Operatoren können mit reaktiven Streams auf der Basis von java.util.concurrent.Flow verwendet werden. Eine Threading-Operator-Kette kann einfach mit io.helidon.common.reactive.Multi oder io.helidon.common.reactive.Single für Einzelwert-Streams erstellt werden.

Die Reactive-Streams-API ist weit verbreitet und vollständig kompatibel mit vorhandenen APIs und Implementierungen (RxJava, Reactor usw.).

Es gibt bereits eine Integration mit Kafka und Oracle-Streaming-Service. Die Unterstützung für JMS und Oracle-Advanced-Queuing ist in Vorbereitung.

(Listing 38) zeigt ein Multi-Beispiel und (Listing 39) ein Einzelbeispiel.

(Listing 38)

(Listing 39)

Helidon-Entwickler sind besonders stolz auf gRPC Server & Client. Die Implementierungen beider Module wurden im Wesentlichen von Grund auf neu geschrieben, ohne von Google-Bibliotheken abhängig zu sein, und funktionieren in modularen Umgebungen (ab Java 9) einwandfrei. Eine minimalistische gRPC-Anwendung wird in (Listing 40) gezeigt.

(Listing 40)

Helidon kann jedoch nicht nur ein Server für gRPC-Dienste sein, sondern auch deren Verbraucher.

Der Helidon-gRPC-Client bietet ein Framework zum Erstellen von gRPC-Clientanwendungen. Dieses Framework bietet eine einheitliche Möglichkeit, auf gRPC-Dienste zuzugreifen, die entweder Protobuf oder ein benutzerdefiniertes Serialisierungsformat verwenden. (Listing 41) zeigt ein Client-Beispiel.

(Listing 41)

gRPC sowie Server und Client sind bereits stabil, und können in der Produktion eingesetzt werden. Mehr Informationen hier.

Es ist zu beachten, dass vor kurzem bei der Integration von Helidon und Neo4j die reaktive Neo4j-API verwendet, von der Helidon-SE-Seite in Multi verpackt und dann asynchron an Response gesendet wurde. Da der Neo4J-Driver vollständig mit GraalVM kompatiibel ist, wird das gesamte PRojekt vollständig in Native kompiliert und ist sehr schnell. Die bessere Performance macht sich bemerkbar (Abb. 6).

Operationen pro Sekunde. Größer ist besser. Der Code für diesen Benchmark ist hier verfügbar.  (Abb. 6)

Im Allgemeinen ist Helidon-SE eine geheime, versteckte Waffe für Fans von Leistung, Kreativität und anderem Hardcore.

Den Bewertungen nach zu urteilen, bemerken die Benutzer die sehr hohe Intuitivität der Helidon-SE-Architektur. Drückt man einfach den Punkt am Ende des Ausdrucks in den Starterbeispielen, und die Autovervollständigung der IDE zeigt, was noch getan werden kann und welche Funktionen hinzugefügt werden müssen.

Anstatt Low-Level-APIs zu schließen, hat das Helidon-Team sie für alle zugänglich gemacht. Es ist klar, dass für 90% der Fälle Magie völlig ausreicht, aber oft können diese 10% der anderen Hardcore-Fälle hinsichtlich Leistung und Reaktionsgeschwindigkeit absolut kritisch sein. Man muss etwas mehr Code schreiben, aber es wird viel schneller funktionieren.

Großartig … aber wie kann man das testen?

Es ist eigentlich sehr einfach. Helidon-SE ist reines Java ohne Magie und kann in der Regel mit Unit-Tests vollständig getestet werden, ohne einen vollständigen Container oder Teile davon in einem Integrationstest hochzufahren.

Aber für Helidon-MP gibt es spezielle Helfer, da CDI bekanntlich viel Magic enthält. Zuerst muss man eine Abhängigkeit hinzufügen (Listing 42).

(Listing 42)

Der Test kann mit der Annotation @HelidonTest markiert werden. Diese Annotation startet den CDI-Container vor dem Aufrufen einer Testmethode und stoppt ihn nach dem Aufrufen der letzten Methode. Diese Anmerkung ermöglicht auch das Einfügen in die Testklasse selbst. Daher ist das Testen selbst sehr einfach (Listing 43).

(Listing 43)

Wie man dem Beispiel entnehmen kann, kann man andere Annotationen anwenden, um die Beans-Erkennung zu deaktivieren, eine Konfiguration hinzuzufügen usw.

Bei der Generierung der Quickstarter-Beispiele, werden alle Tests mitgeliefert.

Was bekommt der Benutzer am Ende?

Zahlen belegen, dass Helidon sehr klein ist. Aber wie viel kann die Anwendung wiegen? Tatsächlich kann es verschiedene Optionen geben, je nachdem wie es erstellt wird. Helidon bietet verschiedene Build-Profile an.

  1. Executable-JAR: Hollow jar. Alle externen Abhängigkeiten werden separat gespeichert. Dies ist besonders nützlich im Zusammenhang mit der Verwendung von Docker und seiner Überlagerung.
  2. Jlink-Image: Wie bereits erwähnt, benötigt Helidon Java 11 oder höher, um alle Extras zu verwenden, einschließlich Jlink. Dadurch wird eine in Bezug auf die JRE optimierte Anwendung erstellt. Das Ergebnis ist ein schnellerer Start, geringere Größe ohne Einschränkungen beim Code.
  3. Natives GraalVM-Image: Mit einer bestimmten Anzahl bekannter Einschränkungen bei Code- und Laufzeitoperationen wird die schnellste Startzeit, minimaler Speicherbedarf und minimale Größe erreicht.

 

(Abb. 7), (Abb. 8) und (Abb. 9) belegen dies in Zahlen.

(Abb. 7)

Speicherplatz (Abb. 8)

Startzeit (Abb. 9)

Mehr als anständige Ergebnisse. Vor allem, wenn man sich die Helidon-SE-Anwendung ansieht, die im nativem Image kompiliert wurde.

Und wie man weiß, ist Zeit (und Ort) Geld. Besonders in den Clouds.

Anstelle von Ausgabe

Helidon ist vollständig standardisiert, produktionsreif und basiert auf den neuesten Java-Versionen. Die Entwicklung von Helidon verläuft sehr zügig. Dabei legen die Entwickler großen Wert darauf, dass Helidon vor allem schnell, leichtgewichtig und flexibel bleibt. Helidon kombiniert Eigenschaften wie Standardisierung und Portabilität dank der Unterstützung von MicroProfile mit hoher Performance dank reaktiver Low-Level-APIs. Diese wurden von Grund auf neu geschrieben und deren Implementierung ist in den neuesten Java-Versionen ab Version 11 enthalten. Durch den Zugriff auf Low-Level-APIs lassen sich hochperformante, reaktive Anwendungen ohne CDI-Magic erstellen.

Die detaillierte Dokumentation mit zahlreichen Beispielen ermöglicht einen einfachen Einstieg.

Am einfachsten ist es, direkt die CLI herunterzuladen und mit der Entwicklung zu beginnen.

Dmitry Aleksandrov

Dmitry ist Senior Principal Entwickler bei Oracle, Java Champion, Oracle Groundbreaker. Er verfügt über mehr als ein Jahrzehnt Erfahrung hauptsächlich in Java Enterprise im Bank- / Telekommunikationsbereich, interessiert sich jedoch für dynamische Sprachen in JVM und Funktionen wie umfangreiche Berechnungen auf GPUs. Ein echter Anhänger von Open Source- und Community-Initiativen. Er ist Co-Leiter der bulgarischen Java User Group und Mitorganisator von jPrime Conf.
Dmitry ist ein Blogger und ein häufiger Speaker bei lokalen Veranstaltungen sowie Weltweit Konferenzen wie JavaOne / CodeOne, Devoxx / Voxxed und Joker / JPoint.

Redaktion


Leave a Reply