33rd Degree ’13

As opposed to previous editions this year 33rd Degree was held in Warsaw. It was quite a surprise to me that so many people from Krakow made it. The conference was 3 days long with 5 or even 6 tracks to choose from almost all the way. Believe me – the choice was not an easy one! So many great speakers with first-class speeches.

The opening talk 7 Things: How to make good teams great was given by Sven Peters from Atlassian. It was a deep dive into how they do it at Atlassian and I have to admit they do it right. From the seven rules I especially found the below applicable for me:

  • Feed your brain: always try to catch up with what’s new and cool; there are several ways to achieve that and personally I will go with brown bags and coding sessions. Actually I’ve already started doing kind-of stuff at my current company so just few tweaks needed 😉
  • Eat your own dog food: if you are not aware of the term dogfooding is about testing your own software by using it as customer would. It is even more about becoming someone else for a few days – becoming a customer of your own product, its first alpha tester. You might also invite people from outside of your time to join the event. It might be sometimes painful to hear from people with who you work how your software sucks but it is good, fast and honest feedback!

Sven’s speech was followed by Decisions Decisions by Dan North. In short it was an enlightening talk stating that there is no one universal answer to the question. It all depends on specific problem to solve and the whole context of it.

Busy Developer’s Guide to Iconoclasm was presented by famous Ted Neward. I have to admit it was really enjoyable one. However will I become a Iconoclast after the talk? I doubt it… :)

Just after Ted’s show the conference was split into parallel tracks. My first pick was Polyglot Web Programming With Grails by Jeff Brown. I was not surprised at all – Grails is a great web framework with rich support for multiple programming languages :) Jeff’s focus was on showing how easy it is to use various languages at different application layers and seamlessly switch between them. Clojure plugin has been used as example of new language integration into Grails.

The next I took was Architecting for Continuous Delivery given by Axel Fontaine. It was one of many talks on Continuous Delivery this year. The topic is really huge and hot! It is extremely amazing and almost unbelievable how some dudes are able to deploy new versions of they products into production every day or even few times a day! Look out for Continuous Delivery and Cloud Computing – it will be an important area in 2013+. And they both go together. Other talks concerning these topics I was to:

  • Developing for multi-component environment while keeping your sanity by Baruch Sadogursky
  • How we took our server-side application to the Cloud and liked what we got by Baruch Sadogursky

The other big topic this year was (again… no surpise :P) NoSQL movement. I started my trip of NoSQL at 33rd Degree with Getting Started with Couchbase Applications Development and Tugdual Grall. I did not know much about Couchbase so it was interesting demo from my point of view. Other speeches concerning NoSQL I was to:

Ratpack is a micro web framework written in Groovy with its own nice DSL. The presentation on it given by Tim Berglund was quite impressive when it comes to Ratpack minimalism. The framework is undergoing some serious surgery just now but I am sure I will give it a try shortly and share my feelings on it with you.

The another Groovy (test) framework I am going to try out is Spock. It is all thanks to Ken Sipe‘s Mocking, Stubbing and Spying with Spock. Of course I knew that Spock framework exists but I was completely unaware of its feature-richness and overall coolness.

Single Page Web Apps Architecture by Pratik Patel was an interesting talk from web universe. It was a high level view showing many important differences when it comes to building Single Page Application vs. traditional one. A lot about JavaScript and various client side patterns like MVP, MVVM etc. Personally it was hard for me to follow all the way through as I am not so much aware of the latest trends in web application design.

There were also some talks regarding new features of Jave SE. One of them was Programming with Lambda Expressions in Java by Venkat Subramaniam. I am quite aware of closures (aka lamba expressions) as I use them all the time in Groovy but it was nice to see they implemented it in Java 8.

To sum it up the conference was great and all the credits go to Grzegorz Duda who was the organizer of the event. An indisputable star was Venkat with his 4 talks including the last one: The rise and fall of empires: Lessons for language designers and programmers. I am still a bit excited but already looking forward to 2014 edition – hope in Krakow this time.

Groovy 2.1.0-rc-2 is out!

Generally it is not a big deal when next RC is released. Generally not but that one is a big deal… at least for me. Why? This is the first Groovy release where my contribution can be spotted :)

Full release notes for RC2 are available here. Of course to get the release you can download it directly from Groovy site or use any other way you like. Personally I always use gvm to obtain new Groovy releases. If you haven’t tried gvm yet it is definitely a tool worth giving a try.

Working with legacy code is fun now!

From time to time we are all exposed to some amount of legacy code. First characteristic of legacy code is that it is hard to work with and even harder to change. Sometimes even a bit of refactoring is not an option. Fortunately there is a way to boost legacy code without really touching it. The option I am talking about is creating a custom Groovy extension module what has never been as simple as of version 2.0. Detailed instruction on creating Groovy extension module can be found here.
The question is how it can be used to easily fix the legacy code. The inspiration to write this blog post comes from my recent experience with Bouncy Castle support for OpenPGP (aka bcpg). I found working with the library really unpleasant due to its fossil API. I won’t go through whole bunch of cases but I will rather focus on one example to give the idea.
The thing I wanted to achieve was getting out proper PGPPublicKey from PGPPublicKeyRing based on the key usage. Since PGPPublicKeyRing is more or less just a set of PGPPublicKeys it sounds easy-peasy. But when it comes to reality it took me some time to find a way to get the correct key – below is the way I achieved it:

public final class PGPUtil {
    public static PGPPublicKey getByKeyUsage(PGPPublicKeyRing keyRing, int keyUsage) {
        final Iterator keys = keyRing.getPublicKeys();
        while (keys.hasNext()) {
            final PGPPublicKey key = keys.next();
            final Iterator signatures = key.getSignatures();
            while (signatures.hasNext()) {
                final PGPSignature signature = signatures.next();
                final KeyFlags keyFlags = KeyFlags.class.cast(signature.getHashedSubPackets().getSubpacket(SignatureSubpacketTags.KEY_FLAGS));
                if (keyFlags == null) {
                if ((keyFlags.getFlags() & keyUsage) != 0) {
                    return key;
        return null;
    private PGPUtil() {
        // intentionally left blank


As you can see the code is already written and extracted to utility class. Despite its ugliness probably it does what it is meant to. But does any guarantee come with it ensuring a developer will ever find a class and use it instead of reinventing the wheel? Won’t it be harder to look past if the PGPPublicKeyRing class simply has a method getByKeyUsage()?

public class PGPPublicKeyRing extends PGPKeyRing {

    ... // code omitted

    public PGPPublicKey getByKeyUsage(int keyUsage) { ... }


Unfortunately achieving this in pure Java will require modification existing Bouncy Castle codebase what is not even considered to be an option. But when it comes to Groovy we have a whole variety of tools to make it happen without making incursion into Bouncy Castle. We will modify Groovy metaclass of PGPPublicKeyRing but we will do it the smart way. And the smart way means here creating Groovy extension module.
Since we already have the util class there is not much left to do:

  1. assuming standard Maven-like structure of the project create org.codehaus.groovy.runtime.ExtensionModule file and put it under /src/main/resources/META-INF/services/
  2. the content of the file shall be as follows:
    moduleName = GroovyBouncyCastleExtension
    moduleVersion = 1.0
    extensionClasses = pl.helenium.showcase.groovy.extension.bc.PGPUtil

Voilà! That’s all. The additional method shall already be visible by the Groovy compiler and at least when it comes to IntelliJ IDEA 12 Ultimate the method is also available for code completion.
What is potentially left to be done?

  • build the project into the jar: every time the jar is added to the classpath PGPPublicKeyRing class will be enhanced with additional meta-method
  • add more easy to use meta-methods to this and other classes: static methods can be added in similar way but staticExtensionClasses property has to be used instead (in module descriptor)
  • make extension classes Groovier: currently PGPUtil is purely implemented in Java but nothing prevents it from being migrated to Groovy:
    final class PGPUtil {

    static PGPPublicKey getByKeyUsage(PGPPublicKeyRing keyRing, int keyUsage) {
    keyRing.publicKeys.toList().find { PGPPublicKey key ->
    key.signatures.toList().any { PGPSignature sig ->
    KeyFlags keyFlags = sig.hashedSubPackets.getSubpacket(SignatureSubpacketTags.KEY_FLAGS)
    keyFlags && (keyFlags.flags & keyUsage)


Benefits over runtime modification of metaclass:

  • elegance: instead of manually modifying the metaclasses let the Groovy engine enhance them for you (IoC)
  • reusability: extension module can be easily reused by simply adding it to the classpath
  • transparency: extension modules are treated as if they were a part of original GDK (support from your IDE like code completion shall be available out-of-the-box)
  • dependability: additional features provided by extension modules are available all the time through the application lifecycle

Main shortcomings of extension modules:

  • scope: there is no way of limiting the metaclass modification to particular block of code or class instances
  • control: it is not as powerful as local metaclass modifications (e.g. Expandos, Categories)

I wanted to show that a lot of legacy code can be improved with help of Groovy without even having to touch it. And additionally that it can be done in an elegant and easy way. However if you are looking for another more complete, yet simple example of Groovy extension module I have created and made one available at GitHub. It is Gradle-based Groovy extension module that adds some missing random functionality to GDK.
And don't ever forget - the best place to look for Groovy extension modules is Groovy GitHub ;)

Bug in String.indexOf()?! No way?!?

I was looking through Groovy JIRA and I run into GROOVY-5858 issue. In short it is about Groovy’s String.count() metamethod which hangs forever when it gets an empty string as an argument:

'any string'.count('')

I dug deeper into it and how surprised I was when it came out that Groovy’s String.count() method fails due to bug in Java String.indexOf(String str, int fromIndex) method. Basically the contract (by javadoc) for indexOf() method is that it returns the smallest index at which the next occurrence of str is found but not lower than fromIndex. If such an index does not exist (probably due to no more occurrences) than it shall return -1. So that is the theory – when it comes to practice user might expect that if the returned index is positive (what means that next occurrence is found) then it will not be lower than fromIndex passed as an argument to the method execution.
Here is the example that shows the above contract is not obeyed by String.indexOf() method:

// given
String strToLookIn = "bug";
String strToLookFor = "";
int fromIndex = 4;

// when
int k = strToLookIn.indexOf(strToLookFor, fromIndex);

// then
assertTrue((k == -1) || (k > fromIndex), String.format("k expected to be in [-1, %d..+oo] but is %d", fromIndex, k));

When the test is run it fails with the following description:

java.lang.AssertionError: k expected to be in [-1, 4..+oo] but is 3 expected [true] but found [false]

This proves that the most basic contract for String.indexOf() method is broken. More generally bug appears always when strToLookFor is empty and fromIndex is greater than length of string in which we look in.
Since Groovy developers trusted String.indexOf() contract they (and we all ;)) have a bug in Groovy now.
Just for a reference here is how Grooovy’s String.count() method is implemented:

public static int count(String self, String text) {
  int answer = 0;
  for (int idx = 0; true; idx++) {
    idx = self.indexOf(text, idx);
    if (idx >= 0) {
    } else {
  return answer;

Exit condition from the above for loop is idx variable to become negative. Unfortunately due to the mentioned bug in String class it never happens for text variable being an empty string.
I’ve submitted a bug report to Oracle and hope it will be processed by the next end of the world which is 2018 😉 Personally I think it might never get fixed as the risk concerned with it might be simply too high. Basically up to now few billions of devices are running the broken String implementation and everyone is happy 😉
I used Oracle JDK 7u10 for the purpose of my investigation but probably the bug is present in (almost) all other versions. As it is quite obvious OpenJDK is impacted as well. Other vendors’ JDKs might not be impacted as they use completely different implementations for String.indexOf() method.