That’s exactly why I have created a slidedeck with 20 slides to cover the FxContainer. You can read it in 10 minutes and start using FxContainer in your JavaFX applications.

You can also download it here:  JavaFX Dependency Injection with FxContainer

You can get additional (sometimes overlapping perspective from my earlier blog

http://objectsource.com/blogs/2010/08/fxcontainer-the-ioc-container-built-using-javafx-and-for-javafx-applications/ 

or my “other blog” at java.net that has more details for the detail oriented folks

http://weblogs.java.net/blog/srikanth/archive/2010/08/21/fxcontainer-ioc-container-written-javafx-javafx-applications

Happy reading

So what is FxContainer?

FxContainer is the only IoC container that is built using JavaFX and specifically meant for JavaFX applications to provide Dependency Injection.
But that is not its speciality really.

The world is already filled with dozens of IoC containers. Do we need another one? That is the question I pondered a lot before setting out to write a DI/IoC container in JavaFX

Writing a DI is fairly easy, but not completely trivial. So I looked at Spring, Guice and others as to how to apply them successfully for JavaFX

Spring supports XML and Annotation based Dependency Injection. Guice supports Annotation and binding & provider API based DI. Both support Constructor and Setter Injection.

Unfortunately for us, JavaFX does not support Annotations. JavaFX also does not support constructor injection. So we are left with XML based setter injection.

However setter injection feels artificial for JavaFX programming style (where variables are initialized during allocation. Variables are generally declared public-init)

In addition, Setter Injection introduces atleast one known side effect that can cause certain type of JavaFX objects not to work correctly. (More details here: http://weblogs.java.net/blog/srikanth/archive/2010/06/12/wiring-javafx-objects-spring-tread-caution)

A minimal Spring DI requires 3-4 jars that can add up and exceed 1 MB. My aim is to have one DI solution for all platforms (dekstop, mobile etc. i.e if JavaFX becomes a reality in mobile. I know you have some doubts about that. Me too), lightweight, powerful, small footprint and easy to use.

FxContainer is exactly that.

More details 

I will not repeat and bore you with details but you can read it up on my “other blog” at Java.net View it here and Vote for it if you like:

http://www.dzone.com/links/fxcontainer_ioc_container_written_in_javafx_for_j.html

And dont forget to provide feedback, ideas and contribute to the project on our discussion forum: https://fxobjects.dev.java.net/servlets/ProjectForumView

I am extrmemely pleased to inform that ObjectSource has now achieved JavaFX Silver Partner status.

JavaFX partner requirements are not very strict as it is still in infancy.

However I feel that the silver partner status validates our commitment and contribution to JavaFX as a  

1. JavaFX systems integrator
2. Application and Content developer
3. Significant contributor  to JavaFX open source projects and community

This also reaffirms our commitment to JavaFX as a RIA platform.

We will continue to work towards eliminating FUD associated with JavaFX in the community. Needless to say we will continue to contribute to extend the horizons of JavaFX.

This calls for a round of beer and then business as usual

Not to worry. I have created a slidedeck with 25 slides to cover the FxObjects. You can read it in 10 minutes and get the overall picture pretty well.

This approach works great if you are a big picture guy and want to scratch the surface before delving in deeper.

Well, here it is:

You can also download it here:  Effective JavaFX Architecture with FxObjects in 10 Minutes

Happy reading

FxObjects is a open source Enterprise JavaFX Application Development framework. The whole intention of the framework is to make Enterprise JavaFX application development easy, elegant and fast. The 0.1 version provides powerful features

1. JavaFX objects to XML round tripping a breeze (zero code)
2. Makes asynchronous calls really easy
3. Consolidated commands for Http calls with option to plug in request and response builders, content processors and token based substitutable url templates and finally callbacks to update the UI.
4. Controller framework provides controller chain to organize your UI into pages and modules
5. Provides Model View Presenter implementation for the very first time in JavaFX to make your UI lean, mean and clean and easily testable with JUnit and jMock.

0.1 release includes a 50 page user guide and 8 fully working samples demonstrating the usage of the framework.

There are big plans for 0.2 and hopefully more people would join and contribute.

Checkout the project: http://fxobjects.dev.java.net

The framework is based on my series of blog posts on Enterprice and Effective JavaFX architecture at java.net -  http://weblogs.java.net/blog/srikanth

In the last few weeks I have blogged about the rationale behind a few of these here. There is some overlap between the contents of the blog and the user guide, as the thoughts became blogs and crystallized into this framework and got refined into the user guide.

• Effective JavaFX Architecture Part 1
• Effective JavaFX Architecture Part 2
• Effective JavaFX Architecture Part 3

When I did some large JavaFX project – about a year back, as I painfully recall, there were no patterns, principles or best practices for developing JavaFX applications. After serious introspection, analysis of our execution and a few more JavaFX projects it became clear to me that there was a gap to fill. FxObjects is now the end result of months of hard work from me and a dedicated team committed to making JavaFX application development easy, elegant and fast for all of us. 

It seems to be part reality and part fashion to rule out JavaFX once in a while. Give JavaFX a try. Combine JavaFX with JFxtras UI controls library (http://jfxtras.org)  and FxObjects application development framework (https://fxobjects.dev.java.net) to architect and develop applications that are beautiful inside-out

Enjoy and code elegantly in JavaFX!!

One cannot cruise through JavaFX land these days without hearing about JavaFX keywords “bind”, “inverse” and “on replace”.

In short, one could think of JavaFX bind as an Observer pattern at the language syntax level. It is one of the biggest “zing thing” purported about JavaFX in common literature. It has even been claimed that the JavaFX bind can be applied for declarative automatic data binding.

[What is data binding – In a typical application the data comes from a server. A common mechanism used in Swing based UI development is to automatically tie the data from the Java based model object to UI widgets. This mechanism is called Data Binding. JGoodies data binding is used frequently with Swing. Similarly SWT and JFace data binding is popular in Eclipse RCP world]

Having successfully used SWT/JFace data binding in the past, I was ecstatic about JavaFX providing language level bind support and decided to try it out in a real JavaFX project and found it is not all that great as hyped. [One would of course say – “Yes it has its limitations”. But what are those limitations exactly? Instead of hand waving, this blog examines them thoroughly]

Let’s start with the first and obviously a big limitation.

Limitation 1: A JavaFX attribute cannot be bound to a Java attribute.

A JavaFX attribute cannot be bound to a Java attribute. I understand there are underlying platform reasons for that, but regardless that’s a big limitation as far as I am concerned. A lot of JavaFX applications that I build are large corporate applications and my data always comes from the server as Java objects. I’d have loved to bind these Java objects to the JavaFX UI widgets – ideally bidirectional bind or at least a unidirectional bind. Both options dont work.

What makes this even more confusing is that the JavaFX compiler happily allows the unidirectional binding syntax, but does not work. However JavaFX compiler throws an explicit error that inverse binding with Java objects is not possible.

This compiles, but does not work

var firstNameTextBox:TextBox = TextBox { text: bind empJavaObj.firstName }

and this does not compile

var firstNameTextBox:TextBox = TextBox { text: bind empJavaObj.firstName with inverse }

One might think, “Hey. No problem – I will copy the data from the Java POJO (or a JPA Entity) sent by the server as a response my service call into a JavaFX presentation object. Something like this:

var firstNameTextBox:TextBox = TextBox { text: bind empFxObj.firstName with inverse }

where empFxObj is a JavaFX object representing a Employee. Well, you might be surprised that this also has its share of gotchas. That brings to me to the next limitation.

Limitation 2: A JavaFX object must be a def for bidirectional binding to work

def is sort of equivalent to Java’s final. Wow! Take a deep breath for the repercussions of this limitation to sink in. This implies that the UI widget attribute can be bound only to a constant JavaFX presentation data object. The memory reference of this JavaFX presentation data object cannot vary (but its attributes can vary). Well, for me, the whole point of data binding is to get data from the server as Java POJOs, construct a fresh JavaFX object and set it in the UI so that the data binding magic takes place. If the Java FX object has to be a constant, then all of bind effort is wasted (Remember folks – To reach this point, we have gone through the effort of copying data from the Java POJO into a JavaFX object – and this can be error prone effort especially when the returned dataset or object graph is large and involves conditional copying of data.)

Workarounds for Limitation 2

Having said that, there are two workarounds for this limitation and I did not like either. But I will mention them anyway.

Option 1: Dispose the UI every time

Since JavaFX expects the bound object to be a def, we can do this – On every invocation (or the end of it), we can throw away the UI itself and construct a fresh one. When the UI is newly constructed every time, the def is also a fresh one and so, the def is no longer a show stopper. So, if you had a controller that is listening to the UI button actions, it could simply access the def JavaFX object from the UI and make appropriate calls to the server to save the data and then construct a new UI with the freshly returned/constructed JavaFX object.

Why I don’t like Option 1

This works, but it works for simple scenarios. The whole reason one chooses JavaFX is because the UI is far more richer/complex than what can be done by traditional Web 1.0 or Web 2.0 AJAX/DOM manipulation (Very Rich Internet Applications – VRIA). This approach works like a charm for the Hello World application, but does not cut it for decently sized applications. When the UI and hence the scene graph is complex, disposing it on every server call is not a wise thing to do. [Unless of course one likes to develop slow and non-responsive application with JVM constantly garbage collecting and CPU cycles wasted in constructing new scene graphs every time ? ]

Option 2: Write some interesting code

Here is the second work around. I will show you the code snippet for the UI first.

Listing 1

public class VeryComplexUINode extends CustomNode {

var currentModel:FxEmployee on replace {

    boundModel.firstName = currentModel.firstName;

    boundModel.lastName = currentModel.lastName;

}

    def boundModel:FxEmployee = FxEmployee { lastName: ""; };

    def lastNameTxtBox:TextBox = TextBox { text: bind boundModel.lastName with inverse };

}

The VeryComplexUINode is my simplification of indeed a very complex UI node. Only one textbox is shown to illustrate the work around. Notice that the node maintains two instances of model objects. One is the boundModel and the other one is currentModel. Whenever the controller gets new data from server and creates a new JavaFX presentation object, it will set the currentModel on this node. The currentModel has an onReplace block that faithfully copies data into the boundModel. When data makes it to the boundModel, voila the UI widgets also show the latest data.

Why I don’t like Option 2

To get the JavaFX bind working, we have coded the following

1. We copied data from the Java model object into a JavaFX presentation model object
2. We then again copied data from the JavaFX presentation object into another

I can already hear you say: “Wait a minute!! I am jumping through hoops here to get the bidirectional syntax work. Wasn’t the goal of data binding is to prevent this kind of coding anyway?” My point exactly.

If I am copying the data from one object to another and so on just to get JavaFX bind syntax working in my scenario, I would rather not do it. Instead I would directly set the UI data manually from the Java model objects into the UI widgets.

Limitation 3: bind with inverse cannot work with expressions

Consider a case when the data to be set is based on a condition as shown below

var firstNameTextBox:TextBox = TextBox {

    text: bind if (empFxObj.lastName == null) "N/A" else empFxObj.lastName with inverse;

}

But guess what? You are not allowed to do that. Bidirectional binding don’t allow expressions. Again, I understand why it is disllowed, but this is a minor irritation while building business applications, as objects from one tier to another don’t map plain-vanilla. A transformation of data between tiers is always in the cards. [You might be wondering – why in the world would anybody not have a last name. Certain cultures don’t have last names. Closer to home, “The Artist formerly known as Prince” does not have a last name!].

NOTE:

1. Followers of “Presentation Model is redundant v/s necessary” discussion might say that – “Hey the presentation model needs to be dumb and the transformation code needs to reside in domain to presentation model mapping tier”. You are right, this code should reside in the mapping tier, but the above code is meant to illustrate the JavaFX limitation – not a showstopper, but a nice to know limitation
2. There is at least one case where a JavaFX presentation model is suitable. In JFxtras libraries, The XTableVIew component can only be bound to a JavaFX object. That bound JavaFX object has to extend a predefined XObject class.

Design choice: Using bind as alternative for loosely coupled Event Listeners

Now, some of you might have thought about a lot of uses for the bind syntax and I am one of them. I even thought I don’t have to write event listeners, change listeners in my system and just use bind. Well a deeper thought proved how wrong I was – The primary fact about JavaFX bind is that you know whom you are binding to. That results in a tight coupling between the source and listener. This is not an issue if the listener and source are in a same UI. There is nothing wrong about it. (In fact this is the only case where using JavaFX bind saves additional coding and is an elegant way to do things).

If you are trying to mimic an event bus sort of thing (for instance enabling the copy icon when text is selected somewhere in the UI). It can be theoretically achieved, but the code will not be pretty.

Summary

The possibilities with JavaFX bind are over-hyped. However use bind only in limited scenarios (Not many as you saw above). There are a whole lot of cases where bind seems like a good idea at first, but read this blog post for the devils in the details. The whole point of this blog post is to convince you to bid good bye to data binding in your JavaFX UI architecture using the bind syntax (at least for now and foreseeable future). It is a slippery slope that will lead you pointless customizations of your UI objects, plugging in PropertyChangeListeners in JavaFX, forcing you to invent one hack after another to support your one-off cases and duct-taping your application to prevent it from falling apart.

I recommend that you do yourself a favor and forget data binding in your application using the JavaFX bind syntax.

I like Spring framework. Who doesn’t? (Well some don’t. But anyway, that’s not the point). I wanted to see if I could combine the both to see if it is a match made in heaven. In other words, I attempted to see if I could wire JavaFX components using Spring. After trying a couple of scenarios, I found at least one scenario, where this may not work as expected. Here are the details:

I started with bare basics of using JavaFX with Spring first. Look at the code in Listing 1 for wiring a simple JavaFX class using Spring.

Listing 1.

<bean id="myfxobj">
  <property name="variable1" value="Initial Value1">
  <property name="variable2" value="Initial Value2">
</bean>

Needless to say that I cannot do constructor injection since there is no concept of constructor in JavaFX. So, my next resort is setter injection. It worked and Listing 2 below shows my JavaFX class.

Listing 2

public class SomeJavaFXClass {

    public var variable1:String on replace {
        println("variable1 repacement called");
    }

    public-init var variable2:String on replace {
        println("variable2 repacement called");
    }

    init {
        println("init called");
    }

    postinit {
        println("postinit called");
    }

    public function setVariable1(s:String):Void {
        println("setVariable1 called");
        variable1 = s;
    }

    public function setVariable2(s:String):Void {
        println("setVariable2 called");
        variable2 = s;
    }
}

 Nothing outstanding, but here are the concessions I made (or slightly violated JavaFX principle)

1. Generally it is not a norm to write setters in JavaFX. But nonetheless I wrote the setters on the JavaFX class.
2. Notice that variable2 is declared as public-init. In JavaFX it means, the variable should be initialized only when the object is created. By providing a setter injection, I am essentially violating that principle in theory. But it did not break anything.

Emboldened by the initial success, I went a step further to wire the JavaFX UI itself with Spring (Normally, when I create Swing UIs, I like to wire the UIs itself in Swing). Listing 3 shows the wiring that I could do (but I did not do)

Listing 3

<bean id="uiNode">
  <property name="variable1" value="Initial Value1">
  <property name="variable2" value="Initial Value2">
</bean>

In JavaFX, as you know, CustomNode is the preferred base class for all custom UI. So, I create a subclass of CustomNode. Listing 4 shows this subclass. Pretty simple – nothing fancy. Amon other things, you will also notice the create() function. This is an abstract function in CustomNode. It has to be implemented by concrete subclasses of CustomNode. The create method is your passport to creating all the UI, so JavaFX runtime could use it when needed.

Listing 4

public class MyNode extends CustomNode {

    public-init var variable1:String on replace {
        println("variable1 repacement called");
    }

    public var variable2:String on replace {
        println("variable2 repacement called");
    }

    init {
        println("init called");
    }

    postinit {
        println("postinit called");
    }

    public override function create() {
        println("create called");
        return HBox {
            content: [  Text { content: "Default Node" }  ]
        }

    }

    public function setVariable1(s:String):Void {
        println("setVariable1 called");
        variable1 = s;
    }

    public function setVariable2(s:String):Void {
        println("setVariable2 called");
        variable2 = s;
    }

}

 Instead of calling Spring, I used traditional JavaFX invocation to look at the order of invocation. as in Listing 5 i.e. by initializing the node in the traditional way .

Listing 5

var myNode:MyNode = MyNode {
    variable1: "init blah1"
    variable2: "init blah2"
};

myNode.setVariable1("Later blah1");
myNode.setVariable2("Later blah2");

Stage {
    title: "Application title"
    width: 250
    height: 80
    scene: Scene {
        content: [ myNode ]
    }
}

Listing below shows the output I got.

variable1 repacement called
variable2 repacement called
create called
init called
postinit called
setVariable1 called
variable1 repacement called
setVariable2 called
variable2 repacement called

See the output carefully. (This is the key take away from this blog).

Notice that create() gets implicitly called even before init(), postInit() and setters. That means if the UI creation logic in create() depended on the initialization of variables for some reason, then Spring setter injection results in bugs.

Granted, UIs do not always depend on initialization variables, but there are enough cases where they do. In such cases, keep this gotcha in mind and tweak your implementation to rely on other mechanisms.

One such mechanism is to write a plain vanilla create and then bind the visibility of UI elements to the instance variables. These variables will be initialized in the very next step anyway.

This way, you keep an eye out for this Spring “gotcha” coding pattern in create() and quash the problem before it even occurs.

Happy JavaFx’ing with Spring

On other machines – The memory usage keeps going up, some amount of memory can never be reclaimed. But there is nothing very conclusive as I saw on my own laptop. Perhaps there is memory leak.. perhaps there is not.. I dont know. I havent had time to check on this again. Just wanted to keep the readers of my blog informed

And I noticed something weird along the way. Anytime I change a node bound to the Scene by creating a new node instance, the previously abandoned Node was not getting garbage collected at all, even when there were no references to it in my application.

“That’s weird”, I thought. “I must be doing something wrong”. And I started paring down the UI until it was no more than a Stage, Scene and a custom node bound to Scene. And funny thing is that I saw the memory leak even then. Here is how my main code looks like:

var myCustomNode:MyCustomNode = MyCustomNode{}

var newNodeImage = Image {
  url: "{__DIR__}folder-new.png"
  width: 50
  height: 50
}

var newNodeImageView = ImageView {
  x: 10
  y: 10
  image: newNodeImage
  onMouseClicked: function(e: MouseEvent): Void {
    myCustomNode = MyCustomNode{ };
  }
}

var appBody = VBox { content: [newNodeImageView, myCustomNode] };

Stage {
  title: "Memory Leak Demo"
  width: 800
  height: 200
  scene: Scene { content: bind appBody }
}

The order of events is as follows:

1. Everytime I click the ImageView, a new CustomNode instance is created.
2. This custom node is indirectly bound to the scene. (In fact, as I understand it, this is the only way of switching scenes in JavaFX.) And by the way, my Custom Node looks like this:

public class MyCustomNode extends CustomNode {

  //bunch of UI components defined here. A few text boxes, radio buttons nothing fancy

  override function create() {
    VBox {
      content: [
        HBox { content: [ ....] }
        HBox { content: [ ....] }
        ....
      ]
    }
}

}

As you can see, it is a pretty simple node. Nothing fancy.

Here is the code for you to grab and try it out yourself: Main.fx MyCustomNode.fx

When I ran this, I monitored using JConsole. Here is what I saw:

Memory status in JConsole

The JConsole screenshot showing the memory usage is self explanatory.

1. Every time I created a new CustomNode, the memory usage went up
2. Even when it reached the critical point, full GC never occurred to recollect all orphaned nodes.
3. Fair enoguh, to say that there is are loitering objects that never get garbage collected, as if somebody is holding on to them.
4. I believe it the JavaFX engine itself that builds complex internal graphs and holds on to previously bound variables. (I am not sure how I can prove it though)

Then I did something interesting.

I removed all radio buttons and all instance variables from MyCustomNode.fx and retained only Texts (a whole lot of them, but only Texts) and ran the tests again.

Surprise Surprise! No Memory leaks this time.

This is the memory usage I saw:

Memory monitored in JConsole when CustomNode only had Text

As you can see, when I used a Node with only Text{}, there was no memory leaks. The moment I introduced radio buttons into the node and made them instance variables, I began to see memory leaks.

There is always a chance that I might be doing something wrong, but seems unlikely since this is a simple example and almost all examples I saw for switching scene involved binding.

Moral of the story:

1. All switched scenes should be created once and retained in memory for the duration of the application.
2. All data populated into the scenes could be recycled but not the underlying nodes that make up the scenes

That seems very limiting for a new platform that aspires to be the ruler of Web 2.0 and Flash and Silverlight killer.

Here is the code for you to grab and try it out yourself: Main.fx MyCustomNode.fx

Cheers,

Srikanth Shenoy