At the beginning of June I had the opportunity of attending the Jazoon conference in Zurich. I will try to focus on the conference and the topics discussed there, instead of talking about Zurich as I don't want this piece to turn into a ten page story. For now, just trust me when I say : go to Zurich and try some Rösti. (You can thank me later) 

 

One thing I totally enjoyed about this conference was the timing. There were no delays, everything happened according to schedule, it ran like a Swiss watch (yes, I know, terrible joke). As the most attendees were from Switzerland and Germany, this was perhaps expected, but for me, it was a nice touch, something I really appreciated. There were lots of topics discussed during the three days of the conference, but if I were to have a tag cloud of the things people were discussing the most it would definitely contain in really big fonts REST, CLOUD, JEE6, JAVAFX, SPRING3.0. I tried to follow most of these topics, trying to see what lies ahead in the months to follow in the Java world. And things look good. 

 

Of course everyone was worried (and most still are) about Oracle's acquisition of Sun, and I think Oracle is doing its best to put people at ease. Being one of the main sponsors of the event, Oracle had its share of spotlight with a very strong focus on Java EE 6 (with Glassfish and Netbeans 6.9 being the de facto tools), and JavaFX. I'll start by saying I personally like EE 6. I don't know yet if I'll use it more than I used J2EE (I've never been a fan of EJBs), but it sure looks a lot easier to develop (well at least Arun Gupta made it look this way). One of the things I found helpful is the fact that web.xml is now optional (most of the setup being possible with just a couple of simple annotations) and modularized, so each of your dependencies can include a web-fragment.xml of their own, which will automatically be recognized and merged into your own. This means that you will no longer have to copy-paste many of the filters and listeners used by various frameworks, as they will already be present in the frameworks themselves. The same goes for resources. If you have for example the same .jsp or .html page used in several of your web applications, then you can simply put it in a .jar file shared by all your applications and it will be automatically picked up by the application server. To use Rajiv Mordani's example, if you have in your application something like this: WEB-INF/lib/shared.jar!/META-INF/resources/shared.jsp then this page can be accessed at http://localhost:8080/mywebapp/shared.jsp. If you are interested in this and other interesting features such as asynchronous servlets (sounds cool, right?), then I suggest you have a look at Rajiv Mordani's presentation on Servlet 3.0. 

Of course there are a lot more things to say about Java EE 6 and for those interested I would suggest following Arun Gupta's blog, as he is one of Sun's (I mean Oracle's) most active evangelists. What I will mention though is the things which relate to Spring. We use a lot of Spring in our projects. When starting a new project it always seemed like you had to make a clear choice: use EJBs or use Spring (it's true that at some point we did use EBJs to expose Spring beans through RMI but that is not always needed/wanted). My feeling was that Spring and J2EE were somehow competing. It's nice that there are a lot of application servers supporting J2EE but then you would still run your Spring application in a web container because let's face it: Spring and Hibernate were ahead of the J2EE specs. Well, this no longer seems to be the case. And by this I mean that a lot of the good ideas promoted by Spring and Hibernate are now in the specifications (EJB 3.1, JPA 2.0, Servlet 3.0, Bean Validation 1.0). So you might ask: why would then anyone still use Spring or Hibernate now? My answer: because they can! And this has always been the beauty of Java: having a choice. People use Java because they do not want to be locked to a specific operating system, to a specific server or application framework. Jurgen Holler explained it best. He said that you could now write you web application using the Java EE 6 specs. You would define your beans, your dependencies using annotations like @Inject, define you persistence layer using JPA and so on. Deploy this on an application server fully supporting EE6 (Glassfish for now) and you're done. By the way, I found out that Oracle is not wasting time and that there already is a commercial version of Glassfish : Oracle Glassfish. But if at one point you are not satisfied with your server's costs or performance, then not only you can deploy your .war to another EE6 server, but you could even drop the application server all-together. Just put Spring and Hibernate (for example) in your application and deploy it to Tomcat. And it will work. It's that simple. If not, well then .. blame Jurgen, he said it.

 

Speaking in terms of quality of presentations, I think Mathew McCullough’s was one of the best at Jazoon. It definitely was the fastest, well rehearsed and with lots of examples. The fast pace at which he presented the new features in Maven 3.0 was in tone with the promised performance boosts in this next version which is in Beta at the time of writing this article. It supports multi-threaded downloads, mandatory plug-in versions, tool-chain behavior (separates the JDK that maven runs on from the JDK used for the build), errors with URLs to wiki pages with possible solutions, etc. The code base is 30% smaller, with around 70% smaller memory footprint. Another big change is that Maven 3.0 is no longer a command-line tool, but a library. You can even add it as a .jar to your application. But it can still be used as a command-line tool; even better, it has it’s own Shell (mvnsh). All this flexibility can lead of course to better applications using Maven, such as an IDE plug-in, for example. And that’s just what they did with the M2Eclipse plugin for .. Eclipse (doh..). It was rewritten from scratch, which in my opinion is very good news for anyone using Eclipse and Maven. For us at least, on the current project I am working on, this plug-in was one of the main reasons we abandoned Eclipse in favor of Netbeans. Hopefully this time they’ll get it right.

 

And speaking of getting things right, according to Stefan Tilkov, developers and web-framework creators never got HTTP right. In the sense that only by using REST you are using the http protocol as it was intended in the first place. He talked about REST in relation to SOA and started by trying to define them both. He pointed out that today, SOA is such an overused buzz word, that no one takes it seriously anymore. He said that SOA’s goal, “is to apply consistent architectural guidance to an IT landscape by transforming it from a collection of applications that require complicated integration to a set of services that explicitly support inter-operation.”. Stefan argued that the use of WS-* does not fit well into the Web model, and that REST is the solution. Not just sending XMLs without SOAP via HTTP, but sticking to the principles defined by Roy Fielding (who coined the term REpresentational State Transfer), where everything on the web is treated as a resource. He proceeded with some examples and closed, as I also will, with some “pragmatical recommendations from an enterprisey RESTafarian” :

All of the presentations I mentioned above are of course available for download on the conference’s site and I encourage you to go check them out.