November 30th, 2011

by Ivan St. Ivanov

Well grounded Java developer (WGJD)

The first three hour session I attended on day two of Devoxx was called Well Grounded Java Developer. The decision to go there was based on some stuff which I read about one of the speakers – Martijn Werburg. Both with the other guy – Ben Evans, they are mostly known as active JUG leaders from London. BTW they are going to publish soon a book with the same name. So I expected something really interesting and fairly unconventional.

What makes a Java developers well grounded? First of all they have to understand some eternal things: the basics of the JVM, think of development as social activities (forget about the Hollywood model of successful guys, who code in their bedroom), spend significant amount of time and energy on software craftsmanship and architecture. Then – the three moving aspects, which are true now, but may change in future: WGJD should know Java 7, polyglot and functional programming as well as good concurrency practices. For the remainder of the talk the speakers turned our attentions exactly on these three moving aspects.

The goal of Java 7 after Plan B was to introduce much more concise and readable code. An example of that is the small language changes implemented as part of project Coin: diamond operator, strings in switch to name a few. The speakers went quickly through the various new platform enhancements. They also emphasized on the new APIs. They advised us to go and look at the all new ‘plural’ classes like Objects and Files. These provide plenty of helpful static methods that ease lots of the things that we usually do. Something like good old Collections class that gives us factory methods as well as basic functionality for searching and sorting. The speakers also pointed that the method handles introduced for implementing the invokedynamic byte code can be used for a lot more things (for example Oracle will maybe use it for realizing the default implementation of interface methods in Java 8).

Another now popular “feature” of the well grounded Java developer is that they should be polyglot programmers. Right now Java the language is not a natural fit for defining DSLs (domain specific languages). That’s why we all should learn a language that is better for that (like Groovy or Scala for example). Good remark was that Java is a more conservative language as opposed to the newly created ones. To introduce a change in it takes much more effort in terms of evaluating its impact on the currently existing features – Java has to stay compatible. I read a very good article on this topic by Brian Goetz.

The biggest difference between [partly] functional languages and Java is the ability to pass code as arguments. The speakers warned the audience to think twice before calling this feature a closure in front of functional programmers. What we are going to have in Java 8 is actually lambda functions, which among the rest cannot modify the state of the enclosing variables, while closures can. Finally Ben and Martijn urged everyone to go on and test the preliminary Java 8 versions, because a product is as good as the number of people using its beta.

The third important ability possessed by a WGJD is utilization of the hardware by avoiding the old synchronized keyword style. The speakers, as well as everyone with more experience, tend to dislike the old fashioned way to do multi-threaded code – using the synchronized keyword and calling wait() and notify() on a monitor object. Yes, you can do concurrency this way, but you have to be very, very careful and pay attention to the smallest detail. As of Java 5 we have the java.util.concurrent classes, which do a lot of tedious things for us: reentrant locks replace synchronized blocks, conditions replace wait and notify and countdown latch is great for testing multi-threaded code (I didn’t get how). You can use also HandoffQueue to hand off work between two threads, which is much better than the old approach with JMS. The fork/join framework introduced in Java 7 raises the abstraction a couple of steps further when talking about concurrency – it takes care of all the locking and other java.util.concurrent stuff, letting developers concentrate even further in the business logic.

This was quite an inspiring talk. Even though Ben and Martijn talked whole three hours, I didn’t feel weary even for a moment. Another thing that I noticed is that these guys had profound knowledge on a lot of aspects on the Java language and platform, languages running on the JVM and frameworks in the ecosystem. I’m not sure how they achieved this, but it’s awesome. With these two, together with other two guys, whose work I closely follow (Stephen Colebourne and Sandro Mancuso) the London Java community seems to have great potential and should be an example for the rest of the world JUGs (yes, sure, don’t forget Paris JUG either).

Java FX

I went to this talk, because I was afraid that the Groovy ecosystem session would be quite advanced for me. Well, I made a mistake. Neither the Groovy talk was too advanced nor was this one quite as interesting as I expected. I already saw a presentation by Michael Heinrich on Java FX 2 at the last Java2Days conference in Sofia and this three-hour talk showed the same things in a little bit more details.

So, what is JavaFX 2? It has 100% Java API as opposed to the previous releases where you coded in JavaFX Script. The main reason for this change – a Java developer is reluctant to learn a completely new language. Besides that, integration of a JVM based language (as JavaFX script is) with another one (like Groovy and Scala) is not as smooth as one would expect – Java integrates better. Of course the UI markup can be specified in FXML – you can get from its name that it is XML based. It follows the Java API in terms of elements and attributes, so knowing the former is good enough when you are reading the latter.

In the middle of the talk the speakers cheered up (and awoke ;-)) the audience by playing the Java life video inside the JavaFX media player. You can have also web content inside JavaFX [desktop] application. A usecase for that feature is if you want to reuse existing OAuth login page, web forms or if you want to embed a map from Google’s site.

In the area of UI controls (this is the first thing to be open sourced) we can finally report the existence of Table component! The checkbox has three states (the GUI that my colleagues in my department develop is not alone in supporting this great feature ;-)). We don’t have to go to JFreeChart for various charts any more – JavaFX has them, even with animation on top.

Last but not least, Java FX scenes should be embeddable inside Swing and even SWT. I don’t know, maybe I will learn HTML 5 first and only then will try JavaFX. But for sure you need either to experiment a lot or to be a GUI magician in order to get right all the gradients and other 2D graphics goodies that JavaFX provides.

Type safe Hibernate and JPA with Scala

This was the most intriguing talk of the day, at least for me. I am not a Scala developer, but I know some of its advantages for defining DSLs. I didn’t know about its implicits, which help you extending existing APIs without being “intrusive” as the speaker stated it. The implementation of the library presented during the talk was inspired by Martin Odersky’s post Pimp my Library.

I don’t remember many details, but the open source library created by the Caelum team “extends” the existing Hibernate and JPA APIs via implicit conversion to enable type safe building of queries. Right now the option is either to use HQL or JPQL strings, which are not checked at compile time for correctness. The other way is to use the tedious Criteria API. The pimped query API introduces Scala language features like named parameters, type reification, operator overloading to build and execute queries. The only decent documentation which I found about the library was its github home page. You may check it to translate the above theory in more practical concepts.

The reaction to the talk was quite controversial. Most of the twitter comments concentrated more on the content: they praised the idea to apply the Scala language features to achieve such a common task as building and executing ORM framework queries. However, there were quite a few foolish comments about speaker’s performance. Yes, he was very uneasy on the Devoxx stage. And yes, the presentation did not go as smoothly as it would go if it was presented by an experienced conference speaker. But yes, I still do support Lucas (this is speaker’s name). Devoxx is a conference for developers by developers. So for me the content is much more important than the way it is presented! And I learned much more from this talk than I lost from the uneasy behavior of the presenter.

Groovy actors

I will not surprise anyone if I state that concurrent programming is one of the prevailing new things these days (check what the Well Grounded Java Developers say). So it is +1 for every [JVM] language if besides web framework, build tool and test library it has an actor proposal.

According to Vaclav Pech, actors are asynchronous guys with a mailbox. The mailbox is read in their onMessage method. They have a reply method if they want to return something to their senders. In order to send an actor something, you use a send method for asynchronous approach or sendAndWait for a synchronous one. Everything is bootstrapped by a start method. You should take care only about these aspects. All the heavy lifting and low level synchronization and messaging is done for you by the library. Basically this is how Groovy’s GPAR (and also Scala’s AKKA) framework is working.

Besides all the Groovy’s parallel machinery, GPARs can utilize other JVM languages constructs. You can transform existing POJOs (or POGOs) to Groovy actors by just annotating them as @ActiveObject and their potential actor methods as @ActiveMethod (with the option to declare them as synchronous or non-blocking).

The library is not as mature as AKKA, though. For example it doesn’t support distributed actors (across several machines). I didn’t take too much notes about that as well, but you can still check the official site.

The fireside chat

Day two of Devoxx finished with the fireside chat. This is not a standard session. It actually features several very smart guys sitting around a table (like in a bar), drinking wine and discussing themes that they decide on the fly. No prepared questions by the moderator (well, at least), no scenario, no presentations. The initial idea was to have a more distributed lineup of participants with James Gosling and an Adobe representative in the list. For one reason or other James didn’t show up for second consecutive Devoxx and Adobe rejected as well. So we had one Googler (Tim Bray) and three Oracles (Henrik Stahl, Mark Reinhold and Cameron Purdy). So it was not the liveliest talk, but anyway, we got some “interesting insights”:

  • XML is awful for describing non-documents – JSON like formats are much better for defining configuration
  • We heard one of Devoxx 2011 jokes: “The difference between Ant and Maven is that Ant’s creator apologized”
  • People like to predict the future but are rarely successful in it
  • Big success stories happen not because, but in spite of the push from company’s CEO
  • HTML5 is just an envelope for standard JavaScript
  • Generics could have been done better

You can see that the discussed topics were diverse enough. The good thing was that already in the beginning Tim avoided the flame coming from the Oracle guys about the ‘Linux based platform that claims to use Java’, so the talk did not turn into a corporative dispute. Hopefully next time we’ll have participation dispersed among the leading companies better than Oracle:Google 3:1. 🙂