Change minimum supported Java version to Java 11

[Artur-]

Description of the bug / feature

There have been two LTS Java releases since Java 8 The ecosystem / libraries are starting to move away from Java 8. We need to move forward also so we do not end up in the situation where security fixes are done to libraries but we cannot upgrade because they no longer support Java 8.

Timeframe? Unclear

[Artur-]

Eclipse moved from Java 8 to Java 11 in Eclipse 4.17 (2020-09)

[knoxyz]

intellij require at least Java 11 to run too. https://intellij-support.jetbrains.com/hc/en-us/articles/206544879-Selecting-the-JDK-version-the-IDE-will-run-under

In generally the drop of Java 8 support shouldn't be a big problem, because it's pretty upwards compatible even until the current JDK 17 LTS. Such big breaks like from JDK 7 to 8 with the complete removement of the XML-libs are not contained. These statement are wrong (thx knoobie), the great XML-break was with 11, not already with 8.

PS: Who need free JDKs with very long support, should try out amazon corretto. LTS - End of Life: 17 (10-2029), 11 (09-2027), 8 (06-2026) https://aws.amazon.com/de/corretto/faqs/

PPS: https://javaalmanac.io/ is an usefully page to compare the APIs between two Java versions.

[knoobie]

The big change was between JDK 8 to 11. In Java 9 and 10, the module java.se.ee, which contains JAX-WS, JAXB and a few other Java EE APIs, is still included but is deprecated, and not included in the module path by default. You need to explicitly enable it if you want to use it. In Java SE 11, the module java.se.ee has been removed. To use JAX-WS and JAXB you need to add them to your project as separate libraries.

[knoxyz]

Hi knoobie,

sorry, you are right! The XML-libs was removed with Java 11 not already in 8.

PS: For my experiences the following maven dependency are necessary:

<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-rt</artifactId>
    <version>2.3.4</version>
</dependency>

<= 2.3.1 for Java 8
>= 2.3.2 and < 3.0.0 for Java 11 and "older" webserver like tomcat 9.x

>= 3.0.0 for Java 11 and a webserver which use the jakarta namespace (like. tomcat 10.x)
I don't try out 3.x.
vaadin isn't already compatible, or?

Differences between rt / jaxws-ri / jaxws-rt / jaxws-tools:

• jaxws-rt = contain all necessary runtime for the webservice
• jaxws-ri = Zip-Version from jaxws-rt. Non maven-integration
• rt = like jaxws-rt, but without servlet-service javax.servlet.ServletContainerInitializer
• jaxws-tools = like jaxws-rt, but additional wsimport and wsgen

So jaxws-rt and jaxws-tools should be the best choices.

[Artur-]

After consideration, we decided to do this for Vaadin 23

[archiecobbs]

Just trying to understand this....

I'm looking at (finally!) upgrading my Vaadin version from 7.x to the latest LTS release which is soon to be 23 LTS, but this incompatibility with Java 8 means I'm going to have to do TWO giant upgrades at the same time : Vaadin and JDK.

Can you explain the technical reasons why Java 8 cannot be supported?

To be clear, I'm not referring to the IDE or development environment used to develop Vaadin 23, I'm referring strictly to the minimum JDK target version for Vaadin 23.

What specific features of JDK 11 are required at runtime?

Thanks.

[Artur-]

The ecosystem is moving forward and we are moving with it. If our dependencies are built using Java 11, we cannot build using Java 8 anymore. We cannot stay on older versions which will become unmaintained maybe sooner, maybe later. We do not want to end up with something similar to the log4j problem that would affect us and we would be unable to upgrade to a fixed version of some dependency because it used Java 11.

[knoxyz]

@archiecobbs The migration from JDK 8 to 11 (17! is the last LTS) will be very small, because the removed xml-libs could easily added by maven (I described this upper in this thread). There are non other really technical breaks, but lot of new more comfortable functions.

Because the most popular IDE like eclipse and intelliJ required at least JDK 11 (with JDK 8 it will even doesn't start anymore), it's pretty uncritical that also Vaadin goes this step too.

Which concrete troubles do you have with JDK 11 and more current? I'm sure that we like to help you.

[archiecobbs]

Just to be clear, I'm not really trying to argue for a change in policy, I'm really just trying to understand elucidate why it's happening. I appreciate your patience in explaining it.

If our dependencies are built using Java 11, we cannot build using Java 8 anymore.

OK, so the issue is being driven by certain dependencies we want to use.

In other words Java 8 incompatibility is "viral" and Vaadin is getting "infected" by virtue of using certain dependencies which are no longer compatible with Java 8 (apologies for the medical analogy, no negativity implied).

Which dependencies are those? Again, just trying to understand the particulars here.

Which concrete troubles do you have with JDK 11 and more current? I'm sure that we like to help you.

Thanks. I haven't actually tried it yet. Actually I did try upgrading only the JDK - but that didn't work because Vaadin 7.x (and several other dependencies we use) are not compatible with JDK 11 (GWT, etc.). So then I tried upgrading Vaadin, but newer Vaadin releases are not compatible with JDK 8. So it's either all or none :)

Most of the issues we have to fix for the JDK 11 upgrade are not Vaadin related, but related to other components we are using.

I guess my simple observation is this: software projects typically use a bunch of different dependencies (Vaadin often being one). The more dependencies you use, and more those dependencies limit their compatibility with other dependencies and/or the JDK itself, the more likely it will be that the intersection of all the various dependency requirements is the empty set, and so your project will not build and/or run.

You might consider this fact in the context of certain types of customers: for any given limitation (e.g., "Only runs on JDK ≥ 11"), the larger the customer's project (using more dependencies), the more likely that the limitation will cause a problem. In other words, your largest customers (in terms of size of their overall project) are the most sensitive.

I may not be a typical Vaadin user - I prioritize stability very much over bleeding edginess. Many years ago I spent a bunch of time moving from Vaadin 6.x to Vaadin 7.x. This involved lots of debugging and fixing numerous memory leak bugs, adding support for Spring (which didn't exist yet), etc. It took a lot of work. When Vaadin started creating new releases so fast that I couldn't keep up, I stopped trying. Better to stick to what works than be continually breaking things just to have to re-break them again. Of course that can't last forever and now I'm having to deal with the consequences... that's OK but I just want to understand it better.

[Legioth]

There isn't any specific dependency at this point, but rather a concern that using an 8 years old version will lead to challenges sooner or later.

If nothing else, then there's the requirement for going even further to Java 17 for Spring Framework 6 which is scheduled for the end of 2022.

[archiecobbs]

There isn't any specific dependency at this point, but rather a concern that using an 8 years old version will lead to challenges sooner or later.

Hmm. I agree that's a totally valid concern, but saying "There isn't any specific dependency" sounds like another way of saying "We haven't actually bothered to do a cost/benefit analysis or determined what work it would take - if any! - to maintain JDK 8 compatibility."

If nothing else, then there's the requirement for going even further to Java 17 for Spring Framework 6 which is scheduled for the end of 2022.

This would affect vaadin-spring yes, but not vaadin-flow, right? So, a separate discussion. And in any case I'd make the same argument here: why not make vaadin-spring compatible with both Spring 5.x and Spring 6.x, which should be feasible because vaadin-spring only interacts with a small part of the overall Spring API surface? I predict you're going to anger a lot of vaadin-spring users if you make it incompatible with Spring 5.x.

Sometimes maintaining backward compatibility is too hard - I get that. But I also think it's really worth putting a little bit of effort into quantifying how much work it would take, because sometimes it turns out it's only takes a few minimal changes. This is particularly true with the JDK, where they try very hard to be backward compatible.

OK I'll stop ranting now.

[Legioth]

While there isn't any specific dependency today, we assume it's only a matter of time before the latest version of various dependencies will move forward from a Java version that is already 8 years old. We're already seeing this with some development-time dependencies where we typically have more leeway with using and older version that might be missing some security fixes or such.

Increasing the Java version requirement sooner rather than later is a precaution against the risk that some production-time dependency will have a serious security issue that is only patched in a version that requires Java 11. It's about probabilities rather than effort.

why not make vaadin-spring compatible with both Spring 5.x and Spring 6.x

Spring Framework 5.x is based on javax.servlet and Spring Framework 6.x will be based on jakarta.servlet. We could in theory create one Vaadin version that is compatible with both, but that would cause significant overhead for us.

Someone who wants to use the latest version of Spring can use the latest version of Vaadin. Someone who is fine with using an older version of Spring would assumingly also be relatively fine with using an older version of Vaadin, and vice versa. The same reasoning can also be applied for the relationship between Vaadin and Java - latest pairs with latest and older pairs with older.

[Legioth]

We have decided to keep maintaining Vaadin 22 for 12 months after Vaadin 23 is released, i.e. until March 2023. We're doing this so that users who are already on Vaadin 22 but not yet ready to upgrade to Java 11 will have more time to upgrade Java while still using a version that will receive security patches and other critical fixes.

[archiecobbs]

Great to hear - thanks. I'm sure there is a subset of the Vaadin user base that will be appreciative of this.