WebSocket ann:websocket.annotation.OnMessage[] methods can now accept a api:websocket.WebSocketPongMessage[] parameter that will receive a WebSocket pong sent as a response to a ping submitted using the new sendPingAsync method on api:websocket.WebSocketSession[].

It is now possible to send resources, e.g. stylesheets required by a HTML page, to the client alongside the request for the page using the HTTP2 server push protocol. See the HTTP/2 documentation for information on how to use this feature.

You can now specify the Jackson @JsonView annotation on @Body parameters to controller methods.

The WebSocket clients now support the ws/wss protocol. To implement this change, the api:websocket.WebSocketClient[] create methods now take a URI instead of a URL. The URL methods have been deprecated.

Note: Should you be calling WebSocketClient.create(null), the method call is now ambiguous. Insert a cast in that case: WebSocketClient.create((URI) null)

The SSL handshake timeout can now be configured using the micronaut.ssl.handshakeTimeout and micronaut.http.client.ssl.handshakeTimeout configurations for the server and client respectively.

Factory Beans can now create beans that are primitive types or primitive array types.

See the section on Primitive Beans and Arrays in the documentation for more information.

Qualifiers can now be repeatable (an annotation annotated with java.lang.annotation.Repeatable) allowing narrowing bean resolution by a complete or partial match of the qualifiers declared on the injection point.

A new ann:context.annotation.InjectScope[] annotation has been added which destroys any beans with no defined scope and injected into a method or constructor annotated with @Inject after the method or constructor completes.

Further build time metadata optimizations have been added included reducing the number and size of the classes generated to support Bean Introspection and including knowledge of repeatable annotations in generated metadata avoiding further reflective calls and optimizing Micronaut’s memory usage, in particular with GraalVM.

Support for Reactive context propagation has been further improved by inclusion of request context information in the Reactor context and documentation on how to effectively propagate the context across reactive flows when using Kotlin coroutines.

The build-time api:inject.ast.Element[] API has been improved in a number of ways:

HTTP filters now support matching URLs by a regular expression. Set the patternStyle member of the annotation to REGEX and the value will be treated as a regular expression.

The way the server binds to random ports has improved and should result in fewer port binding exceptions in tests.

The ann:core.convert.format.Format[] annotation now supports several new values that can be used in conjunction with the declarative HTTP client to support formatting data in several new ways. See the client parameters documentation for more information.

The api:http.multipart.StreamingFileUpload[] API has been improved to support streaming directly to an output stream. As with the other transferTo methods, the write to the stream is offloaded to the IO pool automatically.

The SSL configuration for the Netty server now responds to refresh events. This allows for swapping out certificates without having to restart the server. See the https documentation for information on how to trigger the refresh.

If you wish to programmatically start additional Netty servers on different ports with potentially different configurations, new APIs have been added to do so including a new api:http.server.netty.NettyEmbeddedServerFactory[] interface.

See the documentation on Starting Secondary Servers for more information.

The JAX-RS module now integrated with Micronaut Security allowing binding of the JAX-RS SecurityContext

Micronaut Kubernetes 3.1 introduces new annotation @Informer. By using the annotation on the ResourceEventHandler the Micronaut will instantiate the SharedInformer from the official Kubernetes Java SDK. Then you only need to take care of handling the changes of the watched Kubernetes resource. See more on Kubernetes Informer.

The Micronaut Oracle Coherence module is now out of preview status and includes broad integration with Oracle Coherence including support for caching, messaging and Micronaut Data.

Micronaut 3.0 introduces a new build time metadata format that is more efficient in terms of startup and code size.

The result is significant improvements to startup and native image sizes when building native images with GraalVM Native Image.

It is recommended that users re-compile their applications and libraries with Micronaut 3.0 to benefit from these changes.

Micronaut has been updated to support the latest GraalVM 21.2 release.

The jakarta.inject annotations are now the default injection annotations for Micronaut 3

Using the ann:context.annotation.Import[] annotation it is now possible to import bean definitions into your application where JSR-330 (either javax.inject or jakarta.inject annotations) are used in an external library.

See the documentation on Bean Import for more information.

api:core.annotation.AnnotationMetadata[] inheritance can now be controlled via Java’s @Inherited annotation. If an annotation is not explicitly annotated with @Inherited it will not be included in the metadata. See the Annotation Inheritance section of the documentation for more information.

Micronaut can now resolve the correct bean to inject based on the generic type arguments specified on the injection point:

snippet::io.micronaut.docs.inject.generics.Vehicle[tags="constructor",indent=0]

For more information see the section on Qualifying by Generic Type Arguments.

You can now use annotation members in qualifiers and specify which members should be excluded with the new ann:context.annotation.NonBinding[] annotation.

For more information see the section on Qualifying By Annotation Members.

You can now limit the exposed types of a bean using the typed member of the ann:context.annotation.Bean[] annotation:

snippet::io.micronaut.docs.inject.typed.V8Engine[tags="class",indent=0]

For more information see the section on Limiting Injectable Types.

Beans defined with the ann:context.annotation.Factory[] annotation can now produce beans from public or package protected fields, for example:

snippet::io.micronaut.docs.factories.VehicleMockSpec[tags="class",indent=0]

For more information see the Bean Factories section of the documentation.

The api:context.BeanProvider[] interface has been enhanced with new methods such as iterator() and stream() as well as methods to check for bean existence and uniqueness.

A new ann:context.annotation.Any[] qualifier has been introduced to allow injecting any available instance into an injection point and can be used in combination with the new BeanProvider interface mentioned above to allow more dynamic behaviour.

snippet::io.micronaut.docs.qualifiers.any.Vehicle[tags="imports,clazz", indent=0, title="Using BeanProvider with Any"]

The annotation can also be used on ann:context.annotation.Factory[] methods to allow customization of how objects are injected via the api:inject.InjectionPoint[] API.

Bean introspections on public or package protected fields are now supported:

snippet::io.micronaut.docs.ioc.beans.User[tags="class", indent=0]

For more information see the "Bean Fields" section of the Bean Introspections documentation.

For the performance reasons it’s advised to inject an instance of ApplicationEventPublisher with a generic type parameter - ApplicationEventPublisher<MyEvent>.

It is now possible to intercept bean construction invocations through the api:aop.ConstructorInterceptor[] interface and ann:aop.AroundConstruct[] annotation.

See the section on Bean Life Cycle Advice for more information.

It is now possible to intercept @PostConstruct and @PreDestroy method invocations through the api:aop.MethodInterceptor[] interface and ann:aop.InterceptorBinding[] annotation.

See the section on Bean Life Cycle Advice for more information.

It is now possible to set a max and a range for random numbers in configuration. For example to set an integer between 0 and 9, ${random.int(10)} can be used as the configuration value. See the documentation under "Using Random Properties" for more information.

Micronaut 3 uses internally Project Reactor instead RxJava 2. Project Reactor allows Micronaut 3 to simplify instrumentation, thanks to Reactor’s Context, simplifies conversion login and eases the integration with R2DBC drivers. We recommend users to migrate to Reactor. However, it is possible to continue to use RxJava. See Reactive Programming section.

The Micrometer module has been upgraded and now supports repeated definitions of the @Timed annotation as well as also supporting the @Counted annotation for counters when you add the micronaut-micrometer-annotation dependency to your annotation processor classpath.

Micronaut’s Oracle Cloud Integration has been updated with support for Cloud Monitoring and Tracing.

The Micronaut Cassandra integration now includes support for GraalVM out of the box.

Possibly the most important change in Micronaut 3.0 is how annotations are inherited from parent classes, methods and interfaces.

Micronaut 2.x did not respect the rules defined in the jdk:java.lang.reflect.AnnotatedElement[], and inherited all annotations from parent interfaces and types regardless of the presence of the jdk:java.lang.annotation.Inherited[] annotation.

With Micronaut 3.x and above only annotations that are explicitly meta-annotated with jdk:java.lang.annotation.Inherited[] are now inherited from parent classes and interfaces. This applies to types in the case where one extends another, and methods in the case where one overrides another.

Many of Micronaut’s core annotations have been annotated with @Inherited, so no change will be required, but some annotations that are either outside Micronaut or defined by user code will need changes to code or the annotation.

In general, behaviour which you wish to override is not inherited by default in Micronaut 3.x and above including Bean Scopes, Bean Qualifiers, Bean Conditions, Validation Rules and so on.

The following table summarizes the core Micronaut annotations and which are inherited and which are not:

When upgrading an application you may need to take action if you implement an interface or subclass a superclass and override a method.

For example the annotations defined in jakarta.validation are not inherited by default, so they must be defined again in any overridden or implemented methods.

This behaviour grants more flexibility if you need to redefine the validation rules. Note that it is still possible to inherit validation rules through meta-annotations. See the section on Annotation Inheritance for more information.

The default value of jackson.always-serialize-errors-as-list is now true. That means by default the Hateoas JSON errors will always be a list. For example:

To revert to the previous behavior where a singular error was populated in the message field instead of including _embedded.errors, set the configuration setting to false.

It is no longer possible to scan the classpath at runtime using the scan method of the api:context.env.Environment[] interface.

This functionality has not been needed for some time as scanning is implemented at build time through Bean Introspections.

Micronaut now provides the jakarta.inject annotations as a transitive dependency instead of the javax.inject annotations. To continue using the old annotations, add the following dependency.

dependency:javax.inject:javax.inject:1[]

Micronaut no longer exports any third party dependency for nullability annotations. Micronaut now provides its own annotations for this purpose (api:core.annotation.Nullable[] and api:core.annotation.NonNull[]) that are used for our APIs. To continue using other nullability annotations, simply add the relevant dependency.

Internally, Micronaut makes use of a third party annotation that may manifest as a warning in your project:

This warning is harmless and can be ignored. To eliminate this warning, add the following dependency to your project’s compile only classpath:

dependency:com.google.code.findbugs:jsr305[gradleScope="compileOnly"]

In Micronaut 2 server filters could have been called multiple times in the case of an exception being thrown, or sometimes not at all if the error resulted before route execution. This also allowed for filters to handle exceptions thrown from routes. Filters have changed in Micronaut 3 to always be called exactly once for each request, under all conditions. Exceptions are no longer propagated to filters and instead the resulting error response is passed through the reactive stream.

In the case of a response being created as a result of an exception, the original cause is now stored as a response attribute (api:http.HttpAttributes#EXCEPTION[]). That attribute can be read by filters to have context for the error HTTP response.

The api:http.filter.OncePerRequestHttpServerFilter[] class is now deprecated and will be removed in the next major release. The api:http.filter.OncePerRequestHttpServerFilter[] stores a request attribute when the filter is executed and some functionality may rely on that attribute existing. The class will still create the attribute but it is recommended to instead create a custom attribute in your filter class and use that instead of the one created by api:http.filter.OncePerRequestHttpServerFilter[].

There is also a minor behavior change in when the response gets written. Any modifications to the response after the underlying onNext call is made will not have any effect as the response has already been written.

Compile time validation of HTTP related classes has been moved to its own module. To continue validating controllers, websocket server classes add http-validation to the annotation processor classpath.

dependency:io.micronaut:micronaut-http-validation[gradleScope="annotationProcessor"]

For many cases, one common one being introspections, getter names like getXForwarded() would result in the bean property being XForwarded. The name will now be xForwarded. This can affect many areas of the framework where names like XForwarded are used.

Previously the default order value for the @Order annotation was the lowest precedence. It is now 0.

Classes, constructors, etc. that have been deprecated in previous versions of Micronaut have been removed.

In several places in Micronaut, it is required to get a map representation of your object. In previous versions, a reflection based strategy was used to retrieve that information if the class was not annotated with @Introspected. That functionality has been removed and it is now required to annotate classes with @Introspected that are being used in this way. Any class may be affected if it is passed as an argument or returned from any controller or client, among other use cases.

Previously the secure configuration for cookies was only respected if the request was determined to be sent over https. Due to a number of factors including proxies, HTTPS requests can be presented to the server as if they are HTTP. In those cases the setting was not having any effect. The setting is now respected regardless of the status of the request. If the setting is not set, cookies will be secure if the request is determined to be HTTPS.

Previously if a route could not be satisfied, or an HttpStatusException was thrown, routes for the relevant HTTP status was searched before routes that handled the specific exception. In Micronaut 3 routes that handle the exception will be searched first, then routes that handle the HTTP status.

Status error routes will now default to produce responses with the same HTTP status as specified in the @Error annotation. In previous versions a 200 OK response was created. For example:

The above method will result in a response of HTTP status 415 with a body of "not supported". Previously it would have been a response of HTTP status 200 with a body of "not supported". To specify the desired response status, either annotate the method with @Status or return an HttpResponse.

In Micronaut 2.x it was possible to inject a List<javax.inject.Provider>, although this was undocumented behaviour. In Micronaut 3.x injecting a list of Provider instances is no longer possible and you should instead use the api:context.BeanProvider[] API which provides stream() and iterator() methods to provide the same functionality.

In previous versions of Micronaut it was possible to inject an ExecutorService without any qualifiers and the default Netty event loop group would be injected. Because the event loop should not be used for general purpose use cases, the injection will now fail by default with a non unique bean exception. The injection point should be qualified for which executor service is desired.

It is no longer possible to inject the internal implementation type from beans produced via factories. The type returned from the factory or any of its super types are able to be injected.

For example:

In the above case, if the ExecutorService had been already been retrieved from the context in previous logic, a call to context.getBean(ForkJoinPool.class) would locate the already created bean. This behaviour was inconsistent because if the bean had not yet been created then this lookup would not work. In Micronaut 3 for consistency this is no longer possible.

You can however restore the behaviour by changing the factory to return the implementation type:

In previous versions of Micronaut it was possible to define AOP advice to a factory method that returned a class that featured constructor arguments. This could lead to undefined behaviour since the argument of the generated proxy which would be dependency injected by the framework may be different from manually constructed proxy target.

The following definition is now invalid in Micronaut 3 and above and will lead to a compilation error:

In Micronaut 2.x if you defined a bean that implemented the javax.inject.Provider interface then the return type of the get method also automatically became a bean.

For example:

In the above example a bean of type A would automatically be exposed by Micronaut. This behaviour is no longer supported and instead the ann:context.annotation.Factory[] annotation should be used to express the same behaviour. For example:

Previous versions of Micronaut specified the ann:context.annotation.Executable[] annotation as a meta-annotation on the ann:http.annotation.Controller[], ann:http.annotation.Filter[] and ann:messaging.annotation.MessageListener[] annotations. This resulted in generating executable method all non-private methods of classes annotated with these annotations.

In Micronaut 3.x and above the ann:context.annotation.Executable[] has been moved to a meta-annotation of ann:http.annotation.HttpMethodMapping[] and ann:messaging.annotation.MessageMapping[] instead to reduce memory consumption and improve efficiency.

If you were relying on the presence of these executable methods you must explicitly annotate methods in your classes with ann:context.annotation.Executable[] to restore this behaviour.

In previous versions of Micronaut annotating a class with @Introspected automatically added it to the GraalVM reflect-config.json file. The original intended usage of the annotation is to generate Bean Introspection Metadata so Micronaut can instantiate the class and call getters and setters without using reflection.

Starting in Micronaut 3.x the @Introspected annotation doesn’t add the class to the GraalVM reflect-config.json file anymore, because in most of the cases is not really necessary. If you need to declare a class to be accessed by reflection, use the @ReflectiveAccess annotation instead.

Another change is regarding the GraalVM resources created at compile-time. In previous versions of Micronaut adding a dependency on io.micronaut:micronaut-graal triggered the generation of the GraalVM resource-config.json that included all the resources in src/main/resources so they were included in the native image. Starting in Micronaut 3.x that is done in either the Gradle or Maven plugins.

The classes in Micronaut Cassandra have been moved from io.micronaut.configuration.cassandra to io.micronaut.cassandra package.

Many of the APIs in the Micronaut Security module have undergone changes. Please see the Micronaut Security documentation for the details.

In previous version the missing property wouldn’t set the field value to null as it would do for the Java code, in the version 3 it should behave in the same way.

Please refactor to use the default value in the @Value annotation:

It is now possible to define a body argument of a controller method with an InputStream. For example @Body InputStream inputStream. Note that you must offload the execution to another thread pool to avoid blocking the event loop when reading the stream. InputStream can also be returned from controller methods.

If Dual Protocol is enabled, now it is possible to redirect all HTTP requests automatically to the HTTPS port. See more information about how to enable and configure it.

Micronaut has been updated to support the latest GraalVM 21.1.0 release with the Gradle and Maven plugins now defaulting to 21.1.0.

Micronaut Launch has been updated with support for JDK 16 and Gradle 7.0.

It is now possible to set a max and a range for random numbers in configuration. For example to set an integer between 0 and 9, ${random.int(10)} can be used as the configuration value. See the documentation under "Using Random Properties" for more information.

Huge Micronaut Data update including many new features including:

The Micrometer module has been upgraded and now supports repeated definitions of the @Timed annotation as well as also supporting the @Counted annotation for counters when you add the micronaut-micrometer-annotation dependency to your annotation processor classpath.

Micronaut’s Oracle Cloud Integration has been updated with support for Cloud Monitoring and Tracing.

The jakarta.inject inject annotations are now supported as an alternative to javax.inject. Micronaut 3 will change the default inject annotations to Jakarta, however the javax annotations will continue to be supported if added to your build explicitly.

Micronaut 3 will change the bean context API to return our custom provider contract, api:context.BeanProvider[]. We suggest existing applications to change to use that interface instead of javax.inject.Provider, however both the jakarta.inject.Provider and javax.inject.Provider interfaces will continue to be supported.

With the future of JSR-305 unclear and issues with regards to the module system with existing solutions, Micronaut 2.4 will replace usages of Spotbugs with core nullability annotations: ann:core.annotation.Nullable[] and ann:core.annotation.NotNull[].

Existing applications should switch to using these annotations. If other annotations are preferable, the dependency should be added explicitly to your build because no third party Nullable or NonNull annotations will be available transitively in the next major version.

Micronaut’s support for AOP interceptors has been improved allowing interceptors to be attached to any annotation through the use of api:inject.annotation.AnnotationMapper[] instances. It is also now possible to bind multiple api:aop.MethodInterceptor[] instances to a single annotation instead of there being a 1-to-1 mapping between annotation and interceptor.

From 2.4.x onwards the recommending way to define AOP advise is to use the ann:aop.InterceptorBinding[] annotation on the annotation you wish to trigger AOP advise:

snippet::io.micronaut.docs.aop.around.NotNull[tags="imports,annotation", indent=0, title="Around Advice Annotation Example"]

Then use ann:aop.InterceptorBean[] on the api:aop.MethodInterceptor[] you wish to bind to the above advise:

snippet::io.micronaut.docs.aop.around.NotNullInterceptor[tags="imports,interceptor", indent=0, title="MethodInterceptor Example"]

Multiple api:aop.MethodInterceptor[] types can bind to a single advise annotation and any given interceptor can bind to multiple annotations.

In previous versions of Micronaut, to control the format of error response bodies, it required replacing all of the existing api:http.server.exceptions.ExceptionHandler[] instances. In Micronaut 2.4, the logic to create error response bodies has been moved to a single bean that implements api:http.server.exceptions.response.ErrorResponseProcessor[]. Now instead of having to replace many beans to have a consistent format, only a single bean needs to be replaced. The default implementation behaves the same as in previous versions to maintain backward compatibility.

Micronaut Data JDBC now supports using Java 14+ records to represent persistent entities, for example:

Micronaut Data JPA, JDBC and R2DBC now support persistence events on either entities or Micronaut beans. For example:

The micronaut-coherence-data module alows you to use Micronaut Data with Coherence as a back end data store.

A new micronaut-coherence module provides factories for commonly used Coherence objects, such as Cluster, Session, NamedMap, NamedCache, NamedTopic, and many others, which allows you to easily inject those objects into your application classes.

The micronaut-coherence module also provides support for Coherence server- and client-side events via Micronaut event listeners.

Finally, the micronaut-coherence module provides support for Micronaut Messaging using Coherence Topics.

The micronaut-coherence-cache module adds support for using Coherence as a back end for Micronaut Cache.

The micronaut-coherence-distributed-configuration module adds support for using Coherence as a store for Micronaut Distributed Configuration.

The micronaut-coherence-session module adds support for using Coherence as a store for Micronaut HTTP Sessions.

A new micronaut-oraclecloud-atp has been added that makes it easier to automatically download the Oracle Wallet definition and connect to Autonomous Database on Oracle Cloud.

A new micronaut-oraclecloud-micrometer module has been added that adds support for exporting Micrometer metrics to Oracle Cloud.

With the new micronaut-kubernetes-client module you can now inject apis objects from the official Kubernetes Java SDK as regular beans.

In Micronaut 3 this new module will be used as primary kubernetes client, making the current one deprecated.

Micronaut AWS now includes the new AWS SDK v2 that has support for GraalVM out of the box. Every service included in the module like S3, Parameter Store, SES, SQS,…​ is now compatible with Micronaut-GraalVM integration.

A new customizable banner is now displayed when the application starts up. See Micronaut Banner for more information.

This release is compatible with the latest GraalVM 21.0.0 release, updating and testing all modules against the latest version of native image.

Java 14+ Records can now be used to define Configuration Properties. By default when @ConfigurationProperties is used on a record, configuration injection is applied. For example:

A api:core.beans.BeanIntrospection[] can now declare methods that should generate reflection-free execution handles. This feature allows calling other methods (besides setters) on introspections without using reflection.

An immutable api:core.beans.BeanIntrospection[] (like Java Records as mentioned above) requires different handling when you need to create a new instance with a particular property modified. A typical pattern for this is to construct a new instance passing all existing values plus the modified value (see for example Lombok’s @With).

Micronaut’s Bean Introspections now support this pattern. For example:

The new withValue method automatically creates a new instance, populating the existing properties and returning the instance.

Micronaut computes at compile time an efficient copy-constructor approach that only returns a new instance if the value changes.

A new interface api:http.server.util.HttpLocaleResolver[] has been introduced to support resolving a locale from a given request in multiple ways. A java.util.Locale object can now be a parameter to controller and client methods to automatically bind the locale to/from the request. See the documentation for more information.

It is now possible to validate a resolved host against a list of regular expressions patterns. See the documentation for more information.

Micronaut Launch has been updated to include CI/CD workflows to deploy to common container-based Cloud environments including Oracle Cloud Function, Azure Container Instance and Google Cloud Run.

Combined with the ability to Push to Github this makes it a breeze to set up Micronaut applications to be deployed to the Cloud.

Thanks to a contribution by Vinicius Carvalho, Micronaut GCP supports distributed configuration via Google Cloud Secret Manager.

The Maven plugin now supports different <packaging> types:

To package an application, mvn package is the one-stop shop to produce the desired artifact.

It also supports using mvn deploy as the only command required to deploy an application that, depending on the <packaging>:

Read more information in the Maven Plugin documentation.

The Gradle plugin has a new testNativeImage task that builds the GraalVM Native Image and uses the native application as an embedded server enabling the ability to write native integration tests.

It is now possible to create applications that use build.gradle.kts instead of build.gradle using the --build argument of the CLI:

Or via the Micronaut Launch API:

It is now possible to create an application with and Micronaut Launch and have it pushed automatically to a repository in your Github account. When generating an application just select the "Push to Github" option.

Improving the experience in IoT use cases, Micronaut now has integration with MQTT similar to the integration with Kafka and RabbitMQ. See the Micronaut MQTT documentation to get started.

A new module that adds support for R2DBC (Reactive Database Connectivity) has been added in preview status. Micronaut Data R2DBC lets you define reactive data repositories using R2DBC that work with any of the supported drivers and include support for GraalVM Native Image.

See the Documentation for Micronaut R2DBC for more information.

It is now possible to define bean introspections on JDK 14+ record types (note these currently require the ––enable–preview flag to the compiler and JVM).

@Client interfaces now support suspend methods!

Micronaut 2.1 introduces the concept of a default environment. One or more default environments can be set and they will apply if no other environments are explicitly specified or deduced. See the environments documentation for information on how to use this new feature.

The ann:core.annotation.Order[] annotation has been added to support supplying bean order for factory methods or for those who prefer the use of annotations over the api:core.order.Ordered[] interface.

Micronaut now ships with Kotlin 1.4 for those users using Kotlin.

A new Gradle plugin is available that provides a more expressive way to define a Micronaut application and includes awesome new features for GraalVM Native Image and Docker. The minimum required build to build a Micronaut application is now:

Building a Native Image is then as simple as:

Whilst building a docker image using GraalVM Native Image can be done with:

A new API has been created to allow for binding declarative HTTP client method arguments to an HTTP request. See the documentation for more information.

Query parameters are now respected and bindable in the Micronaut websocket support.

Cookies in HTTP responses from the client side are now retrievable on the HttpResponse. These are the cookies found in the Set-Cookie header.

A new GraalVM Native Image compatible module for Oracle Cloud SDK has been added allowing you to use any part of the Oracle Cloud SDK with Native Image and also enhancing the SDK with RxJava 2 support.

Support has been added for building Oracle Functions deployable to Oracle Cloud including the ability to compute the functions in native images using GraalVM.

Thanks to Vinicius Carvalho at Google, Micronaut now features dedicated support for Google Pub/Sub for seamless messaging in Google Cloud.

Thanks to Vinicius Carvalho at Google, Micronaut can now output logs in the official JSON format supported by Stackdriver on Google Cloud

Micronaut’s /health endpoint now allows you to distinguish liveness and readiness probes at the URIs /health/liveness and /health/readiness. Micronaut Launch’s Kubernetes support has been updated to generate a Kubenetes descriptor that is configured to with these probe endpoints by default.

Micronaut has been updated to support JDK 14.

Micronaut now supports applications written in Groovy 3.

Startup time has been further improved in this release with typical startup time for a new application around 20% faster.

Bean introspections have been improved to support static creator methods, interfaces and enums. This means you can define a bean introspection on an interface with a private implementation such as:

Micronaut’s Dependency Injection implementation has been improved such that you can now receive an api:inject.InjectionPoint[] instance to any ann:context.annotation.Factory[] method. This makes it possible to customize how the bean is created based on the annotation metadata at the point at which the bean is injected.

For example consider the following definition:

A factory method can receive the injection point and create a client based off of the value:

Eager initialization of beans is useful in certain cases, such as on AWS Lambda where more CPU resources are assigned to Lamdba construction than execution. Therefore as for Micronaut 2.0, you can specify whether you want to eager initialization configuration or all singletons using the api:context.ApplicationContextBuilder[] interface:

It is also possible to just eager init configuration using eagerInitConfiguration which will initialize all ann:context.annotation.ConfigurationProperties[] beans.

In Micronaut 1.x the Google distributed JSR-305 annotations library (com.google.code.findbugs:jsr305) was used to specify @Nullable and @NonNull on interfaces of the Micronaut API using the annotations contained within the javax.annotation package.

Due to the fact that JSR-305 has been cancelled and that this dependency has potential licensing issues (by using the javax namespace) as well as problems with the cross packages on Java 9+ with the module system Micronaut 2.x switches to the spotbugs-annotations module provided by the SpotBugs project.

It is recommended users of Micronaut use this API instead (although the javax.annotation.Nullable and javax.annotation.NotNull annotations continue to be supported).

Micronaut’s mn command for the CLI has been rewritten in Micronaut itself and is now compiled into a native image available on Linux, MacOS X and Windows.

Create Micronaut 2.0 applications without having the CLI installed using curl:

Or by visiting https://launch.micronaut.io in your browser.

Run curl https://launch.micronaut.io for more instructions on how to use the API or visit the OpenAPI documentation.

Run mn feature-diff --features=[FEATURE NAME] from the root of another Micronaut project to create a diff of the changes that need to be applied to enable the feature. For example:

It is not longer necessary to configure static resources for your Native Image builds. The micronaut-graal annotation processor will automatically do this for you for all resources found in src/main/resources.

It is no longer necessary to provide additional GraalVM related configuration to connect to databases via JDBC or Hibernate/JPA. Micronaut includes automatic support for the following drivers with GraalVM Native Image:

The Micronaut Flyway module has been updated with GraalVM Native Image support so you can now run database migrations in Native Image.

Version 2.0 of the Micronaut AWS module includes support for Native Image for the majority of the v2 AWS APIs including S3, Dynamo DB, SES, SNS, and SQS which will be helpful for those developing native AWS Lambda functions with Micronaut + GraalVM.

The Micronaut jOOQ module includes support for Native Image and it’s possible to use it with SimpleFlatMapper.

The Micronaut Redis module includes support for Native Image. There are still some pending uses cases that won’t work because of how Lettuce driver works. Make sure you read the documentation.

The Micronaut Elasticsearch module includes support for Native Image

Micronaut now provides a new parent POM that can be used in Maven projects to get setup quickly:

The parent POM mentioned above includes a new Micronaut Maven Plugin that enables automatic application restart during development. Just run the following:

Whenever you make a change to a class file the server will restart automatically.

For Gradle users who create new applications Gradle 6.5 is used which is compatible with JDK 14.

Gradle builds with Micronaut 2 for both Java and Kotlin should be significantly faster thanks to improved support for Gradle incremental annotation processing.

Micronaut’s Netty-based HTTP client and server have been updated to support HTTP/2.

See the HTTP/2 documentation for more information on how to enable support for HTTP/2.

Micronaut 2.0 uses a new shared default Netty EventLoopGroup for server worker threads and client request threads. This reduces context switching and improves resource utilization.

See the HTTP Client Configuration section for information on how to configure the default EventLoopGroup and add additional `EventLoopGroup’s that are configured per client.

In addition, as of Micronaut 2.0 all operations are by default executed on the EventLoop and users can optionally use the new ann:scheduling.annotation.ExecuteOn[] annotation to specify a named executor to execute an operation on if required (for example to offload blocking operations such as interactions with JPA/JDBC to a specific thread pool).

It is now possible to bind the properties of a POJO argument to a @Controller to request parameters, headers and so on using the ann:http.annotation.RequestBean[] annotation.

Thanks to Github user asodja for this contribution.

Micronaut now includes support for creating Servlet applications and users can use the command line to create an application that targets popular Servlet containers:

Micronaut will now correctly handle the HTTP Accept header and pick the most appropriate route for the specified accepted media types using Server-Side Content Negotiation.

Micronaut will now process the VCAP_APPLICATION and VCAP_SERVICES environment variables and treat them as property sources.

Thanks to Fabian Nonnenmacher for this contribution.

It is no longer necessary to use @Client(..) to inject a default api:http.client.RxHttpClient[] instance. You can now inject the default client simply with:

If no host is provided at the time of a request, a api:http.client.exceptions.NoHostException[] will be thrown.

A new API for writing API gateways and proxying requests has been added. See the documentation on the ProxyHttpClient for more information.

It is now possible to control the sensitivity of individual endpoint methods. The ann:io.micronaut.management.endpoint.annotation.Sensitive[] annotation can be applied to endpoint methods to allow for some methods to have a different sensitivity than the value supplied to the endpoint annotation.

The Instrumentation mechanism for RxJava 2 has been improved to address issues with MDC and reduce the size of reactive stack traces. Thanks to Denis Stepanov and Lajos Gathy for their contributions in this area.

You can generate a Micronaut + Ktor application from Micronaut Launch or via the command line.

New Kotlin Extension Functions are available that make the Kotlin + Micronaut experience that little bit better.

You can now write Serverless functions that target Google Cloud Function using Micronaut. See the Micronaut GCP documentation and example application for more information.

You can now write Serverless functions that target Microsoft Azure using Micronaut. See the Micronaut Azure documentation and example application for more information.

Micronaut AWS 2.0.0 includes a number of improvements to support for AWS Lambda and AWS in general including new client modules for AWS SDK 2.0, cold start improvements on Lambda and improvements to the support for Amazon Alexa.

Caching has been moved into a separate module and out of micronaut-runtime. If you need caching (including the annotations within io.micronaut.cache.annotation) you just need to add the individual module for the cache provider you are interested (for example Caffeine, Redis, Hazelcast etc.).

See the documentation for the Cache module for more information.

Micronaut SQL has been improved to default to Micronaut transaction management (making Spring management optional) and includes support for Jdbi (Thanks to Dan Maas for this contribution).

In addition, support has been added for Oracle Universal Connection Pool. Thanks to Todd Sharp for this contribution.

The security module has seen many changes to improve the API and introduce new features to support a wider array of use cases.

See the Security module for more information.

Whilst RxJava 2 remains the default, individual modules for other reactive libraries have been added.

For RxJava 3:

dependency:io.micronaut.rxjava3:micronaut-rxjava3[]

For Reactor:

dependency:io.micronaut.reactor:micronaut-reactor[]

And legacy support for RxJava 1:

dependency:io.micronaut.rxjava1:micronaut-rxjava1[]

Included within the new RxJava 3 and Reactor modules are variants of api:http.client.RxHttpClient[] called Rx3HttpClient and ReactorHttpClient respectively.

To use the RxJava 3 HTTP client add the following dependency:

dependency:io.micronaut.rxjava3:micronaut-rxjava3-http-client[]

To use the Reactor HTTP client add:

dependency:io.micronaut.rxjava3:micronaut-reactor-http-client[]

A new messaging module for Nats.io has been included in Micronaut core.

See the documentation for Micronaut Nats for more information.

Thanks to Joachim Grimm for this contribution.