Eclipse Vert.x 4 milestone 3 released!

We are ex­tremely pleased to an­nounce the third 4.0 mile­stone re­lease of Eclipse Vert.x .

Vert.x 4 is the evo­lu­tion of the Vert.x 3.x se­ries that will bring key fea­tures to Vert.x.

This re­lease aims to pro­vide a re­li­able dis­tri­b­u­tion of the cur­rent de­vel­op­ment of Vert.x 4 for peo­ple who want to try it and pro­vide feed­back.

Futurisation

Vert.x 4 ex­tends the 3.x call­back asyn­chro­nous model to a fu­ture/call­back hy­brid model.

public interface NetClient {

  // Since 3.0
  void connect(int port, String host, Handler<AsyncResult<NetSocket>> handler);

  // New in 4.0
  Future<NetSocket> connect(int port, String host);
}

This third mile­stone makes progress and coverts the fol­low­ing stack mod­ules:

• vertx-​service-discovery
• vertx-​config
• vertx-​circuit-breaker

Data object mapping for service proxies

Vert.x 3 ser­vice prox­ies is a light­weight layer on top of Vert.x Event-​Bus pro­vid­ing typed con­tracts.

One can eas­ily cre­ate a ser­vice on top of the Event-​Bus.

@VertxGen
interface DateService {

  // callback the handler with the current date
  void date(Handler<AsyncResult<String>> handler)
}

Ser­vice prox­ies re­quest/re­sponse pay­load are of type JSON.

Of course ser­vice prox­ies allow to map beans to JSON using data ob­jects but this comes with two caveats

• only JSON ob­ject can be mapped
• the data ob­ject must be a @DataObject an­no­tated bean with a toJson() method and a JSON ob­ject con­struc­tor

In Vert.x 4 we ex­tend the data ob­ject sup­port to any Java class and any JSON type, e.g in this ex­am­ple

@VertxGen
interface DateService {

  // encode the date with iso date format
  @Mapper static String toJson(ZonedDateTime value) {
    return ZonedDateTime.format(value);
  }

  // decode the date with iso date format
  @Mapper static ZonedDateTime fromJson(String value) {
    return ZonedDateTime.parse(value);
  }

  // callback the handler with the current date
  void date(Handler<AsyncResult<ZonedDateTime>> handler)
}

The gen­er­ated code will then use these map­pers to en­code and de­code JSON val­ues.

For reusabil­ity map­pers can also be java.util.function.Function in­stead, e.g

@Mapper Function<String, ZonedDateTime) fromJson = ZonedDateTime::parse;
@Mapper Function<ZonedDateTime, String> toJson = ZonedDateTime::toString;

Mongo client GridFS

The client can store and re­trieve files and bi­nary data using Mon­goDB GridFS.

Future<String> fut = gridFsClient.uploadFile("file.name");

fut.setHandler(res -> {
   if (res.succeeded()) {
     String id = res.result();
     //The ID of the stored object in Grid FS
   } else {
     res.cause().printStackTrace();
   }
 });

The client can per­form the usual CRUD op­er­a­tions on files and also pro­vide bucket man­age­ment.

Vert.x Web utilities

While the rout­ing con­text will allow you to ac­cess the un­der­ly­ing re­quest and re­sponse ob­jects, some­times it will be more pro­duc­tive if a few short­cuts would be present to help with com­mon tasks. A few helpers are present in the con­text to fa­cil­i­tate with this task.

Serve an “at­tach­ment”, an at­tach­ment is a re­sponse that will trig­ger the browser to open the re­sponse on the OS ap­pli­ca­tion con­fig­ured to han­dle a spe­cific mime type. Imag­ine you’re gen­er­at­ing a PDF:

routingContext
  .attachment("weekly-report.pdf")
  .end(pdfBuffer);

Per­form a redi­rect to a dif­fer­ent page or host. One ex­am­ple is to redi­rect to an HTTPS vari­ant of the ap­pli­ca­tion:

routingContext.redirect("https://securesite.com/");

Send a JSON re­sponse to the client:

// no need to specify the content type headers
rc.json(new JsonObject().put("hello", "vert.x"));

Sim­ple con­tent type check:

if (routingContext.is("application/json")) {
  // ...
}

Ver­ify if a re­quest is “fresh” with re­spect to the cache head­ers and the cur­rent val­ues of last mod­i­fied/ etag:

if (rc.isFresh()) {
  // client cache value is fresh perhaps we
  // can stop and return 304?
}

Other changes

• Groovy has been sim­pli­fied in Vert.x 4 to re­move code gen­er­a­tion that was not re­ally needed in prac­tice
• The orig­i­nal Redis client dep­re­cated in 3.7 has been re­moved re­placed by the new Redis client
• JSON changes
  • Jack­son data­bind is now an op­tional Maven de­pen­dency which means that ap­pli­ca­tions need to ex­plic­itly add this de­pen­dency to the class­path
  • Spe­cific Jack­son util­ity meth­ods are moved to spe­cific Jack­son classes
  • Vert.x can use an al­ter­na­tive im­ple­men­ta­tion than Jack­son for JSON en­cod­ing and JSON de­cod­ing
• The fol­low­ing com­po­nents have reached their end of life and have been pruned
  • MySQL / Post­greSQL async client re­placed by the Vert.x SQL Client (since 3.8)
  • AMQP bridge re­placed by the Vert.x AMQP Client (since 3.7)

Ramping up to Vert.x 4

In­stead of de­vel­op­ing all new fea­tures ex­clu­sively in Vert.x 4, we in­tro­duce some of these fea­tures in the 3.x branch so the com­mu­nity can ben­e­fit from them. The Vert.x 4 de­vel­op­ment focus on more fun­da­men­tal changes that can­not be done in the 3.x se­ries.

This is the third mile­stone of Vert.x 4, we aim to re­lease Vert.x 4 by the end of this year and you can of course ex­pect more mile­stones to out­line the progress of the ef­fort.

Finally

The dep­re­ca­tions and break­ing changes can be found on the wiki.

For this re­lease there are no Docker im­ages.,

The re­lease ar­ti­facts have been de­ployed to Maven Cen­tral and you can get the dis­tri­b­u­tion on Maven Cen­tral.

You can boot­strap a Vert.x 4.0.0-​milestone3 project using https://start.vertx.io.

The doc­u­men­ta­tion has been de­ployed on this pre­view web-​site https://vertx-​ci.github.io/vertx-​4-​preview/docs/

That’s it! Happy cod­ing and see you soon on our user or dev chan­nels.