What is FxContainer?

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

It is open source (Apache License). You can use it in your JavaFX applications, extend it, redistribute it, OEM it - pretty much anything you want.

Why FxContainer?

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.

An analysis of Spring and Guice - two of the popular DI frameworks, and how to apply them successfully with JavaFX reveals the following:

1. Spring supports XML and Annotation based Dependency Injection.
2. Guice supports Annotation and binding & provider API based DI.
3. Both support Constructor and Setter Injection.
4. Unfortunately, JavaFX does not support Annotations.
5. JavaFX also does not support constructor injection.
6. Setter injection feels artificial for JavaFX programming style
7. Setter Injection introduces atleast one known side effect that can cause certain type of JavaFX objects not to work correctly. For instance, CustomNode create() functions that depend on objects injected by setter injection fail
8. A minimal Spring DI requires 3-4 jars that can add up and exceed 1 MB. This is okay for server side applications. But this can be a overhead for medium sized client side JavaFX applications that are not regularly used (and hence not cached)
9. No IoC container supports "sequence" - JavaFX's very own version of collection.(understandably so)

FxContainer Features

1. It is 75K in size.
2. No more awkward setters (awkard in the context of JavaFX that is). Uses Init Injection - the style that is natural to JavaFX language.
3. Uses xml for DI configuration. In fact the xml is very much like Spring. You will feel very much at home if you know Spring
4. Supports sequence, list, set, map
5. Mix and match Java and JavaFX objects during wiring as needed.?

Useful Links:

1. Project Website: https://fxobjects.dev.java.net
2. Download: https://fxobjects.dev.java.net/files/documents/11182/152368/fxcontainer-1.0.zip
3. Get Started in 10 minutes: http://www.slideshare.net/skshenoy/javafx-dependency-injection-with-fxcontainer

Do people actually use JavaFX??

Do people actually use JavaFX??

As long as JavaFX keeps popping up security dialogs, it is, and will remain a dead technology.  Flash and Silverlight don't have that problem.  I don't know how in the world the Sun engineers could have screwed this up so badly.

Do people actually use JavaFX??

TimePass,

That is a very good question. The honest answer is Yes. People (and Companies) are indeed using JavaFX to build serious applications, but not a whole lot as Oracle expected.

Whatever the non-technical issues are (licesning, mindshare, resistance etc.),

On the technical side one could see that there is very small ecosystem around JavaFX. That is a chicken and egg situation . If there are no good frameworks in the ecosystem, developers will not come and the frameworks will not be built if developers dont come.

So, we are trying to build a ecosystem with frameworks for making development easier with JavaFX for serious applications.

Thanks,

Srikanth

Sorry, my question is a little naughty and is a result of being a bit disappointed with my first trials to use DI containers like Weld and Guice in my own projects. But maybe this is just because I mainly write frameworks, and it seems to me that in these cases using such DI containers is difficult and to invasive. It's much easier to implement my own DI for the specials places where it makes sense.

This said (for any or no reason), I would like to know why exactly do one need DI in JavaFX? Which kind of instances are injected and what about their lifecycles?

Sorry, my question is a little naughty and is a result of being a bit disappointed with my first trials to use DI containers like Weld and Guice in my own projects. But maybe this is just because I mainly write frameworks, and it seems to me that in these cases using such DI containers is difficult and to invasive. It's much easier to implement my own DI for the specials places where it makes sense.

I write frameworks now and then and I cannot think of a scenario where I used DI while writing frameworks.  The reason is because the frameworks are focused and mean to be used by wide audience. But then I write business applications (front and back ends) and that's where I use DI. And I use DI in these scenarios because it makes writing business apps easier, simpler.

If I might add, it is the users of your framework that should be wiring your framework components into their applications !!

This said (for any or no reason), I would like to know why exactly do one need DI in JavaFX? Which kind of instances are injected and what about their lifecycles?

When everything is said and done, A UI in JavaFX is still a UI.

A UI has Views, Controllers, Presenters, Local Services, Helpers and Remote Service Stubs and more. A lot of these classes would then acutally be implementing some interfaces.

Views, Controllers, Presenters and Remote Stubs would most certainly be extending soe framework classes (You write frameworks so you would know your users how they extend it)

These kinds of collaborating classes will number in hundreds (depending on the complexity of your app).  All of these need to collaborate and hence wired up ideally at the interface level. (and hence their implementation needs to be plugged in)

That's what a DI container does. A lot of people are somehow under the impression that Spring, Guice or any such Dependency Injection Container are needed ONLY on the server side. Boy, they are so wrong! A DI container on the server side starts yielding results after a certain threshold of complexity is reached. This is true for client side as well.

When developing JNLP apps deployed on Intranet, I have had great success by using Spring on the client side as well. These were apps meant for regular users (and hence the app was cached on their machine).

The improvements in JRE, allow delivery of full feldged JavaFX apps over the internet to casual users. Startup times are crucial here. So there was a dire need of DI container with smaller footprint and that worked well with JavaFX. Hence FxContainer  

 Srikanth, your answer fits exactly to my actual problem, because I'm developing a flexible MVC framework. Don't want to bloat this answer about its details, but I agree totally that I can't use DI while writing it. But now to my users, implementing lots of models, views and controllers: This is exactly the place where I wanted DI-Containers do their magic - but I found that it brings more pain than pleasure. First the composition perspective: You wouldn't use DI for composing internal model or view structures - ok! Next: Injecting service objects like remote stubs, event-managers, framework-services: Would make sense, but lacks of appropriate life-cycle management. No scope was able to say "start to live with controller execution and stay alive until the user closes the view". And: I had problems that the DI container can actually "see" the controllers and models that needed injection - this meant they have to me managed by the DI container, too - resulting in total loss of control on behalf of my own framework. Don't want to go deeper, but I think you got the point where I was stuck. This lead me to the idea to discard Weld and Guice and to offer some kind of DI support in my own framework: It already knows and sees all those views, controller and models, so why not look a bit inside them and recognize some annotations. No need for new (foreign managed) contexts or scope. Seems much more promising for me - even if it's not compliant to some certain JSRs.

It's a great effort!

We re developing a javafx enterprise application client and server, we have just created and defined a set of patterns inside our javafx framework and we re developing many application on top of it. When we ll reschedule a  framework enhancements  we ll include FxContainer and the others  FxObject patterns and instruments.

Dependency Injection is good if we use it with the proposed FxObject mvc model, but now, in this phase of the project  we cannot do it. We ll do it in the next new UI components. At that time when we started project didn't exist many useful frameworks and methodical patterns to write javafx programs.

I hope that fxObject project will continue its development also in multimedia area involving javafx team to start audio/video device capture features and improve streaming video capabilities and performance.  This is a big problem in javafx.

Thanks for your effort again!

Raffaele