On today’s platform call, we discussed the following proposal that we would like to share with the whole community and ask for feedback:
Major upgrades of Hibernate, Spring, and a few other libraries, require us to stretch beyond Java 8. We first thought of requiring a minimum of Java 11, but then discovered that it would simply be much better if we went all the way to Java 17, as the minimum required Java version for openmrs core and modules.
Because Java 17 support was added in openmrs core 2.7.0, this means that for modules, the minimum required openmrs core version would be 2.7.0.
Therefore, we would start by creating a branch for each module, to support lower versions of Java and openmrs core, and then ensure that the master branch of each community supported module compiles on Java 17
A module like webservices rest, in its master branch, would drop all those sub module folders for supporting previous openmrs versions.
FWIW, one of our awesome volunteers @k4pran is ready to help us with the from Hibernate 5 to Hibernate 6 upgrade.
All this is planned to happen in the next platform version (3.0.0), which will be released before the end of this year 2025.
Thanks @dkayiwa. I’m definitely up for increasing the required Java version.
Could you please shed some light on why you think switching to Java 17 is better than Java 11?
I see that Java 11 is good enough for the latest Spring and Hibernate.
Java 17 is required for the latest Spring Boot if we want to experiment with that some day.
In terms of extended support Java 11 is Jan 2032 and Java 17 is Sep 2029, which gives us 2 years extra before we need to switch to the next supported version.
Do we know if Java 11 requires from us to branch modules as well?
All of our modules are pretty fixed to being compiled by Java 8 right now. There may be mitigations (e.g., including various Maven artifacts to “patch” the various classes removed from the JDK), but those aren’t substantially different if we target Java 11 vs Java 17.
I see that Java 11 is good enough for the latest Spring and Hibernate.
Spring 6 requires Java 17 as a minimum. Spring Boot actually inherits that minimum version from that. Granted Spring 6 also requires migrating from javax.servlet → jakarta.servlet, so it may not be an immediate target.
Wouldn’t it be better to jump straight to Java 21 instead of stopping at Java 17? Since we’re already dropping support for Java 8 and 11, upgrading directly to Java 21 could future-proof the platform and reduce the need for another upgrade in the near future.
@wikumcTRUNK-6311 seems to indicate that there’s not many changes required in core (and possibly modules) to support Java 21, which makes it quite a compelling reason to do as you suggest. It would be probably good to release 2.8.0 before 3.0.0 to have a released version of core supporting Java 21 before requiring Java 21 in 3.0.0.
The decision to upgrade to Java 17 makes sense given the dependencies on Spring 6 and Hibernate 6. However, @wikumc suggestion about moving directly to Java 21 is interesting, considering long-term support and future-proofing.
Would it be possible to evaluate the challenges of Java 21 adoption alongside the Java 17 migration plan? This could help determine if skipping directly to Java 21 is feasible without adding too much complexity.
But the code compiled for Java 17 will run just fine on Java 21, just like the code we currently compile for Java 8 runs perfectly well on Java 11 and 17. Are there compelling features between Java 17 and 21 we need to take advantage of?
We’re specifying a minimum version here and I’d prefer the minimum version to be as lenient as possible (if it weren’t for dependency updates, there wouldn’t really be a good reason for dropping Java 8 or Java 11).
I just mean that if we make Java 21 the required version, then everything will need to run on Java 21. If we make Java 17 the minimum version, then everything will still run on Java 21 (it seems), but it will also run on Java 17. Basically, I don’t see a compelling reason for requiring Java 21.
I was looking at it this way. If for users, upgrading from Java 8 to 17 is the same as upgrading from Java 8 to 21, where is it a matter of which file to download and run. Then if tomorrow, an upgrade of Spring or Hibernate, etc requires a minimum of Java 21, we are already set.
Similarly, I was looking at upgrading an embedded Debezium library in a module, in order to support MySQL 8.4+, and found that the only version of Debezium that supports MySQL 8.4 are in the 3.x line, which requires Java 17+ for connectors and 21+ for Debezium server.
Since OpenMRS is likely to be at the top of the food chain (nothing depends on it, but it depends on other libraries), and because forcing the entire module and implementation ecosystem to adopt a new, higher Java version is painful, there is a case to be made for bumping it as high as possible each time we do this kind of thing.
Of course, there may be compelling reasons to stick with a lower version of Java for now. Just just something we should factor in.
@ibacher did @mseaton’s post convince you – i.e., if we’re going to ask modules/implementations to adopt a new requirement, better to do it closer to once a decade instead of every few years?
My main hesitancy about JDK 21 kind of comes from the same place as not wanting to make the update cycle too hard, albeit, I guess from the opposite direction. Mostly I’m concerned about our update cycle and how that might affect the “success” of this. I.e., our “current” platform now supports JDK 17 and I don’t think many implementations have actually moved to that. So I kind of worry saying “here’s all this new stuff that requires JDK 21 and you need to be on the Core SNAPSHOT” might make it harder to get buy-in?
Still, it’s a reasonable point that we should try to reduce the need to keep updating the Java version. Personally, I’m very happy with us requiring Java 21 as a minimum.
PS If we’re going through a painful migration, we should also do the migration from javax.servlet → jakarta.servlet.
I stand by that. 2.8.0 should be compatible with Java 8 and continue using javax.servlet. But if we’re already going to migrate modules to a minimum version of Java 21, we may as well migrate to jakarta.servlet and save ourselves having to do another breaking module change down the line.
