Update Geode from Spring 4 to Spring 5

To be Reviewed By:  2019/11/08

Authors:  John Martin, Udo Kohlmeyer

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: N/A

Problem

What is this proposal solving? Why does the problem matter? How does the problem affect the user?

...

Additionally, as Spring 5 was released in July of 2016, users that utilize server-side code are not able to write modern day applications using the new features available in Spring 5. For users starting an application, using the prescribed approach of using Spring Initializer (which generates roughly 17 million projects a year), will use Spring 5 libraries by default. This means, the prescribed recommended usage approach already conflicts with our underlying libraries.

Solution

Describe your solution and how it’s going to solve the problem. This is likely the largest section of your proposal and might even include some high-level diagrams if you are proposing code changes. While all important aspects need to be covered, also keep in mind that shorter documents are more likely to be read.

...

The final outcome is to have a Spring version agnostic system, which will allow for upgrading of the project without affecting the core.

Changes and Additions to Public Interfaces

If you are proposing to add or modify public interfaces, those changes should be outlined here in detail.

None. As this is a library update, no public interface changes are envisioned. There might be some changes to code/module structure within the project, but nothing that is user/publicly facing.

Performance Impact

Do you anticipate the proposed changes to impact performance in any way? Are there plans to measure and/or mitigate the impact?

None. Current plans to mitigate impact are to run the existing performance test suite before and after upgrade to verify “no impact”.

Backwards Compatibility and Upgrade Path

Will the regular rolling upgrade process work with these changes?

...

There are no changes that affect backwards compatibility. All changes are going to be local to the node instance only. 

Prior Art 

What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?

• The project will be using EOL libraries without support if something were to fail. 
• Without upgrading Spring libraries will severely impede the project from supporting the users wanting to use current Spring libraries and projects. 
• The deployment of Spring enabled features on the server-side will not be possible, as users will experience Spring version compatibility issues. This will deter users from using the project and seek alternative products to support their use case.
• Future work to use newer technology approaches and architectures (Reactive, k8s, etc.) could possibly be simplified using the Spring abstractions.

...

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?