Support Strategy for Java

Development
#1

Hi devs,

So far we have a section about the Java requirement at https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/#HHardwareandSoftwarerequirements.

I’ve also sent a proposal to support Java 11 at
https://forum.xwiki.org/t/support-oracle-19c-java-11/5928.

However these 2 are not general strategy and I think we need that.

Thus I propose the following strategy:

  • Always support the Java LTS (currently Java 11 and the next one will be Java 17 in 2021). Specifically this means working actively to make xwiki work on it as soon as it’s available.
  • Keep supporting the previous LTS of Java. Right now this means supporting Java 8 and Java 11. When java 17 is out, and when XWiki is confirmed to work with Java 17, then we would support Java 11 and Java 17. Java LTS cycle are every 3 years so that seems a good cadence for us to move Java versions too.

WDYT?

Thanks

1 Like
#2

Hi Vincent, Hi everyone,

This sounds good but I’m wondering upon which criteria XWiki should support two Java LTS (the current one and the previous one) rather than only one. Given the large lifespan of each Java LTS, this would mean quite long periods of time, with the possible risks to 1) hinder innovation since XWiki code would not be able to use Java features that are only available in the current LTS, 2) increase significantly the test burden.

I see that the latest ElasticSearch supports both Java 8 and Java 11, which seems to be along the same line as what you propose (they also indicate which specific implementations of the JVM are supported). But since it’s now easier to set up dedicated environments in isolated containers, I’m wondering what would be the hard reasons for users to run XWiki on top of a penultimate Java LTS rather than on the latest one. What do you think?

Cheers

#3

@slauriere it’s really too early to abandon Java 8. That would reduce a lot our use base and we don’t want that. For example, right now I’d say a large majority of businesses are still on Java 8.

EDIT: in October 2019, there were 80% on Java 8, see https://snyk.io/blog/jvm-ecosystem-report-2018/. Note that even when there’s only 20% on Java 8, I still think we should support it. TBH I’m not even sure that in 2021 we’ll be able to abandon Java 8.

EDIT2: Note that once we say we abandon Java8, it means we can start using Java 11-specific language constructs and thus it means XWiki won’t run on a Java 8 JVM anymore.

#4

The jump Java 8 Java 8+ is very special, it’s possible in the future we only need to support the LTS but not really sure about that either.

#5

I’m positive it won’t be possible. Companies lag behind by several years (at least 3-4 min). Right now it seems the safest is to propose 2 LTS.

#6

That’s interesting to know these percentages @vmassol, thanks. Aren’t they from October 2018 rather than 2019 though (but I doubt there are much more users of JDK 11 today)? What is the underlying motivation of the users in your opinion? Why would they be reluctant to jump to Java 11, possibly only for XWiki in case they don’t want to impact all other software running on the same server? Knowing what most users do is of course key for decision making, but it’s not the single criteria in my humble opinion, otherwise things would never change. XWiki is innovative and opinionated in many areas, so its users might be more than average early tech adopters already, what do you think? What about surveying XWiki users directly whether the latest LTS only would be an issue for them? Probably they will confirm your view, but it case they don’t or are open to something different with the counterpart of having more efficient and more innovative software, couldn’t it be a significant advantage?

That’d be interesting to know the view of sysadmin persons like @khoarau…

#8

Companies just take time to move. They have operations and they need to be trained/certified for the new JVM. It’s not easy. You can’t imagine how many problems there are and how long it takes. I’ve been there and I’ve seen it when I was working for largish companies. And it’s not just operations, it’s all their best practices / support / etc.

XWiki is meant to be for businesses (hence why it was called XWiki Enterprise before ;)) and one of its strong point is stability and backward compatibility. I would hate to loose users and I really don’t see the motivations of forcing language choices too early. Yeah it’s nice to use new constructs but that’s quite minimal IMO compared to preventing users from using XWiki.

Those are definitely not the only ones to survey :slight_smile: They are advanced users and mostly technical. If you want to do a survey, you should ask the companies supporting XWiki, such as XWiki SAS and ask them if their clients would be ok. But again, this is moot, we just need to look at global JVM stats. I would definitely be against loosing 10% of our users.

#9

I don’t have a background about large companies IT processes but I definitely trust you. However XWiki jolts company processes heavily, because the wiki approach is still quite disruptive per se. I may be wrong obvisouly but aren’t companies choosing XWiki open to discuss possible evolutions of their IT infrastructure if needed, or use cloud hosting, since they may know it’s actually key for their business? My question is about whether XWiki would not gain more users than it would loose by focusing even more clearly on innovation, and if the lost users would not be ready to consider setting up a server for more “power”, since knowledge is power, indeed. As for surveying users, I was referring to users at large indeed, not specifically the ones on the forum.

#10

Can you elaborate and provide examples of what dropping support for Java8 and introducing Java11 language constructs would do to our users?

#11

I have only superficial knowledge about what specific features introduced between Java 8 and Java 11 would be meaningful, but I agree that’s a key question. While browsing the latest Java release notes on Oracle.com, I noticed that the Java module system seems to have been introduced in Java 9, is that right? If that’s the case indeed, wouldn’t it be a major feature that would ease the developers work, hence enhance the quality of the product? More generally, aren’t there many solved bugs and new optimizations available in Java 11 in comparison to Java 8, allowing the code to be more concise, easier to understand, easier to optimize and the bytecode execution to monitor (I don’t know)? I was questioning the scope of testing as well: what is the impact of supporting two major Java versions when doing tests? Do all tests need to be executed on top of the two versions, or are the differences considered to be too marginal to be meaningful?

#12

You’re mixing lots of different things @slauriere :slight_smile:

  • For users: AFAIK there’s nothing or very little that would help them. Quite the opposite; it prevents them from having more options. The module system is a big mess that will take 10 years to implement properly throughout XWiki and its 3rd party dependencies. It won’t help users, quite the opposite.
  • For developers: Yes it’s interesting for them to use newest features. Makes the job nicer and ore interesting.

One thing you forget I think, is that XWiki users can already use Java 11 and thus benefit from the JVM improvements regarding optimizations and performances and solved bugs. Dropping support for Java 8 would not have impact on this.

#13

We run all our docker-based tests on all supported configurations. The cost is execution time (and possibly money since it means having enough physical agents). That’s why we try to restrict the supported configurations to what we deem is the minimal list, without endangering the usage of XWiki of course.

#14

Indeed, my reasoning here hinges first on developer experience, only indirectly on the user one, even though 1) XWiki blurs the line between usage and development, 2) the two aspects are correlated even for non-technical users: as you point out, Java 11 makes the job nicer and more interesting, I was wondering whether this aspect could not result into a nicer and more interesting product for users. As for optimization: sorry for mixing things indeed, however it’s not because users can benefit from Java 11 that they will, which means (but maybe it doesn’t happen in practice) that it opens the path for investigating issues which end up being Java 8 issues rather than “real” XWiki issues, is this irrealistic or insignificant?

#15

This is true everywhere. In an ideal world we would use all the latest technologies and frameworks (and certainly not Struts 1.x for example ;)).

But the world is not ideal so we do what we have to do to be able to progress and not break everyone.

1 Like
#16

And the java version is really at the bottom. It’s quite insignificant IMO compared to using latest frameworks.

#17

@vmassol
I can only confirm this. Also, distributions like RHEL/CentOS remain on the old java version by default AFAIR.
Then, there is the entire story about updates/new JVM provided by Oracle are no longer free for business use. I can only imagine that already or very soon, JVM are not updated at all until there is a “trusted” alternative … OpenJDK is default on RHEL/CentOS, but not Windows for example …
HTH

1 Like
#18

@XWiki Developers: could you please provide your opinion so that we can close this topic and document it (or kill it)?

So far only @tmortagne answered from the xwiki dev team and he seemed to be ok with the proposal; is that correct Thomas?

Thanks!

#19

Yes ideally, just hope Java 8 market share will have reduced a lot when next LTS is out…

#20

+1

Thanks,
Marius

#21

I have now created https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/JavaSupportStrategy/

Maybe we should say something about the JVMs we support (Oracle vs Adopt vs Amazon Corretto vs …)?

Maybe we need to check the JVMs used by https://github.com/xwiki/xwiki-jenkins-pipeline/blob/master/vars/dockerConfigurations.groovy.

I don’t have a strong idea about this right now. Ideas welcome.