Micronaut 3.0 brings significant changes adaptable for future development


Object Computing, Inc. To published Micronaut 3.0 with the removal of a default reactive streams implementation, a change in annotation inheritance and HTTP compile-time validation. This release was the culmination of work to resolve design flaws from the past in order to make the framework more intuitive and adaptable to future requirements.

Micronaut, the JVM-based full-stack development framework for building modular and easily testable microservices and serverless applications, defined as its core mission to reinvent application startup time and memory consumption. The “Micronaut way” is based on the fact that application startup time and memory consumption are unrelated to the size of your codebase, resulting in a “monumental jump in startup time, a extremely fast throughput and minimal memory footprint ”as indicated on their website.

Previous versions included RxJava2 as a transitive dependency and the default reactive streams used to implement many features in the framework. The release of RxJava3 was a good time to make a decision: upgrade or move to Project reactor. The Micronaut team chose the latter because of its functionality allowing it to maintain state within the responsive flow and wider adoption by the community. The team also recommends that projects currently using RxJava2 upgrade to Project Reactor. This will result in fewer classes on the execution classpath and less potential issues with context propagation and reactive type conversion.

The current version changes the way a developer will interact with annotations. Until now, annotations were inherited from interfaces or parent classes. However, from version 3.0, all annotations annotated with @Inherited will be inherited. Among other things, as a result of this change, any annotations related to bean scopes or around / intro tips will no longer be inherited.

Some names qualified as annotations have been changed, imposed by license changes or the movement of HTTP-related components. In the first case, the javax namespace licensing issues affected all annotations under javax.annotations. Namely, with this version, jakarta.annotation.PreDestroy and jakarta.annotation.PostConstruct are the recommended alternatives. The annotations of javax.inject which have been replaced by jakarta.inject annotations. Thus, for common uses of javax.inject.Provider, the recommended alternative is io.micronaut.context.BeanProvider. In the second case, the components related to HTTP at compile time have been moved to a new module, io.micronaut:micronaut-http-validation. This dependency must be added to the annotation processor classpath to continue using validated classes at compile time.

There are enhancements with Micronaut’s Inversion of Control (IoC) mechanism for improved granularity and control. Developers can now qualify an injection of a type by its generic arguments. A class that uses type arguments can be targeted by specifying these generics in the argument type.

public Vehicle(Engine<V8> engine) {

Beans are now seen as a super type or interface rather than the type they are. This can be used to prevent direct searching for an implementing class and to force the interface to search for the bean.

@Bean(typed = Engine.class)
class V8Engine implements Engine {


Previously, lifecycle methods like @PostConstruct and @PreDestroy Aspect Oriented Programming (AOP) advice could not be applied to them. But now constructors and lifecycle methods can be caught for AOP advice on those methods.

Another novelty comes from the way in which the server filters are called: they are called only once for each request under all conditions. Exceptions are no longer propagated to filters. Instead, the resulting error response is passed through the reactive stream. Previously, server filters could be called multiple times in the event of an exception being thrown.

Other changes come in the GraalVM space where the addition of the @Introspected annotation also adds configuration of GraalVM to allow thoughtful use of the class. This behavior is no longer available because, in the vast majority of cases, it is not necessary. To restore it, add the @ReflectiveAccess annotation to the class. Another “magic” that has been happening under the hood so far has been the addition of the src/main/resources folder to the native image. Micronaut build plugin users will receive the same behavior while Maven users are now responsible for creating and maintaining the resource configuration.

As with most major releases, Micronaut 3.0 comes with breaking changes, but also promises an easy upgrade with Open Rewrite, a framework that would modify the source code to upgrade an application from Micronaut 2 to Micronaut 3. This can be accomplished with the Maven or Gradle plugin.

Micronaut was officially presented in March 2018 by Graeme Rocher, then Senior Software Engineer for Grails and Micronaut Product Manager at OCI, at the Greach Conference. Micronaut was then open-source at the end of May 2018. Three years later its first GA version, the third version is a consolidation version. The team put into practice all the learnings gathered during this period, improving the architecture and providing more flexibility for users in terms of which libraries can be used and what the memory footprint will look like. Also, it aligned its namespace name to avoid any licensing issues related to the javax namespace.

fbq(‘init’, ‘842388869148196’);
fbq(‘track’, ‘PageView’);


Source link