Vertites,
I was thinking of putting together an alpha, or "preview" release for
Vert.x 3.0 today, then I thought, well, if you want to see what is going
on you don't need to download a tar.gz distro and install it, all you
need to do is look at an example Maven project - all the Vert.x
dependencies are already in
oss.sonatype.org as snapshots. Creating a
tar.gz doesn't really add much at this point. So I'm not going to create
a "release", but I will explain what is new in Vert.x 3.0 and explain
how you can explore this.
We can create more updates like this as things progress.
I include below a list of the main changes in Vert.x 3.0 (amongst other
things) to date, compared to Vert.x 2.x. This is not an exhaustive list,
there have been many, many small changes, fixes and new features, so
I've just highlighted some of the more significant ones.
* Code location
Vert.x 3.0 core is in the main Eclipse project:
https://github.com/eclipse/vert.x (master branch)
The rest of Vert.x 3.0 is under the new Vert-x3 umbrella organisation in
GitHub:
https://github.com/vert-x3/
* No more module system
The Vert.x module system has gone. Now you create your verticles and
package them into standard java jars. These jars can be pushed to Maven
repositories (or bintray) just like any Maven artifact.
When you use these artifacts in your application you specify them as
standard Maven dependencies in your project and they are resolved at
build-time, not at run-time like in Vert.x 2.0.
Non Java verticles (e.g. JavaScript) can also be packaged in jars and
pushed as Maven artifacts. We will also support resolving in other ways
and from other places (e.g. at run-time and from npm modules) before
3.0.final.
We recommend package your application into [a set of] of fat executable
jars which contain all the dependencies they need to run. The example
project (see bottom of this document) shows an example of that.
* Code generation of other language APIs
One of the big pain points of Vert.x 2.x development was keeping all the
other language APIs in sync as changes occur in the Java core APIs, as
it was a manually process. As we have a small team, this was becoming
unsustainable and hard to manage.
In Vert.x 3.0 we maintain just the core Java API and we will generate
other language APIs from that.
Generation works by inspecting the Java source of the core APIs before
compile and constructing an internal model from that. This is then fed
into a MVEL2 template (one for each language) which then outputs the
code in other languages.
In order for codegen to be feasible we specify a set of constraints that
any API that we run codegen on must follow. The codegen project details
these constraints:
https://github.com/vert-x3/codegen
So far we have JavaScript and Groovy more or less complete, and Julien
is currently working on Ceylon. Other languages will follow.
* Use of Maven for the Vert.x builds
We now use Maven, not Gradle to build the Vert.x main project and the
"ext" projects. Please note that we do not mandate Maven for your own
Vert.x 3.0 projects - you shoud be able to use whatever build tool you
want for that (e.g. Gradle). Vert.x 3.0 projects generally have a very
simple setup (much simpler than Vert.x 2.0).
* Java 8 only
Vert.x 3.0 is Java 8 only. This is to take advantage of new language
features in Java 8, the most important of which is Lambdas which make
developing against event based APIs so much nicer than in previous
versions of Java. We also chose Java8 so we can use Nashorn - the new
high performance JavaScript engine that it contains.
* Flat classpath by default
When deploying verticles, there is a simple single flat classpath (by
default). This should greatly simplify embedding and debugging. If you
do wish to deploy verticles with classloader isolation this is still
available as an option, but it's considered an edge case now.
* Verticle factory simplification
There is no more `langs.properties`. Verticle factories are loaded from
the classpath using the service loader pattern. Verticle factories can
also be registered and unregistered programmatically.
* Deployment of Verticle instances
You can now instantiate verticles and deploy verticle *instances*
programmatically.
* Warnings if you block an event loop
You will now see warnings in the logs if you inadvertently (or
deliberately!) block an an event loop, so you can identify and fix the
issue more quickly. You will also see warnings if you block a worker
thread for too long.
* Removal of platform manager
The platform manager API has been removed, and methods for deploying
verticles have moved to the Vertx interface. The API for deploying
verticles is much simpler, so this should simplify things when embedding.
* Programmatic cluster manager
Cluster managers can now be specified programmatically
* Clustered shared data
Vert.x now supports a distributed Map API which works across the
cluster. You can put data in at one Vert.x node and read it from another.
We also provide an asynchronous cluster wide lock implementation, and
asynchronous cluster-wide counters. These are very useful building
blocks for distributed applications.
* Completely rewritten HTTP client
The HTTP client has been completely rewritten with much saner behaviour
for opening and closing connections, pipe-lining and keep alive.
* WebSocket API improvements
The WebSocket API has been improved so you can now send and receive
WebSocket frames.
* Improvements to SSL/TLS
The new SSL API allows you to configure certificates and keys in several
ways, not just with Java key stores. For example, with Strings and
Buffers (similar to Node.js).
We also support certificate revocation lists and specification of cipher
suites.
* Event bus API improvements
When registering a handler you now receive a Registration object which
you can later use to unregister.
We also now support custom codecs on the event bus so you can send any
object you want across the event bus (e.g. a POJO) as long as you write
a codec for it. We also support receiving messages as a different type
to what was sent, e.g. you could send a buffer which contains some BSON
and receive it as a POJO representing that BSON.
* Event bus proxies
You can register service interfaces with the event bus, then you can
interact with the service from a completely different verticle using a
proxy for the service.
* The 'ext' stack
https://github.com/vert-x3/ext
Vert.x extensions live in the `ext` project. This is functionality which
is not part of Vert.x core but contains useful stuff that people need to
write real applications with Vert.x. You can think of this plus Vert.x
core comprising the Vert.x "stack".
So far, ext just contains a few things including: SockJS, RouteMatcher,
and MongoService and Reactivestreams but will contain many other
services before 3.0.final.
A lot of the work in Vert.x 3.0 is in creating this stack.
* MongoService
This is a component of the ext stack. It's an API that lets you interact
with a MongoDB database. It uses the experimental 100% Async driver from
the MongoDB folks. You can deploy it as a verticle and interact with it
over the event bus using a proxy.
* ReactiveStreams
This is an implementation of
http://www.reactive-streams.org/
* Use of options classes
We now use options classes widely throughout Vert.x in order to
configure objects. This means a lot of the setter methods on interfaces
such as NetClient, NetServer, HttpClient and HttpServer have been removed.
* Example project
I've put together an example Maven project which shows how you might
write a simple application with Vert.x 3.0.
It's a simple web application that uses SockJS and also has a REST API.
It has a JavaScript main verticle which starts up the app and a Java
WebServer and a Groovy stock ticker.
https://github.com/vert-x3/example-proj
* What's next?
** Most of Vert.x 3.0 core is done but there is a some more work to do
** More work on codegen
** Codegen templates for other language APIs (Scala, Ruby etc)
** Documentation, including JavaDoc/Asciidoc.
** The rest of the ext stack. This is where most of the work is.