Project Avatar was open sourced at this year’s JavaOne Conference, but the framework has been under development for a while, and was first announced at JavaOne in 2011. The primary purpose of Avatar is to give Enterprise developers the ability to develop “modern” applications with Java EE 7, by leveraging much of the “Future Tech” that EE 7 brings to the enterprise realm.

One of the showcase features of Avatar is that its applications can be built to employ the powerful features of HTML5, like WebSockets, all the while not requiring developers to write any front-end JavaScript. It even builds the view components as single-page applications, sporting its own hash router that’s driven without the need for any explicit programmatic interaction. Indeed, the entirety of an Avatar application’s front-end can be broken down to HTML and some Java Expression Language code.

And while, “no front end JavaScript required” is an impressive feature of the framework, perhaps its most tantalizing assertion is that Avatar developers don’t even need to write Java code. In fact, a full-stack Avatar application can be written and deployed without ever importing a package or defining a class. This is all possible because of the fact that Avatar application are required to be written and run under JDK 8. This is needed because the framework is built entirely on the basis of the Nashorn ECMAScript engine that is to be delivered with the upcoming release of the Java programming language.

Nashorn is arguably one of the most impressive components of Java 8, perhaps second only to Project Lambda. Nashorn provides a fully-compliant ECMAScript compiler and runtime environment on the JVM, opening the world of JavaScript to the server-side Java developer, and allowing an intermingling between the two languages. All of the server-side code in an Avatar application is run through the Nashorn engine, making it a seamless integration into the runtime container. As it stands today, Glassfish is the required container for Avatar applications.

Developing applications under Glassfish presents its own set of challenges for those developers coming from a more-contained development experience. Having developed Grails applications on the regular for the past few years has definitely spoiled me to the seamlessness of the embedded container during development and testing. Even developing Java EE web applications is pretty easy if you are able to benefit from an embedded container like Jetty or Tomcat. Suffice it to say, the process to get Glassfish up-and-running is less streamlined than a simple grails run-app.

Nevertheless, the appeal of Avatar was enough for me to undertake getting Glassfish going, so that I could see if the framework lives up to its promise. My final assessment of the framework is that it does deliver on its sales pitch, and it is very exciting to see Oracle moving the direction of polyglot implementations on the JVM. I’ve been very opinionated, and remain to be, on the matter that I believe that the web frameworks that will win in the long-run are those that are able to support a variety of languages in their application implementations. Seeing Avatar as the premise to that future is validating, and a welcome refreshment to the enterprise web development space.

However, I was still faced with the problem of bootstrapping a development environment that would make me as productive with Avatar as I am with other frameworks. Luckily, the Glassfish developers have gone to the extent to provide an all-inclusive embedded artifact, which can be used to fire-up a standalone container instance. Though perhaps not as perceptually seamless or streamlined as its counterparts in the field (and certainly not as well documented), after much trial and error, I was able to produce a project under Gradle that leveraged the embedded context for compilation and development runtime. The result is a project structure where I can write, compile, and archive Avatar applications.

The project defines a source directory under src/main/avatar, which is where the Avatar application code and resources are homed. The run task is handed off to the com.objectpartners.avatar.Main class, which is what’s responsible for bootstrapping the Glassfish container and deploying our application.

As expected, the verbosity of code for this process is greatly reduced when utilizing Groovy, so that is the core-language of choice in this example. Given that the Gradle task is simply a JavaExec type, any runnable Java class will do.

You may notice from the project build file that some of the dependencies are resolved from the lib directory of the project. The reason for this is that (at the time of this writing) the Avatar artifacts are not available in a Maven repository. Given that, you’ll have to download a zip file of the project and extract it somewhere. Once it’s extracted, you can copy all of the jar files from the glassfish4/glassfish/modules/ directory into your project’s local lib directory.

When you’re ready to go, you can write your Avatar application and fire it up with gradle run.

I’ll be delivering a webinar this week on developing web applications in Avatar, which will demonstrate its features and functions. All of the project demos will be self-contained and runnable given the above project configuration. If you or your organization are interested in the webinar or Project Avatar, please do not hesitate to contact us today!