BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Cloud Native Java Avec Le Framework Micronaut

Cloud Native Java Avec Le Framework Micronaut

Points Clés

  • Le framework Micronaut fournit une base solide pour la création de microservices Cloud Native Java basés sur une approche compilation-time.
  • L'intégration étroite avec GraalVM Native Image Ahead-of-Time Compilation (AOT) facilite la conversion des applications en exécutables natifs, ce qui présente d'énormes avantages, en particulier pour les charges de travail serverless et microservices.
  • La réduction de l'utilisation de la réflexion Java, de la génération de proxy à l'exécution et du chargement de classe dynamique a entraîné des améliorations des performances, de la mémoire et du démarrage et facilite le débogage et le test des applications Micronaut.
  • La vérification active au moment de la compilation (compilation-time) augmente la sécurité des types et améliore la productivité des développeurs en signalant les erreurs au moment de la construction plutôt qu'au moment de l'exécution.
  • Un vaste écosystème de modules et d'intégrations, tels que Micronaut Data pour l'accès à la base de données, a contribué à fournir d'autres innovations dans le framework Micronaut.

Cet article d'InfoQ fait partie de la série "Les compilations natives boostent Java". Vous pouvez vous abonner pour recevoir des notifications via RSS.

Java domine les applications d'entreprise. Mais dans le cloud, Java est plus cher que certains concurrents. La compilation native rend Java dans le cloud moins cher : elle crée des applications qui démarrent beaucoup plus rapidement et utilisent moins de mémoire.

La compilation native soulève donc de nombreuses questions pour tous les utilisateurs de Java : comment Java natif change-t-il le développement ? Quand faut-il passer au Java natif ? Quand ne devrions-nous pas ? Et quel framework devrions-nous utiliser pour Java natif ? Cette série apportera des réponses à ces questions.

Changer la perception de Java côté serveur

En 2017, le paysage Java côté serveur avait un problème de perception. Avec le passage aux microservices et aux environnements d'exécution plus légers et souvent conteneurisés, les développeurs ont commencé à remarquer le poids relatif des applications Java traditionnelles, packagées et déployées dans une machine virtuelle Java (JVM) partagée sur un conteneur de servlets. L'émergence de Serverless a encore accéléré cette perception.

C'est à cette époque qu'une équipe d'Object Computing a commencé à repenser la conception des frameworks Java à partir de zéro. Le résultat est le framework Micronaut, un framework Java qui adopte une approche totalement différente en déplaçant le traitement de la façon dont le framework est câblé dans la phase de compilation avec des annotations Java. Cela élimine complètement le besoin de réflexion, de proxies générés à l'exécution et de chargement de classe dynamique complexe, qui sont présents dans les frameworks Java traditionnels.

La première version publique du framework Micronaut en avril 2018 a déclenché un changement radical dans la façon de penser dans l'espace Java et a changé le perception que Java est lent et bouffi. De nombreuses initiatives plus récentes ont adopté une approche similaire : déplacez plus de logique dans la phase de construction et de compilation de l'application pour optimiser le démarrage de l'application et éliminer la réflexion.

Les avantages d'une approche build-time sont clairs : en calculant davantage lors de la compilation, le framework est déjà prêt pour l'exécution de la manière la plus optimale. Et l'élimination de la réflexion, du chargement dynamique des classes et de la génération de proxys à l'exécution nous offre d'autres opportunités d'optimisation en aval pour le JIT et, surtout, l'outillage GraalVM Native Image. Grâce à cette approche, Native Image ne nécessite aucune configuration supplémentaire pour effectuer une analyse statique en monde fermé d'une application du framework Micronaut.

En raison de cette synergie entre le framework Micronaut et GraalVM, le co-fondateur du framework Micronaut Graeme Rocher a rejoint Oracle Labs. Oracle Labs n'est pas seulement propriétaire de GraalVM mais aussi, en plus d'Object Computing, contribue de manière significative au développement continu du framework Micronaut.

Qu'est-ce que le Framework Micronaut ?

Une idée fausse courante à propos du framework Micronaut est qu'il est uniquement conçu pour les microservices. En fait, le framework Micronaut présente une architecture extrêmement modulaire pour une gamme de types d'applications !

À sa base, le framework Micronaut implémente la spécification de la JSR-330 dependency injection. Le framework fournit un certain nombre de fonctionnalités intégrées supplémentaires qui en font un excellent choix en tant que framework à usage général soutenu par un modèle de programmation basé sur des annotations, notamment :

Micronaut a un serveur HTTP et un Client HTTP construit sur la boîte à outils Netty I/O.

Les utilisateurs ont adopté le framework Micronaut pour créer des applications serverless, des applications en ligne de commande, et même des applications JavaFX.

La base solide du framework Micronaut fournit la base d'un vaste écosystème de modules qui permettent à Micronaut de résoudre une gamme de problèmes. Cette flexibilité est responsable de la croissance spectaculaire de la popularité du framework Micronaut parmi les développeurs. Le schéma d'architecture suivant décrit la structure du framework :

La couche fondamentale est basée sur Java Annotation Processing (APT), implémente l'injection de dépendances au moment de la compilation et prend en charge la construction de divers modules, y compris le serveur HTTP basé sur Netty. Mais il couvre également d'autres domaines, tels que l'accès aux données, la sécurité et la sérialisation JSON.

Pourquoi devrais-je utiliser le framework Micronaut ?

L'objectif du framework Micronaut est de fournir une alternative légère aux frameworks Java traditionnels en éliminant complètement les parties dynamiques de ces frameworks qui utilisent des fonctionnalités telles que la réflexion Java, le chargement de classe dynamique et la génération d'exécution de proxys et de byte code.

L'élimination de ces aspects des frameworks traditionnels a un impact profond sur l'amélioration des performances, la consommation de mémoire, la sécurité, la robustesse, la facilité de débogage et les tests. Et contrairement à d'autres solutions, une application utilisant le framework Micronaut démarre aussi rapidement dans la JVM !

Les améliorations apportées au temps de démarrage éliminent souvent complètement le besoin de diviser le code entre l'intégration et les tests unitaires, améliorant considérablement la durée du cycle entre le code et les tests. Trop souvent dans le passé, nous écrivions moins de tests d'intégration car l'application démarrait trop lentement. Le framework Micronaut élimine ce problème et n'inclut donc pas de fonctionnalités de mocking étendues pour la couche HTTP. De nombreux frameworks le font afin d'éviter le coût de démarrage de l'application.

L'élimination de la réflexion aide également au débogage avec une réduction de la taille des stacktraces qui peut souvent être énorme dans les frameworks traditionnels.

Le framework Micronaut fournit également des mécanismes et des API pour déplacer votre propre code vers des approches build-time. C'est pourquoi, en s'intégrant directement au compilateur Java, le framework Micronaut peut produire et produit des erreurs de compilation lorsque les annotations sont utilisées de manière incorrecte, améliorant la sécurité de type du code et l'expérience globale du développeur.

Premiers pas avec le framework Micronaut

Cette section explique comment démarrer avec le framework Micronaut pour créer des microservices Cloud Native Java.

Il existe plusieurs façons de démarrer avec le framework Micronaut. Au minimum, vous avez besoin d'un JDK pour Java SE 8 ou version ultérieure. Pour utiliser la fonctionnalité Native Image, vous avez besoin de GraalVM JDK pour Java 11 ou version ultérieure.

Pour créer une application Micronaut, vous pouvez utiliser l'un des assistants intégrés à votre IDE préféré, par exemple, IntelliJ IDEA Ultimate ou les Outils GraalVM pour l'extension Micronaut pour VSCode.

Alternativement, il est très facile de créer une nouvelle application Micronaut via le Web avec Micronaut Launch. Il s'agit d'un assistant de création de projet qui vous permet de sélectionner le type d'application que vous souhaitez créer et les fonctionnalités que vous souhaitez inclure. Il génère ensuite un fichier ZIP avec l'application que vous pouvez télécharger ou vous permet de pousser le code vers un référentiel Github de votre choix.

Si vous vous sentez plus à l'aise avec la ligne de commande, vous pouvez également créer une application en installant la CLI Micronaut via des méthodes courantes, notamment SDKMAN!, Homebrew, etc. Une fois installée, créer une nouvelle application est aussi simple que :

mn create-app demo –build gradle

Cependant, si vous ne souhaitez pas installer une application CLI supplémentaire, pas de problème ! Vous pouvez utiliser l'API Micronaut Launch directement via curl :

curl https://start.micronaut.io/demo.zip\?build\=gradle -o demo.zip && unzip demo.zip && cd demo

Les commandes ci-dessus créent des applications avec l'outil de construction Gradle. Vous pouvez remplacer le mot "gradle" par "maven" pour utiliser Maven à la place.

En termes de structure de projet, un projet de framework Micronaut est structuré de la même manière que tout autre projet Java :

  • Une build Gradle ou Maven (bien que tous les outils de build puissent être configurés, comme Bazel, par exemple)
  • La configuration est fournie via src/main/resources/application.yml par défaut. Cependant, si vous n'êtes pas un fan de YAML, vous pouvez utiliser les properties Java, JSON, HOCON ou TOML comme alternatives.
  • La journalisation par défaut est basée sur la combinaison SLF4J + Logback via src/main/resources/logback.xml. Vous pouvez remplacer l'adaptateur SLF4J par d'autres systèmes de journalisation.
  • Les tests sont basés sur JUnit 5, mais la prise en charge d'autres frameworks de test, notamment Spock et Kotest pour Kotlin, existe comme alternative.

Un projet nouvellement créé comporte quelques sources Java pour vous aider à démarrer. La première est une classe Application.java située dans src/main/java qui inclut le point d'entrée principal pour une application Micronaut :

package demo;
 
import io.micronaut.runtime.Micronaut;
 
public class Application {
 
   public static void main(String[] args) {
       Micronaut.run(Application.class, args);
   }
}

L'appel à Micronaut.run(..) déclenche la séquence de démarrage du framework.

La deuxième classe générée se trouve dans le répertoire src/test/java et teste que l'application peut démarrer avec succès sans aucune erreur :

package demo;
 
import io.micronaut.runtime.EmbeddedApplication;
import io.micronaut.test.extensions.junit5.annotation.MicronautTest;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.Assertions;
 
import jakarta.inject.Inject;
 
@MicronautTest
class DemoTest {
 
   @Inject
   EmbeddedApplication<?> application;
 
   @Test
   void testItWorks() {
       Assertions.assertTrue(application.isRunning());
   }
}

Ce test JUnit 5 est annoté avec @MicronautTest, une extension JUnit 5 qui permet à un test JUnit 5 d'injecter n'importe quel composant dans le test lui-même. Dans ce cas, c'est le type EmbeddedApplication qui modélise l'application en cours d'exécution.

La configuration d'un IDE pour développer avec Micronaut

D'une manière générale, l'un des avantages du framework Micronaut basé sur Java Annotation Processing (APT) est qu'aucun outil de construction spécial n'est nécessaire pour travailler avec le framework. Tous les IDE populaires prennent en charge le traitement des annotations, bien que certains, comme Eclipse, vous obligent à activer explicitement le traitement des annotations.

Cela dit, l'augmentation de la popularité du framework Micronaut a vu les fournisseurs d'IDE développer un support spécifique pour le framework. IntelliJ Ultimate de JetBrain inclut d'excellents outils pour les utilisateurs du framework, y compris un assistant de projet, la complétion de code pour la configuration, la prise en charge de Micronaut Data, etc.

De plus, Visual Studio Code bénéficie d'un support exceptionnel via le GraalVM Extension Pack, qui est basé sur l'IDE NetBeans. Il comprend un assistant de création de projet Micronaut, la complétion de code pour la configuration et des fonctionnalités d'image natives intégrées pour les applications Micronaut.

Une fois que vous avez installé l'une de ces options, il suffit d'ouvrir le projet Gradle ou Maven dans l'IDE pour tout configurer et vous êtes prêt à partir.

L'écriture d'API REST

Le framework Micronaut prend en charge un large éventail de charges de travail côté serveur, notamment les microservices REST, gRPC, GraphQL et Message-Driven avec des technologies de messagerie telles que Kafka, RabbitMQ, JMS et MQTT. Cette introduction se concentrera sur la création d'applications REST avec le serveur HTTP par défaut basé sur Netty.

Chaque route HTTP dans une application Micronaut est définie par une classe Java annotée avec l'annotation @Controller. Le nom de l'annotation provient du pattern MVC Model View Controller. Un type annoté avec @Controller peut spécifier une ou plusieurs méthodes qui correspondent à un verbe HTTP et à une URI particuliers.

L'exemple canonique "Hello World" peut être implémenté avec un contrôleur Micronaut comme suit :

package demo;
 
import io.micronaut.http.MediaType;
import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;
 
@Controller("/hello")
public class HelloController {
 
   @Get(uri="/{name}", produces=MediaType.TEXT_PLAIN)
   String hello(String name) {
       return "Hello " + name;
   }
}

Le contrôleur est mappé à l'URI /hello. Une seule méthode annotée avec @Get gère un HTTP GET et utilise un modèle d'URI RFC 5741 pour lier le paramètre name de la méthode. Vous démarrez le serveur en exécutant la méthode main de la classe Application à partir d'un IDE ou utilisez ./gradlew run ou ./mvnw mn:run. Vous pouvez maintenant tester manuellement le endpoint en envoyant une requête curl au port 8080 par défaut utilisé par le serveur HTTP Micronaut :

curl -i http://localhost:8080/hello/John
HTTP/1.1 200 OK
date: Mon, 28 Mar 2022 13:08:54 GMT
Content-Type: text/plain
content-length: 10
connection: keep-alive

Hello John

Cependant, avec l'accent mis par le framework Micronaut sur les tests, quelle meilleure façon d'essayer l'API que de la tester ? Voici un simple test JUnit 5 pour l'exemple HelloController ci-dessus :

package demo;
 
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;
 
import io.micronaut.http.client.HttpClient;
import io.micronaut.http.client.annotation.Client;
import io.micronaut.test.extensions.junit5.annotation.MicronautTest;
 
@MicronautTest
public class HelloControllerTest {
 
   @Test
   void testHello(@Client("/") HttpClient client) {
       var message = client
       .toBlocking()
       .retrieve("/hello/John");
       assertEquals("Hello John", message);
   }
}

Le test ci-dessus injecte le client HTTP de Micronaut et envoie une requête GET à l'URI /hello/John, affirmant que le résultat est correct.

L'un des énormes avantages du framework Micronaut est que l'exécution d'un test tel que celui ci-dessus est extrêmement rapide et rivalise avec les tests unitaires réguliers. Même si l'annotation @MicronautTest démarre le serveur Micronaut et que le test exécute un cycle de requête/réponse entièrement HTTP, la vitesse d'exécution du test n'en souffre pas. Il n'est pas nécessaire d'apprendre une API de mocking étendue pour le serveur HTTP ! Cela encourage les développeurs à écrire davantage de tests d'intégration qui offrent des avantages significatifs en matière de maintenabilité à long terme et de qualité du code.

L'accès à une base de données

L'accès à une base de données est une activité tellement courante dans les applications côté serveur que de nombreux frameworks proposent des simplifications pour améliorer la productivité des développeurs dans ce domaine. Le framework Micronaut n'est pas différent.

Micronaut Data est une boîte à outils d'accès à la base de données avec une particularité, cependant : tirer parti de l'intégration avec le compilateur Micronaut, Micronaut Data ajoute la vérification au compilation-time et le calcul au build-time des requêtes de base de données pour améliorer l'efficacité de l'exécution.

Tout comme Spring Data JPA, Micronaut Data vous permet de spécifier des interfaces Java à l'aide du pattern repository qui implémente automatiquement les requêtes de base de données pour vous au moment de la compilation.

Micronaut Data effectue une analyse au moment de la compilation sur les signatures de méthode d'une interface de repository et implémente l'interface s'il le peut. Sinon, une erreur de compilation se produira.

Micronaut Data prend en charge plusieurs bases de données et formats de requête différents, notamment :

  • Hibernate et JPA - Vous pouvez utiliser JPA et Hibernate, et Micronaut Data JPA calcule requêtes JPA lors de la compilation (comme décrit ci-dessus).
  • JDBC et SQL - Pour ceux qui préfèrent SQL brut et un simple mappeur de données plutôt que d'utiliser un Object Relational Mapping (ORM), Micronaut Data JDBC fournit une solution simple pour lire et écrire des records Java 17+ et des POJO depuis et vers une base de données relationnelle.
  • MongoDB - En tant qu'ajout le plus récent, Micronaut Data MongoDB s'intègre directement au pilote MongoDB pour encoder des objets vers et depuis BSON de manière totalement sans réflexion à l'aide de Micronaut Serialization.
  • R2DBC - Basé sur Netty, le framework Micronaut dispose d'un noyau réactif et non bloquant. Vous pouvez écrire des applications SQL qui évitent le blocage de bout en bout en combinant le serveur Micronaut Netty avec la spécification Reactive Database Connectivity (R2DBC) et une base de données prise en charge.
  • Oracle Coherence - Une grille de données distribuée à grande échelle, Coherence propose une intégration dédiée avec Micronaut Data pour implémenter facilement des repositories adossés à un cluster Coherence.

Couvrir toutes les différentes options d'accès à la base de données dans le framework Micronaut nécessiterait une série d'articles en soi. Heureusement, il existe d'excellents guides sur le sujet : consultez "Accessing a Database with Micronaut Data JDBC" ou "Accessing a Database with Micronaut Data Hibernate/JPA" pour obtenir de l'aide pour débuter.

Un de mes favoris personnels est Micronaut Data JDBC, qui est un simple mappeur de données pour JDBC. Il est basé sur des introspections de bean au moment de la compilation, qui éliminent complètement la réflexion de la couche de persistance.

Une fois que vous avez configuré votre build Gradle ou Maven pour inclure Micronaut Data JDBC, vous pouvez créer des records Java 17 qui correspondent aux tables de base de données, aux vues ou aux résultats de requêtes. C'est différent de JPA, qui encourage à avoir un mappage un à un entre une classe Java et une table et à modéliser complètement le schéma grâce à l'utilisation d'associations. Ces associations introduisent des concepts tels que le chargement lazy qui entraînent souvent des problèmes de performances (comme le tristement célèbre problème de sélection N + 1). Voici un exemple de définition d'un record :

package demo;
 
import io.micronaut.core.annotation.Nullable;
import io.micronaut.data.annotation.GeneratedValue;
import io.micronaut.data.annotation.Id;
import io.micronaut.data.annotation.MappedEntity;
 
@MappedEntity
public record Person(
   @Id
   @GeneratedValue
   @Nullable Long id,
   String firstName,
   String lastName,
   int age
) {}

Vous pouvez ensuite définir la logique du référentiel dans les interfaces qui implémentent la majorité de la logique commune requise pour créer une application. Par example :

package demo;
 
import java.util.List;
import io.micronaut.data.jdbc.annotation.JdbcRepository;
import io.micronaut.data.model.query.builder.sql.Dialect;
import io.micronaut.data.repository.CrudRepository;
 
@JdbcRepository(dialect=Dialect.H2)
public interface PersonRepository extends CrudRepository<Person, Long> {
   Person findByAgeGreaterThan(int age);
 
   List<Person> findByLastNameStartsWith(String str);
}

L'exemple ci-dessus fournit un ensemble complet d'opérations de création, de lecture, de mise à jour et de suppression (CRUD) via la super interface CrudRepository. Il définit également des requêtes personnalisées à l'aide des expressions de requête prises en charge.

Si vous avez des exigences personnalisées nécessitant des cas d'utilisation plus avancés, vous pouvez écrire des requêtes personnalisées, des requêtes criteria ou écrire directement une logique JDBC pour lier les résultats. Micronaut Data JDBC en fait un jeu d'enfant tout en étant totalement exempt de réflexion et de proxies générés à l'exécution. Il n'y a pas de notion de synchronisation d'état et de session comme dans JPA, ce qui aide à garder votre application super légère et fonctionne parfaitement avec GraalVM Native Image.

De plus, chaque interface de référentiel est vérifiée au moment de la compilation. Cela empêche les méthodes de référentiel qui interrogent des propriétés inexistantes ou utilisent un type de retour non pris en charge, en maintenant la sécurité de type de Java tout en activant une fonctionnalité dynamique aussi impressionnante.

Construire un exécutable natif

Le framework Micronaut a été publié pour la première fois avant que GraalVM ne soit accessible au public. Pourtant, une synergie naturelle s'est développée entre ces deux grandes technologies principalement en raison de la facilité avec laquelle le composant Native Image de GraalVM peut transformer une application Micronaut en un exécutable natif.

GraalVM Native Image offre une excellente prise en charge de la réflexion, des proxys à l'exécution et du chargement dynamique des classes en Java. Cependant, le développeur doit fournir à Native Image la configuration nécessaire pour déclarer quand et où ces utilisations se produisent. Mais avec le framework Micronaut, nul besoin de déclarer ces usages puisqu'une application Micronaut n'utilise aucune de ces techniques au niveau du framework ! Cela rend l'analyse du monde fermé lors de la compilation anticipée (AOT) beaucoup plus simple pour GraalVM Native Image.

Bien sûr, si vous engagez une bibliothèque tierce qui s'appuie sur la réflexion, vous devrez déclarer l'utilisation. Mais cela aide beaucoup que la majorité des cas dans le framework que vous utilisez soient sans réflexion.

Les plugins Micronaut Gradle et Micronaut Maven exploitent l'excellent projet GraalVM Native Build Tools par Oracle Labs pour aider à simplifier la création d'exécutables natifs. Donc, construire un exécutable natif avec Gradle est aussi simple que :

./gradlew nativeCompile

L'équivalent pour Maven est :

./mvnw package -Dpackaging=native-image

L'une ou l'autre commande produira un exécutable natif pour la plate-forme sur laquelle elle s'exécute dans le répertoire de construction de chaque outil.

L'exécution de l'exécutable natif démontrera le premier énorme avantage de devenir natif :

./demo
 __  __ _                                  _
|  \/  (_) ___ _ __ ___  _ __   __ _ _   _| |_
| |\/| | |/ __| '__/ _ \| '_ \ / _` | | | | __|
| |  | | | (__| | | (_) | | | | (_| | |_| | |_
|_|  |_|_|\___|_|  \___/|_| |_|\__,_|\__,_|\__|
  Micronaut (v3.4.0)

[main] INFO  io.micronaut.runtime.Micronaut - Startup completed in 23ms. Server Running: http://localhost:8080

Le temps de démarrage est réduit à quelques millisecondes (23 ms dans l'exemple ci-dessus) et la consommation de mémoire diminue considérablement. Avec une telle réduction, il est possible de déployer des applications Micronaut dans des environnements avec des contraintes de mémoire plus limitées ou dans des cas où le temps de démarrage est critique (charges de travail serverless, par exemple).

Notez que d'autres recherches sont en cours pour fournir des améliorations encore plus significatives grâce au projet Micronaut AOT, développé chez Oracle Labs. Il exécute une étape d'analyse statique supplémentaire sur le byte code avant de créer l'exécutable natif pour optimiser et éliminer les chemins de code morts et effectuer des tâches telles que la conversion de YAML en Java pour éviter d'avoir besoin d'un analyseur YAML au moment de l'exécution.

Construire pour le Cloud

Au-delà de Native Image, le framework Micronaut prend en charge un certain nombre de formats de packaging et de cibles de déploiement différents, notamment :

  • Un JAR exécutable traditionnel avec ./gradlew assemble ou ./mvnw package.
  • Images Docker avec ./gradlew dockerBuild ou./mvnw package -Dpackaging=docker
  • Images Docker contenant un exécutable natif de GraalVM Native Image avec ./gradlew dockerBuildNative ou ./mvnw package -Dpackaging=docker-native
  • Des environnements d'exécution AWS Lambda personnalisés peuvent être créés pour déployer une application Micronaut sur la plate-forme serverless.
  • Une intégration étendue avec Kubernetes existe pour simplifier les déploiements sur Kubernetes.

Dans l'ensemble, le framework Micronaut offre un ensemble de fonctionnalités qui en fait un excellent choix pour la création d'applications Cloud Native Java, de la prise en charge de la configuration distribuée à la découverte de service intégrée aux modules qui fournissent des implémentations d'abstractions courantes pour les fournisseurs de cloud tels que AWS, Google Cloud, Azure et Oracle Cloud. Ces abstractions garantissent que vos applications restent portables entre les fournisseurs de cloud.

Résumé

Le framework Micronaut a introduit une bouffée d'air frais dans les charges de travail Java côté serveur. Il fournit une approche innovante du temps de compilation et un ensemble de fonctionnalités qui en font un excellent candidat pour la création d'applications Java Cloud Native modernes.

Une intégration étroite avec GraalVM Native Image et une relation de travail avec l'équipe GraalVM d'Oracle Labs signifient que des innovations importantes ont continué à apparaître avec des projets tels que Micronaut AOT et Micronaut Serialization (une alternative sans réflexion à Jackson Databind).

Une communauté dynamique a émergé autour du framework Micronaut avec la matérialisation de nombreux modules qui améliorent la productivité des développeurs, y compris Micronaut Data qui comprend des intégrations clés avec les technologies de base de données.

Les commentaires de la communauté continuent de guider le développement du framework. Par conséquent, si vous avez des commentaires, n'hésitez pas à partager des idées de nouvelles fonctionnalités et d'améliorations via la Communauté Micronaut.

 

Cet article d'InfoQ fait partie de la série "Les compilations natives boostent Java". Vous pouvez vous abonner pour recevoir des notifications via RSS.

Java domine les applications d'entreprise. Mais dans le cloud, Java est plus cher que certains concurrents. La compilation native rend Java dans le cloud moins cher : elle crée des applications qui démarrent beaucoup plus rapidement et utilisent moins de mémoire.

La compilation native soulève donc de nombreuses questions pour tous les utilisateurs de Java : comment Java natif change-t-il le développement ? Quand faut-il passer au Java natif ? Quand ne devrions-nous pas ? Et quel framework devrions-nous utiliser pour Java natif ? Cette série apportera des réponses à ces questions.

 

Au sujet de l’Auteur

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT