Consider dropping Java 8 and 11 as Micronaut 4 baseline

[sdelamo]

Advantages

Use Latest Java Features

17 baseline for the framework allows us to take advantage of Java feature such as Java Records, Sealed Classes, Switch Expressions, Text Blocks, and Pattern matching for instanceof.

Use Java 17 features and code style in every guide

Currently, we have to write guides for Java 8 style.

Reduce CI Build times

Reduce our CI build matrix, decreasing build times and enhancing developer productivity.

Reducing the number of major versions supported

We may want to maintain each major version branch when we drop a Java version. Dropping both 8 and 11 may mean maintaing only two major branches until 2023 (next LTS).

In 2022 - Micronaut 3 with base Java 8 to 17. Micronaut 4 base 17. In 2023 - Micronaut 3 base 8 to 17. Micronaut 5 base 17 to 21.

If we drop JDK 8 in 4 and JDK 11 in 5, it may mean maintaining three branches.

In 2022 - Micronaut 3 with base Java 8 to 17. Micronaut 4 base 17. In 2023 - Micronaut 3 base 8 to 17. Micronaut 4 base 11 to 17. Micronaut 5 base 17 to 21. I don't think we can tell users in Micronaut 4 to "go back to 3 if you want to keep using 11 and be patched". That is the reason I list three branches in this scenario.

I have concerns about our capacity to maintain multiple major branches in core and modules.

Disadvantages

Dropping a JDK will keep some users running old versions of Micronaut

Any time we raise the baseline, it means some users will not be able to update to the latest version of the framework because they cannot update Java baseline for various reasons.  

Some modules will have a minimum of Java 17

Supporting Micronaut Spring with Spring Boot 3 and Spring 6 requires a JDK 17 minimum. This is a situation which we have today. Some modules (for example, GCP) require a minimum of Java 11.

Cloud vendors not ready

Today, March 8th, major cloud vendors still don't support Java 17.

• Azure functions support 8 and 11
• Lambda Java runtime supports 8 and 11
• Java SE and Tomcat platforms for AWS Elastic Beanstalk support 8 and 11
• Google Cloud Function execution environment supports 11

Timeline Bet?

By the time we release Micronaut 4 in late Q3 2022 or Q4 2022, the cloud vendors may be ready for Java 17. Java 17 would have been out for one year.

Moreover, Spring going 17 pushes the Java ecosystem to be ready for 17.

Misc

Next LTS is 21 which targets September 2023.

[melix]

For the record, maintaining 2 branches of Micronaut (3 and 4) probably also means 2 branches of the build tools.

[sdelamo]

About reducing CI Build times:

https://github.com/micronaut-projects/micronaut-guides/runs/5583412872?check_suite_focus=true

Java 17 1h 39m Java 11 2h 22m

[sdelamo]

Twitter Poll results:

https://mobile.twitter.com/micronautfw/status/1522313794432733187

6.9% | Stay on version 8 31.7% | Move to version 11 61.4% | Move to version 17

[sdelamo]

Today 18th July, most cloud vendors still don't support JDK 17. Only Google Cloud Functions now supports and recommends JDK 17.

• [x] Azure functions support 8 and 11
• [ ] Lambda Java runtime supports 8 and 11
• [x] Java SE and Tomcat platforms for AWS Elastic Beanstalk support 8 and 11
• [x] Google Cloud Function execution environment supports 17

[avarun42]

Elastic Beanstalk now has support for 17

[hantsy]

Java 17 will be accepted widely by Java communities, esp, Spring 6 is switched to Java 17, and Jakarta EE 10 also be compatible with Java 17.

[Goldmensch]

Looks like azure functions now support java 17 also

[sdelamo]

Micronaut Framework 4.0 baseline will be Java 17.