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.

by Ivan St. Ivanov

Your nosoftskills bloggers spent great times at the last Devoxx edition. And they decided to share some of the experience with you (for the rest – you’ve got to feel it!). Most of you may have already started reading, but we decided to put up this page for those who want to have the complete picture at a glance.

Here are the reports from the different days:

University Day 1
University Day 2
Conference Day 1
Conference Day 2
Conference Day 3

And here are the more in-depth reports from our latest nosoftskills author Stoyan:

Crash Course into Scala
The Groovy Ecosystem
What’s in store for Scala
Java Past, Present and Future

Good luck, cheers and thanks!

by Ivan St. Ivanov

Discussion panel

Each Java conference starts with keynote and most of them end with a discussion panel. There some of the most respectful people of the industry come on stage and answer the questions from the community. Devoxx is not an exception – on Friday morning we had Oracle’s Brian Goetz and Mark Reinhold, Google’s Josh Bloch, JBoss’s Emmanuel Bernard (actually he was representing the open source movement), JUGs’ representative Ben Evans and Brian Prince from Microsoft (:-)). The talk was moderated by JavaPosse’s Joe Nuxxol and Carl Quinn. Joe was posing the questions that everybody had the opportunity to ask in a Google Moderator group. All the speakers had foil hats, which they put in case when they could not answer certain questions for “political” reasons. Fortunately the hats were used just a few times.

I again will try not to paraphrase each question and the answers. I will give just some statements that were interesting to me:

• The definite winners of the Oracle – Google lawsuit (and all the other lawsuits on patents) will be the lawyers. The losers will be the developers
• If Java and its successors want to be successful, then they should avoid creating incompatible dialects like there are in C++
• Oracle’s corporate culture is better for Java than Sun’s. According to Ben, Oracle did not place any barriers in front of the community
• Open sourcing doesn’t mean just dumping code on the internet. A lot of big companies that have done it that way, have miserably failed
• The Java language did not become much more complex than it was in 1.02. Just the level of abstraction rose. It was the same in the very beginning: the first versions hid memory management from the developers

Of course there were some flames on the scene as well. Josh Bloch: “What is JavaFX?” Mark Reinhold: “What does Android have to do with Java?”  We heard also Joe ask Emmanuel a question in English, but with French accent. Which reminds me that the French people were target of a lot of jokes during this conference, most of which friendly. They will surely strike back on DevoxxFrance next April.

Evolution of Java

This was the second talk by Josh Bloch on Devoxx and it was a sequel to his first one about the first version of Java. I will not go into too many details here as my nosoftskills co-blogger already did it (thanks, Stoyan ).

So Josh evaluated all the 17 language changes made after the inception of Java in 1995. The criterion for that was whether they kept the feel of Java, defined by James Gosling: Java should be a blue collar language. One that takes all the good stuff from the existing languages and in the same time stays simple enough to be understood by the average programmer.

The most bashed features were serialization and generics. The first one was criticized because it does a lot of things behind the scenes: introduces hidden constructor, by default leeks private fields (unless not explicitly declared transient), it breaks the hashes of the serialized objects, so structures like hash tables, where these objects reside, are also broken, etc. Generics were basically fine before wildcards were added in the last moment. With this last minute act they introduced big complexity (the FAQs are 297 pages long) and harmed the feel of Java. The erasure of the generic type during compilation (done for backward compatibility with raw types) is just the opposite to what is done with arrays – they pertain their type in runtime. This impedance mismatch hides a lot of puzzlers inside and Josh has some of them in his book.

On the other side we have features like enums, foreach and annotations, which help a lot in simplifying the language, the runtime and in bringing type safety. Josh confessed that he has not tried intensively the new stuff in Java 7. However he said that Joe Darcy and his team have done a great job in their definition and implementation. And all the new features in the latest release got good ratings. Let’s hope that next year we’ll not have to watch yet another Java 7 puzzlers talk on Devoxx.

The Ceylon programming language

The last talk that I attended on this year’s Devoxx was about the Ceylon (pronounced Se-lon) programming language. Like Kotlin it was one of the JVM languages that emerged this year. Unlike Kotlin it did not have a compiler and IDE support. Well, not any more. Emmanuel and Stephane announce the brand new project site, where you can download the Eclipse plugin and find out how you can get the compiler.

The goals of the language are: easy to learn, less verbose than Java, very type safe (i.e. statically typed), hierarchical structures (like XML, UI, etc.) should be better expressed, etc. I have also heard that its target would be people writing business application. As the language author is Gavin King (the creator of WebBeans, a.k.a. Seam), I would not be surprised if we see contexts and dependency injection (CDI) as part of the language. Some of the most prominent features of Ceylon are:

• Everything is by default final. If you need to mutate your variables, you have to express that explicitly. If you need to override a method you have to declare that explicitly both in the parent as well as in the child class
• Method overloading is not possible. However, methods can have default values for their parameters, so you can omit them when calling the method. This looks like currying
• Interfaces can define default implementations for their methods, just what we expect in Java 8
• There are no primitive types
• There are optional types (String? s). When you have such a type, the compiler explicitly checks whether you have a check for null before invoking a method
• There is operator overloading for a limited set of operators. You cannot redefine new operators as it is in other languages. The way to overload (or override actually) an operator is by overriding the respective method. For example for == and != you need to override equals

There are a lot of cool features that can be looked up in the documentation. What I didn’t get is whether it supports Java in the way that Groovy or Scala does – can you write Java code inside Ceylon classes. I didn’t get also how you define the main method of a module. But anyway, this is not so important. More important is the following observation: we have several new languages (I mean serious ones) coming out each year. Every one of them claims that it solves most of the problems of Java and that it does it in a better way than the other ones on the JVM. Every new language usually also adds something unique (e.g. Ceylon has a different type system). OK, that’s fine, it’s great that lots of people in the community are creative and I do believe in Gavin King’s creativity. However, I still cannot find what’s in for me in most of the emerging JVM languages. And the Ceylon guys have still much work to do (which they realize even better) to bring me on their side (not that I am particularly important to them ).

The good part is that they are doing the things in the right way. Just to mention some other observations:

• It’s not necessary that the language is backward compatible (it’s not decided yet though)
• The Ceylon team values the community (which I guess is the JBoss culture) – everything is on Github, there are mailing lists, even the project page can be edited by people from outside
• They tend to avoid lots of Java fallacies (e.g. threads and parallelization are part of the libraries not of the language)

Good luck guys, I’ll be watching your progress!