Category Archives: Java

Java’s CountDownLatch JavaDoc is flawed

The first example of usage provided in the CountDownLatch JavaDoc might give you the idea that the example work to synchronize the simultaneous start of multiple threads. At least I thought so until a concurrency test I was working on failed. Closer examination revealed that almost all threads actually missed the start completely. A lot of my concurrency testing involves minimizing phase shifting and do as much preparation as possible in a desperate attempt to avoid parallel execution in theory turning into serial execution in practice. When all is done I seek to maximize the parallelism by a simultaneous start of all worker threads. The CountDownLatch JavaDoc give two properties of their example:

The first is a start signal that prevents any worker from proceeding until the driver is ready for them to proceed.

The second is a completion signal that allows the driver to wait until all workers have completed.

These are the two properties you get. One third property is totally left out:

Only if the administration delay is large enough, do worker threads have time enough to be prepared for the start signal.

..meaning that you’re just lucky if not some of your worker threads, if not all of them, miss the start. Could it be knowing about this third property that made Oracle inject a call to doSomethingElse() before firing the start signal? I understand you might not have seen the problem yet so let me rephrase myself a bit and try my best to be clear.

The driver thread, the thread “administrator”, can be really really quick creating his worker threads. So quick in fact that the operating system hasn’t had the time yet to schedule the worker threads for a first run before the driver thread moves on and fires the start signal. Thus the start is not synchronized among the workers. The start signal prevent workers from starting too early, but it does not prevent workers from starting too late. For a small amount of worker threads, you might never see a problem. But it will become one as soon as the size of the thread pool grows a bit.

The threads will always start too late of course, just like the human runners in a real marathon race. But if you’re up to the task of writing a marathon game where each runner is represented by a thread, wouldn’t you want the start to be as fair as possible? Of course the game design should probably be totally reworked, but I think you get the idea.

The Oracle example never address the issue of threads starting too late, but if a synchronous start is important for you, then their example cannot be applied. As my testing has shown, if the driving thread (the coordinating thread that spawn workers) makes no delay, and the worker threads do (just 10 milliseconds in my test), then all worker threads will miss the start. For a marathon, that would be a disaster. One fix could be to use yet a third CountDownLatch. The third latch will synchronize the driver and make him wait for all workers to become prepared before firing the start signal. Another more clean solution is kind of built on the same idea: Instead of setting the count of the start latch to 1, set it to the amount of worker threads + 1 (the driver) and make all threads including the judge count down the latch. Not until all threads has cooperatively reached the starting line will the race begin. Quite simple really. See the example code here.

I’ve built a smallish test framework for this particular example that also demonstrates both solutions. You can find the source code here. It is a Maven project and you can have it run on your machine within minutes. Enjoy!

The Enterprise Side of JavaFX: The Missing Part

The introduction you most likely don’t need

If you’re just a bit like me, you adore Java EE and all it has to offer. Java EE makes remoting from an application client a breeze if you stick to ordinary Java SE Swing based application clients, Java Web Start and dependency injection. Then all you have to do is to annotate a static field in your application client’s Main class and then go to work with this variable and everything just works.

But Java SE 7 update 6 happened which began the Oracle tradition of including JavaFX runtime libraries and utilities. Oracle also announced they will drop Swing in favor of JavaFX and indeed that is a good thing since Swing, which is today some kind of a standard for Java GUI:s, hasn’t been updated for a really long time and lost its competitive edge to other frameworks and languages. JavaFX on the other hand is new technology; featuring nice stuff like hardware acceleration and touch capabilities. I’m sure you can google the rest 😉

So what is the problem?

You cannot package a JavaFX client in an EAR package and then do dependency injection as if the application client is just another regular enterprise application client. Well, in theory I don’t think there’s anything there to stop you. I just haven’t got it to work in a straight forward way..

..until I found the solution I will present in this post/tutorial. The solution that will package a JavaFX application in an EAR package and then use resources from your Java EE application server with dependency injection.

You will not have to do any JNDI lookup programmatically and it even works with role based authentication as will be shown! All because your application client will for starters be a standard Java SE application that in his turn, when everything has been setup, starts a JavaFX application. The trick is not ugly, it is a pure JavaFX solution with kept benefits. Your ordinary thread will call javafx.application.Application#launch(Class, String) which will launch and setup the JavaFX application you’re used to. No strings attached! The solution is to be considered more of a packaging trick than anything else. If I haven’t made myself clear enough: The end GUI is a complete JavaFX application and nothing will be lost. You will even maintain your standard working model with separate FXML files for the structure of your GUI elements and controller classes in separate files that handle the business logic behind the GUI elements. You will not have to build scripts for Maven or Ant. You will not have to pass eye straining arguments to the Java- compiler or virtual machine. The solution will be completely built using only wizards from the NetBeans IDE and some minor code customizations.

Alternative solutions

One apparent way to connect a remote JavaFX desktop application with your application server is to use a HTTP wired web service. Oracle has demonstrated consuming a RESTful web service from a JavaFX application here, here and here. Oh yes, there are some “parts” here and here too. However, REST is not the only enterprise communication model out there, although as of today, it is the only remoting model you can found demonstrated on the Internet. For a particular project of mine, I found that JMS was a better alternative. I also needed remote access to an EJB. Alas invoking server side resources through JNDI proved to be error prone and a real hassle. But with Java Web Start and dependency injection, the user won’t even have to supply an IP and port that maps to the server.

What we will produce

In this tutorial, you will build a JavaFX application, packaged together with an EJB in an EAR package and have the application client launch through Java Web Start. Then the client shall login and get a role before he makes a remote call to a server side EJB. Here is a screenshot of the finished application:


JavaFX Application Client


If you really want to know: My setup is NetBeans IDE 7.3 and GlassFish (build 5). All running on Windows 8 x64. And one more thing before we begin; I use a tremendously simplified package naming scheme. I use only one package name shared across all my projects/modules for this tutorial. IRL, that practice is much discouraged.

What you will find in this tutorial and related pages:

  • Create a new Java EE Enterprise Application (page 2)
  • Create a shared library (page 3)
  • Create a new stateless Enterprise JavaBean (page 4)
  • Setup the role in GlassFish (page 5)
  • The JavaFX client template (page 6)
  • The Swing client (page 7)
  • Setup the Swing client (page 8)
  • Configure GlassFish (page 9)
  • Write some Java logic (page 10)
  • Build, deploy and run! (page 11)
.Create a new stateless Enterprise JavaBeanCreate a new stateless Enterprise JavaBeanCreate a new stateless Enterprise JavaBeanBuild, deploy and ru