Montag, 30. Juni 2014

Custom Transitions

Long time since my last post, but I didn't had enough time to do more JavaFx work...

JavaFX has a lot of built in ready to use animations, called Transitions. There is a base class javafx.animation.Transition and many useful implementations, like the ScaleTransition for animating the size, the RotateTransition for animationg the rotation, or the FadeTransition for animation the transparency or the TranslateTransition for moving a node.

They are easy to use: Instantiate them, set a start and end value and a duration, and call play. Here an example that fades out myNode in 500 milliseconds:

FadeTransition transition = new FadeTransition(Duration.millis(500), myNode);

But sometimes, the built in transitions don't fit. Either because the built in transitions only work on nodes, but e.g. not on popups, or because you want to have an animation, that is not yet implemented. So write your own! It is very easy. Just subclass the abstract class Transition and implement the protected method interpolate. Thats all. The param frac is a double between 0 and 1. From this value, the value change of your transition has to be calculated. This is very easy if the target value is a double between 0 and 1 like for opacity. So the easiest possible example is a fade transition for popups:

private class FadeTransitionForPopup extends Transition{
  private Popup popup;

  public FadeTransitionForPopup (Popup popup){
    this.popup = popup;

  protected void interpolate(double frac) {


Samstag, 18. Januar 2014

Major bug with Java 8 default methods in interfaces found in JavaFx project

I work on a Swing to JavaFx migration project with the guys of canoo. We reimplement features of existing Swing controls with JavaFx. On implementing additional features for the TableView we found a major bug when moving columns. We filed that bug in the openfx JIRA and had some discussions with the Oracle developers.

On trying a workaround we were told of, a canoo developer found, that it was no JavaFx bug in the TableView, it was a critical bug in the Java 8 VM itself!

If you use the new default interface methods, an interface can provide a default implementation for a method. That means, that an implementing class does not have to implement this method, but it can do. See the example:

public interface MyInterface{
  default int answerToAllQuestions(){
    return 42;

public class MyClass implements MyInterface{


public class MySecondClass implements MyInterface{
  public int answerToAllQuestions(){
    return 21;

The interface MyInterface defines a default method. We have two classes implementing the interface. The first one does not implement the method of the interface, so the default method implementation will be used. The second class implements the method.

The bug is now, that if you have a class overriding a default method, the using of that method instead of the default method is not stable. After some time the VM decides sometimes to use the interface default implementation instead of the method in the implemented class. That can result in weired behaviour, that is really hard to reproduce and find out.

This bug (see the JIRA here) costed us more than 25 days of work, so have that problem in mind, if you use interface default methods in your project. A big problem is, that the collection and the new stream framework use that feature heavily. It will be interesting to see, if this P1 bug will be fixed before the release of the first Java 8 release in March.

The bug was fixed. The cause was an over optimization of the hot spot compiler. So the fix will be part of the official JDK 8 release in March! So we can use the default methods in interfaces again with not being afraid of strange behaviour.