Why?
So the first question comes up.Why migrate Spring applications to OfficeFloor?
Spring provides dependency injection to create a graph of objects. Spring, however, provides little management over threading and attempts to model behaviour through object composition. This is where OfficeFloor in it's Inversion of Coupling Control provides injection management of threading and functional behaviour.
Now this is not to say Spring is inferior. Spring's focus has come from and stays with mainstream Object Orientation. OfficeFloor has merely taken these Object Orientation concepts and extended them with Functional Programming composition concepts and Process/Threading concepts.
Now if you are happy with mainstream Object Orientation then by all means stick with Spring. Spring is a great Object Oriented framework that deserves its success.
However, if you want to avoid writing your own threading or would like more seamless support for functional programming, then please read on.
Let's not replace Spring
It would be unreasonable to port a Spring application in its entirety. Spring has been under active development since the turn of the millennium. Ok, at the time of writing this article that is just under two decades. For some industries that could be considered a short time. However, in the IT industry, where there are new JavaScript frameworks popping up every day, this longevity is testament to Spring's success.For me, Spring's success has been because it got something fundamentally right. Now we could argue academically about Object Oriented composition vs Functional Programming composition. We could argue about libraries vs frameworks. We could even argue about Java vs new languages like Kotlin. But what I see in these arguments is focus on finding simpler and easier ways to write software. And for me, Spring (and more specifically Spring Boot) did that by getting rid of the repetitive plumbing code. This is so we could get on with writing the important functionality of our applications.
To enable focus on removing repetitive plumbing code there are a few things required:
- Extensible framework
- Plugins written for supporting the various infrastructure / existing solutions
- Open platform for community addition / management of plugins
Plugins then extend the framework to cover including various infrastructure and existing solutions. The plugins avoid us re-inventing the wheel so our focus can be on achieving the functionality of our application.
The final aspect is supporting the IT ecosystem. There are so many competing technologies and even platforms with the various cloud providers. A single group or company attempting to support this would be overwhelmed. Therefore, Spring has developed a strong open source community to write and maintain all the plugins. Even VMWare's acquisition of Spring mentions this open source community.
Therefore, it is unreasonable to rewrite Spring into something new. There is too much of an ecosystem to replicate.
Integrating Spring
So rewriting everything Spring into OfficeFloor is not a feasible direction.Rewriting is also a violation of the first point - an extensible framework.
OfficeFloor must subsequently be extensible to plugin Spring. OfficeFloor supports extension via Object Orientation, Functional Programming and Threading. Therefore, if OfficeFloor is not extensible via Object Oriented Spring, then OfficeFloor fails at being extensible.
OfficeFloor supports plugging in Spring via a SupplierSource. This extension point of OfficeFloor allows for third party dependency injection frameworks to make their dependencies available for injection in OfficeFloor applications.
Now OfficeFloor's website provides detailed tutorials on various aspects. OfficeFloor likes to adhere to the DRY (don't repeat yourself) principle, so this article series will direct you to the relevant tutorials for detailed aspects of Spring to OfficeFloor migration. Therefore, please see the Spring tutorial for how to plugin Spring dependencies into OfficeFloor.
The result of plugging Spring into OfficeFloor is that OfficeFloor gets a library of pre-written objects. Spring focuses on wiring together a graph of objects. OfficeFloor does not interfere with this, as Spring does this exceptionally well. What OfficeFloor does is allow reference to the various objects in the Spring graph for injection into its own application. This effectively allows OfficeFloor to be extended with Spring managed objects.
