On Sat, 2026-03-21 at 12:29 -0700, Ryan Schmitt wrote: > > 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. >
Ryan, I have no intention of antagonizing Amazon given it is one of the project's most visible consumers. At the same time, we are being perceived as a legacy project more and more. I personally hardly see any reason for choosing Apache HttpClient over Java HttpClient these days unless one is still stuck with Java 8. I am perfectly fine waiting a few years more years but there may be point when we all collectively have to decide if we are all better off having another hobby project. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
