• Home
  • Events
  • About
  • Running TestFX tests in headless mode

    January 31st, 2016

    For the past few months I’ve been working on a JavaFX based product that has lots of bells and whistles. Last week we succeeded in setting up functional tests using TestFX. While everything was working fine on a developer’s machine (see this for more information) we were experiencing trouble with our CI environment.

    At first we thought it was a faulty configuration related to xvfb on the server but as it turns out xvfb was working correctly. We even ssh’ed into the server, exported the DISPLAY to a different machine and saw the test run. Kind of. The following is the basic test code that was causing us trouble:

    Clicking on #optionsMenu (a button) should bring a popup menu; clicking on #preferencesActionTarget then selects an item from the popup menu. The button is placed at the top right corner of the window.

    When running the test on a local machine we can clearly see the robot clicking on all items we told it to, however the execution on the server always left the pointer at the center of the window. Aha! the problem was that the mouse pointer froze completely. The Robot was unable to move it to the right point on the screen and the click on the expected element.

    Searching for clues to fix this problem led us to this thread at the TestFX Google Group. The problem discussed there was of a different nature, nevertheless the thread contained a small nugget of information:

    The DragAndDropBug occurs when the GlassRobot is used without Monocle. Automatic mouse movement will freeze. — Benjamin

    So we had to enable Monocle on the server. As far as we can tell there’s only one release of Monocle available at JCenter/Maven Central: 1.8.0_20. This version worked well for us although we’re running JDK8u72. Please follow the instructions laid out here if you require another version; or point that repository to jitpack.io and let it serve the binaries for you.

    Assuming you’re building projects with Gradle (if not, what are you waiting for? Maven is so old school now) you only need to configure the following dependencies to have Monocle in your build

    The last bit found in this file allow us to enable/disable headless mode in our tests. In this way we can use the real Glass Robot when running locally or the Monocle Robot when running on CI. Headless mode is disabled by default; it can be enabled by invoking

    $ gradle -Pheadless=true test

    Of course, one could tweak the build file and have the value of the headless property be set according to the current environment, that is, if the build is being executed inside the CI server or not. Once we’re done with the setup the only thing left to do is update the tests so that the correct robot is used. You’ll typically use a static initializer block to perform this feat, such as

    And that’s it. There’s nothing much to it once you know what to tweak.

    Basilisk 0.0.0 released!

    October 12th, 2015

    It’s here! Basilisk 0.0.0 has just been released! You can grab it from Bintray and JCenter immediately!

    Following the steps of the first Griffon release (0.0 back in 2008) Basilisk brings high productivity and fun to mobile/desktop JavaFx application development. This release includes the following goodies:

    Want to take it for a spin? Here’s how you can get a Basilisk application running in no time

    The recommended way to get started with a Basilisk project is to use a Lazybones project template and Gradle. You can install these tools with SDKMAN.

    $ curl -s http://get.sdkman.io | bash
    $ sdk install lazybones
    $ sdk install grade

    Next register the basilisk-lazybones-templates repository with Lazybones’ config file. Edit $USER_HOME/.lazybones/config.groovy

    bintrayRepositories = [

    List all available templates by invoking the following command

    $ lazybones list
    Available templates in basilisk/basilisk-lazybones-templates


    Select a starting template from the list and invoke the create command

    $ lazybones create basilisk-javafx-ios sample

    Compile, run and test the project with any of these commands

    $ gradle build
    $ gradle test
    $ gradle run
    $ gradle launchIPhoneSimulator

    Also have a look at basilisk-samples, a repository that will contain reference and sample applications as time passes by.

    If you decide to give it a try, do let us know what you think at the mailing list, issue tracker and/or @basilisk_fw.

    And Griffon beget Basilisk

    October 9th, 2015

    I’ve been keeping an eye on JavaFXports ever since Johan announced the project. From time to time I test the latest builds to see how the project grows. A few months ago we had a breakthrough with Griffon and the jfxmobile plugin; after a few tweaks (and some API changes from Griffon’s side) it was clear that running Griffon on an iOS device was no longer a wild dream, but rather a reality.

    So what about those API changes? There were actually not that widespread, actually they were concentrated to a particular set of common, standard APIs that every Java SE developer knows and encounters almost ever single day: the java.beans package. For historical and practical reasons RoboVM relies on the Android SDK to enable Java (and JavaFX) to run on Android and iOS devices. This brings along some of the restrictions Android users know by heart: black listed classes such as the ones contained in the aforementioned package. The only way to make things work was to replace the black listed API with something that’s functionally equivalent but with a different name, and so openbeans got into the picture. Funny thing, this package contains code from Apache Harmony, the alternate “Java” implementation that never was.

    Anyway, it was clear that a breakage in compatibility was needed in order to allow Griffon applications to reach out into the mobile space with JavaFXports’ help. We’re over a year now since Griffon 2.0.0 was released; the 2.x line broke compatibility with the previous series, and the team thinks we still have a few more releases before we decide to break compatibility again for 3.0.0, if needed be. But we don’t want to wait long in order to enjoy the benefits of Griffon on mobile, so we came up with a different plan: fork Griffon.

    Basilisk is a fork of the Griffon 2 codebase (2.5.0-SNAPSHOT as we speak) that aims to bring the Griffon experience to mobile/desktop application development. Basilisk targets Java8 and JavaFX8 specifically, any Java developer will be able to pick it up quite easily.

    For now, the differences between Griffon and Basilisk are minimal, besides the package renaming and the usage of openbeans almost everything else is the same. Migrating between one framework to the other can be done with a small set of steps:

    • s/org.codehaus.griffon/org.kordamp.basilik/
    • s/griffon/basilisk/i

    We expect Basilisk to grow on its own, sporting features that make sense for desktop and mobile environments. It will be possible to migrate features between Griffon and Basilisk, so that porting applications will remain an easy task. While Griffon remains as the preferred solution for building all kind of desktop applications, from the very small to the full fledged, enterprise ready ones, we foresee Basilisk taking its place as the choice for developers that need to build applications that cross between desktop and mobile spaces.

    There’s no release yet for Basilisk; there are still some migration aspects to be taken care of, such as the guide and documentation, however you can take Basilisk for a spin right now by simply cloning https://github.com/basilisk-fw/basilisk.git and building your own version. It’s as simple as

    $ curl -s http://get.sdkman.io | bash
    $ sdkman install gradle
    $ git clone https://github.com/basilisk-fw/basilisk.git
    $ cd basilisk
    $ gradle publishToMavenLocal
    $ gradle installAllTemplates

    After this you can use the provided templates to create and test an application

    $ sdkman install lazybones
    $ lazybones create basilisk-javafx-ios 0.1.0-SNAPSHOT sample
    $ cd sample
    $ gradle launchIPhoneSimulator

    Don’t be fooled by the low version number, Basilisk comes from a fine codebase lineage that includes Griffon (2008) and Grails (2005), it’s pretty mature as you will see.

    These are exciting times to be building Java(FX) applications for desktop and mobile.

    Keep on Groovying!

    BootstrapFX, the early days

    September 4th, 2015

    I clearly remember back in 2007 when Ben & Dion mentioned at DesktopMatters: “Web is becoming more desktopy, and desktop is becoming more weby“. The past few years have proved them right. Webapps continue to imitate the behavior of desktop applications, while desktop tries to emulate the ease of use and better experience found in web apps.

    If someone told me years ago I’ll be back to “web development” but targeting the desktop instead I wouldn’t had believe it, but lately I’ve been working a lot with JavaFX, CSS, and SASS at may day job. Yup, that’s right. It’s surprising how fast one can change the look of an JavaFX application by using CSS, deceptively fast ;-) You can spend more than half the time tweaking borders and colors instead of writing business logic. Still, the experience is much better than writing custom renderers and UI delegates in Swing.

    With this in mind, I decided to give a try at porting Twitter’s Bootstrap to JavaFX. There have been a couple of prior attempts (mixed with ScalaFX even, something that does not play well with the rest of the JavaFX ecosystem) but no concrete releases just yet. Without further ado here are some screenshots and corresponding FXML files on what can be done after a few hours of tweaking Bootstrap 3.3.5 with SASS



    Granted, it’s not much but buttons, labels, headers and badges are already working. With a few more hours of work I’m positive I can get tables and lists ready too. I’ll post the CSS after reaching that milestone.

    Keep on Groovying!

    Griffon: stacking webfont icons

    August 29th, 2015

    Some days ago I blogged about the availability of web based font icons for Griffon applications. Adding icons to a Griffon application is quite easy as shown in that entry. Today I’m going to show how JavaFX can make it plain simple to create composite icons.

    Fontawesome defines a couple of CSS classes that can be used to create stacked icons. Unfortunately those CSS classes cannot be used with JavaFX directly, however you can create stacked icons given the right container is used. It turns out JavaFX provides a node container named StackPane. It lays out its children based on the order in which they are added to the container. We can use this knowledge and the fact that any JavaFX Node that exposes a graphic property accepts a Node as its value, to our advantage. Let me show you what we want to accomplish:

    Stacked Fontawesome Icons

    The screenshot is an exact replica of the stacked example found at Fontawesome. So how do we make it happen? There are several options, but it all boils down to the following:

    • create a StackPane.
    • add instances of FontawesomeIcon with the right settings in the correct order.
    • set the StackPane instance as the value of the graphic property of a button.

    We can do all these things with FXML alone, here’s how to do it

    As you can see, FXML makes it pretty straightforward to follow the steps needed to create stacked icons. You may notice there are no text-danger or fa-stack-2x CSS classes in use for this particular demonstration. Instead, icon sizes and colors are set directly on the icons. Of course someone could create an appropriate CSS stylesheet that goes along with the settings provided by fontawesome.css in order to minimize XML code.

    This trick will work pretty much the same with the rest of web font based Griffon plugins listed at the bottom of the previous blog entry.

    Keep on Groovying!