October 3rd, 2014

by Ivan St. Ivanov


This post will be covering days two and three of JavaOne. The reason for that is that yesterday morning I had to prepare for my first ever talk at JavaOne.

The batch talk

In March this year I had great time at the JavaLand conference. Along with other great people, I met there the freelancer and blog author Roberto Cortez. He told me that he is going to send a few session proposals to JavaOne and asked me whether I wanted to join him for the Java EE Batch talk. I hadn’t heard much about that topic at that time, but I agreed. Then the proposal got accepted and here I am at JavaOne now. What do you know…

Our intention for this talk was to introduce the audience to the Batch applications as a whole with topics like what is batch, why do we need it, is there batch processing in real life, etc. Then we wanted to continue with a review of the JSR 352 (Batch Applications for the Java platform) APIs. And last but not least, we wanted to live code a real world application. The topic that we chose was aggregating World of Warcraft auctions data per realms, processing and presenting some statistical data like minimum, maximum and average bid for the items at various auction houses. We (well, mostly Roberto, to be honest) even prepared that application beforehand.

The risk here was that the topic is so broad, that we were afraid that we may not have time to deliver everything as planned. We also made the things even more complex by letting the audience ask questions anytime they have it. And of course the time was not enough and we could not do the live coding session. On top of that I was surprisingly to myself extremely nervous during the session and delivered one of the poorest performances in my talk-giving history. I will not go into details on what is batch and what’s the patch processing in Java API, Roberto already uploaded the slides.

The coolest thing about this is that we (and especially myself) have our lessons learned. And the next time we give this talk we’ll be much better prepared. And this next time will be the Java2Days conference in Sofia mid of November. I would love that the order would be the other way round, but…

Java concurrency internals

A while ago I read a brilliant article by Gleb Smirnov about how setting and reading volatile variables in Java works under the hood. This year at JavaOne I had the opportunity to see the author of this post live on stage explaining all these things for the mere mortals as me.

In a nutshell, javac and then the JIT compiler make optimizations of the executed instructions. Sometimes these optimizations are more aggressive (in the server VMs for example), which means that the compiler would make more assumptions on the program flow. One of these optimizations is reordering instructions to avoid cache misses when a variable value is read or written. To make things even more complicated, in a multicore environment we have multiple level of caches on every core.

So if we want to make sure that the most recent variable value is read by all cores at any time, we declare that variable volatile. This would make the compiler emit memory barrier instructions. What a memory barrier ensures is that all the read operations above that instruction will stay there and will not move below it. The same if the read operations are below the barrier and the same with the write instructions. The other thing that the volatile keyword implies is that long and double variables that have it are written in atomic fashion.

This might sound very simplistic, but if you want to get into more details go and read the article. The slides are also available online.

After the talk I asked the speaker whether the synchronized blocks have the same effect. He told me that in principle yes. But they do also many other sorts of things so for something as simple as telling the compiler not to reorder read and write instructions, volatile is a better option.

Java EE. Again and again

I visited a lot of Java EE talks these days most of them given by distinguished luminaries from the industry.

First, Dave Blevins of Tomitribe gave one of those talks that only he is capable of on Java EE game changers. Let alone the fact that his “slides” were actually in the IDE, he again managed to present the topic without just boring us with endless rumbles on the other cool feature in the platform. Amongst the biggest game changers he mentioned the introduction of annotations (heavily inspired by XDocklet) which allowed the revolutionary change in Java EE 5 that returned the people back to the platform. Being able to package almost everything in a single (war) archive was another important turning point in the Java EE history. It removed the impression of java web applications looking like Russian dolls. The embedded EJB container functionality introduced in Java EE 6 makes it possible to very easily create a microservice out of a Java EE application. Even now you can take the TomEE server and run a Servlet, CDI, JAX-RS and what not in your public static void main class as described in this great blog post from Alex Soto and can be showcased in this simple Java class. Dave shared also his regret that Spring is not on the JCP. The talk finished with an outlook on the future: how the Java EE APIs can be adapted with respect to the big thing in Java 8: the lambdas and especially the method references.

This year I went to only one talk by Adam Bien. In that he challenged a lot of practices considered as a norm in most of the Java EE projects these days:

  • Too many layers. He made a joke that in a project he deleted most of the layers and the app was still working
  • Thinking about wrong thing first: create all the exceptions (and putting them in an exception package) or deciding on what framework to use prior to even thinking about the domain model and requirements
  • Including all sorts of external dependencies without even checking whether the JDK or Java EE has the same functionality

Among the good practices he mentioned having a simple design and implementation (there are even tools that measure that), continuous quality, short development cycles, bottom up approach on architecture, boundary-control-entity layout of the application, etc. In his opinion Arquillian is a great tool, but is overly used these days. For simple tests he proposed having a simple unit test with some mocks. It wouldn’t be Adam Bien if the talk didn’t contain live coding part.

Manfred Riem (very well known in the JSF world) gave a talk on one of the newly proposed JSRs for Java EE 8 – JSR 371, the Model View Controller specification. It provoked a lot of comments in the java world these days: why do we need another MVC solution in Java EE as we already have JSF, do we want to have Struts again, etc. So Manfred went on to explain the difference between the Component-based MVC (JSF being of this type) and action based MVC (e.g. Spring MVC). The main difference is that in the first type the request processing is responsibility of the framework, while in the other case the application developer should take care of it. At the end, it was the community that wanted this in the survey done by Oracle a few months ago. Manfred showed what his view of the future API will be. The second part of the presentation was on some extensions in Jersey (the JAX-RS reference implementation), which allow to have real action based MVC in Java EE even now. I think it is a very good opportunity for JUGs to adopt this JSR, as it is on one side a cool thing to work on and on the other side it is something very important for the industry. That is why I will propose it to our JUG once I get into Bulgaria, hoping that we have some experts in the area.

Finally I went to a talk describing various recipes for concurrency in Java EE. As of Java EE 7 application modules can get the good old java.util.concurrent.Executor service (managed by the containers of course) and do things like executing jobs in the background (also showcased in our Java EE batch presentation), scheduling tasks for executing later or repeatedly at a certain interval, etc. You can even obtain and execute plain old Java threads now inside a Java EE application using the ManagedThreadFactory.

Hacking @ JavaOne

This year I spent quite some time at the Hackergarten area in the exhibition hall. It becomes a tradition for me to make contributions to the Arquillian group of projects at JavaOne. This year I worked on something new: a Groovy DSL for running the tests. After some help from the project lead (happy birthday, Aslak!) I was managed to come with my pull request: added support for modelling deployments to different runtimes (just modelling, not real deployment).

I took part in the Adopt OpenJDK  hands on lab as well. Not too many showed up, but I helped Martijn from LCJ to introduce how you download the sources, configure and build them. I wanted to show the people how they can change a class (StrgingBuilder for example) and then run their program against JDK built with that change in. But things were running a bit slow, so there was no time for that final step.

At the end we sit together with George Gastaldi from the Forge team. He helped me with FORGE-1610. Unfortunately we did not complete it. We must work on making Furnace test run faster on Windows (Really? OK)!

So much good things to come…

Leave a Reply