Kinja Technology
Kinja Technology
Illustration for article titled A Quick review of Avatar.js

Avatar.js is touted as Oracle's answer to popular server side JavasSript solutions like node.js. It's running on Nashorn, supports most of the core node API-s and comes with custom integration for doing HTTP, WebSockets and SEE. It also provides a data access API.


That sounds good on paper but how does it stack up against node.js or other Nashorn based initiatives?

Let's find it out!

Main concepts


Views in Avatar contain regular HTML markups combined with Avatar specific attributes (data-model, data-type, data-url) and #{} tags that encapsulate Expression Language(EL) expressions. A data-model identifies a model, while a data-type attribute provides a binder between a model and the corresponding url (data-url).


In the example above, we first define a Server and an Updates model. Then bind these to specific services. After that, we declare input/output fields and attributes in order to communicate with our services and finally, we also setup the backend REST call via EL.



Avatar provides access to three different protocols: HTTP(REST), Push service(SSE), Socket service(WebSockets).


Avatar services can be obtained via "org/glassfish/avatar" JavaScript module. Since Avatar is single-threaded and asynchronous, services need to be registered.


In the example above, first we register a REST service where we define the different behavior for our PUT and GET methods. (The only interesting thing to note here is that avatar methods start with a dollar sign.). Then we bind the $onOpen and $onTimeout events to our push event (i.e. pushing out the time via SSE every second).


Right now the only way you can talk to data stores (or external services) is via DataProviders. DataProviders can obtain data from either a "key=value" property text file or from a database using JPA (yep!).


Launch a service

Finally, Avatar apps can be started like this:

asadmin start-domain && asadmin deploy demo

And that's it in a nutshell.


Development environment

The dev environment unfortunately is clunky. The log file is hidden, log messages are hard to parse, also there is nothing on the console. Deploying a JavaScript app to an application server feels odd and cumbersome. The role of avatar script and certain avatar tasks are somewhat unclear. Sometimes my glassfish server went into some sort of a loop or gave me this (my MBA has 8gb of RAM):

Illustration for article titled A Quick review of Avatar.js

Other times, my Avatar app got into a weird state and only a redeploy could help.

Concurrency model

Even though Avatar is running on the JVM, it's trying to mimic node.js' threading model (e.g. single-threaded, async). While the single-threaded, evented design makes sense, being on the JVM should mean some sort of API support for threads (perhaps in the form of WebWorkers).


The other interesting thing to note is that Avatar APIs can deal with both callbacks and promises. Personally, I don't think having this duality on such a low-level is a great idea, certainly not from an ecosystem standpoint.

Java EE & ecosystem

And this brings us to the next point: most of the underlying Java ecosystem and especially the EE libraries are synchronous. As far as I can tell, Avatar does not provide any simple API to at least wrap these blocking calls into Promises or Avatar specific concurrency abstractions.



  • leading dollar signs in Avatar method calls feel rather arbitrary
  • models potentially need to be defined both at client and server side
  • no way to make external HTTP calls
  • no special support for sharing code between backend and frontend
  • no way to access a database without JPA or wrap existing solutions
  • unclear how to deal with exceptions on main thread (Node uses a concept called Domain)
  • The REST data binding for JPA models (in the form of data-props="dependsOn:'itemCollection' attribute) is unnecessary complicated
  • No support for Chunked responses. (Chunked responses and XHR2 on the client side provide a great streaming combo. In terms of browser support it beats SSE hands down.)


Avatar is only a preview right now, so things may change until the final release but my current impression is that Oracle is mainly counting on Java EE folks who are interested in dynamic languages and heard about node.js. (However, it's hard to see why even this crowd would not go with a more mature web stack like JRuby on Rails.)


As for everyone else, using Nashorn scripting as a way to cobble together flexible evented services is still going to be an exciting option.

Either way, Java 8 can't come quickly enough!


removed inaccurate point about node support. Please see comments.

Share This Story

Get our newsletter