Part I – Parallel event loops

Oracle presents: Avatar 2.0 – where to next?

Niko Köbler
Data illustration via Shutterstock

Oracle recently announced a new version of the JavaScript platform Avatar. It’s time to take a deeper look at the changes that await us.

For three years now, Oracle has presented news related to the JavaScript platform Avatar at the annual developer conference in San Francisco. And this year was no different.

Avatar originally started as pure HTML5 / JavaScript framework. Since then it has been enriched on the server side with Node.js implementation for the JVM (called Avatar.js) and Java EE specific extensions. “Project Avatar”, the open-source project, never made it past the early-access stage (i.e. version 1.0).

In the last six months, not a single commit in the code has appeared in public repository – only tests and comments were added or changed. But at the recent JavaOne, John Clingan – the Principal Product Manager of Oracle GlassFish team and also responsible for the avatar activities – announced some Avatar news.

In previous years there has been a great deal of confusion about the naming of Avatar.js (the Node.js runtime environment for the JVM) and Project Avatar (the Java EE feature enhancements) – now Oracle only speaks of “Avatar 2.0”.

Application Server: passé

The biggest change is certainly the fact that a Java EE application server is no longer required to run Avatar. Until now, the GlassFish 4 and Oracle WebLogic version 12.1.3 were supported (or even required). Avatar 2.0 is now running in a separate JVM, in a separate process and can be easily started from the command line.

As a result, users can avail of the already built-in HTTP module (like with Node.js) and are no longer subject to the restrictions on the use of the HTTP stack. This feature allows Avatar 2.0 to avail of even more standard Node applications that use the HTTP module. A management integration in the WebLogic Server is currently under consideration and this release is expected soon.

avatar 2.0 architecture

Avatar 2.0 architecture © Niko Köbler via

Parallel Event Loops

A great advantage of Avatar 2.0, compared with standard node environments is that parallel event loops can run in their own threads, but these only require one single JVM process at the operating system level. This means only a single process must be monitored and managed.

All event loops share a single port via the built-in HTTP Load Balancer. With a 16-core processor, 16 event loops (each loop in one thread per core) can be managed in a single process through one operating port. Operating that kind of infrastructure with Node.js is much more complex and cumbersome.

The individual event loops can communicate with each other via an internal event, Message Bus or Shared State. This means the exchange of data between states and various threads is possible at runtime. An event bus listener for a specific topic can can be registered with:

// listen for messages on topic 'hello'
bus.on('hello', function(body, msg) {
     print(name + ' got message: ' + JSON.stringify(body));

You can send messages (from other parallel threads) with:

// publishing to 'hello' topic:
bus.publish('hello', { x : 'x', y : 'y' });

Data that is sent via the Event Bus is not persistent and if a recipient is not available at the time the message is sent, the message disappears into oblivion. If you want messages be stored for a while so they can be accessed at a later date (eg. to recover a certain state), you can use the Shared State which is implemented with a map API.

var state = avatar.application.state;
state.put('key', {'value': 'myValue'});
var object = state.get('key');

Even here, Oracle is resorting to coherence as a cache implementation, so that even a distributed communication is possible, not only across multiple threads in the JVM, but also across multiple nodes and JVMs. Since coherence has also implemented the JCache JSR-107, it is even conceivable that other applications not based on Avatar 2.0 can participate in this shared-state communication.

Read Part II on Avatar 2.0 – the Model Store API and the removed client framework

Originally published on / translated by Anna Job

Niko Köbler
Niko Köbler is a freelance software architect and Java and JavaScript developer, as well as a regular speaker at JAX conferences.

Inline Feedbacks
View all comments