Discussion: Future release based on Jetty 12 and Jakarta

[holgerfriedrich]

With the release of Karaf 4.5 expected this summer, we can finally replace the quite abandoned Jetty 9 by Jetty 12 and finally switch from Javax to Jakarta.
This is a quite disruptive change, largely affecting core developers and binding developers (official bindings and marketplace).

I wanted to get to a rough estimate of the impacts and decided to build a working prototype of OH core - and in the meantime I have got a running prototype which includes a full port of the add-ons repo as well. It can be downloaded and tested! See progress in the following PR:

• Migrate to Jakarta EE 10 / Jetty 12 / Jersey 3.x / Karaf 4.5 #5479

This issue is intended for having a discussion how to introduce this.
There are a lot of questions to discuss: version numbers, handling in the CI, how to develop bindings for an older and the current release, snapshots, Java version, etc.
@openhab/core-maintainers @openhab/add-ons-maintainers @openhab/webui-maintainers FYI and any feedback is welcome!

[holgerfriedrich]

Just my 2 cents:

• Version: I'd like to call this release 6.0 as it is disruptive.
• Java: I'd like to allow Java 25 once Karaf does, but Java 21 should probably also be supported; which one should be default is not yet clear to me.
• Branch or merge: For me it is totally open if we could just handle this like a normal PR and merge just after the 5.2 release - of if we want to develop on a separate branch for a while to get everything running and stable. Going for the separate branch would likely cause a lot of work in reconfiguring the CI appropriately. I think we need time to do some testing of the prototype to see how bindings are affected, if tests are still working, etc.

[lsiepel]

From a user's perspective, moving to version 6.0.0 creates certain expectations. Karaf 4.5 by itself does not bring noticeable user-facing improvements, and from that standpoint it may not justify a major version bump. Unless we can bundle this release with a set of highly valued user-facing enhancements, there is a risk that users will be disappointed.

Java 21 will remain fully supported for more than two years. What are the main reasons for moving to Java 25 already?

Alternative 1:
The Karaf 4.5 release also seems difficult to align with our current release cycle. What if we instead introduce an openHAB 5.5.x release? (jump from 5.2 to 5.5) It would allow for a more substantial update without requiring a Java version change, but include karaf 4.5 and could provide a good middle ground. We could target a release around Christmas this year.

Alternative 2:
It took long to get Karaf 4.5 released and it changes a lot, maybe good to let it mature for some months. Proceed with 5.3.x for christmass and move to 6.0.0 in summer 2027, including java25, karaf 4.5 and more (improved UI, energy dashboad, whatever we pick). This would also allow developers to have more time to adjust the marketplace and custom addons to adapt.

[rkoshak]

I second @lsiepel's concerns. Though given enough forewarning the rest of the developers seem to step up with meaningful user facing changes. Once breaking changes become allowed developers can be more ambitious. So I would vote for alternative 2 to give developers time to implement new user facing stuff.

[holgerfriedrich]

@lsiepel thanks for the feedback, Leo!

I am clearly against alterative 2, if we can avoid it. Jetty 9 is something we want to replace since ages.
And building the prototype was way to much effort to throw it away (or rebase for another 7 months....) 🤕

Regarding Java: 21 is perfectly fine for me, I just want to be able to able to run it on Java 25 runtime. JEP515 (Ahead-of-time complication) and JEP519 (Compact object headers) could be interesting to speed up the startup and runtime/memory use on RPI. Maybe Florian has a some comments regarding Graalvm.

I will try to support the upcoming Karaf release. For Karaf 4.4.11 this already worked well, and we have improved the workflow for Karaf project a lot in the last months (GH, dependabot, up-to-date dependencies)....

[andrewfg]

I think we will need to allow some extra SNAPSHOT time to check that addons do actually work with Jetty 12.

Speaking for myself, the Hue API v2 binding runs over HTTP/2 for both SSE and HTTP GET/PUT/POST transactions. AFAICT the Hue binding was the first (and maybe still the only one) to use HTTP/2 properly in this way. And since Jetty 9.5x was so Jurassic even at that time, I had to make kludges to force an ancient Jetty version to support a modern HTTP/2 implementation (e.g. modern certificate handling, new SSL encryption standards). So I am pretty certain that Jetty 12 will not be a drop in replacement for the Hue binding. In the best case it probably will not compile, and in the worst case it will compile, but not actually work..

[holgerfriedrich]

@andrewfg Yes, I also see an amount of work ahead of us.
You could give the hue binding a try. IIRC, all tests/itests were PASS on my system.
See openhab/openhab-addons#20800 and the latest download link for the full distro from #5479.

I will need to rebase over the weekend. We had a few conflicting changes. I think my build is roughly matching 5.2.0-M5.

[andrewfg]

You could give the hue binding a try. IIRC, all tests/itests were PASS on my system.
See openhab/openhab-addons#20800 and the latest download link for the full distro from #5479.

Hmm. I tried it just now and unfortunately I did not even make it as far as the first wizard page in OH Main UI...

[lsiepel]

And building the prototype was way to much effort to throw it away (or rebase for another 7 months....) 🤕

If this is the main argument, we are somewhat forced to move forward without having a proper discussion and adding different perspectives. Now that the PR is there, i fully understand the rebase / maintenance burden. Did you consider to have this discussion before creating that PR?

We usually bump java with a mayor openHAB release. This is what users expect. Moving to java25 by the end of this year is IMO too soon. This could mean:
openHAB 6.0.0 with karaf 4.5 at the end of 2026
openHAB 7.0.0 with java 25 at the summer 2028

Personally i would prefer alternative 2. But maybe alternative 1 is a good middle ground:
openHAB 5.5.0 with karaf 4.5 at the end of 2026 (bumped/skipped version to signal its technicall significance)
openHAB 6.0.0 with java 25 at the summer 2028 (or end of 2027)

Would be nice if other @openhab/maintainers could join the discussion and share there thoughts.

[lolodomo]

We already upgraded to Java 21 in July 2025 for 5.0. Requesting users to upgrade Java again in 2026 looks early, no ?

I also tend to prefer alternative 2.

I do not understand the proposal of naming version 5.5 in December 2026.

[andrewfg]

Hmm. I don't think it helps to be talking about the actual version numbering. Or even their dates.

The essence is that Karaf / Jetty change is likely to be a breaking change .. so we must avoid a pathway where users on release, milestone, or snapshot versions get automatically (unconsciously) bumped up to the next (trivial) minor version. We need to make it so that users must actually make a conscious decision to upgrade.

My two cents:

1. don't delay the karaf / jetty change
2. if the "don't automatically (unconsciously) bump" criterion requires a new major version number then just do it

[lolodomo]

Just to be clear, is Java 25 a prerequisite for Karaf 4.5 / Jetty 12 or 'ot ?
If not, we can move fast.
If yes, that's another story.

[holgerfriedrich]

@lolodomo

Just to be clear, is Java 25 a prerequisite for Karaf 4.5 / Jetty 12 or 'ot ?

Karaf 4.5 will require Java 21 or later. The current Karaf dev branch is still lacking some changes to add additional support for Java 25, but this is planned to be completed before release.

@lsiepel

Did you consider to have this discussion before creating that PR?

Let me give some background. I got involved into Karaf development over the last months, and it helped to identify bugs before releasing Karaf to have an OH port available. When I started working with Karaf 4.5, the idea was just to have a prototype of OH core - focusing on replacing Jetty and RS whiteboard. This comes with javax to jakarta transition and upgrades of libraries to next major versions. A prototype of core did non help much, webui was missing to actually "see" it working.

For add-ons, it is a different story - the PR was actually intended to estimate risks and efforts of the overall introduction of Jetty 12. I wanted to identify obstacles and get a rough feeling about a realistic timeline. 500 bindings to be manually adapted is quite a number (~50% compiled and verified ok without any change when I started). Note that the add-ons PR is mainly done by AI, is intended to be a prototype, and will need review! But still, it is a prototype now available for testing - unit tests and itests are fine!

---

With the prototypes available, we at least can give it a try and decide how to move forward. It still could be to setup a separate branch and CI infrastructure to work in parallel until it is ready (a lot of work, though). Karaf is not even released. My prototype patches pax web and other libraries to make it work. But hopefully we can sort this out in the next weeks and include the feedback into Karaf 4.5.

[lolodomo]

Karaf 4.5 will require Java 21 or later

So if Java 25 is not required, where is the problem, we can then plan the upgrade for 5.3 in December, more or less like any other Karaf upgrade. And we keep Java 21 as our dev version for all of our 5.x versions.
But the upgrade to Jetty 12 could take most of developers free time during the next months, to upgrade our 500 bindings. But you already started this job and you know more than any of us what are the difficulties and the potential impacts.
The risk would be to have many bindings broken in 5.3 due to lack of tests.

5.3 will then be mainly a technical upgrade, taking most of our time, but this is necessary.

Move to Java 25 will then be only in OH 6.0 in July or even December 2027. Like that we remain consistent with our strategy, that is change of Java version only in major OH version and not too much often.

[lolodomo]

Please don't forget that jupnp library has certainly to be upgraded too.