Semaphores on Java – Some Edge Cases

At work, we recently had a discussion about semaphores. With these two tests, I want to shed some light on using semaphores on the JVM with Java:

import java.util.concurrent.Semaphore;

import org.junit.Assert;
import org.junit.Test;

public class SemaphoreTests {

@Test
public void releaseWithoutPreviousAcquirePossible() {
Semaphore semaphore = new Semaphore(1, true);
semaphore.release();
Assert.assertEquals(2, semaphore.availablePermits());
}

@Test(expected = Error.class)
public void upperBoundOfSempahoreDefinedByMaxInteger() {
new Semaphore(Integer.MAX_VALUE).release();
}
}

Building Command Line Apps With Gradle

Over the course of the last years, the build automation tool gradle has established itself as the favourite kid on the block regarding build tools. It is used in many great open source projects, e.g., hibernate and grails, and is now even the default build system for Android apps.

In betsy, one major open source project of the distributed systems group, we also use gradle. I want to elaborate one particular use case we had in mind when leveraging gradle for our project.

Our focus was to have one simple command that can do the following:

  • download all dependencies (including the build tool itself)
  • compile the software
  • run the software passing it arguments from the command line

Most build tools today can download all dependencies via a repository like central maven and compile the software. Downloading itself as part of the build process, however, is not an easy task. The same holds true for starting the built software with passed parameters as part of the build process. I want to show you how we achieved it with the help of gradle.

Download all dependencies (including the build tool itself)

Gradle ships with the amazing feature of the Gradle Wrapper which consists of a shell and a batch script that can automatically download gradle and start the gradle build. Its only dependencies are that Java has to be installed. These scripts can be automatically generated with gradle. To achieve this, you need to define the wrapper task in the build.gradle script like that:

task wrapper(type: Wrapper) {
    gradleVersion = '1.7'
}

Then, by running the command gradle wrapper on the command line, we generate the gradlew and the gradlew.bat files. Thus, no local gradle installation is required anymore, as we can use these scripts instead. This allows developers interested in our project to try it out with much less hassle.

Run the software passing it arguments from the command line

To be able to run the software directly from gradle, we use the application plugin which lets us define a Main class which can be started using the run command. To achieve this, we extend the build.gradle file as follows:

apply plugin: "application"
mainClassName = "some.package.MyMainClass"

With this extension, we can run our application with gradlew run. However, it is not possible to pass in arguments from the command line, yet. For this, we use the following extension of the run task:

run {
    if(project.hasProperty('args')){
        args project.args.split('\\s+')
    }
}

Then, we can pass in arguments using the args property via gradlew run -Pargs=”–my args for the system”. This works really well, however, we always have to type in gradlew run -Pargs=”” when we want to pass in custom parameters. Thus, we introduced one shell and one batch script to circumvent that problem. We named these scripts after our project, in our case betsy and betsy.bat.

gradlew run -Pargs="$*" # contents of the betsy shell script
gradlew run -Pargs="%*" REM contents of the betsy batch script

Now, we are able to download gradle, run gradle with our build script, download all dependencies, compile our tool and start the tool with our parameters in an easy way by only typing in betsy -o bpelg Sequence.

Fixing Nokogiri Warning After Ubuntu Upgrade

I develop Ruby On Rails projects in Ubuntu-based virtual machines.
A few days ago, Canonical released Ubuntu 13.04.
After upgrading to this new release, I got the following warning when running my rails test suite:

$ rake
WARNING: Nokogiri was built against LibXML version 2.7.8, but has dynamically loaded 2.9.0
...

I invoked the nokogiri command for more information:

$ nokogiri -v
WARNING: Nokogiri was built against LibXML version 2.7.8, but has dynamically loaded 2.9.0
# Nokogiri (1.5.9)
---
    warnings:
    - Nokogiri was built against LibXML version 2.7.8, but has dynamically loaded 2.9.0
    nokogiri: 1.5.9
    ruby:
      version: 2.0.0
      platform: i686-linux
      description: ruby 2.0.0p0 (2013-02-24 revision 39474) [i686-linux]
      engine: ruby
    libxml:
      binding: extension
      compiled: 2.7.8
      loaded: 2.9.0

Ok, it seems that nokogiri was compiled with libxml 2.7.8 but the system currently only provides a new version of libxml, namely libxml 2.9.0.
This issue can be fixed by reinstalling nokogiri as the new installation will be compiled against the new LibXML version.

$ gem uninstall nokogiri # remove nokogiri
$ bundle # if you use bundler
$ gem install nokogiri # if you do not use bundler

As you can see, the warning is now gone.

$ nokogiri -v
# Nokogiri (1.5.9)
    ---
    warnings: []
    nokogiri: 1.5.9
    ruby:
      version: 2.0.0
      platform: i686-linux
      description: ruby 2.0.0p0 (2013-02-24 revision 39474) [i686-linux]
      engine: ruby
    libxml:
      binding: extension
      compiled: 2.9.0
      loaded: 2.9.0

Please leave a comment if you found this guide helpful!

The helpful java.awt.Desktop class

I am currently working with Jörg on the betsy tool which compares the WS-BPEL 2.0 conformance of open source WS-BPEL 2.0 engines. At the end of a successful comparison run, html reports are generated and can be opened by the user via the browser. I often had to execute such a betsy run in different configurations and wanted to look at the results only. The problem is that you have to wait until the run is completed (no notifications available), open the windows explorer, navigate to the correct folder and open the html file. This process can be shortened by using bookmarks in the browser for the results. However, this does not solve the problem on being notified after the run is completed. Regardless, I have found a very simple solution: the java.util.Desktop class.

This class is shipped with the Java SE edition since Version 6 and can be used to open the default browser at a specific URI, open the default mail application (even open the compose mail window) or open/print a specific file using the registered application for this file type. I created a few examples in groovy code to show you how simple this functionality can be used as mostly only one import statement and one code statement is required. The code is written in groovy, however, it is also compatible with Java code. Just copy the import statement to the top of the Java class and past the other code line where you want to execute it.

Moreover, you can open a file using the default editor, too. As some operation systems may not support this class, you can check with the static method Desktop.isDesktopSupported() whether it is possible to use this functionality in general. For more information using this class, please refer to the Javadoc documentation.

The Renaissance of command line tools

A few years ago, everybody created GUIs for simply anything. IDEs were created with plugin mechanisms that support a clicking way to achieve everything a developer wanted. They were perfectly for specific programming languages and supported the tasks around them quite well compared to the command line tools of compilation.

However, with the coming of Java, Ruby, Python, etc. as well as the Web, many frameworks have been developed. Some innovated, some copied, some had success. I think, one the success factors are automation tools accompaning the frameworks. The best example for this is the rails framework. Ruby on Rails (rails in short) is THE web framework within the ruby language. It has gained some popularity as it describes a DSL (domain specific language) for writing web applications using the Model-View-Controller (MVC) design pattern for the web. It is packaged and distributed with the rails command line tool. This command line tool allows to automate many tasks like creating a first application, creating controllers, models, views, changing models, starting the web server with the rails application deployed onto it.

In one of my personal projects, I will provide such a command line tool for a web framework which does not have one.

JS 2.0 is CoffeeScript

Avoiding all the bad things in JavaScript, CoffeeScript provides the solution. It is a language with very expressive and clean syntax which is compiled into fast JavaScript avoiding many pitfalls, providing higher level constructs, etc.

It even generates clean and readable JavaScript. This is a solution to avoid writing loads of JavaScript. It can be executed locally using node.js as it is mainly targetted at running on servers or desktop pcs.