-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Vert.x 5
Vert.x 4 was released two years ago (december 2020) and brought key features such as a future based programming model, microservices monitoring, a fully non-blocking and high performance SQL client, a redesigned Redis client to name a few. Since its release, new features were gradually added to the stack.
Reactive stacks have been recognised as strategic when it comes to performance, resource efficiency and scalability, they are continuing to evolve. External factors influencing the design of Vert.x are well known: virtual thread support (for which Vert.x has an incubator project) and Netty 5 (for which we did a small prototype) are the most impacting ones.
After two years and a few minor versions, it is time to deliver a new major Vert.x version. We think that it is too early to commit to virtual threads or Netty 5. Instead we want Vert.x 5 to revise and improve some of its parts, while at the same time preparing Netty 5 and virtual threads.
- This document is not a formal roadmap, rather a description of what Vert.x 5 shall be and not be, defining the major themes of the release
- We recognise that sometimes the landscape changes and a project needs to adapt, therefore the scope of Vert.x 5 is subject to potential changes
- This document targets Vert.x 5 (i.e 5.x releases)
We expect Vert.x 5 to be released in 2023.
Vert.x 4 will continue to get new features while Vert.x 5 is in development.
After Vert.x 5 is released, Vert.x 4 will remain supported for 2 years.
We will recommend using the latest Java LTS version and support Java 11 as minimum Java version.
- Biased locking removal: Address biased locking removal in Java 15.
- Finalizer removal: Replace various usage of Java finalizer with Java cleaner.
- Cleanup: Some code present in Vert.x 4 for Java 8 will be removed
- Codegen Java 8 compiler bug fixes
- Verticle extra classpath support based on multi release jar
- Asynchronous callbacks removal
- Permitted types is the new default
- Buffer might become a data object instead of being a generated type
The Vert.x public API is coupled to Netty 4, by a small degree yet it is. This coupling will be removed from the public API providing the opportunity to provide an alternative implementation of Vert.x 5 based on Netty 5 during the lifetime of Vert.x 5.
Vert.x 5 will provide the opportunity to provide a Netty 5 implementation along with a Netty 4 version at a later stage of the 5.x development.
Code duplication for Netty 5 might be necessary in a few places
- SQL clients relies on custom handlers
- MQTT client relies on Netty codecs
Such duplication shall be kept to the minimum and likely require a refactoring.
SQL client is mature, no major changes happening, a few enhancements
- TestContainer integration usability
- Improvement of the query API that does not allow to chain mapper/collector
- Prepared query builder to help building SQL query parameter placeholder syntax
Vert.x 4 has developed a new gRPC stack based on Vert.x HTTP/2 stack, the existing gRPC stack (based on Netty 4) becomes legacy and goes away in Vert.x 5.
Support for grpc-web without the need of a sidecar proxy.
Addresses a few concerns
- Using service proxies with EventBus serialization when exposing gRPC services requires transcoding Protobuf to JSON
- Provides an alternative to EventBus to use with service proxies
The implementation can be achieved in several steps
- Code generated Protobuf codec: a service proxy/handler implementation can serialize/deserialize to/from Protobuf.
- Transport switch: Vert.x gRPC client and server
- Protofile generation: generate a Protofile from the service proxy interfaces (services and messages).
Vert.x already supports SockJS or TCP bridge in various languages. A gRPC bridge complements this bridge offering with minimal maintenance of the client, as only a protofile is required.
Combined with grpc-web, it extends the Vert.x event-bus to the browser in a similar fashion than the SockJS event-bus bridge does. This does not replace the SockJS bridge, rather it complements it.
- Drop RxJava support
- Despite RxJava 3,the use RxJava 2 is still dominant
- Prune callback support
Dropping dynamic resolution of metric ids is under consideration, because the performance impact is not negligible.
The Vert.x CLI was popular a few years ago while it was the most prominent way to use Vert.x. Vert.x 3 started to embrace the fat jar approach and since then grew in popularity to the point that maintaining the CLI support is no longer necessary. Vert.x 5 will drop the CLI support, yet it will keep the Vert.x launcher feature and the convergence of its jar dependencies to provide a coherent stack to integrate with.
Superseded by the virtual thread incubator project.
Service factory is no longer adapted for delivering Vert.x services. For the most part it relies on classloading and clearly the Java platform has evolved toward a path that does not encourage classloading.
- vertx-service-factory
- vertx-maven-service-factory
- vertx-http-service-factory
- JDBC client API is removed
- the SQL client implementation is kept
We continue to support it, although we won't encourage to use it. Modern micro services usually rely on Kubernetes instead.
- CLI and documentation removal
- Deprecate corresponding configuration (VertxOptions)
Docker image generation is dropped.