alt
November 6th, 2011

by Ivan St. Ivanov

The greatest thing after the first Java2Days day was that the next one was coming. And it had the same great lineup of talks. No keynotes this morning, so straight to the first talk about.

Pomodoro Technique

The most intriguing part of this not-exactly-no-soft-skills type of talk was that the speaker (Staffan Noteberg) had drawn the slides by himself by hand. From the very beginning I thought: “This is the guy!” as I saw a lot of similarities between the stuff he was talking about and the things that I was doing. For instance, he reads every morning in the bus while going to work (at least that’s what he said). I do exactly the same thing, although I am quite sure that Sofia public transport is not as cozy and appropriate for reading. Procrastination was something else that I often do – I prefer to check twitter, read blog post or anything when I get a task, which I don’t like or which I don’t know how to approach. Did you know that your little rituals before doing something are not simply superstitions, but more a way to increase your focus on that?

So, what is pomodoro? First, it’s the Italian word for tomato. The origin of the technique comes from an Italian guy, who used his mother’s cooking timer (having the form of tomato) to ring after a certain amount of time has passed. During this time he did nothing different than concentrating over his studies. Really, nothing different. No twitter, no facebook, no RSS feads, nothing. Well, it was easier at the time this technique was invented – the powerful distracters which I mentioned did not exist in the 80s.

The pomodoro technique has its other tools besides the cooking timer. These are the three sheets of paper: to-do-today sheet, activity inventory sheet and record sheet. The first thing you do in the morning is look at the inventory sheet and take a couple of tasks that you want to do today. As in kanban you should make sure that you don’t take too much work. You write them down on the to-do-today sheet and start working on one of them. And you do it for a fixed period of time. The default is 25 minutes, but the speaker said that it can be strongly individual. During this period you don’t do anything else. No twitter, no facebook, no chatting, nothing. After this is finished (and you know it because the timer rang) you put a sign besides the task description in the to-do-today list and happily declare that you have completed one pomodoro. Then have some rest – go to the coffee machine, talk to your colleagues or whatever. And then the next 25-minute time slot starts – you start working on what you left in the last timeslot.

When you finish a task, you strike it through and if there’s still time in the current pomodoro, you begin reviewing what you have done and pondering whether you have done it right or you can do it better next time. At the end of the day you put the number of completed pomodoros in the record sheet.

At the end the speaker said that he could talk much more about the topic. And unfortunately he didn’t touch one very interesting topic that most of us suffer from – what does Pomodoro say about interruptions from other people. And more interesting, how can I avoid not to seize the work of a colleague of mine (most of us wish not to be interrupted, but nobody of us realizes that often we are the interrupters).

Modern components design with Spring

The Spring sessions of the second day kicked off with a talk about designing modern applications with the help of the frameworks. It was given by Juergen Hoeller and I expected to see some patterns and good programming styles rather than yet another Spring 3.x features review.

The speaker started with the fact that Spring doesn’t mean tons of XML any more as most of its opponents accuse it. Yes, XML configuration of application context is still supported and even further developed and improved. But that’s not the only option for quite a long time. You have a great set of annotations (industry specified and Spring specific) in your belt, which you can use for defining both your data model and the runtime behavior of your apps. Juergen’s talk concentrated exactly on that – different aspects of configuring the developed software so that Spring can do the bootstrapping and setting up the dependencies, while developers can focus on doing the business logic.

Juergen continued with explaining the different annotations for configuring various kinds of beans (remember, the ones that you used to put between the <bean> tags in the app context XML): services, components, repositories, etc. Besides the automatic injection with standard JSR330 (@Inject) and Spring specific (@Autowire) annotations, you can have even more sophisticated object creation with annotated factory methods, where you can initialize the beans based on more complex logic. I didn’t know so far that Spring can find these factory methods on all classes annotated with @Component – so far I thought that they can be part just of special configuration classes.

I also learned that there are two types of “macros”. The good old property placeholders starting with dollar sign ($) are evaluated just once – when the application starts. While the Spring expression language (SpEL) expressions starting with hash sign (#) are evaluated dynamically each time they are accessed. You can put inside not only strings, but also Spring bean methods, which are eventually called and their result is returned. In Spring you can inject not only services, i.e. types, but also values. This is achieved via the @Value annotation. You can use both approaches for specifying the concrete value that you want to inject – placeholders and SpEL.

Another big step forward in Spring 3.x is the new Spring MVC. As it is fully annotations based, it is called @MVC. It is designed to follow REST architecture in defining the controller methods that handle the different kinds of requests coming from the users. It’s natural as REST itself follows the same HTTP principles.
The time was not enough for Juergen to explain in more details about declarative validation (using JSR303 annotations), declarative formatting, scheduling (cron jobs & asynchronous methods) and caching. I’m afraid that some of the attendees didn’t get the session’s idea correct. Of course that most of the presented stuff exists for quite a long time in the framework, so Juergen’s goal was not so much to present them. What I got was that he wanted to show us a very rich model for designing and developing applications. I personally took some notes of ideas that we may apply in our [not Spring based] application that we write at work.

Building better clients with Spring

I stayed in the big hall for another portion of Spring (no folks, it was not too much for me :-)). This time Josh Long gave us a brief introduction on how Spring can enable us to use various client technologies for our web applications. Again the framework shines in integrating everything in order to make developers’ lives easier. The coolest thing is that some of the client frameworks themselves are writing the libraries for integrations with Spring.

Josh started with the necessary steps for writing web applications with @MVC. It is as easy as configuring the appropriate dispatcher servlet and the application context location in the web.xml. Spring comes with predefined dispatcher servlets. Their role is to act as front controllers – they listen for incoming requests from the client side, then dispatch to a controller that has declared to handle that request and finally return the result back to the client.

Josh stated that in one way or another Spring supports JSF, Struts, Tapestry, Stripes, GWT, Wicket, Vaadin, Play!, etc. Well, I’m have some doubts about the JSF support. I’m pretty sure that this Java EE standard technology should be well in the positive list. But I had big problems when using it in for recent home project, so I went back to JSP. Another new thing for me was that Spring @MVC can now be configured in Java code as part of the @Configuration class, where the bean factory methods are declared. Up until now I was using the XML for defining that I was going to use MVC annotation config.

One of the biggest issues of the first version of JAX-RS was that the client side development, i.e. the calls to the RESTful web services, was not as easy and convenient as the server side development. Of course it will be much better in JAX-RS 2.0, but Spring already has the REST template class, which does all the infrastructure code and again the developers can just concentrate on the business logic.

When talking about web clients, Josh pointed out that it is not only the browsers on the desktop that matter, but also those on the mobile devices. Spring basically supports all the popular native platforms in the area – Android, Apple, Windows Mobile, Blackberry. It was very cool to see how one and the same application is rendered in a different way on desktop and mobile without touching single line of code.

The time was not enough for Josh either, so he quickly went through the Flex and GWT technologies support in Spring. Especially for the Google web toolkit, I read an article on Java Code Geeks a couple of years ago.

JBoss Forge

The lineup of the afternoon sessions of the second day was quite impressive. The first one which I attended was about JBoss Forge. It is a tool for further increasing developer’s productivity by generating the needed artifacts, running builds, deploying on local servers and in the cloud, etc. My particular interest in this session comes not only by the fact that I had already seen some videos by the project lead Lincoln Baxter III, which had drawn my interest in the area, but also because this is the open source project that I want to contribute to. Why? Well, read on… 🙂

Before going into more details about the topic, Lincoln introduced the Java EE 6 improvements in the typical JBoss presentations style – mainly pictures and not too much text on the slides, so that the spectators pay more attention to the speaker and not to stare at bullets on the screen. To summarize: we have annotations instead of XML, completely new EJB component model, profiles, etc.

So, what can Forge do for us? It can save us the startup costs when creating a new project: creating directories, configuring dependencies to external libraries, putting the various configuration files (persistence.xml for example) in the appropriate folders, etc. There was a question from the audience how does the tool differ from the maven archetypes. Well, archetypes stop at this point of the project lifecycle (initializing directories and artifacts), while the application of Forge is well beyond the initial kickoff.
In order to show this, Lincoln proceeded with a demo on how you can create a simple web application. He used the Forge plugin for the JBoss tools (IDE based on Eclipse). As Forge is a shell-like tool, you can use it both from within the IDE or from the command line. You just have to issue commands for doing what you are up to. It has auto-completion so you don’t have to remember by heart all the commands and their parameters.

Lincoln started with creating a web application project, which downloaded the necessary libraries in the maven local repository, created the directories and the different files, etc. Then went on with creating a JPA entity and adding columns to it. And this only in the shell! No need to remember or copy paste any XML or other configuration stuff. Then in less than a minute the sample application got its web pages for creating, reading, updating and deleting instances of the previously developed entity (the process is called scaffolding). Adding RESTful web service was also a matter of running a few commands.

Most of you might have heard about Spring Roo, which does nearly the same things. The basic difference between that and Forge is that the latter touches only the Java files without leaving any junk on the file system. While SpringSource’s tool doesn’t touch the Java files. It rather manipulates AspectJ artifacts in parallel to them.

The speaker further on showed integration with the Redhat’s PAAS solution – Openshift. Currently there’s no support for other cloud platforms, but with Forge it is not that hard to introduce such. To put it more generally: it is not hard at all to extend the tool. It is plugin based and maintains a list of all the known plugins. You want to introduce URL rewriting? No problem, just tell Forge to get the appropriate plugin. It will download its source, build and integrate it automatically. The great thing is that even if your plugin of interest in not in the list, but just on Github, Forge can do the same thing with URLs. So not only it makes development faster, but is a great example of social coding.

Clashes and actors

The next time slot brought me (and maybe most of the attendees) the biggest clash in the whole conference – Spring Roo, Actors model on the JVM and Domain Specific Languages. The three topics were of a particular interest to me and the fact that I couldn’t easily choose one is another example of the great content that we had this year at Java2Days.

I decided however to go to Vassil Dichev’s talk. It was on the actors model and its implementation in the JVM languages. It was again a full room of people who wanted to learn how to do concurrent programming.

First the speaker started with a brief history of giving up language constructs. First it was the GOTO statement, then the memory management and now it seems that it is time for developers to forget about low level thread management and locking and leave it to libraries and frameworks. The problem with thread management is that it’s very easy to do it wrong – all of us have experience with modifying shared state or with atomic updates of some complex types. I remember a JavaPosse episode, where Dick Wall mentioned that there are only two people in the Java world who know how to work with threads – Doug Lea and Brian Goetz. They happen to be the authors of the two most prominent books on the topic.

After that Vasko went on to describe the actors model. It’s a concept made up by Erland language designers. Each actor can be thought of as a very lightweight thread. However, there are some specifics:

  • Actor’s state is private – only internal private variables are mutable
  • Communication between different actors is organized through immutable messages. So if a thread wants to change the state of another one, it should send it a message
  • Actor’s methods are asynchronous

The greatest thing today is that you don’t have to use Erlang if you want actors. There is a Scala library called Akka, which implements the model. As Scala is JVM based, there’s no problem if you want to use it from Java – there’s Java API as well. That’s why Vassil’s code examples were again making a parallel between Scala and Java. While showing them, he explained that actors are implemented with proxies; that’s why you cannot change their internal state. The only thing you are allowed to do is to send them messages via the appropriate method (! in Scala and tell in Java). This is why different actors can be on separate JVMs and still be able to communicate. There are also synchronous methods (? in Scala and ask in Java), which return a Future objects (not java.util.concurrent.Future, but very similar).

Another area where actors shine is the fault tolerance and error handling as a whole. This comes from Erlang’s goal to reach 99,9999999% reliability for the Ericsson’s network (the nine nines). The idea is quite fascinating: you have one actor that is responsible for the normal flow of the program. If anything bad happens, there are separate actors (called supervisors) that do the error handling. Thus you can handle even big crashes and your code is cleaner (no big chain of try/catch/finally blocks).

The conclusion was that you can have deadlocks even if you use actors, but they are more likely to happen in the business logic part of the code and not in the thread management. I must confess that by the end of the talk I lost Vassil. Maybe this was my idle hour (around 15:30). I quickly rushed out of the room at the end of the talk to go and grab some refreshments and prepare for the last two sessions.

Scala and Spring

Up next in the big conference hall was Oleg Zhurakousky’s “Scala for Spring developers”. He started by admitting that he is not a big Scala expert. Happily Vassil Dichev (the most passionate Scala developer I know in person) was also in the audience. Oleg was cool enough to let Vasko jump in his speak, whenever he was not 100% sure about anything or when Vassil wanted to add something.

The reason why the Spring guys started thinking about Scala was a proposal from one of Oleg’s colleagues to use the language as DSL for Spring integration. The currently existing XML format was quite verbose and hard to write. At the same time Scala shines when defining domain specific languages. When you create a Scala function, it finally compiles down to a Java class, which in Spring is a bean. And Spring itself shines when dealing with beans. Scala and Spring both provide utilities – the first to solve language deficiencies, the other one for solving domain specific problems.

While working on his colleague’s proposal Oleg discovered some great language features that help a lot framework development: closures, expressions returning values, operator overloading, etc. One of the features that some people love OSGi for is the ability to restrict access to some of the packages in a library. Well, in Scala you have it as part of the language, so you don’t need OSGi for it (yey!).

Most of the talk was slideless. The speaker showed us examples of integrating Scala DSL with Spring application context and at the same time we heard some useful notes from Vassil. You can find the samples and some explanations on Oleg’s blog. There were all kinds of cool features – closures, beans, named parameters, predefined operators, etc. We also saw a test class, where there were different flavors of using the DSL: using the builder pattern, named parameters, with or without dots (.) and parentheses.
The talk was particularly helpful to me. At my job we have a process description for the tool that we are writing in the form of a huge XML. So I got some useful ideas on re-implementing it. And also now I know whom to ask for an advice 😉

JBoss AS7 – the death of the slow

The last talk of the conference. It was in the big hall and the speaker was Andrew Lee Rubinger. He talked about the new release of the JBoss application server. Version 7 was completely redesigned and even developed from scratch. The reason – the previous releases were quite slow, hard to develop, configure and manage, etc.
Andrew started with explaining the improvements in AS7 (again just pictures and a few words on the slides – the JBoss style ;-)):

  • Fast startup time – just 3 seconds. I wonder was it with or without deployed application. BTW here is a great review by Antonio Goncalves on the startup performance of existing application servers (Tomcat also included)
  • Modular design and isolation of application libraries. You don’t need necessarily OSGi for that (cool!)
  • Efficiency in terms of memory consumption and CPU. This is particularly important in the cloud era, when you pay for the resources that your software consumes
  • JBoss is not just an application server, but also a runtime for all kinds of applications that run on various devices
  • Easier than ever configuration and administration of the cluster

Developers hate constant cycles of long rebuilds, slow startup time, never ending deployment, etc. That is why JBoss has tools and libraries like Forge, Shrinkwrap and Arquillian (all of them were covered in earlier talks on the conference). There are also some other components that may run on top of JBoss AS and that help integrating other aspects for even greater developer productivity: RestEasy, Snowdrop (integration with Spring), IronJacamar, HornetMQ, Weld, Infinispan, Hibernate. Besides java, you can also have Ruby and from quite recently Clojure on top of JBoss.

The demo that Andrew showed was on developer productivity in more complex scenario including transaction management and database access through JPA. The demo was based on an Arquillian test that caught all kinds of functional problems that are usually found by manual tests or in production. The sample used JNDI to inject the dependencies into the test. But I’m pretty sure that Arquillian can work even with pure CDI and stereotypes. It would have been much more impressive if Andrew used in the examples @Inject for the EJBs under test instead of that lengthy and error prone “java:comp/…” injection style. Anyway, furthermore we saw how with the injection of app server’s own entity manager you can easily test your JPA logic without the heavy lifting of starting up the container and deploying your test there.

Conclusion

Java2Days, third edition, is over now. And I must say that it was the best so far. The content was as great as always and in the same time the organizers seem to have polished all the little bugs that they experienced in the previous years. Just one small remark: it is a good idea to publish the agenda well before the conference starts. And only adapt it if needed. I couldn’t find anywhere the abstracts of the sessions, so I had to guess what the speakers would talk about. For example Oleg’s session on the first day had the title “Building cloud-ready systems using Spring technologies”, but focused more on enterprise integration patterns. But anyway, the overall impression was that everything was greatly organized.

One of my biggest pains in the recent years was the flame between the Java EE and the Spring camps. Well, I’m glad now that it seems to be over. I heard from Spring guys that they are not against specifications, they are just against overly specifying things. I heard from JBoss guys that Spring and Java EE are not orthogonal anymore and I see some efforts in integrating both worlds. Yes, we saw from both camps just people that are mainly developers (even Juergen Hoeller develops) and no evangelists, and we didn’t see anyone from the Java EE group at Oracle. But my general impression is that things are changing in positive direction. Guys, innovation is much faster with cooperation than with blaming and flaming!

I didn’t visit too much of the cloud and mobile talks (where does the Akka presentation count?). But there are a lot of people who did, so having these topics in the conference is great! Who knows, maybe next year I can go and see some Android stuff.

Thank you all guys for the great time and for the passion! These are [Java] 2 days that I can hardly forget. Now it’s time to have some rest and then: Devoxx, I’m coming!