Hello Fineract Community, Thank you for all your feedback. I think this is the natural and expected next LTS step because Fineract already requires Java ≥ 21 (the previous LTS). JDK 25 is the current Long-Term Support release (GA September 16, 2025). Staying on 21 while the rest of the Java ecosystem moves forward creates growing technical debt. The previous successful upgrade from 17 to 21 (was led by Adam and me) followed the same pattern and delivered clear benefits without major disruption. *Repeating that proven process for 21 to 25 is consistent project practice*.
I think there is real and measurable technical benefits for Fineract itself, I have to highlight this a is a Non Functional Requirement (NFR), I will list some of them: 1. Performance & resource efficiency: Compact Object Headers (JEP 519) reduce object header size, often delivering 10-20% lower memory usage which is highly relevant for multi-tenant and containerized banking workloads. Ahead-of-Time method profiling and improved class loading further reduce startup and warm-up times. 2. Concurrency improvements: Virtual-thread pinning issues (a known limitation in Java 21) were fixed in the intervening releases and are production-ready in 25. This strengthens Fineract’s ability to handle high concurrency safely. 3. Security & maintenance: Newer JDKs receive the latest security fixes, cryptographic improvements, and platform updates. Remaining on an older LTS longer than necessary increases exposure over time. 4. Developer velocity: Contributors and CI already benefit from modern tooling, language improvements and library support that increasingly target newer JDKs. Delaying keeps the project on a slower-moving baseline. These gains are largely “free” once the runtime is upgraded, no large rewrite of Fineract application code is required as observed in the PR. Because of the points exposed by James and Paul I consider that the practical impact on users is modest and already mitigated by the release process, Adam’s key point is correct because most production deployments of Fineract today use containers. Changing the base image from a Java 21 to a Java 25 image is typically a one-line change. Users who need more time can simply stay on the current stable release (1.15.0 or whichever is current) until the next one. The quarterly release cadence already provides a natural multi-month window. Merging the completed PR to develop now means the upgrade lands cleanly in the next official release. That is exactly the controlled, notice-providing mechanism James is asking for without creating a new process. Requiring a multi-month formal heads-up + long-lived feature branch for a runtime upgrade that has already been prepared and tested goes beyond normal practice for a project of this size and maturity. Because of previous experience in other projects, long-lived branches and extra processes add more risk than they remove. It will add an overhead to maintain it and testing if not long-lived branches diverge, create merge conflicts and slow down the contributors doing the work. An FSIP is not required or customary for a JDK LTS upgrade when the change is largely infrastructure-level, the work is already done, and the normal release process already provides notice. Previous JDK upgrades did not use one. The financial-sector caution James and Paul raise is valid in principle, but it is already addressed by: (a) the existing quarterly release train (b) the ability of institutions to pin to a known-good release (c) the low-friction nature of container base-image updates. Timing is right because the JDK 25 has been GA for nearly a year and has received multiple update releases (currently 25.0.4 as of July 2026). It is mature. Waiting significantly longer simply delays benefits that the project and its users can start receiving sooner. So then the proposal is to: 1. Merge the existing PR to develop as soon as CI is green https://github.com/apache/fineract/pull/6222 2. Let it bake on develop branch. 3. Ship it in the next regular quarterly release (October 2026?/November 2026?). 4. Communicate clearly in the release notes and on the mailing list and other channels something like *“This release requires Java 25. Users who need more time can remain on the previous stable release.”* Also I think it is important to know how the community is using the Apache Fineract for better release planning but that is another thread. Best regards Victor Romero El vie, 7 ago 2026 a las 4:47, Paul (<[email protected]>) escribió: > Agree with James > These types of upgrades may impact related integrations. Even modest size > institutions need impact planning and prep time. > > -- > Paul > > On Thu, Aug 6, 2026, 7:47 PM Adam Monsen <[email protected]> wrote: > >> I'm fine waiting until the next release to officially move to Java 25. If >> the existing PR is merged to develop asap, that's exactly what will happen. >> And folks running Fineract can always decide to wait for the next release >> if they choose, providing them an even longer migration window. >> >> But I'm not convinced they'll need one. Containers are the most popular >> deployment/dependency bundling/resource segregation mechanism today, and >> changing from a Java 21 base image to a Java 25 base image is a one-line >> patch. >> >> Long-lived branches are a bad idea. The work is pretty much done and I'm >> strongly in favor of proceeding asap. This helps development speed and >> likely runtime speed+safety as well. >> >> There's no FSIP. I don't believe we need one for this. >> >
