• Home
  • Events
  • About
  • Dierk Koenig interviewed: Groovy is a pioneer for new ideas

    September 11th, 2015

    Dierk Koenig (JavaOne Rock Star) works as a fellow for Canoo Engineering AG. He is a committer to many open-source projects including OpenDolphin, Frege, Grails and Groovy. In the interview with JAXenter he talks about building user interfaces with projector patterns with HTML5 and JavaFX, Groovy and the W-JAX 2015.

    Read the full article (in German) here.

    JavaOne 2013 | September 22-26, 2013 | San Francisco

    September 18th, 2013
    JavaOne JavaOne 2013 will be beginning in 4 days’ time in San Francisco. And conference attendees can scarcely miss Canoo. Our speakers – two JavaOne Rockstars and a Java Champion – will be giving a total of 13 talks on the topics of JavaFX, Groovy and RIA technologies.

    Devoxx exceeds expectation again in 2012

    November 22nd, 2012

    When it comes to Java, web and mobile technologies, Groovy and robotics: Devoxx offers a great deal more than just Java. Andres Almiray and Gerrit Grunwald put Groovy and JavaFX in their true light on the stage in the Kinepolis Centre. Andres Almiray presented the Groovy based testing framework “Spock” and delivered a talk entitled “Rocket Propelled Java”. Meanwhile, Gerrit Grunwald provided his audience with a basic overview of JavaFX and demonstrated the creation of a custom control.

    Interesting sessions, convivial visitors and much fun contributed to Devoxx’s special atmosphere. And the conference’s high entertainment value is apparently not just down to its exceptional location; the organisation team’s motto von Entwicklern, für Entwickler (by developers, for developers) further won the audience over. Here you can view the video of the Welcome Keynote and several pictures from Devoxx 2012.

    UI Construction with JavaFX

    February 12th, 2012

    When constructing a UI then on the technical level I am concerned with
    – creating the respective widgets
    – putting them in the right place, i.e. layouting
    – making them look nice and consistent, i.e. styling
    – hooking them up to the data they should display, i.e. binding
    – and putting them to action, i.e. attaching handlers.

    Creating the widgets

    The usual way of creating widgets like labels, buttons, menus, tables, charts and the likes is by calling their respective constructors.
    Alternatively, one can use factory methods like in Swing to either set some common attributes consistently on each widget or to even construct compound components like a labelled text field.
    JavaFx provides additional Builders for creating preconfigured widgets by following the classical GOF Builder pattern with additional create() and build() methods.


    Where Swing puts its components inside containers, JavaFX adds its nodes to a parent node in the SceneGraph. Either way, layouts define how the added widgets are placed inside the available area: side-by-side, stacked on top of each other, in the cell of a grid, in equally sized tiles, or else.
    Layouts also have their own strategies of reacting to changes in the available area and how they deal with missing or excessive space.

    Selecting a layout and putting each widget in its proper place can be done by API calls or via an external description in XML format (FXML).
    GroovyFX adds the additional capability of defining the layout with tree-like builders as part of the usual code.


    Swing styling was confined to API calls that would set visual properties per-widget (plus rules for proliferation of these property values down the containment tree) and the Look&Feel concept.
    JavaFX builds on top of the API approach with CSS-like styles. This adds a fully new magnitude of power to the visual design capabilities but also a new dimension of complexity. Without going into too much detail, here are some points to consider:
    – CSS has its own notion of cascading and how to “inherit” values
    – JavaFX supports multiple stylesheets per scene plus “inline” styles per node
    – selectors are per id, node type, and/or styleClass plus some pseudo-classes
    – styles, styleSheets, styleClasses, and API-controlled properties may change at any time

    Layout styles

    To make things even more complex, it is not only the widgets that have visual properties like a Label bearing Font. Even layouts have styles, e.g. values for paddings, margins, gaps, alignments, etc. (but not for positioning ATM).


    The binding story in JavaFX follows the same approach as Swing does by registering listeners that get notified for value changes of any bindable source. Such a source is typically a data model or some other widget. The latter case has a special support in JavaFX through accessor methods that end with “Property” and provide a very efficient update mechanism.

    Projects like GroovyFX add on top of that concept further capabilities for declarative binding.

    Event handlers

    Value changes are not the only events that one can listen for. A long list of registration methods for callbacks that start with “on” are at our disposal for setting the application in action: onAction, onKeyReleased, onMouseOver, etc.
    Quite surprisingly has JavaFX chosen to only support one such event handler per registration. We cannot add to an existing list of those unless we build such a facility ourselves.

    Organizing the codebase

    With all the work of creating, layouting, styling, binding, and event handling comes the need for some organization.
    – there are sequence dependencies between these tasks
    – there is scope to be managed to keep reference usages traceable
    – styles, layouts, and whole building blocks may be shared for faster building, consistency and less maintenance effort

    In other words, we need some grouping that keeps these aspects together while making them distinct enough such that each part is easily recognizable, potentially reusable, and subject to proper lifecycle management.

    Use Griffon when you can

    The Griffon framework provides a full solution for this challenge with its organization into MVC groups and the rules and conventions that it imposes on the code structure.

    For those of us who do not have such a luxury: down below is a proposal for a simple structure that can help keeping track of the various aspects.

    Example: a simple feedback form

    We start with a simple example of a feedback form that looks like this:


    We can implement this form easily in GroovyFX by putting all the UI code (widgets, layout, style, behaviour) in one single place.
    Here is a possible solution.


    Having everything in one place has its advantages: at least you know where to start looking.
    But it comes at the expense of clarity and consistency, e.g. the initial example makes all labels to be of white color.
    Is that by accident or shall that be a consistent rule – a common style? This is most likely.

    Separating the various aspects into their own methods also provides a better overview about
    – what widgets we are dealing with
    – how they are arranged on the screen
    – what dependencies they have (binding)
    – and what they are supposed to do.

    The better structured code becomes this:


    Pretty much all styling information is out of the way and can be maintained in an extra class or css file – and used in multiple places.



    Having the styles in one place makes it often more worthwhile to improve the style. Here we worked a little on the background gradient and added an additional feat that makes the form scroll-in at startup – just as if you would be handed over a feedback form from someone who sits in front of you.

    This is how it looks now:


    This is the end of the story for today but not for tomorrow. Further improvements of this structure are likely to be needed for any project of size.

    stay tuned
    Dierk König, @mittie

    The Best Groovy Inspections You're Not Using

    January 18th, 2012

    Many, many tools perform static analysis on code. There are all sorts of automated ways to look through your code and tell you if there are likely errors or not. FindBugs, PMD, and CheckStyle are some of the big names from the Java world. On the Groovy side we have two real options: IntelliJ IDEA and CodeNarc.

    This post highlights my favorite static analysis rules for Groovy in IDEA that are not enabled by default. Groovy in IDEA 11 has well over 100 rules, but less than half of them are activated when you install the product. To turn these rules on you’ll need to go into Settings (Ctrl+Alt+S) and enable them under Inspections.

    So here are my favorites that I think you should turn on:

    Threading comes first because these inspections have saved my butt in the past. None of them are enabled by default, so do yourself a favor and enable a few. These ones are all must haves:

    * Access to static field locked on instance data – Reading and writing a static field from multiple threads is not thread-safe. It needs to be done within a synchronized block. Do you know what happens when you synchronize on instance data, like this:

    The object ‘lock’ is an instance field, not a static field. So this assignment within the synchronized block is not thread-safe. It is possible that the static field is accessed from multiple threads, which can lead to unspecified side effects.

    * Synchronization on non-final field – If you are accessing a variable within a synchronized block then your synchronization token must be final. Consider this code:

    The field ‘lock’ is not final, so different instances of MyClass may have different values for lock. The result is that different threads may be locking on different objects even when operating on the same object. Make your locks final.

    * Synchronization on variable initialized with literal – Do you understand the problem with synchronizing on a primitive literal? Consider this code:

    Strings are interned by the JVM, so the string ‘my lock’ may also be used by another class. Numbers are even worse because they can be assigned from a cache. Some other object in the system may be initialized with the same literal, and could create an accidental (or malicious) dead-lock situations.

    * Unsynchronized method overrides synchronized method – In some limited circumstances you may actually want to override a synchronized method with an unsynchronized one. But probably not. More than likely you don’t even know and you are accidentally creating a subtle bug. If the parent is synchronized then the child should be also. Or better yet, make the parent final.

    Probably bugs
    * Named arguments of constructor call – This inspection warns you when something like the following happens when using named arguments, which is almost certainly a bug:

    See the problem? The field is named ‘orderId’ with a big ‘I’ and the constructor call uses ‘orderid’ with a small ‘i’. RuntimeException if you run this code. This is a type of bug that CodeNarc cannot find because the type information of the classes is so limited. IDEA keeps track of types much better and can do nice things like this.

    * Access to unresolved expression – There has been a lot of talk over the years about adding static compilation to Groovy. Some people want to be warned by the compiler or in the IDE if their Groovy code is referencing an object that does not exist. For example, they’d like this to produce a warning or error:

    See the problem? The closure parameter is named ‘parm’ but the closure references the parameter by the standard name ‘it’. The access to unresolved expression inspection turns this into a warning or error in the IDE. IDEA is quite smart about it too and knows all about delegate/super and the other Groovy dynamic variables. If you like this sort of thing then be sure to read up on Grumpy mode in Groovy 2, coming soon.

    Control Flow
    There are many features in Groovy that simplify standard and verbose Java code. Two of these are the Elvis operator and the Null-Safe Dereference. IDEA contains inspections to help you migrate to the new way of writing code with these features.

    * Conditional expression can be elvis – This inspection migrates you from code like this:

    And suggests you rewrite it into the equivalent Groovy:

    Is it always safe to make this transformation? (Think about it for a few seconds). GroovyTruth means it is not. Technically speaking, the two code snippets are not equivalent: value != null may be true while value is false, such as when value is an empty String. Overall, I like the inspection but you need to be careful with it.

    * Conditional expression can be conditional call – This inspection promotes the use of the Null-Safe dereference. This following code produces a violation:

    … and you will be prompted to transform it ito:

    These two code blocks really are the same and this can be safely accepted as the correct way to write the code.

    * If statement (or conditional) with identical branches – I periodically refactor code and accidentally leave an if or conditional statement with identical branches. These are of course redundant and can be cleaned up by removing the if expression. If you have good unit tests and use automated refactorings then this sort of things happens from time to time. The cleanup reminder is nice.

    Error Handling
    * Unused catch parameter – My favorite Error Handling inspection is ‘Unused catch parameter’. Consider this code:

    What happens to the stack trace in this scenario? It gets eaten up, never to appear in a log. You shouldn’t have any unused catch parameters. If you really don’t care about the exception then name it ‘ignore’ or ‘ignored’ to suppress the warning.

    Validity issues
    * Duplicate switch case – Groovy has Switch on Steroids, meaning you can put almost any object in the case statement, including regular expressions:

    See the problem? The same regex appears twice. The second case will never be executed, even if it would match. As long as your case statements have literals in them then IDEA can verify that there are no duplicates.

    Naming Conventions
    Lastly, there are a whole bunch of naming convention inspections that you can activate and configure. If you’re not using CodeNarc (why not?) then you should at least activate some of these. Standards, on a whole, are good to adhere to.

    IDEA Inspections of CodeNarc?
    So which should you use, IDEA or CodeNarc? These two tools complement each other. There is good reason to use both CodeNarc and IDEA together. CodeNarc does have more inspections than IDEA, but the IDE integration in IDEA is better. Pressing Alt+Enter typically rewrites the offending code, and the speed of the actions are much better in IDEA. Also, the static analysis rules do not overlap between the products because the CodeNarc developers (that’s Chris Mair and myself) already use IDEA and made a conscious effort not to duplicate anything.

    And if you do want to use CodeNarc and IDEA, then you might try out the CodeNarc IDEA plugin.

    If you like this then you might check out some of my other IDEA related posts: The 10 Best Inspections You’re Not Using (in Java), or the IDEA archive on my blog and the Canoo blog.

    And remember if you need Groovy and Grails help, then give us a call or drop me an email at hamlet.darcy@canoo.com