RFC: Remove support for Java 8 in V2

[scottgerring]

Removing support of Java 8 in V2

Date: November 20, 2023 Status: Draft

Abstract

In this RFC I propose the deprecation of Java 8 support in Powertools for Lambda (Java) starting from version 2 ( #1522 ). Maintaining support for Java 8 has imposed significant resource requirements on the team and limited our ability to focus on new features. While this deprecation is not expected to happen immediately, I am seeking feedback from the community to ensure this is the right path forward with the library.

Background

With the release of Java 21 and the ongoing advancements in the Java ecosystem, supporting Java 8 has become increasingly burdensome.

• Complex Weaving Setup: Differences in aspect-oriented library support between Java 8 and subsequent versions have become a recurring complication. Powertools must continue to support both the old AspectJ codehaus plugin from 2021 and current AspectJ and prevents us from using newer features in the library.
• Friction Adding new Tooling Examples: Adding Gradle and Kotlin examples needed to take into account the same issues with the AspectJ libraries, increasing frustration of new contributors. For now, we build Kotlin and Gradle against Java 8 only because it was too difficult to get them to work generically across this and the other runtimes.
• Complex Third Party Library Support: Mockito has dropped support for Java 8 and we have to support both old and new versions increasing the complexity of the build environment and limiting our ability to use newer library features; this will only affect more of our dependencies going forward. Many other popular third party Java libraries have dropped support for Java 8 - Spring Boot 3 (Java 17), Mockito (Java 11). Additionally Kafka 4.0, Flink 2.0, Hadoop, and Spark 4.0 have all dropped Java 8 support.

This has lead to concrete issues for our users:

• Increased Friction Getting Started - The weaving configuration complexity impacts the clarity of the examples and the documentation which must special-case Java 8. It also means that Powertools must continue to support both the old AspectJ codehaus plugin from 2021 and current AspectJ. This leads to user confusion and bugs (e.g. #1401, #1342, #1156 ) .
• Incomplete Tooling Examples - In order to use Gradle or Kotlin examples with a newer version of the JDK some customization is needed on top of the included code. We have decided everything must support our lowest common runtime, which in this case complicates the newer runtimes, and again, adds friction for new users of the library.
• Decreased Feature Velocity - Time spent maintaining backwards compatibility detracts from time spent working on new features, such as achieving parity with the Python version of Powertools and improving performance. For example, we have been accumulating work for the v2 release - a focus of the project - since February 2022 - and have not yet got to RC status.

Java 8 was officially released on March 18, 2014, and will be deprecated by the end of 2030. Java8 on AL1 Lambda Runtime will be deprecated end of 2023. Java has continued to evolve since with each new version bringing performance improvements, language enhancements, and better tooling. Developers can benefit from these advancements by moving to a more recent version of Java.

While some organizations may still rely on this older version, it is important for Powertools for Lambda (Java) to align with the evolving Java landscape to maintain efficiency and support for new features.

Proposal

Deprecation Timeline

I propose that Powertools for AWS Lambda (Java) v2 will drop support for Java 8. We expect to release v2 in Q1 2024. With v2 launched, we will deprecate v1 and support critical security updates & bug fixes for 6 months. We will target new features and enhancements to existing utilities to v2 only.

Continued Support for Java 8 in Powertools for Lambda (Java) Version 1

To ensure a smooth transition for our users, we commit to continuing support for Java 8 in Powertools for Lambda (Java) version 1 for one year after the release of version 2. During this period, we will provide bug fixes and critical security updates, but no new features or enhancements specific to Java 8 will be introduced.

Implementation Plan

To execute this proposal effectively, we will follow these steps:

1. Develop and release Powertools for Lambda (Java) version 2, which includes the necessary deprecation notices and update guide.
2. Provide critical security updates for Java 8 support for a minimum period of 6 months after the release of version 2.
3. Communicate the timeline and implications of the deprecation through official channels, including documentation, release notes, and community forums.
4. Gather feedback from users and address any concerns or issues raised during the deprecation process.
5. Continuously monitor the adoption of newer Java versions among our user base.

Open Questions

1. Are there any specific concerns or considerations from the community regarding the deprecation of Java 8 support?
2. Are there critical use cases or reasons for maintaining Java 8 support that we may have overlooked?
3. How can we assist users in migrating their existing projects from Java 8 to a more recent Java version?

Conclusion

The deprecation of Java 8 support in Powertools for Lambda (Java) is a strategic decision aimed at improving resource allocation, staying current with Java advancements, and enhancing the overall quality of the library. We believe that this change will benefit our users in the long run, but we are committed to listening to the community's feedback and addressing any concerns throughout the deprecation process.

[roamingthings]

Thank you for opening this conversation and the detailed analysis. I think setting a new baseline for the next major version of Powertools is a good decision. Version 2 will probably be around for a long time and will profit from a current base version. Many other important frameworks are following the same route. I wonder though, what would be the next minimal Java version for Powertools. Would that be 11?

[jeromevdl]

Thanks for your feedback and support @roamingthings. Yes we would keep 11 as the minimal.

Java 8 on AL1 will be deprecated end of 2023, which hopefully will convince some users to leave Java 8. But Java 8 itself will remain for some time (December 2030). We don't know if there will be a Java 8 on AL3 when AL2 will be deprecated.

But with Java 21 today, plus Java 25 in two years, it becomes very complicated to support a version that was released almost 10 years ago.

We'll work on having a V2 stable enough to live for a few years, just like v1 did (we started in 2016). But we also would like to avoid parking breaking changes for years too. Look at the metrics for example, we still use the v1 of the EMF library. We're not yet thinking about v3 obviously but maybe we'll introduce a cadence in major releases (one every x years). Anyway that's not the topic, let's talk about the end of Java 8:

image generated by bing generator with prompt: "winding walking path that disappear in the horizon" and modified by myself

[AdamBien]

I would remove support for Java 8 AND Java 11 -- or at least mark the support for Java 11 as deprecated. Migrations from Java 11 to Java 17 are easier, usually there is nothing to do. Java 21 is the new LTS and therefore in my (client) projects I'm already considering Java 17 as "deprecated".

V2 could drop the support for Java 8 and Java 11. Thanks for the detailed writeup!

[jeromevdl]

Thanks for the feedback @AdamBien.

Based on the metrics we have today, it's very hard to say that we remove support for Java 11. Java 11 represents an important part of the Java runtime usage in Lambda as of today. Even if it's easier to migrate to 17, we cannot really say to the majority that we stop supporting the version they use. But thanks for the support on Java 8.

[iamkhattar]

This RFC is detailed and gives a lot of insight into the roadmap which is great! A Java 17 baseline would have been ideal but I can see why you are going with 11. Looking forward to the v2 release :D

[jeromevdl]

Thanks for your participation everyone. We're end of Feb and it looks like the majority is agree to move away from Java 8 in v2. We even have people suggesting to move directly to Java 17, but the step is probably too big yet. Together with @scottgerring, and with all your support, we now act that v2 won't support Java 8 anymore and minimum version will be Java 11 !

[jeromevdl]

v2 is not built on java 8 anymore with #1606.

Next step is to go through the code and improve where possible by using Java 9-10-11 features:

(source: https://advancedweb.hu/a-categorized-list-of-all-java-and-jvm-features-since-jdk-8-to-21/)