I want to introduce the idea of programming in Flux using POJOs (plain old Java objects). In a Flux release later this year, you'll be able to instantiate Flux objects as POJOs in addition to the traditional factory approach that Flux has employed since its inception.
The historical perspective is simple. Back in 2000 when Flux 1.0 was released, J2EE was the most important enterprise Java technology, and J2EE architectures used factories extensively. That concept influenced Flux 1.0. For that reason, Flux uses the factory design pattern to instantiate objects.
Today, the POJO programming model is the modern way. After all, it's simpler. It also makes it easier to integrate with other frameworks, most notably Spring, but Spring is certainly not the only framework that Flux could plug into easier if Flux supported a POJO programming model.
So, what will the new Flux APIs look like? Picture lines of code like this:
new FlowChart();I'm working on this task now and will report back once something more substantial is in place. Comments? Questions?
new TimerTrigger();
FlowChart.add(timerTrigger);
new Configuration();
new Engine(configuration);
In working on the POJO model against the development version of Flux, I see that it's going to be highly confusing to have many different classes that have the same name, only in separate packages. For example, the existing Engine interface needs to be a class in the POJO model, but if we want to maintain the existing APIs, we will also need the old FlowChart interface. What to do?
One obvious thing to do is to move off the existing "flux" package to a new package called "oldflux". Existing code that uses the "flux" package would need to be updated to use the "oldflux" package. That would free up the "flux" package to be populated with classes instead of interfaces.
But that's confusing.
The simplest thing would really just be to change all the existing interfaces in the "flux" package to POJO classes and leave it at that. That change implies that existing Flux users would need to update their code to say "new Engine()" instead of "Factory.makeInstance().makeEngine()".
That's the direction that things are heading in now.