Remove functional mode, spring-fu/spring-init references

[sdeleuze]

We should maybe remove this hard split and make those 2 modes working together, by introducing more functional into the default mode based on reflection behavior gradually. That avoids the issues of our curent all or nothing mode and would be a path toward something unified. If we choose that path we should probably just use default for the unified mode name.

[aclement]

If you mean 'functional mode with spring-init' then I think we've already gone down this path. For a while they were radically different (reflection vs functional-spring-init) but once we found that the spring-init approach was triggering off spring.factories and was no longer requiring an explicit list of configurations to make an app work, we changed our feature functional mode to do the same thing as reflection mode - it walks spring.factories and follows configuration links. The only difference is that in functional mode it does not register configuration/condition classes for reflection, and only applies hints applicable in functional mode.

Where things are still different is 'functional fu style' and reflection/functional-spring-init - that still remains all or nothing I would say (and all or nothing meaning 'do I follow spring.factories and at imports from my spring components' or 'not') . Maybe we eliminate functional fu style mode and are just left with reflection/functional-spring-init. We should chat about this to dig into it a little more.

[sdeleuze]

I think we should also wait for oracle/graal#2500 that could change some behaviors.

[sdeleuze]

My proposal is to remove the functional mode, rename reflection todefault, integrate and improve what Spring Init brings in 0.9.1, specify hints with the right trigger in order to make sure there are not activated in Spring Fu apps while they should not, and let Spring Fu provide its own substitutions if needed.