Switching from Java 8 to Java 17 as the minimum required for the core platform and modules!

Development
, ,
1

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. :slightly_smiling_face:

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.

What do you think about all this?

9 Likes
2

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?

3

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.

4

Thanks. In such a case Java 17 makes the most sense to me as well.

1 Like
5

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.

2 Likes
6

@wikumc TRUNK-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.

3 Likes
7

Hi everyone,

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.

Looking forward to hearing more thoughts on this!

1 Like
8

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).

2 Likes
9

For some one who has to upgrade from Java 8, do you mind explaining how Java 17 would be more lenient than Java 21? :smiley:

1 Like
10

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.

11

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. :wink:

4 Likes
12

I think to some degree it’s a question of staying ahead of our dependencies for as long as possible.

For example, I recently was looking at what our options might be for upgrading the Event module to use a later version of ActiveMQ, and found that only deprecated versions still support Java 8, the latest in the 5.x line requires Java 11+, and the latest in the 6.x line requires Java 17+.

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.

3 Likes
13

I’m in favor of upgrading, and I do think it’s worth debating Java 17 vs Java 21, specifically for the reasons @mseaton and @dkayiwa mention.

Take care, Mark

4 Likes
14

@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? :slight_smile:

2 Likes
15

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.

1 Like
16
17

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.

7 Likes
18

@ibacher @wikumc @mseaton @burke @dkayiwa I see work is already started on this migration… sorry I haven’t been following closer, but where are discussions about this strategy happening, is it on the platform call? Sorry for joining recently but I can do more frequently because I want to weigh in on the implementation.

19

The discussions happen both on talk and the platform calls. Whatever we decide from the platform call, we also share it on talk, just in case others want to weigh in.

1 Like
20

Thank you for sharing the proposal. I believe upgrading to Java 17 is a great approach. In fact after upgrading from Java 8 to Java 17 in my own work, I have seen clear benefits. One major advantage is the ability to create custom modules with Java 17 features. This will empower contributors and implementers to build and test modules more efficiently using modern language features and tooling compatibility.