> When do you think we could finally discontinue support for those versions?
One question is what that buys us. We have a lot of API surface area, so we would struggle to adopt features like records without doing a major version bump. (For the same reason, we still mainly use our own pre-Java 8 async abstractions rather than CompletableFuture.) There are some newer language features that we could use purely internally like switch expressions, local variable type inference, and text blocks, but that's a fairly minor benefit in the grand scheme of things. I think the Java 8 Maintenance Releases have been good to us; they've backported TLSv1.3, ALPN, the socket keep-alive options, etc, and we've filled in other gaps like JEP380 using reflection or optional dependencies. Modern Java features like modules, Graal AOT compilation, and virtual threads are also pretty easy to support while still targeting Java 8. I just upgraded our build toolchain to Java 17 without issue, and even Java 26 (released just days ago) still supports cross-compiling to Java 8. This support will eventually be dropped from a future version of Java, and someday we will get to the point where no supported JDK version can emit Java 8 bytecode, but we are years away from a forced move like that. For example, Corretto 25 security support is scheduled to end on October 31, 2032: https://endoflife.date/amazon-corretto I think a big selling point of HttpComponents is that it's small and highly portable. It doesn't have a giant dependency graph, it doesn't pull in the Kotlin runtime, it doesn't need special permission to reflect into JDK internals or load native libraries, it's compatible with old Android apps and build tools, it doesn't perform bytecode manipulation, etc. The project has a long track record of forward- and backward-compatibility, so it behooves us to be conservative about the runtime requirement. We recently saw (HTTPCLIENT-2413) that someone running on IBM J9 was broken when we introduced the call to `ExtendedSocketOptions`, which was an instructive example of just how much enterprise weirdness is out there, and the people we break will often not be in a position to "just" upgrade their runtime environments since they don't actually control them. Some other Java projects are going ahead with major version bumps to drop Java 8 support: Jackson, Log4j, Spring, and JUnit come to mind. I'd like to wait and see how it goes for them before we upgrade. There's ongoing work at Amazon to raise the minimum build-time JDK version from 8 to 11, as well as to deal with major version bumps more gracefully, but at the moment I have no way of pushing out an HC upgrade that requires Java 17. Note the implications of this: we would have to continue maintaining a Java 8-compatible maintenance branch, and we would lose out on all the bug reports that I surface from internal testing and production usage. There's also the matter of open source libraries like the AWS Java SDK v2, which recently published an HttpClient 5 integration. These libraries are subject to the constraints of _both_ ecosystems (internal and open source) and will probably be among the last to drop Java 8 support. On Sat, Mar 21, 2026 at 7:39 AM Oleg Kalnichevski <[email protected]> wrote: > On Sat, 2026-03-21 at 07:34 -0700, Ryan Schmitt wrote: > > It looks like RAT won't get any more updates on Java 8. Should we > > raise our > > build-time Java requirement to 17? An increasing amount of build > > tooling is > > dropping support for Java 8, including Maven itself (Maven 4 has to > > run on > > Java 17+), and Windows for ARM doesn't even *have* Java versions > > older than > > 17. This isn't an externally visible change, as we would still build > > for > > Java 8 and test on Java 8/11 JREs; it mainly involves reworking the > > CI > > workflows and the POM files as needed. > > > > Ryan, > > There is a bigger question. > > How would you feel about dropping support for Java 8 and 11 altogether? > Is compatibility with those JREs still important for Amazon? > > When do you think we could finally discontinue support for those > versions? > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
