Java Support Strategy clarifications

Development
,
#1

Hi devs,

Our Java support policy at Java Support Strategy - XWiki is missing some details and I’d like to discuss them with you in order to provide a better strategy for us.

Concept of recommended

Right now we just say that we support LTS and LTS-1 but we don’t mention what we recommend.

I propose that we mention that we recommend the LTS version (the latest one).

--release versions

This is the new replacement of the old source/target parameters and we use it in our top level pom. It corresponds to the java source level we use in our code.

ATM we don’t say anything about it in our support strategy doc, except having a Source Level column at Java Support Strategy - XWiki that is just indicative.

Actually we do say something about it:

  • Java LTS cycle are every 3 years so that seems a good cadence for us to move Java source versions too.

So right now, I understand it as saying that whenever a new LTS is out we should increase the source level we support. For example, when Java 21 is out (Sep 2023), we were using a release value of 11 and we should increase it to 17 (the next LTS).

Also, it should be noted that Java LTS cycle is now every 2 years, which IMO is too fast for us to follow (more precisely for our users to follow). I propose we stay on a 3 years cadence on our side.

So we need to clarify this to be more explicit:

  1. Do we agree about staying on increasing our release value every 3 years to the next LTS from its indicated value (e.g. if the last update of it was on Jan 2022 to 11, then the next update will be on Jan 2025 to 17?
  2. We also need to decide when we do this and on what branch. I propose that we do it on master, when we start the development of the next XWiki version, i.e. in N.0 where N = XWiki version when we did the last update of the release value + 3. To be more precise, imagine we’re in Jan 2025 and last time the release value was changed was in Jan 2022. Master is 17.0-SNAPSHOT at that time. It would mean moving release to 17 for the release of XWiki 17.0.

Note that for 2), there’s the open question as to whether XWiki users will be able to upgrade their java versions that fast. Now, for them it means being about 4.5 years behind the latest Java LTS in practice if they are on the XWiki LTS, which I feel is acceptable. For example:

  • We’re in Jan 2025 and master is 17.0. The release value is increased to 17 (since release was set to 11 in Jan 2022).
  • Our LTS users will only use the 17.10.x LTS in Jan 2026 at earliest.
  • This means they’ll be forced to switch to Java 17 roughly 4.5 years after it was out (it was released in 2021-09-14).

Building version

Right now we don’t say anything about this in the policy. The only consequence from it is that when the release version changes we also need to update the java version used to build XWiki.

We could align the java version used to build XWiki at the same time as when we change the release version. This seems the simplest, even if it would be possible to build with a more recent java version and use an older release value than itself.

Precisely, this means that we would start building with Java 17 only in Jan 2025 (at which date we would be allowed to use java 17 constructs in our code).

WDYT? Do you see any need to start building XWiki with Java 17 earlier?

Supported versions

This is about the versions to run XWiki on.

I propose to keep what we have but make some clarifications. Right now, the page says:

  1. that we should Specifically this means working actively to make XWiki work on [the latest release Java LTS] as soon as it’s available but it doesn’t say for which branch.
  2. that as soon as XWiki is confirmed to work with the new Java LTS, then we drop support for the previous LTS (it used to say the following, which I’ve removed when updating the doc recently: When java 21 is out, and when XWiki is confirmed to work with Java 21, then we will support Java 17 and Java 21, and thus drop support for Java 11).

I propose the following:

  • We don’t change the minimum supported version for the currently supported XWiki branches.
  • We do a best effort to also support the latest Java LTS for the currently supported branches
  • We only drop the oldest supported LTS on master and in N.0 where N = current cycle + 1

As an example, right now we support Java 11 and 17 for all our supported XWiki branches. Java 21 has just been out in Sep 2023. This means that we verify if XWiki 14.10.x, and master work with it (e.g. by having an env test pipeline execute on it). If it does then we update our java support policy to indicate it. If not, we do a best effort to work to support it on these branches. However, when we will work on 16.0, we will drop support for Java 11 for 16.x. However for 15.10.x, we will still support Java 11.

In conclusion this means that we’ll need to support quite a few Java versions (probably 3).

WDYT? Do you see other topics to be discussed here (I see some but I wanted to finish this post which is already long. One topic for later is to have a checklist of actions to do when N.0 is being developed. But we probably don’t need a discussion for this)?

Thanks

#2

Thanks for opening this again!

Honestly, I would prefer that we always put in our support strategy a specific version that we recommend: we might take a bit of time to have XWiki working with the LTS (e.g. currently it doesn’t work properly with the LTS without some config). So I would be specific on the version of Java we recommend, especially since it might also not be the same version for all supported branches.
Also IMO we do not upgrade Java that often, so it’s not that much work to ensure we update the support strategy page when we upgrade it.
[After reading the end: I think what I said matches what you’re saying about the supported version, so I’m a bit confused right now… shouldn’t we just say that the recommended version is latest LTS among the supported version, and it depends on the branch?]

LGTM

In theory I’m ok with this computation. In practice, we might be a bit late if there’s issues. So we’ll probably need to plan ahead to perform the upgrade to ensure there’s no blockers.
Globally that strategy is a best effort: we don’t know yet how complicated the upgrades will be in the future.

I don’t see any reason to not stick to that plan.

LGTM

#3

There is one thing that feels like an inconsistency to me: from what I understood, you propose to drop support for Java 11 in XWiki 16 but still keep the source version to Java 11 (since the move to Java 17 would be in XWiki 17).
I really don’t see the point of having a source version different from the minimum supported version, they should always be equal for a given branch, otherwise it’s way too hard to understand.

About the 3 years to switch the source version (and minimum supported version), I honestly don’t know if it’s the best value or not. But I feel it would be much simpler to have a rule based on what is the current LTS when starting a cycle (which, in practice, means switching every 2 years). And LTS-1 (so the current rule, XWiki 16/2024 for Java 17 and XWiki 18/2026 for Java 21) does not seem that bad honestly to me (Debian dropped support for Java 11 6 months ago). We could also try LTS-2 (so XWiki 18/2025 for Java 17 and XWiki 20/2027 for Java 21) but I’m afraid it might be a bit too far behind (the current Jetty stable branch, 12, started 3 months ago, already requires Java 17).

#4

I think we agree. What’s important is to decide what’s our strategy for recommended is and my suggestion is to use the latest LTS we support (per branch since we won’t have the same level on all branches). It’s not because a new LTS of Java is out that we support it immediately (see the other points about that). We support it for a branch only when we have proven that XWiki for that branch works with it.

Definitely. For example, I’m going to add a test env to test XWiki with Java 21 right now, even though we’ll not move to release = 21 before a long time.

Thx

#5

Good point. We need to decide. Support means testing that XWiki works 17 and 21 in XWiki 16. It doesn’t mean anything about the source level, which could stay on 11 and be changed later. Now I understand your point, which is basically: why not continue testing XWiki 16.x with Java 11 (in addition to 17 and 21) since the source level is 11. I think we could do that, it’s just more work and bigger costs (since we need more agents globally since we need to test more builds on java 11). We could decide that we’ll only use Java 11 for some test env that execute once a week for example. I guess that could be enough and would mitigate the extra cost.

In this case the strategy would be to drop support for a Java version only when we change the release version.

Yes, and that’s what I wrote initially before realizing that the Java release cadence had moved from 3 years to 2 years. I really think 2 years is not doable for our users, especially our users using XWiki in a business environment.

What do others think about the cadence of upgrading our minimal java version? Do you think 3 years is good or should we move to 2 years (or even 4 years) ? Note that the more year we add; the more cost we have to run our builds on all the java versions in between and ofc the more the devs have to wait to benefit from the language new features.

Thanks

#6

Regarding the Java syntax to use, if LTS branches are in a different versions than master, this can lead to issues when cherry-picking.
So another option is to only allow the use of the syntax of the older java version we have on a supported branch.

#7

Interesting. However, that would make moving to an increased release value, a year later if I understand correctly (the time for the XWiki LTS branch to change). Thus moving from 4.5 years to 5.5. Or we change the cadence to be 2 years (as Thomas wanted) and not 3 but with this additional rule which should keep the real user cadence to 4.5 years.

WDYT?

PS: haven’t thought through all this. I’d need to create an example to make sure that what I said is correct.

#8

Note that this is already what’s happening in practice. This is a remark that has been made initially by @surli on this proposal, regarding the use of the var keyword.

#9

I’m not so sure this is the right way to look at this. Using Java LTS-1 at the beginning of a cycle means that when the cycle becomes the XWiki LTS we are 3 years behind the current Java LTS which I think is acceptable. And frankly that’s actually what you proposed too in practice since I don’t see why people would use XWiki with an unsupported version of Java, whatever we put as source version. I’m mainly proposing to align the source on the minimum supported version, which is a lot easier to understand for everyone.

#10

What’s the cost for the infra team of upgrading Java?

  • Upgrading the OS used on the server running XWiki? This shouldn’t be a problem when XWiki runs inside a (Docker) container right? But I guess most installs don’t use containers. You still need to upgrade your OS from time to time (e.g. to get security fixes), but probably most OS providers offer multi-year LTS support (I see Debian has 5 years LTS)
  • Conflicts with other Java applications that run on the same server? But the infra team can install multiple Java version no? (unless more recent Java versions are not available for the old OS you’re using)

Having to wait 4.5 years to use some “new” Java syntax feels a lot. I haven’t followed very closely what new Java versions bring in terms of syntax and APIs, I guess most of that is not really critical / blocker for us, but it’s enough to have one or two that are useful to make wait painful :slight_smile: .

Thanks,
Marius

#11

Hello.

As a man responsible for a consequent amount of XWiki instances in the XWiki SAS Cloud, I do not really mind about the version of Java we use, as soon as:

  • the version is available on popular Linux distributions by default (especially, on Debian Stable).
  • the version is maintained.

When it comes to upgrading XWiki, it doesn’t pose a problem for me or our Infrastructure team to upgrade the operating system if needed. We generally aim to utilize the latest stable versions of the OS, so the upgrade aligns with our usual practices.

#12

Hello all,

I read the whole thread but I didn’t do all the math and timelines in my head. I am trying to answer with what I’d expect to have rather than with the rule that would result in that.

the way that I am looking at this is:

  • I’m a self-hoster of XWiki
  • I am upgrading to XWiki LTSes or mid-cycle versions with bugfix releases - once or twice per year
  • how often I also need to “bump my infra” so that XWiki still runs?

I think that if I need to manipulate my infra every 2 years or every 3 years it’s acceptable (both are actually acceptable). If I cannot manipulate my infra that often, I may not want to manipulate my XWiki that often either…

Now, the next questions I need to ask myself is how special that infra would be (downwards or upwards) - if I’m not running XWiki in a container:

  • honestly, I would say that the most frequent case here is servers running Debian, so it would be ideal if we could have a smaller gap with Debian: not using a version that’s already not supported anymore by Debian for a recent version of XWiki but also not requiring a version not yet available on Debian for an XWiki LTS. I don’t know the numbers, so you’ll need to help me here.

I would say that if this is the case, we cannot to much about it, as it can be very diverse. It’s not the 2 years to 3 years difference that will be able to cover enough of the cases that can occur (what other applications?) in order for the XWiki project to be worth making an effort in this direction.

I would also prefer actual numbers for some of the support strategies. We can keep the strategy also as a “rule” about what we plan to work on in terms of support in the future, but as announcement to the users it would be great to have the actual numbers for all released versions of XWiki elsewhere than in the test results (same for the database engines and servlet containers).

Thanks,
Anca

#13

ok so it seems all people who answered think it’s ok to follow the Java LTS cadence of 2 years (and not do 3 years). Taking into account all comments, here are 2 proposals:

Proposal 1

  • We recommend to our users to run XWiki on the latest Java version we support.
  • We follow the Java LTS cadence (every 2 year), which means that at the beginning of every 2 XWiki cycles, we drop the oldest Java version that we were supporting, and at the source level we upgrade it by one version. This means for example:
    • XWiki 14.10.x (2022) supports Java 11, XWiki 15.x (2023) supports Java 11 & 17.
    • In XWiki 16.0 (2024), we drop the support of Java 11 and support Java 17 (new source level) and work as fast as possible to support Java 21 in 16.x. We support Java 11 & 17 for XWiki 15.10.x.
    • In XWiki 17.0 (2025), we continue to support Java 17 & 21. We support Java 17 & 21 for XWiki 16.10.x.
    • Java 25 is out in September 2025
    • In XWiki 18.0 (2026), we drop support for Java 17, continue to support Java 21 (new source level) and add support for Java 25 asap. We support Java 17 & 21 for XWiki 17.10.x.

Proposal 2

Variation to decide (suggested by Manuel above to avoid cherry-picking issues):

  • We recommend to our users to run XWiki on the latest Java version we support.
  • We only upgrade the source level when the LTS stops supporting the version. For example:
    • XWiki 14.10.x (2022) supports Java 11 & 17, XWiki 15.x (2023) supports Java 11 & 17.
    • In XWiki 16.0 (2024), we drop the support of Java 11 and support Java 17 and work as fast as possible to support Java 21 in 16.x. We support Java 11 & 17 for XWiki 15.10.x. Source level = 11 for 16.x.
    • In XWiki 17.0 (2025), we continue to support Java 17 & 21. We support Java 17 & 21 for XWiki 16.10.x. Source level = 17 for 17.x AND 16.10.x.
    • Java 25 is out in September 2025
    • In XWiki 18.0 (2026), we drop support for Java 17, continue to support Java 21 and add support for Java 25 asap. We support Java 17 & 21 for XWiki 17.10.x. Source level = 17 for 18.x
    • Source level = 21 for 19.x AND 18.10.x.

Pros of proposal 1:

  • Faster to be able to use the new construct of the Java language

Pros of proposal 2:

  • Less potential problems with merges on the LTS branch

What do you prefer?

On my side, I have a preference for proposal 1, even if it could be harder for merges (but the build will quickly find the problems when that happens). Basically I’d prefer favoring the use of new constructs sooner. Also, it’s not great to change the source level in a LTS.

Thanks

#14

+1 for proposal 1, it’s just a lot simpler to understand for everyone, and I really don’t like changing the source level in a LTS x.10.y…

-0 for proposal 2

Now, for me, the rule discussed here mainly make sense for the minimum supported version and the source version.

I think we need a different logic for the maximum supported version (one not based on the change of cycle in XWiki). For example, I’m not sure it makes much sense to never support Java 21 in 15.10.x. After all, we felt the need to support Java 17 in 14.10.x (contrary to what you indicated in the proposal).

#15

-0 for proposal 2 as it does not feels right to change the source level of a LTS
+1 for proposal 1, with a best practice to avoid using “new” code constructors on code that has a risk if being cherry-picked to LTS (what we already do for APIs for instance anyway).

#16

yes, I agree that we should not have any constraint for the max supported version. It’s a best effort to support the max # of java versions. This is non-controversial and I’ll add it to our java support page after we agree.

PS: I’m not sure where I indicated something different.

#17

Your proposal suggests that XWiki 14.10.x only support Java 11 and that XWiki 15.10.x only support Java 11 and 17.

#18

Ok so the proposal is not clear.

BTW this line was not a proposal, it’s the current situation :slight_smile: See Java Support Strategy - XWiki

But to extrapolate, when I say for example:

In XWiki 16.0 (2024), we drop the support of Java 11 and support Java 17 and work as fast as possible to support Java 21 in 16.x.

This doesn’t mean that XWiki 16.x will not support Java 25. It means that we must support Java 17 & 21 in it. The rest is a best effort.

I’ll make sure this is clear when I update the doc after the proposal is agreed.

#19

+1 for option 1.

Thanks,
Marius

#20

+1 for option 1