CDI vs JRebirth

A lot of blog posts are related to CDI for JavaFX applications.

But why do you need to add a complex mechanism to perform simple task, you will answer that all these magical things will simplify developer’s life.

You’re wrong, magic things that add additional stuff are not so useful when they don’t simplify the whole feature.

Why should we inject loader or other utilities classes to do a common task ? It’s better to simplify the common task itself !

For example when you want to load a fxml file to use the root node into your Scene, you can think that it could be pretty cool to inject the FXMLLoader to load the FXML stuff.

One developer will complain about this technique because he will prefer to not manage this loading phase which is only related to technical stuff. So how can we help developer to only grab what he needs from its fxml file ?

JRebirth provides a more useful way to do it by using JRebirth Resources engine.

Let’s see how to retrieve a node from an FXML file:

Step1 : Define your FXML file resource:

The best way is to group all FXML resources into a custom Interface.

Or using a custom Enumeration.

This FXML & its resource bundle will be converted to an FXMLComponent and cached into JRebirth internal engine.

Step2 : Use your FXML definition:

To add this node into a BorderPane just write this:

The get() method will retrieve the resource from internal cache;  some unused resources can be released if memory usage is constrained; if the resource hadn’t been create or had been released it will process the FXML file to generate a  FXMLComponent.

The node() of FXMLComponent class is used to retrieved the FXML root node as generated by FXMLLoader.

This FXMLComponent let access to the root fxml node and also to automatically attached FXMLController (controller()).

What else ?

Getting a FXML node so quickly without memory leak is brilliant but how about dealing with a lot of FXML files in an huge stack of different views ?

All combinations are possible by using JRebirth wCS-Mvc pattern which provides custom classes that wrap FXML files in different way.

It’s also possible to define singleton fxml defintion or multiton, for the latter each call will load another instance of the fxml root node.

you can have a look to FXML showcase application here:

Code is available here:

As you can see JRebirth’s main goal is to simplify developer life to help us to be more efficient and business-ready.

We will see later how to use Guice library to plug different components on the fly according to your guice configuration by using the customized ComponentFactory


One thought on “CDI vs JRebirth

Leave a Reply