November 17th, 2011

By Stoyan Rachev

In the afternoon of Devoxx Day 2, the new language parade continued with Andres Almiray’s overview of The Groovy Ecosystem.

Unlike Scala, I have some previous experience with Groovy. I studied the language earlier this year and was really impressed by its richness and expressive power. You could think of it as “Java on steroids” or as “Scala with a Java-compatible syntax”. On the downside, in my experience its dynamic typing, Eclipse support and performance were not that great. At the time, I thought Groovy might still be ideal for internal use, in any case much better than ant, batch files, or other scripting languages we use so far in this area.

The session abstract says that “Groovy is the fastest growing JVM language out there. It might be because it is so easy for Java developers to pick it up, but also because there’s an increasing number of projects and libraries that make use of Groovy as the starting point.”

Instead of presenting language or framework concepts on slides, Andres showed just a single slide per framework, and moved straight into coding to demo their features. Most of the demos went flawlessly and were quite impressive. You could check the slides here.


Grails is a popular Web application framework similar to Ruby on Rails. It builds on top of Spring and Hibernate and has more than 600 plugins available. In a few minutes, with the help of few console commands and a text editor (no IDE), a new “Book / Author” application was born and then enhanced by adding custom actions, views, and even tags. One could use the built-in Grails console as an interactive playground to test various dynamic methods (added by the framework), or other behavior of the application. Finally, it could be further enhanced by adding more plugins, and even by creating a custom plugin, all with very little effort.


Griffon is another framework that brings the power of Grails to desktop applications. It also has a very rich plugin ecosystem, and is “polyglot aware”. Using Griffon is very similar to using Grails, just the grails command is replaced with griffon. Swing or SWT components can be created and wired with a special DSL, instead of custom code. The same Griffon application can be started as a standalone app, as an applet, or with Java Web Start by just using a different command for launching it. Properties of UI controls can be easily bound to other properties or the model with very little code. With a simple annotation one could control if the controller code runs in the same or in a different thread than the UI (event dispatcher) thread.

There are also archetypes that allow you to bootstrap applications in a different way. In the demo, one of the built-in archetypes was used to create an application with a predefined set of models, views, and controllers and a richer set of features. Griffon also has a very lightweight event bus. With it, you can publish an event and then listen to that event following a simple convention, in the same or different threads.

What if you are not allowed Groovy, but forced to use Java? You could still use Griffon by specifying the correct “file type” and “archetype” when creating your application, which creates Java code instead. If a certain plugin is installed, Groovy annotations such as @Bindable could be used as well. The Java version took a few rounds to compile correctly since the speaker didn’t use an IDE. As one might expect, it had twice the amount of lines of code compared to the Groovy application.

With Griffon, you can package your applications as a zip file, or as a different distribution type (dmg, izpack, rpm, …) with the help of the installer-plugin.


Gaelyk lets you access Google App Engine (GAE) services by lightweight abstractions. According to Andres, it is “the PHP for GAE”. It also has an emergent plugin system.

Gradle and Gant

Gradle is a better way to build. This is a Groovy DSL for building projects, which harnesses the power of Maven conventions. It is actually similar and compatible with Maven, just much less verbose. If the conventions are followed, a simple application can have a build script which contains just a single line of code. In the demo, this simple build finished in 6 seconds the first time and much faster after that, because Gradle is smart enough not to repeat the steps that are not needed. If conventions are not followed, Gradle still gives you the full power to configure what you may need. Unlike Maven, it uses a very clear and concise syntax, typical for Groovy DSLs. Multi-projects in Gradle are also much easier than in Ant or Maven. Just by calling install, Gradle generates pom files and install the artifacts in the local Maven repository.

Gant is a “groovier” version of Ant – take away the XML and substitute it with a real scripting language. Although both Grails and Griffon still use Gant, it’s now somehow fading away because of Gradle.

Easyb and Spock

Easyb enables Behavior-Driven Development (BDD) for Groovy and Java. Some claim that BDD is TDD done right. When doing BDD, you define expectations from your customer’s point of view, write it in a natural language, and finally sprinkle some code inside. With Easyb, you could test both Java and Groovy code. It follows the usual BDD “given / when / then” syntax for defining stories and scenarios.

Spock is a testing DSL similar to RSpec. It hijacks the Groovy syntax to create something really “funky” using features that are available in the JVM, but not really exposed in programming languages. Did you know that you could have method names that are strings? With a simple @Unroll annotation, one could have a single method test multiple inputs, which is “unrolled” into multiple tests. Good bye @RunWith(Parameterized.class).

More …

CodeNarc is Groovy’s version of FindBugs and PMD. It enables static code analysis for Groovy code, and has plugins for Grails, Griffon, and Gradle. Andres showed how to add the plugin to Gradle and analyze the Groovy code with it. You could define what rules you want to apply using either XML or a Groovy-based DSL.

Concurrency is a new hotness. GPars brings concurrency management abstractions and facilities to Groovy, including actors, dataflow, and fork / join.

Ratpack is a clone of Sinatra for Groovy. It’s a nice way to create REST-based API for a command line tool.

GContracts provides “contract-oriented development”, which allows you to define pre-conditions and post-conditions to methods in the form of annotations (@Requires and @Ensures). This should not be seen as an alternative for testing or semantic validation.

Groovy++ is an attempt to make certain extensions to the Groovy language such as static compilations, traits (similar to Scala), immutable data structures, etc.


It seems that not only the Groovy language has all the features you may not see in Java in the next 10 years, but also that those Groovy guys have built up frameworks comparable (and to a large extent compatible) with whatever is in the Java SE / EE space, just much easier to use. And despite that they are built as open source by different people, they are still amazingly consistent. How did they manage to do all of that without JCP?

November 17th, 2011

by Ivan St. Ivanov

The keynote

Last year this was my first Devoxx session. This year I’m here for the university days too, so before the keynote I was not as excited as in 2010. Stephan Janssen, the Devoxx guy, came on the stage wearing a Brazilian flag and thus bringing some association with the always strong Brazilian groups on Java conferences. As Petyo mentioned – we should bring some of them on Java2Days. This year the conference is about three topics: Java, Android and HTML 5. There are 3350 attendees from 40 countries (at least four people from Bulgaria, yaaay). We have now seven halls in the cinema, which means seven parallel tracks. will stream live one of the tracks (in the big hall number 8). However, you need to have registration to watch it (it costs 79 euro a year). The cool thing tough is that all the attendees will have one for free in a couple of weeks. So starting from Christmas we’ll be able to watch all the recordings – conference, tools in action, university days.

As in every keynote, we had a big announcement. In April 18 to 20 2012 there will be a Devoxx edition in France. Unfortunately for people like me, most of the talks (75%) will be in French. Good work Paris JUG!

Then on the stage came Henrik Stahl from Oracle to talk about Java SE. Apparently all the big news (if at all) were announced at JavaOne, but we had an announcement though – JavaFX was approved by OpenJDK, so we expect it to be open sourced soon. The topic of the talk was “What Java needs to do next”. In the near future we’ll have modularity (project Jigsaw) as well as lambda expressions. The latter will creep also in the Collection API by providing map and reduce methods as well as means of parallelizing the data structures (it happened that I will hear this two more times today). We are expecting also JavaFX 3.0. JRocket and HotSpot virtual machines will converge (not on 100% though, but pretty enough). We heard the promise: “Java will be there for you”. So, Oracle is not killing it 😉

The final presenter in the keynote was Oracle’s Cameron Purdy. His talk was on Java EE. The focus of the technology in the next year or so will be on cloud, modularity and HTML 5. Modularity can come after Jigsaw is implemented, which means Java EE 8 at earliest. As HTML 5 is still quite fuzzy, it wasn’t surprising that most of the talk was concentrated on the cloud. The platform as a service (PAAS) paradigm is becoming Java EE as a service. You should be able to declare what kinds of services you need for your enterprise application to run (database, JMS, etc.) and they will be provisioned to you by the cloud provider. We saw a demo how Oracle’s own PAAS implementation infers the needed types of resources without reading manifests, but just by looking at the type of the archive being deployed, the availability of certain files (persistence.xml), etc.

It was not only the cloud though. Cameron vaguely mentioned what everyone expects – migrating some of the EJB model features (like transaction provided by the container) to the CDI model. Will we have both models in Java EE 7? Hope not, but I didn’t hear it from nobody from Oracle. At the same time JBoss guys are pretty certain about it.

The last part of the talk was not so very interesting to me and I believe this is the same for most of the other geeks at the conference. The speaker advertised Oracle’s own Java EE server (Weblogic). Besides a few employees of companies providing similar PAAS solutions, nobody really cares about how far is Oracle in implementing Java EE 6 and in integrating its server in the cloud.

Java: the good, the bad and the ugly

I stayed in the same place for the next slot. I watched the talk by Josh Bloch, who always has something interesting and unconventional to say. No surprise that the biggest hall was more than full. The topic was the good, the bad and the ugly parts of the Java language and the Java library. Josh actually looked at the state of the language when it was created 16 years ago (JDK 1.02). He started with the virtues of the platform. To name a few:

  • Tightly specified language primitives and evaluation order – int is always 32 bits and operations are executed always from left to right, without compilers messing around
  • Dynamic linking – when you change a class, you need to recompile and rebuild just the jar that has it and not the whole application
  • Syntax  similarity with C/C++ – most existing developers at that time felt like at home
  • Object orientations – it was cool at that time as well as functional programming is today
  • It was statically typed language – helps in faster runtime, better IDE support, etc.
  • No operator overloading – well, I’m not sure why it is good. Scala has it for example and that’s why it is far better for defining DSLs. But I will not argue with Josh 😉

Of course there were some bad things in the platform, like inlining final variables (or constants) – it violates the dynamic linking principle, so if you change a constant you have to recompile and rebuild all the other classes and jars, where it is used. There were also other bad and ugly things, but I will not list them here. I’m pretty sure that the slides will be available soon, so everyone will be able to review them.

The second part of the talk was dedicated to reviewing the JDK 1.02 library. It may sound surprisingly, but it contained just 7 packages (java.lang, java.util,, and three java.awt ones), 117 classes and 18 interfaces. What I took away after his review (I will not discuss the details here) is the following:

  • Why do we need algorithms for hash code and pseudo random number generators specified in the Java language specificatio down to the last bit? If someone comes with a better alternative, it can’t be integrated into the code any more
  • The negative attitude towards checked exceptions today is mainly due to the fact that all the important classes and interfaces throw them and you have to always take care of them
  • Most of the important stuff was then synchronized. At that time it was fine, but not anymore today
  • Non-deterministic behavior of functions is not fine. If it is non-deterministic, then why do we need the function at all?

Despite all the criticism Josh still loves Java and its small and simple libraries. Looking forward to his next talk on Friday to see how these evolved throughout the years…

Java 7, 8 and 9

To be honest, I was not sure why I went to this session. Initially I thought about going to the Kotlin talk, but finally decided to see what Mark Reinhold has to say.

He started with, guess what, Java 7 features review. I must say that I am fed up with reviews of diamond operator, strings in switch, fork join framework, invokedynamic and all the rest. I’m pretty sure that most of you think the same. Luckily it was quick browse and then Mark continued with Java 8. Looking at the history of the language, its eighth version looks revolutionary. It should be out somewhere in 2013. The most prominent features will be lambdas and modularity. It was exactly what the speaker presented in more details.

Mark showed an algorithm of determining a list member, which has maximum value. It appears that this can be parallelized and with the help of lambdas the boilerplate can be largely reduced – you don’t need to create anonymous inner classes anymore when you can pass code blocks as if they were regular variables. Another feature that walks hand in hand with lambdas is availability of default implementation methods to interfaces. Thus you can add new operations to existing interfaces without bothering to extend the implementations out there. Having that in hand, you can extend the existing collections. But for that a little bit later.

Another important feature that will be part of Java 8 will be modularity and project Jigsaw. There will be a new language construct, called module, which describes library’s (i.e. jar’s) versioned dependencies. Thus you eliminate the need of declaring these in the classpath, which becomes really appealing in case of transitive dependencies (the dependencies of my dependencies). A new packaging format is also proposed. It’s called jmod and is way better than jar when talking about distributing the libraries (I don’t know why, but I guess that I can find it on the internet). The essential thing is that it will be used just for transporting the files – jmods will have to be “installed” before executing. This much resembles Linux packages and Ruby gems.

Project Jigsaw actually is not about modularity, but rather about applying that on the existing JDK. The goal is to split it up in modules with clear dependencies and then use just the ones that apply for the current scenario (you will not have CORBA module if you just need to copy files for example). The topic of already existing module system – OSGi, was slightly scratched. Mark mentioned that both systems will be able to co-exist. Personally I like the proposed modularity more than OSGi, but it is not a surprise for people who know me.

The last part of the talk was a quick overview of what may be in for Java 9:

  • Self tuning JVM, which can figure out its settings by inspecting the machine capabilities
  • Improved JNI – fix the initial plan to make it hard so that developers don’t use it
  • Support for really big arrays and collections (with 2^63 elements)
  • Reified generics – the type of the elements inside is known at runtime, rather than erased. Doesn’t that mean breaking backward compatibility?
  • No more primitive types, autoboxing and unboxing
  • Tail recursion and continuations
  • Multi tenancy

I wonder whether such a comprehensive list can be implemented for two years, which is the intended schedule. Or maybe we’ll have another Plan B for Java 9?

Finally, Mark confirmed that SAP is part of OpenJDK. Was it because my colleague Krassi Semerdzhiev reminded him about it the day before? 😉

JRuby introduction

I had great doubts for this time slot. This time it was not a clash of titans, but rather no topics of particular interest to me. I didn’t want to go to yet another review of project Coin, even though I knew that Joe Darcy and Maurizio will enter in the implementation details area. The partner talks were also of no interest to me. The same applies for HTML 5 (I promise not to attend any session on the topic until the end) and Android. So what only remained was the JRuby talk by Hirotsugu Asari. I must say that I am not at all interested in the Ruby topic. To me this language has nothing that can gain me on its side. The combination Java+Groovy looks much more promising. But anyway, I decided to give it a chance.

So, the guys are giving their best to attract developers: they have a web page, where you can try the language. For those of you who are on my level of understanding: JRuby is a dynamically typed language with single inheritance. It is method oriented – everything is a method, even the constructor (it’s called initialize) and the new operator. The @ symbol is the same as “this.” in Java. As in Scala, Groovy and co. you don’t have to explicitly say return at the end of the method. JRuby has closures, but their syntax doesn’t look very similar to that in Scala or Groovy. The language supports operator overloading. It also supports changing existing classes – even those which are part of the core.

JRuby applications can be deployed on Rails. JRuby code can be deployed as part of a Java Web application – alone or together with Java EE code. The language has its own servlet and servet filter.

After Hiro gave this short introduction to the language, he continued with the tools and frameworks based on JRuby. There are several testing frameworks quite similar to Groovy-based Spock and easyb. I’m not sure whether they can be used to test Java code though. Because this is one of the safest ways to learn a JVM language – write the test for your Java application in that language’s test framework. JRuby has also quite a few build tools that integrate well with Ant and Maven. It can install maven artifacts in the same manner as it installs its own gems.

As we heard from Mark Reinhold JNI was designed deliberately hard so that Java developers avoid writing native code. Well, JRuby has much better alternative in that area, and it’s called FFI. To be honest, I didn’t get much of it from the presentation, but I hope Google search would know better than me how it works.

I’m pretty sure now that when you create a new JVM language, after it gains some traction, you will inevitably create the wholly trinity: web framework, testing framework, build framework. It is even better if they integrate seamlessly with existing Java solutions in the respective area. A great plus for the language is if it offers to the world something very specific that is not present in other “competitors”.

NoSQL for Java developers

After a very intense attendance of Spring sessions at Java2Days a couple of weeks ago, I must confess that this was my first talk at Devoxx. Well, it was not exactly on Spring, but more about NoSQL (which means Not Only SQL). The speaker was Chris Richardson, who is the founder of CloudFoundry, which was acquired by SpingSource several months before it was acquired by VMWare.

So, why is NoSQL so popular these days? Well, it addresses some issue of RDBS like storing complex object graphs and semi-structured data, it handles very easily schema changes and scales both out and up. Well, it doesn’t support ACID. If you want faster, relational and ACID-ful database, you may look at a new proposal on the market – NewSQL.

So…., the presentation was about NoSQL. Very good approach by Chris. He chose three different kinds of NoSQL databases: Redis (key-value store), Cassandra (column oriented database) and MongoDB (document DB). Then he explained in detail what are their advantages, how they store the data, what are the commands to be executed for regular operations like inserting and reading, what are the usecases where they shine and which companies are using them productively.

After that Chris went on with a case study on how you can implement two simple scenarios in the three data stores. The first scenario was quite straightforward, but the second one was quite more complex – it would be implemented with three joins in standard SQL. It seems that most of the data stores have problem with such type of queries. I’m pretty sure that I didn’t get it, but it seemed to me that for the Redis and Cassandra examples Chris tailored the data store structure to follow the query logic, so that it can be executed. If it is true, then what would you do if you have to implement a second query. Apparently you cannot restructure in runtime your database before running each query. Anyway, MongoDB didn’t have problems with this, as it has very powerful JSON based query language. BTW InformIT has a great review on this data store.

The conclusion was that each NoSQL solution solves a particular set of problems that RDBMSs have. But none of them solves them all and all of them have a drawback – they are not ACID-compliant. So Chris’s advice was: be very cautious when you decide to use NoSQL. If at some point of time you decide that you need ACID, then you’ll have to rewrite the whole data access logic.

Language/library co-evolution in Java 8

The last session, which I attended today was by Oracle’s Brian Goetz. It was about adding lambda expressions to Java and the enhancements in the libraries that follow that. It’s always better to solve a problem by contributing code to the libraries rather than by adding new language features. However, sometimes the latter is inevitable.

This presentation followed what Mark Reinhold presented in the morning about project Lambda, but in more details. Brian started with the same code example – looking at a list of students and finding the one with highest mark. Right now it can be only implemented by writing a sequential algorithm that runs outside of the list – iterate over all of is elements and find the one with maximum mark. However, this solution tends to be non-thread safe and inherently serial. And serial algorithms are the root of all evil. Then Brian proposed a better algorithm that uses the Java 7 fork/join framework. But the code looked quite unreadable – with three inner classes representing the different functional concepts like predicate or mapper. The lambda functions solve exactly that – remove the boilerplate by providing the possibility to treat code as data and let it be passed as parameter.

The Java team at Oracle didn’t stop with adding the closures to the language. They searched actively for their application inside the existing libraries. And the collection framework seemed like a perfect fit. Having sort or filter methods in the various collections would be perfect and will eliminate the need to implement sequential means of sorting them. However the collection API interfaces are already very stable and touching them is not the best idea, as all the implementations in the world have to be adapted as well. So, the solution here is to have a new language construct – default implementations defined in the interfaces. Thus the extending class does not have to implement this method – if it decides not to do so, the default application will be executed. This means that if you add sort method in the List interface with implementation that calls Collections.sort(), then if some of the existing List implementations doesn’t override this method, that default method will be executed. As I already mentioned, this small feature is not less important than Lambdas, as it enables adding methods to existing interfaces without breaking compatibility.

Then Brian went on to present the convenience methods that will be added to the Iterable interface. Just to mention filter, sort, map, reduce among the rest. The default implementation of each of them simply calls the respective method in the Collections class. The next question is which of the methods are lazy (i.e. they don’t change immediately the collection) and which are eager. It appeared that all the operations that return as a result an Iterable (like filter for example) are lazy. While methods that return anything else are eager. Usually when you would call the collections API the sequence is lazy, lazy, …, lazy, eager.

The last part of the presentation was dedicated to parallelizing the collections. Fork/Join will definitely be used for that. Each Iterable implementation will have a method called parallel(), which will return a corresponding Spliterable interface implementation.

I will not go into more details. Hopefully Brian’s session will soon be made public as it is very useful for understanding the benefits of both features – lambdas and default methods.

November 17th, 2011

By Stoyan Rachev

I am interested in the “New Languages on the JVM” theme at Devoxx for two reasons. Firstly, I tend to be rather enthusiastic about programming languages. I’ve switched them few times during my career and it was mostly a rewarding experience. I fully buy into the idea that we programmers should be familiar with several languages even if using actively only one, simply because the different concepts in each language provide useful “thinking tools” for approaching problems. Secondly, however, I am a bit overwhelmed by the current boom of new JVM-based languages. Groovy, Scala, JRuby, and Clojure, are only some of the more popular at Devoxx, and this is by far not an exhaustive list. What should we do with all this diversity? As beautiful, concise, and runtime interoperable with Java as they may be, how does this help us with that half a million LoC legacy Java stuff? And as enthusiastic as I and my colleagues may be, how could these newcomers possibly penetrate the corporate product standard fortress that often declares the “one language to rule them all”?

In the first part of the Crash Course into Scala session, Mario Fusco presented an introduction into the Scala programming language. What is Scala? The abstract really got me hooked: “Scala can be used both as an object oriented language, more elegant, concise and powerful than Java and a pure functional one as rigorous as Haskell. Moreover, despite of having all the safety of any other statically typed language, it allows to have also all the expressiveness and flexibility of a dynamic typed one like Groovy. In a word Scala can be many languages in one, but where it really shines is the way it seamlessly combines all these paradigms together”.

In the beginning of the session, Mario outlined the language philosophy of “Do More With Less” against the Java “Keep It Simple” mantra. He then proceeded to compare Scala with Java, Groovy, and Haskell, revealing its “object-oriented”, “scripting”, and finally “functional” features. This included a brief overview of constructor syntax, operator overloading, override keyword, default parameter values, named parameters, singletons, companion objects, traits, case classes and sealed traits, pattern matching, implicit conversion, structural typing, functions as parameters and return values.

To put all of that together, Mario created a simple DSL for looping, which also nicely demonstrated Scala’s power to create DSLs. The end of the session contained an overview of some more functional programming concepts such as tuples, list manipulation operators, higher order functions, and for-comprehension.

The talk itself was well structured, full of technical details but at the same time also understandable for Scala newbies (like myself).

In the second part, Kevin Wright proceeded to outline the Scala’s perceived role as “agile enabler”. First he tried to amaze the audience by executing the following “expression”:

A long time ago in a galaxy far far away

This demo took a few compile attempts before it could actually run, but still it was intriguing. After that Kevin presented a few examples of language features where he pointed out Scala felt “natural” and helped developers translate their ideas into code more easily, without boilerplate, and still in a type safe way. One particular example referred to Kevin’s gist at, in which he showed how by overriding the “+” operator for chaining filters one could capture business domain knowledge in a way that is both more concise and more readable.

At the end of the session, Kevin answered questions from the audience based on real experience. We learned that:

  • Scala is best introduced in the team by creating tests against the existing Java codebase
  • Scala practitioners may pay a bit higher one time upfront cost to get a substantial payback later
  • Some of the powerful language features could be abused (“you can cut deeper with a sharper tool”) and not doing that takes discipline.

Overall, this talk contained some pretty interesting ideas and examples, even though it was a bit too unstructured for my taste.

Although this talk did not address all the concerns I expressed in the beginning, it was still quite helpful. It did convince me that Scala could be a really great language that is worth trying out. As a first step, I could probably write a few unit tests for my project and share them with my team. Then, if enough enthusiasm is born, we could together find also other ways to adopt Scala. But wait, should that again be Scala, or Groovy, or JRuby, or … well, let’s see how the other new languages will fare in the Devoxx parade.

Posts in other blogs about this session: