Red Hat og GraalVM-fællesskabet annoncerede for nylig udgivelsen af en ny GraalVM- distribution kaldet Mandrel . Denne nye distribution forventes at styrke Red Hat-versionen af Quarkus, en nyligt annonceret tilføjelse til Red Hat Runtimes.
Quarkus er et native Java Kubernetes-framework til JVM og native compilations. Quarkus leverer en effektiv løsning til at køre serverløse Java-applikationer, microservices, containere, Kubernetes, FaaS eller cloud-applikationer. Mandrel er open source og tilgængelig på GitHub, men det har endnu ikke en binær distribution.
Ifølge en note fra Mark Little, senior direktør for ingeniørarbejde hos Red Hat, kan Mandrel beskrives som en distribution af en standard OpenJDK med et specielt pakket native GraalVM-billede.
Det primære mål bag Red Hats introduktion af Mandrel er at forbedre hastigheden og effektiviteten af Quarkus-frameworket. Det er et framework, der tilbyder lokal udvikling med hurtige genindlæsninger og containeriseret eller serverløs distribution til cloud computing-udbydere.
Quarkus fokuserer på evnen til at bygge native eksekverbare filer , der starter hurtigere og samtidig reducerer omkostninger og driftsressourcer i skyen.
Faktisk forklarede Red Hat, at for Quarkus er det vigtige element i GraalVM dens native image-funktion , som producerer native eksekverbare filer – en nøglefunktion for Java for at være konkurrencedygtig i cloud-native workloads. Derfor tillader Mandrel, at GraalVM bruges sammen med OpenJDK 11 på Red Hat Enterprise Linux og andre OpenJDK 11-distributioner.
Ifølge Red Hat er forskellen for brugeren minimal, men for vedligeholdelsesevne er forudgående tilpasning med OpenJDK 11 og GraalVM afgørende.
"Med Mandrel drager Red Hat-kunder og GraalVM-samfundet fordel af virkelig åben udvikling, og Red Hat kan støtte sine kunder med gennemprøvede mekanismer, mens de giver tilbage til de samfund, de stoler på, for at fortsætte med at udvikle staten. Inden for open source computing," sagde virksomheden og talte om Mandrel.
Med hensyn til ydeevne skiller GraalVM sig ud med en 50 gange hurtigere opstartstid og 5 gange lavere hukommelsesforbrug.
Disse forskellige tests blev udført ved hjælp af en ældre version af Quarkus-rammen mod Java HotSpot-tilstand. Selvom denne forbedring kræver længere kompileringstid, kan den bruges parallelt med implementeringen af Quarkus Lambda- og Azure-funktionerne.
Derudover tilbyder Mandrel GitHub-arkivet endnu ikke en binær distribution. Derfor kompilerer brugerne selv JDK'en efter instruktionerne. Derudover har softwareudvikler James Ward gennemgået GraalVM i detaljer og skitseret dens fordele i forhold til ydeevne samt nogle ulemper, såsom applikationer, der er afhængige af refleksion.
Ifølge ham skaber dette et problem for indfødte GraalVM-billeder, fordi refleksion opstår ved kørsel, hvilket gør det vanskeligt for en AOT-kompilator (early bird) at bestemme eksekveringsstier.
Når det kommer til apps, der ikke behøver at tænke over, peger Quarkus-hjemmesiden direkte på fordelen: 12 MB RAM versus 73 MB (et fald på 83%) og 0.016 sekunder i det første svar versus 0.943 (et fald på 98% ).
Udviklere kan nu bruge Mandrel med deres eget build , eller de kan benytte GraalVM-fællesskabet eller enhver distribution af JDK 11 og nyere. Andre siger, at disse native Java-frameworks ikke rigtig fungerer og ikke bør blive en industristandard.
Ifølge dem er det ikke en generel teknologi , hvor man kan tage en eksisterende Java-applikation og gøre den native. Dette vil ikke fungere, selv ikke for applikationer skrevet ved hjælp af et bibliotek fra det enorme Java-økosystem.
Sidstnævnte mener, at forskellige rammeleverandører satser på det faktum, at de fleste Java-applikationer er HTTP / ORM / JSON-applikationer ud over foranstaltninger og sikkerhed osv.
Hvis du vil vide mere om det, kan du se følgende link.