[The following is from #176 (closed), from which this issue is split off]
Eclipse 2021-12 natively support Java 17 (for Eclipse 2021-09 you have to install the support separately). Benefits of Java 17:
It is the new/current LTS version of Java, after Java 11 that we currently use.
There are various nice new language features, such as multi-line string blocks, enhanced switch statements, instanceof pattern matching, etc, for which I see many uses in our code base. As part of this issue I don't propose to migrate the existing code to use the new features, but only to do the version migrations.
Probably going from Java 11 to Java 17 will also give us 3 years of performance improvements.
JustJ 11 doesn't include the JDK sources, making debugging a bit more difficult in certain cases. JustJ 15 and higher include the JDK sources.
JustJ 17 should support macOS notarization. Enable that.
See https://www.eclipse.org/lists/cross-project-issues-dev/msg18680.html for JustJ announcement regarding JustJ and Eclipse Adoptium (successor of AdoptOpenJDK). We may expect service releases of Java 17 to become available via JustJ, rather than just a single 17.x.x version. Already for Java 11 now 11.0.12 is available as a JustJ pre-release.
We should see what is a good moment to go to Java 17. For the product we can just include Java 17. But there are other users (myself included in my day job) that use e.g. CIF as a set of plugins and thus build against CIF and would thus need to switch to Java 17 as well. Not all companies adopt Java versions as quickly. I propose to delay Java 17 adoption a bit.
The maximum BREE up to and including the 2022-06 release is Java 11. Starting in 2022-09, BREE up to and including Java 17 Starting in 2024-06, BREE up to and including Java 21 (assuming Java 21 remains the LTS release and it is released in Sept 2023 as currently planned) and going forward the first Eclipse SimRel release to allow an LTS will be 6-9 months later.
JustJ 11 doesn't include the JDK sources, making debugging a bit more difficult in certain cases. JustJ 15 and higher include the JDK sources.
I would already settle for getting Javadoc for the standard Java library. It's amazing how often I need to find some little detail by browsing a web-version of the JDK documentation.
I guess that is automagically included with source (X-ing fingers).
Java 17 should be fine, I already have it installed as package, just not default selected as java version.
Not that it matters much, Eclipse will likely install its own version.
No idea about maven, although not very important currently as I hardly ever build a product locally.
It indicates: "Despite being released less than a year ago, use of Java 17 (the LTS release of Java SE) has surged to 26%. Java 11 use remains steady at 57% (58% in 2021). This is a good indicator that enterprises closely follow the LTS releases."
Considering the overhead, only upgrade if there is a use for it. For instance, if we need a bug fix, some new feature, or so.
Upgrade when a Java version we use is no longer actively supported.
Only upgrade to a Java LTS release.
Don’t upgrade to newer Java versions immediately, but only after (industrial) adoption is high enough. As a general guideline, if at least 50% of developers, users and enterprises use the new LTS version, consider upgrading. Java usage is regularly surveyed, and reports can typically be found online. For instance, the 2021 Jakarta EE Developer Survey Report of the Eclipse Jakarta EE project indicates that in 2021 about 58% of the developers and 11% of the enterprises used Java 11.
Let's go point by point:
The first point regards whether there is a use for upgrading. This seems covered, as we need to upgrade at some point to be able to upgrade our dependencies, as there are already some dependencies that we use that require Java 17 for their latest versions. Examples include Eclipse 2022-09 (#399 (closed)), Tycho 3.0.0 (see #434 (closed)) and m2e(eclipse) 2.0.5 (see #428 (closed)). Therefore, we are discussing whether we want to upgrade now to Java 17. Note that we upgraded to Java 11 in April 2021, so that is a while ago, so we're not upgrading too often with too much overhead, I think.
The second point is not yet relevant, as Java 11 is supported for a while still. Oracle supports Java 11 until September 2023, and with extended support even until September 2026.
The third point is covered. We are considering upgrading to Java 17, which the current LTS release. Java 21, the next LTS release won't come out until September 2023.
The fourth point is the question that remains. Is this the right moment to upgrade? In September the Jakarta EE 2022 survey indicated an adoption rate of 26% for Java 17, a significant percentage given that Java 17 was released just a year prior. This was about two months ago, and it will be some time before we actually release. Furthermore, users can stick with older version of ESCET if they are not ready to migrate to Java 17. Also, we bundle Java, so in that sense users of the product and command line scripts can use ESCET regardless of what Java version is standard on their system. It is mostly developers that are affected.
We recently upgraded to Eclipse 2022-06 (#176 (closed)). Running this version with Java 17 should work. We don't need to upgrade to Eclipse 2022-09 (#399 (closed)) to migrate to Java 17, I think. However, I don't know if we can migrate to m2e 2.0.5 without upgrading to the latest Eclipse. If we can't use m2e 2.0.5 with Eclipse 2022-06, that would require another Eclipse upgrade as well.
Did I miss anything? What do you think? Let's discuss.
Given that I already use Java 17 I have no objections. The decisive thing is perhaps the agreement about Java version usage that we made earlier? Bending the rule a bit would be fine with me though, eventually we'll end up at Java 17 anyway.
More reasons start to appear why we want to upgrade to Java 17. It might be a good time to start working on the upgrade. We need to do it for the next Eclipse upgrade anyway.
I agree it may be good to see what the upgrade would entail. Try it out in a branch at least. Given the minimal impact for users, I'm inclined to just migrate now.