alt
October 4th, 2012

by Ivan St. Ivanov

Who is more functional

The first session that I attended today was in the early morning slot, when JetBrains’ Andrey Breslav (the leading designer of the Kotlin programming language) compared four languages (Java 8, Groovy, Scala and Kotlin) in terms of being functional. The comparison was done following four criteria: availability of recursion, no side effects done by the language, higher order functions and availability of abstract and algebraic data types.

I must say that the no side effects part was most interesting for me. All of you have heard the ‘immutability’ mantra. This is a very popular word in today’s programming. Everything should be immutable so that our code can be parallelized easily and reliably and take advantage of the multiple cores of the CPUs. Immutability implies that there is no shared state between two objects, so the execution of an operation of one of them cannot potentially cause side effects on the other one. The operation (or as it is called in the functional programming – the function) just takes some parameters, does something without changing them and returns a result. Talking about side effects, according to Andrey writing to a file, to the network or even to the console is a side effect. That’s why all the compared languages failed to meet this criterion.

Another very interesting aspect of functional programming was also mentioned. FP is cool and makes you look smart, but this doesn’t mean that you must use it for every feature you develop. For example the functional implementation of the Fibonacci numbers algorithm is much slower and takes more memory, than the classical (iterative or von Neumann) approach with a loop. So there is always this tradeoff between clean code and performance that you should consider.

Another corner stone of the functional programming are the higher order functions (or lambdas, or closures, or what not). Instead of explaining what they are (most of the people visiting JavaOne should know them very well), Andrey pointed us to one of the patterns in the GoF book – the strategy pattern. It’s implemented most intuitively with lamdas in mind. Think about filtering the content of a collection. Instead of getting an iterator out of it, then iterating it, then creating the new collection based on a certain predicate, you just call a filter method with the predicate (or a strategy) as parameter. This is something that was also mentioned by Brian Goetz during the technical key note: the knowledge how to apply the function on the elements of the collection should be in the collection itself and not in the client code. As the collection knows best how its content is structured and organized and can do the job in most efficient manner.

The two ADTs (abstract and algebraic data types) represent the interfaces that define contracts and the data classes. The availability and ease of use of the latter is key to functional programming. Modern languages (like Scala and Kotlin for example) have case classes and easy pattern matching when working with them. While in Java you have to do:

 if (dataType instanceof Type1) {...}
 else if (dataType instanceof Type2) {...}

Which is not really elegant.

The final functional aspect that was touched was the ability to extend (or open) existing classes without changing their code. In Java it is not possible – you cannot add a new method to the String class for example. While other languages have it in some way or another: the expando meta class in Groovy, the implicit conversions in Scala and extension functions in Kotlin. In Java the standard approach is by creating static utility methods in other classes (Collections, Strings, Arrays classes are such examples).

Very interesting talk. Andrey as always was trying to provoke audience’s participation: he had funny slides, asked questions, stopped the presentation when somebody had a question.

Continuous development

Another agile software engineering (ASE) talk. It was given by my JBoss buddies Andrew Lee Rubinger and Aslak Knutsen. They are most known by their leading the Arquillian and ShrinkWrap integration testing projects. However, the focus of this talk was something beyond testing, which appears to be the focus of their upcoming book: continuous development. So after continuous integration and continuous delivery, we are now looking at the continuous development.

The core of the continuous development process is to write code, which is able to be tested. The tests should be portable to any environment. In the enterprise world this translates ‘to any container’. They should be executable without any tweaking both from the IDE and as part of the build. They should also leverage existing testing frameworks like JUnit or TestNG in the Java world and not make up ones of their own.

Before giving us these rules, the speakers talked a bit about testing in general, as it is the most important part of the continuous development. As Jeremy Norris had stated, “The purpose of automated testing is to enable change. Verifying correctness is just a nice side effect.” Another very important thing about testing is that it makes you use your own API and thus get an early feeling whether it is good and usable. Andrew didn’t insist that you should follow the test-first approach. Just make sure that at the end you have automated tests for all your features.

The next big topic in the talk was unit vs integration testing. When you unit test a piece of code, which interacts with other objects, you usually have to use stubs or mocks in order to be able to test that piece of code in isolation. But is this isolation always a good idea? Using mocks takes your class outside of the environment it usually runs in. Thus you miss large portion of the picture. This was a nice intro to the Arquillian framework (or library, or model…). If you are doing Java EE development and you haven’t heard or are not using Arquillian, then you should consider doing it.

The rest of the talk was a demo of some of the aspects of the continuous development:

  • Using Arquillian persistence extension to test persistent data by easy way of preparing the initial and the expected data sets
  • Using Arquillian Graphene – the enhancement of Selenium browser automation library
  • Using the cloud and Openshift in particular for running your own continuous integration server
  • The hotswapping capability of Openshift: while debugging your cloud application you can change the code locally in the IDE and it gets automatically updated on the remote location

Behavior Driven Development on the JVM

The agile track continued for me with the next session. It was John Ferguson Smart’s about modern JVM tools and frameworks for doing Behavior Driven Development (BDD).

The talk started with a theoretical introduction which, as John said, was more for the Business analyst type of people (nobody in the audience confessed to have such a role). The first thing about BDD is that it advocates common language between all the participants in a project: the business analyst, the developer, the tester and the customer. You don’t really write tests in BDD, you rather create specifications. This does not mean 100-page word document, but stories following a specific format. The most common such format is the “given, when, then” triad.

The stories should describe the most relevant features of the product as seen by the final user. Which are the most important features? Well, according to the speaker, those that meet the goals of the project and bring value (in terms of money).

The agile approach of defining stories is: as a ‘role’, I want ‘…’, so that I achieve ‘…’. According to John the order should be changed and the last section should come first – the reason why we need a feature is the most important incentive for doing it.

The second part of the session was on existing BDD frameworks in the JVM world. The first two presented were jbehave and cucumber. The common thing about them is that you define the stories in human readable style in a text file and then write annotated Java code where you state your given, when and then functionality. Next was easyb, BDD library with a Groovy DSL, where both the rules and the code are at one place. This sounds good, but the code may become unreadable for more complex tests.

A forth library was also presented. It is the one developed in John’s company and is called Thucydides. I have read quite a few articles and blog posts about it, so I kind of knew what it was doing. So, its basic idea is to encapsulate any existing BDD library (those from above and also many more, Selenium 2 for example), to run the tests, observe their results and report what happened (with many screenshots). Just a side note, John approached the Forge team after the talk as he was very interested in creating a Thucydides plugin that could spare its users writing some boilerplate.

The final part of the talk was called BDD for developers. It was about BDD frameworks that replace existing unit testing frameworks and the best one here is definitely Spock. It’s again based on Groovy-based DSL and follows the given-when-then style of writing unit tests. It has its own mocking framework that is easier to setup and use even than Mockito. It’s quite easy to write data driven tests as well (remember the Parameterized JUnit test cases?). Then the speaker spent some time talking about Spec2 (which is the same as Spock, but with a Scala DSL) and Jasmine, which is the same for JavaScript.

The slides are already available on SlideShare so you can go and check them out.

What’s new in Groovy 2.0

This talk was given by the Groovy language project lead Guillaume Laforge. It was the informative kind of talk, one of those where you don’t have too many funny slides or some philosophic diversions.

Actually Guillaume talked first about the Groovy 1.8 new features, as they are also very interesting and important:

  • After 1.8 Groovy is even better for creating DSLs as there are now a lot of other possible situations where you can drop your dots and parenthesis: in functions with multiple arguments, when you have named arguments or closure function parameters and even no arguments at all
  • GPars, the Groovy parallelization library providing such features as actors, fork/join, map/reduce, parallel arrays, etc. is now part of the official distribution
  • Annotations can take closures as parameters. This is very useful for validation frameworks for example: you can define your rules as boolean functions and attach them to your model as annotations
  • There’s now built-in JSON support, the same as the XML support – with the slurper and builder objects
  • A groovy compiler plugin can do some transformation on your code before translating it to byte code, based on common annotations. For example, if you add @ToString or @EqualsAndHashcode, after you compile, you’ll automatically get toString(), equals() and hashCode() methods (something like Lombock for Java). I counted more than 10 possible transformations on the slide, but there was no time for the speaker to talk about them all

And now for Groovy 2.0. It’s major release so you may expect something really major inside. However, Guillaume started with the (in my opinion) not the greatest new features.

So, as of 2.0 Groovy is more modular. Instead of needing to download the big 6MB jar that has it all, you can download just the core (3MB) and the modules that you might need for your application. There’s now another way to extend existing classes (like the expando meta class): the extension modules. There you have to do some more plumbing code like adding some files in the META-INF/services directory of the jar, but now the static compiler (ooops, spoiler!) and the auto-completion of IDEs can really understand that the class is extended with your own methods. Groovy has now full support for all the Project Coin enhancements (multicatch, binary literals, etc.) and also for the new InvokeDynamic functionality of the VM. The speaker mentioned that the Oracle engineers have some more work to do for invoke dynamic, as for now there is not a big change in the performance of Groovy code.

And now for the most prominent part: if you wish, you can make Groovy type safe! And this can be done in two ways:

  • Ask the compiler (and IDEs) to check for things like wrong method and variable names in the code, executing methods that are not part of the called type or return wrong result types. You just annotate your class or method with the @TypeChecked annotation and voila! The compiler will check all those things for you. Beware that inside such code blocks you cannot do things like parsing or creating XML or JSON as the API there relies on the dynamic features of the language
  • One step further is the static compilation: it not only checks for compilation errors, but generates byte code, which performs much better at runtime.

At the end Guillaume showed some benchmark results for Java, Groovy with static compile and older Groovy versions. And the result showed that the compiled Groovy is just slightly slower than Java is. Nevertheless, I’m sure that there will still be people that will continue saying that Groovy is slow. To be honest, they look to me like the folks who keep telling for the last 15 years that Java is awfully slower than native code. The history repeating?

Functional style of programming in Java

My day 3 started with functional programming and ended with the same topic. The speaker was John Fergusson Smart again (this is his third session that I attended this JavaOne).

The talk kicked off by introducing the main concepts and advantages of the functional programming style and they were basically the same as in Andrey’s talk in the morning:

  • Immutability is your friend: it makes your code thread safe. Unfortunately you cannot have true immutability in Java as even private final fields can be changed with reflection
  • No side effects: no matter how many times you call your functions, they give the same result for the same set of parameters
  • Avoid using loops: leave that to the library that you are calling, just tell us what you want, not the way how to achieve it

John then showed us how you can do most of these things in Java 8 with project Lambda. But… Java 8 will not be here any time soon. So if you need something now, you’ll have to look at the libraries that are available now in the ecosystem. So the speaker presented us two such libraries: Google Guava and LambdaJ.

The Guava part of the talk was relatively short, most probably because most of the functional features there are based on using anonymous inner classes. There are immutable collections in the library. They are immutable in a sense that you cannot add or remove element to them or change their order (by sorting for example). But the immutability of the elements themselves is not enforced. The ‘don’t return null’ programming style is also addressed. If you intend to return null for some reason in your code, then consider returning Optional<?> type. This looks and behaves much the same as the Scala Option type. And this was it for Guava…

The rest of the session was about LambdaJ, which seemed to be John’s favorite FP style library. Its APIs for collection operations like filter, sort, aggregate, convert, etc. are quite better than Guava’s. The magic is that it integrates with the Hamcrest matchers (usually used instead of the JUnit asserts in your tests). An very good example of the integration is the filter method:

filter(startsWith(“P”), arrayOfNames);

Here filter is LambdaJ static method and startsWith is Hamcrest matcher method. There are plenty of matchers and it is very easy to create one of yours, so you can easily do without any anonymous inner classes. Sometimes your code might not be very readable as the design of the Hamcrest APIs was not really intended for such use. In such cases John’s advice was to encapsulate the matcher code in your own method, give this method a meaningful name and use that in the LambdaJ functions.

At the end John showed a benchmark, according to which LambdaJ performs relatively slower than the iterative code (with loops). D?j? vu: the same thing was mentioned by Andrey Breslav in the morning, so again you have to make the trade off: readability or clean code.

As always, the slides are available on SlideShare.

Conclusion

This was my day 3: functional programming and agile software engineering. And finally I could get some sleep (Oracle, thank you for that!). The quote of the day was by John Smart: “The amazing thing about [the JavaScript BDD library] Jasmine is that it exists”.