Project Avatar - What's in it for Java EE 8?

Tweet

With Java EE 7 out the door since a while it is already time to start planning for the next revision of the platform which will most likely be called Java EE 8. Oracle set up a community survey with which they would like to get input from the community on the relative importance of some of the features they intend to add. First of all this should encourage the interested reader to participate and take the survey. One particular point in it is all about support for HTML 5 based, dynamic applications. While WebSocket and JSON Processing already made it into Java EE 7 there is another feature particularly in GlassFish and WebLogic (via Jersey) at the moment which has some potential to be standardized. The Server Sent Events (SSE). It already is part of the HTML5 spec and would be a very good candidate for standardization. But Oracle is thinking even further and is asking if there would be enough support and interest to actually standardize the use of JavaScript on  Java EE servers. When this kind of question started to appear at JavaOne 2012 it was basically referred to as Node.jar on Nashorn. Since this September we know the real name: Project Avatar.

Avatar At A Glance
Project Avatar provides a JavaScript services layer zeroed in on supporting REST, WebSockets and Server-Sent Events, and a rich client side framework that assumes very minor JavaScript knowledge. The services side is focused on building data services using JavaScript, while the optional client side is entirely focused on supporting HTML5 and TSA (Thin Server Architecture).

Project Avatar (Source: avatar.java.net)

Thin Server Architecture
With the introduction of HTML5, CSS3 and fast JavaScript engines, modern browsers have become a powerful platform. In the advent of the so called single-page application (SPA), also known as single-page interface (SPI) the design of modern user interfaces shifted away from server side generation to web applications or web sites that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application. An SPA moves logic from the server to the client. This results in the role of the web server evolving into a pure data API or web service. This architectural approach has been coined "Thin Server Architecture" to indicate that complexity moved from the server to the client while reducing overall system complexity.

What is really in Avatar?
But Avatar is far more than just a TSA approach. It basically consists of three parts. The foundation is build by the upcoming Java 8 and it's included JavaScript implementation called Nashorn. On top of it is the Avatar Runtime including an additional compiler layer and a Servlet API based server. Those abstractions  enable it to be hosted on various runtimes. Avatar applications are comprised of either client side ‘views’, server side ‘services’ or both. Importantly, there is no inherent coupling between them which enables views to communicate with existing services and for services to be consumed by any type of client. An application ‘archive’ is deployed on the server and is compiled to generate JavaScript tailored to the application. Generated JavaScript for views handles data-binding with the DOM/UI as well as data-management to remote services and local storage. The Avatar archives are somewhat similar to Java EE web-archives. They consist of a WEB-INF folder, an avatar.properties file in the root and either a views directory and/or a service directory. Both file-system directories or .zip (.war) files are supported by Avatar.

All that is left on the Server - Services
An service extends either a REST, WebSocket or Push (SSE) abstraction and it's life-cycle is completely handled by the framework. Service implementations can leverage built-in Node modules as well as most third-party modules. Thanks to Nashorn's support for direct invocation of Java code you can also use most Java libraries directly.

The Client Side - Views
A view is the HTML required by the browser. It also contains custom 'data-' HTML extensions and simple JavaScript models. Those views get translated by a (server-side) compiler before sending the complete SPA HTML file including the custom generated JavaScript to the browser.

Putting it all together. A Simple Example.
Oracle provides a decent set of examples and documentation for Avatar which basically is enough to get you started. First thing to try it out yourself is a JDK 8 Early Access Build for your OS. At the time of writing I tried it with the latest Developer Preview b118. After installing you need to get the latest GlassFish Open Source Edition 4.0 server and unzip it into a suitable location. Make sure it runs with the installed JDK 8 by either putting <jdk8>/bin to your PATH environment variable or adding the following entry to the <gf4>/glassfish/config asenv.bat/conf

set AS_JAVA=<jdk8>

Now go ahead to download latest avatar-1.0-ea.zip and expand it to the <gf4>/glassfish/ directory. After that you need to set a AVATAR_HOME environment variable and point it to the <gf4> install directory. And make sure to add %AVATAR_HOME%\glassfish\bin to your PATH environment variable.
If all of that is done you can switch to your workspace folder and issue the following command to have Avatar creating a simple example app for you:

avatar new --example=hello

It creates a basic "hello" application which only consists of a view. It is a good place to start exploring and you can directly start your Glassfish instance afterwards and deploy the application as you would with every typical Java EE application:

asadmin start-domain

asadmin deploy hello

The "hello-example" app.

Pointing your browser to http://localhost:8080/hello will display the application. You can start editing the view located at <workspace>/hello/view/src/hello.html directly. While the server is running Avatar takes care of re-compiling it directly for the next request. This ensures a rapid development. This behavior is controlled by the "debug=true" property in the avatar.properties file and can be altered for productive systems. Further on, setting it to false causes all .js and .css files to be minimized before delivery.
At least if you first download and add the required YUI Compressor (jar download) to Avatar first. Due to license restrictions it hasn't been bundled. Simply put it into <gf4>/glassfish/modules/avatar-ext/lib. You might need to create that directory first.

Beside this very simple example without any service at all there are more complex ones available with the distribution at %AVATAR_HOME%/Project-Avatar-examples/. For convenience reasons there is a complete examples.ear available which can be directly deployed and tested. To access the samples simply prefix the example name with "demo-". So the "rest" example can be accessed via http://localhost:8080/demo-rest/.

TodoMVC - Example App with Avatar

You have to look out for different features to be showcased in the different examples. If you want to know how Avatar handles persistence you can exactly look into the rest example which uses a FileDataProvider to save the items. Another interesting example is the TodoMVC based app (http://localhost:8080/demo-todo/). It showcases a more complex view which also has been styled.

What is next?
As of today nobody knows what is going to happen with Avatar. The community feedback hasn't been tremendously loud or excited in general. I guess the reason for it is that nobody really knows what to do with it. The biggest drawback as of today is, that it only runs with GlassFish which will further limit adoption and community interest. Given the fact, that SSE isn't part of the Java EE specification it might make it even more difficult to port it to other app-server. Even if the license (GPL2 with Classpath Exception) should allow it. Back to the initial survey and the thought about specifying a server side JavaScript integration with Java EE, you know at least have a brief idea about what Oracle is talking if they are talking about Avatar. Go ahead and take that survey and tell them what you are thinking about having that kind of stuff in Java EE.

Meta: this post is part of the Java Advent Calendar and is licensed under the Creative Commons 3.0 Attribution license. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on!

My vJUG Session: Don’t Be That Guy! Developer Security Awareness

Tweet

I've been invited to talk at the vJUG which is the newest JUG around. A virtual JUG reaching out to interested Java Developers over all time zones and locations. The  aim is to get the greatest minds and speakers of the Java industry giving talks and presentations for this community, in the form of webinars and JUG session streaming from JUG f2f meetups.

"Don't be that guy! Developer Security Awareness" by Markus Eisele
Was a session already scheduled for JavaOne this year. Due to scheduling conflicts I actually had to cancel it and I was pretty excited to finally be able to deliver it to the many who signed up for the session in SF. With 174 registered attendees I count this as a success.

The session was given via Google Hangout (Thanks Google!) and recorded to Youtube for you to re-watch.

The slides are on speakerdeck.com:
Thanks everybody for attending! It was a pleasure!

R.I.P. GlassFish - Thanks for all the fish.

Tweet

We've all heard it coming probably. Yesterday the official roadmap update for JavaEE and GlassFish was updated and published. And beginning with the title the whole post was basically about one thing: GlassFish Server as we know it today is deprecated from a full blown product to a toy product.

The Long Road from Sun to Oracle
GlassFish was something to worry about right from the start. After the merger it took some time to silence the voices which insisted on "Oracle killing GlassFish". Oracle did a decent job in nurturing the community and keeping their stuff together. I've written a couple of blogs myself helping to get the word out. The 100-day releases 2.1.2 and 3.0.1 have somehow become the milestone to prove the will to improve. And we all have been fine with it after a while. Even back in January 2013 I compiled a list of open source application servers and which one to pick. The final criteria was vendor support. That kicked WAS CE out of the game. As of yesterday it would also removed GlassFish. The two remaining alternatives burned down to one: Which is JBoss AS7 / WildFly.

Customers Need Support for their Servers
But come on, what is the issue here? Who wants support anyway? And Oracle obviously did not make enough money out of the commercial licenses otherwise they wouldn't have killed the offering at all. It might not be a very obvious reason but I can offer some kind of explanation. First of all if a vendor is not only developing an open source alternative but also has a commercial offering this leads to different things that will be taken care of implicitly:
- Changes/Bugs discovered by customers go into the oss release
- Changes need to have a decent quality. Developers knowing about the need to support their solutions will be (at least a bit) more careful implementing stuff.
- Developers knowing that their stuff is run under decent load think differently implementing it. The complete list of non-functional criteria changes with that move.
- Customers demand more frequent releases and security patches which also end up in the oss version.
- Customers have different requirements than people using free and open source servers. One prominent example is clustering. Which is rarely used among oss projects.

Another factor is driven by experience. I would never try to develop project on a completely different setting than the production setting is at. Even that both WLS and GF understand at least a bit of each others deployment descriptors there is a high risk buried in here that such a setting is the road to trouble.

The bottom line of my argumentation basically is, that the need for providing a commercial distribution improves the overall quality and reliability by changing some relevant non functional requirements for the product. If those aren't there and nobody is consequently taking care of them ... they will not be in there.

Why will Java EE suffer from a dead GlassFish?
The quality of the Java EE TCK has been questioned a lot. And in the past many people used GF as a showcase for not working code. On top of that some production scenarios and errors lead to different implementations and last but not least specifications. All the practical field knowledge has been in the heads of the team. I don't know how Oracle is running WLS development internally but I expect it do be different from what the team did for GF, probably a bit heavier. Extracting specification edge-cases and removing product specific parts from WLS based customer cases will for sure be trickier and not happen very frequently. So I expect the spec to be a little less Oracle driven and a little less mature generally. Not the worst part in the story. But given the fact that some very bright minds are working in that area I expect that their passion and knowledge will be missed a lot. And there is nobody there to catch them falling.

Which Parts of GlassFish will die?
So GlassFish will stay the reference implementation for upcoming Java EE standards. Oracle needs it to be around just for that one reason. With the emerging JCP which is becoming more and more open it isn't a big surprise that they are not simply going to define WLS as the RI. But that will be the cut between things that will die and things that will be around. I DON'T have any insights here and I'm just speculating and I could make an educated guess about the first comment on this blog but .. bottom line for me is, that everything that isn't covered by the Java EE spec is going to age very fast. This could include clustering and for sure some of the admin features and security also is a good candidate (PAM realm and others). And frankly I can't confirm any of them. It is pure speculation!

Is there a good part in that at all?
Well, yes: The move leaves a field wide open for strengthened competition. And this is not only WildFly but for sure also TomEE with tomitribe. Congratulations to them. Further on many customers will save a lot of license fees. GF and WLS are differently licensed and using WLS standard gives customers more options on picking the right license. And at least the WLS team will be strengthened with those people don't having to switch heads anymore working frequently on different products.

Can Oracle do something to make the killing worth it?
As of today it is a senseless death. Users can simply sit back and wait for the next minor release which probably will happen once a year. If you've been complaining about infrequent releases until today .. prepare for even less in the future. There are indeed a couple of things Oracle could do to make this a strategic move for everybody and not only themselves:
1) Develop and support a clear upgrade path. Find a way to at least support a development setting based on a very lightweight server and only deploy to a full blown WLS in production. With the given features and differences between the two this is hardly a working story as of today.
2) Make an attractive licensing offering for GF users. Not only to the customers as of today but for all. Or even better: Come up with a bunch of licensing terms in the OTN license which allows NPOs to use WLS free of charge.
3) Consequently open-source GF (under a decent license) and make community contributions attractive. The used infrastructure and OCA makes this impossible as of today. Move the server code (including modules) to GitHub and appoint a change manager who reviews and pulls in proposed fixes and changes. Let the community decide on releases.

The Echoes Are Gone In The Hall
Basically the news isn't a big surprise. We all understand the move. Having two servers instead of one is a double burden. With the BEA merger Oracle killed their own application server. Now it was GlassFish's turn. Oracle already tried to reduce the needed efforts to maintain it by merging the teams and also discussed different options along merging WLS to HK2 or extending the use of the same components for both servers. Some things happened and pushed the time for yesterdays announcement out by a couple of months but finally did not prevent it. So. R.I.P. GlassFish. It was nice. Thanks for all the fish.

JavaLand 2014 - CfP Statistics And Answers To Common Questions

Tweet

You probably have heard about the new upcoming Java centered conference in Germany next year. JavaLand 2014 will open its gates for two days. So make sure you are around when this new conference will become the hub of the German Java developer scene. I'm proudly part of the conference organizers and as a program chair I get plenty of help from the awesome program committee which was recruited out of the German JUG umbrella called iJUG.

With every new conference or thing to happen people start asking questions. Until the final schedule isn't published and the first conference is run, most of it is unanswered. But I like to give you a solid first set of impressions about the conference. The following charts and arts are generated based on the more than 400(!) paper submissions we got during the official CfP! It is intended to give you a first impression but will probably not completely reflect the finished conference schedule which will be out shortly (expected: mid November).

The Topics - An Overview

First of all I tweeted a Wordle about the submitted topics.
Basically a broad mix around Java. It is quite interesting to see, that there is quite a bit of Spring in there and JavaFX absolutely was among the big topics. It was good to see, that JVM based languages also got some love because this conference is intended to host different topics around the JVM as a runtime and as such give exposure to all the different JVM languages also. Enterprise and Mobile together with different DevOps topics are spread among the place. If you look carefully you see some German in it. As of today we don't know the ratio between German and English talks. But given the fact that we got a good number of international proposals I expect it to play a role. We basically don't focus on either one. As long as there is good content in it.

Proposed Talks from 18 Different Countries
Overall we got proposals from mostly Europe and the States. In total 18 different countries. Which is amazing! A big "Thank you!" to all the submitters!

What role does Oracle play?
Next big question is what role does Oracle play in all that. The conference is organized by German Oracle User Group (DOAG) and many suspect any (probably unfair) Oracle involvement. The only thing I can reply to it is: There isn't anything wrong going on here. Oracle actually IS supporting this conference along the lines they did before with the annual DOAG Conference and Exhibition. Given the fact, that the DOAG Conference will be hosting less and less Java over the next years Oracle was given the chance to submit talks. Like anybody else could. Additionally they host program committee meetings in their locations. Which was incredibly kind of them. That is great support for the German Java Community!
The overall ratio Oracle vs. Non-Oracle talks in the CfP was 6:94 ... Yes, only 6 out of 100 talks were proposed by Oracle employees. This is not a typical Oracle conference ratio. If you compare the numbers I published from last year's JavaOne the Oracle Speakers take up to 30%.

What will the content look like?
A great question. We don't know yet. The last PC meeting will happen shortly but what I can tell you is how the overall distribution looks like according to the submitted proposals:

Comparable evenly distributed. Except that we got too less security submissions. But at least some good ones. I expected to see more JVM languages talks but the feedback we're taking here is that we did a bad job communicating the focus correctly. We'll try to correct this. We're beginners here. Please be patient ;)

What about the Rest?
There is plenty of stuff upcoming. We are hosting a complete scheduled conference and plan on different community centered activities around it. We also will have some other surprises in stock. Announcements are pending but will follow shortly. Best is to follow @iJUGeV or @myfear on Twitter to stay up to date.

Can I book? Where? How? How much?
Sure you can. The registration is open since a couple of days already. Going for a registration until the 01/31/2014 you get the non-iJUG member price for €250/day. If you're an iJUG Member you get it for €200/day! Which both is nothing!
Find all the details on the registration page. I'm looking forward meeting you there! If you have additional questions feel free to ask! I'll try to answer!

New Article in German iX Magazine: CapeDwarf

Tweet

Another article hit the road today. This time a comprehensive introduction to CapeDwarf which is Red Hat's Google App Engine implementation for AS 7. In German iX Magazine 11/2013.

Flexible 

CapeDwarf tries to bring Google's App Engine to JBoss AS7

Red Hat's CapeDwarf project tries to bring two well-established technologies together: Google App Engine and Red Hat's Java EE server AS 7. The aim of the project is to implement all the APIs that Google App Engine provides and make them available on the application server.

This is a German article and you can either grab the latest issue online or buy it at your favorite kiosk.

Find some other articles of mine by searching this blog for posts labeled "article" and you get some results.