[BUILD-550] Java Technical update Created: 30/Sep/21  Updated: 19/Dec/23

Status: Selected
Project: Build
Component/s: None
Affects Version/s: None
Fix Version/s: BOM 6.3.0

Type: Epic Priority: Neutral
Reporter: Mikaël Geljić Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: java11, maven
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones BUILD-303 Build on JDK11+ Selected
Relates
relates to MAGNOLIA-8193 Repository is not cleaned up post tes... Closed
relation
is related to BUILD-698 Update Guice Closed
Template:
Epic Name: Java Technical update
Acceptance criteria:
Empty
Date of First Response:

 Description   

This epic is about dropping target compatibility towards Java 8. Target Magnolia version will require Java 11 as minimum runtime environment (knowing Java 17, the next LTS is already out anyway).

  • Bump module's target java-version to Java 11 or 17 straight
  • Ensure Core's test-jar is usable on Java 11–17 (Repo test-cases & MVHTests)

In parallel with this change, we aim to generalize a few things with how we build/release modules:

  • Permanent x.y SNAPSHOTs ( on p13n, test-framework)
  • Consider Keep a Changelog & SemVer ( on sso, test-framework, parent-poms)

Create release/6.2 branches (and respective release branches in modules)
+/- Automatic branch merges (DEV-1720)

See also BUILD-303 for prior work on going beyond Java 8.



 Comments   
Comment by Mikaël Geljić [ 20/Jan/22 ]

Considering moving straight to 17, nice catch from jfranco: Spring 6 is moving straight from Java 8 to 17.
https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6

Motivation:

  • 11 would quickly become the new 8, those things tend to stick
  • If we begin to deliver container images rather than tomcat bundles, then we can be more prescriptive: Java version is no longer managed by the DevOp person running it, in their own images or on their host environment. Opportunity.
Comment by Michael Duerig [ 24/Jun/22 ]

> Considering moving straight to 17

In the end we chose to go to Java 11 first as the the jump to 17 seemed too big. The latter entails replacing e.g. PowerMock, cglib and updating Guice as well as checking other core dependencies (Vaadin ? Jackarabbit ?).

We figured that we still want to get the benefits from Java 11 and iron out whatever issues we run into with it while working on these prerequisites for bumping to Java 17 later.

 

 

Generated at Sun Feb 11 23:42:54 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.