You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support is extended to two prior LTS JRE's. Java 17 is no longer in that list. Java 21 brings new benefits, not least of which the use of UTF-8 as a default charset (#256).
When servers were typically bare metal and ran multiple applications, it was important to support multiple versions in order to help admins running multiple Java applications. That said, I think most of the world has moved to virtual infrastructure and OIE is very likely to be the only application/server running on the JVM.
Because of this, I think we only need to support a single LTS JVM per release. Those who are not ready for the new JVM or need a newer JVM are free to roll their own.
If there is no consensus for a single Java version, I support current minus one.
I think the main question is do we want to only support the most recent LTS or (current minus one). If it's current minus one, then users have the option to use a newer one. If it's current, then using the older one will not be possible and will force an upgrade.
In other words, should we force everyone to the most current LTS release or not?
Pros:
it makes it easier on the development side to run all of the build, tests, and releases on the same version
It allows us to use new language features sooner
Cons:
Takes away user choice to run the software on a lower version which they may already be using
When I proposed current and current minus one years ago, that allowed a user to stay on the same java version through 2 LTS cycles before being forced to upgrade. That was also when java 8 had long overstayed its welcome and seemed like it would never go away. For example, if I'm running java 21 during the 17/21 cycle, I can stay on 21 during the 21/25 cycle. Then I can skip 25 and go straight to 29 when forced to upgrade for the 25/29 cycle.
Sorry, but how is upgrading to a newer JDK this much of a burden? Other languages/environments already take this choice away from the user and in a modern world, OIE would be deployed through Docker or with the supplied JRE anyway. It's not like a new JDK comes around every other month. This is plannable effort; developers can even know the features in advance and can test their plugins on pre-release.
I want to be considerate, but I don't see how we have to be this considerate.
e.g. Python: if something I want to use requires 3.14, I simply have no choice. I set up 3.14 and use it.
Again, I want to point out the question isn't "do we support one or two versions?" The choice today would be between:
Release for java 21. Users have the choice to use 21 or 25. Our current pattern would be to bundle 25 in the release.
Release for java 25. Users have no choice (but we get to fully utilize java 25, and I guess, technically, they could run 26 or 27)
In this case, I'm going to place more weight on the opinions of integrators who work with many companies and have a wide area of exposure to how the software is run in different orgs and what their upgrade cycles look like. I know with the limited number of facilities I work with, integration engine feature upgrades usually have several years in between.
I'm advocating for essentially an embedded JVM per release, in an attempt to improve test coverage and overall quality. And that we build, test and release on this single LTS JVM version.
In this case, Java 25 for the next lease, while keeping existing Java versions for 4.6 and 4.7. When Java 17 is EOL, I'm not in favor of supporting 4.7 hotfixes.
I don't have the download stats in front of me, but I seem to recall the embedded JVM is substantially more popular than the builds without it. Again, I just don't see organizations curating a single standard enterprise JVM in the world of cloud, VMs and containers.
If we had a single user or organization that requested n-1 and wanted to help support it, I would be happy to change my mind.
Healthcare enterprises run change-controlled, validated environments. A Java baseline bump means security review, vendor certification, approved base images, and regression testing across every channel, custom code template, and third-party driver. For a hospital system, that is a project with a budget, not a quick upgrade.
• Interface engines sit in the middle of clinical workflows. The tolerance for "works on my machine" breakage is near zero.
• Plugins and database drivers that the engine loads lag behind the newest Java release.
14. Healthcare enterprises run change-controlled, validated environments. A Java baseline bump means security review, vendor certification, approved base images, and regression testing across every channel, custom code template, and third-party driver. For a hospital system, that is a project with a budget, not a quick upgrade.
• Interface engines sit in the middle of clinical workflows. The tolerance for "works on my machine" breakage is near zero.
• Plugins and database drivers that the engine loads lag behind the newest Java release.
Granted, my wider experience here is dated and is now limited to maybe a dozen hospitals.
@pacmano1, I’m not asking you to name (please don’t), but are you aware of a specific healthcare enterprise that is running OIE, or Mirth derivative and that still validates just the JVM, absent of the application?
Every healthcare enterprise I know is now attempting to validate the entire application and SBOM. They are running so many applications, platforms and frameworks, they are running security tools that attempt to evaluate every single JVM version and variation, and software component. They evaluate the entire app regardless of what JVM it runs on. They want a supported JVM that is patched, but the versions and the distribution is of no consequence. The one exception is the Oracle JVM, which I see on questionnaires, but I think is more related to licensing than security or support.
So again, if there is just one healthcare organization that runs OIE and says this is important, I’m more than happy to change my mind.
I'm fine with the Latest LTS + Latest LTS N-1. I'm not pushing for a change of what I take to be our historical policy.
If we're changing it, the overwhelming tendency I see in industry at large and in healthcare is to limit variance. Especially with medical devices, pinning releases to a specific set of dependencies is common to the point of being required. The "assemble the system yourself" model is quickly dying in favor of appliances and now containers. I do not see the benefit in supporting multiple JRE's per release - we're likely to support prior releases anyway, so prior JRE's are still supported by OIE thereby.
TL;DR: I don't think a change is needed from the 2 latest LTS versions, but if we do, put me down for "packaged latest LTS JRE only" team.
Here it seems quite balanced, however there could be up to 1000 admins who are installing OIE into their own JRE and who soon come face to face with either a Java 21 or a Java 25 wall. I wonder what kind of custom plugins and libs they may be relying on internally.
I thought the Eclipse move might come with some weight on this decision. Looking around I find that, while there are no official requirements as to LTS support strategy, there are hardly any projects which currently enforce 25. There seems to be a solid general culture of compatibility with LTS N-1.
Activity
edthri commentedon May 19, 2026
So is the policy to support the latest LTS version (currently 25) and latest minus one (currently 21)?
mgaffigan commentedon May 19, 2026
@edthri, correct. Not sure if that's written policy or just convention. See #18 (comment) for prior implementation of this policy.
pacmano1 commentedon Oct 29, 2026
"In" LTS is my vote. With the rare exception if some new thingy adds amazing value to the engine.
ssrowe commentedon Oct 29, 2026
When servers were typically bare metal and ran multiple applications, it was important to support multiple versions in order to help admins running multiple Java applications. That said, I think most of the world has moved to virtual infrastructure and OIE is very likely to be the only application/server running on the JVM.
Because of this, I think we only need to support a single LTS JVM per release. Those who are not ready for the new JVM or need a newer JVM are free to roll their own.
If there is no consensus for a single Java version, I support current minus one.
NicoPiel commentedon Oct 29, 2026
I also vote for supporting one single LTS.
tonygermano commentedon Oct 29, 2026
I think the main question is do we want to only support the most recent LTS or (current minus one). If it's current minus one, then users have the option to use a newer one. If it's current, then using the older one will not be possible and will force an upgrade.
In other words, should we force everyone to the most current LTS release or not?
Pros:
Cons:
When I proposed current and current minus one years ago, that allowed a user to stay on the same java version through 2 LTS cycles before being forced to upgrade. That was also when java 8 had long overstayed its welcome and seemed like it would never go away. For example, if I'm running java 21 during the 17/21 cycle, I can stay on 21 during the 21/25 cycle. Then I can skip 25 and go straight to 29 when forced to upgrade for the 25/29 cycle.
pacmano1 commentedon Oct 30, 2026
Supporting one version pushes the burden on enterprises to go change what may be a corporate driven decision. I'd just move carefully here.
NicoPiel commentedon Oct 30, 2026
Sorry, but how is upgrading to a newer JDK this much of a burden? Other languages/environments already take this choice away from the user and in a modern world, OIE would be deployed through Docker or with the supplied JRE anyway. It's not like a new JDK comes around every other month. This is plannable effort; developers can even know the features in advance and can test their plugins on pre-release.
I want to be considerate, but I don't see how we have to be this considerate.
e.g. Python: if something I want to use requires 3.14, I simply have no choice. I set up 3.14 and use it.
tonygermano commentedon Oct 30, 2026
Again, I want to point out the question isn't "do we support one or two versions?" The choice today would be between:
In this case, I'm going to place more weight on the opinions of integrators who work with many companies and have a wide area of exposure to how the software is run in different orgs and what their upgrade cycles look like. I know with the limited number of facilities I work with, integration engine feature upgrades usually have several years in between.
ssrowe commentedon Oct 30, 2026
I'm advocating for essentially an embedded JVM per release, in an attempt to improve test coverage and overall quality. And that we build, test and release on this single LTS JVM version.
In this case, Java 25 for the next lease, while keeping existing Java versions for 4.6 and 4.7. When Java 17 is EOL, I'm not in favor of supporting 4.7 hotfixes.
I don't have the download stats in front of me, but I seem to recall the embedded JVM is substantially more popular than the builds without it. Again, I just don't see organizations curating a single standard enterprise JVM in the world of cloud, VMs and containers.
If we had a single user or organization that requested n-1 and wanted to help support it, I would be happy to change my mind.
pacmano1 commentedon Oct 30, 2026
Healthcare enterprises run change-controlled, validated environments. A Java baseline bump means security review, vendor certification, approved base images, and regression testing across every channel, custom code template, and third-party driver. For a hospital system, that is a project with a budget, not a quick upgrade.
• Interface engines sit in the middle of clinical workflows. The tolerance for "works on my machine" breakage is near zero.
• Plugins and database drivers that the engine loads lag behind the newest Java release.
ssrowe commentedon Oct 30, 2026
Granted, my wider experience here is dated and is now limited to maybe a dozen hospitals.
@pacmano1, I’m not asking you to name (please don’t), but are you aware of a specific healthcare enterprise that is running OIE, or Mirth derivative and that still validates just the JVM, absent of the application?
Every healthcare enterprise I know is now attempting to validate the entire application and SBOM. They are running so many applications, platforms and frameworks, they are running security tools that attempt to evaluate every single JVM version and variation, and software component. They evaluate the entire app regardless of what JVM it runs on. They want a supported JVM that is patched, but the versions and the distribution is of no consequence. The one exception is the Oracle JVM, which I see on questionnaires, but I think is more related to licensing than security or support.
So again, if there is just one healthcare organization that runs OIE and says this is important, I’m more than happy to change my mind.
NicoPiel commentedon Oct 30, 2026
Here at my hospital, we always use the supplied JDK and really couldn't care less about which version it is. It needs to work, that's it.
mgaffigan commentedon Oct 30, 2026
I'm fine with the Latest LTS + Latest LTS N-1. I'm not pushing for a change of what I take to be our historical policy.
If we're changing it, the overwhelming tendency I see in industry at large and in healthcare is to limit variance. Especially with medical devices, pinning releases to a specific set of dependencies is common to the point of being required. The "assemble the system yourself" model is quickly dying in favor of appliances and now containers. I do not see the benefit in supporting multiple JRE's per release - we're likely to support prior releases anyway, so prior JRE's are still supported by OIE thereby.
TL;DR: I don't think a change is needed from the 2 latest LTS versions, but if we do, put me down for "packaged latest LTS JRE only" team.
paul-hristea commentedon Nov 5, 2026
Total downloads by version, Bundled JRE versus Non-bundled JRE:
4.5.21,956 / 2,5004.6.01,111 / 3,5924.7.0226 / 2,590Installer vs installer only (excluding .tar.gz and .zip):
4.5.21,956 / 1,3934.6.01,111 / 7474.7.0226 / 119Here it seems quite balanced, however there could be up to 1000 admins who are installing OIE into their own JRE and who soon come face to face with either a Java 21 or a Java 25 wall. I wonder what kind of custom plugins and libs they may be relying on internally.
I thought the Eclipse move might come with some weight on this decision. Looking around I find that, while there are no official requirements as to LTS support strategy, there are hardly any projects which currently enforce 25. There seems to be a solid general culture of compatibility with LTS N-1.