Personally, I would strongly prefer that we modernize without giving up what makes HttpComponents its own project. A new major version should be an opportunity to clean up and simplify, not to dissolve the project’s technical identity.
Arturo On Fri, Mar 27, 2026 at 6:02 PM Oleg Kalnichevski <[email protected]> wrote: > On Thu, 2026-03-26 at 14:06 -0700, Ryan Schmitt wrote: > > > > > > I want to see three things > > > > > > * custom functional interfaces replaced with standard ones > > > * custom concurrency primitives replaced / complemented with > > > standard > > > ones > > > * virtual threads > > > > > > The first two are not possible without a major release, so we might > > > as > > > well upgrade all the way to Java 21, Java 25 or even Java 29 the > > > same > > > time. > > > > > > We're already compatible with Java 21 virtual threads (this is one of > > the > > reasons the AWS SDK added an HttpClient 5 integration), so I'd want > > to know > > how specifically we would want to use virtual threads, and why it > > couldn't > > be done with reflection similar to the JEP 380 Unix domain socket > > support. > > I do not want to resort to reflection unless I absolutely have to. > > > > Typically, new Java features are deliberately designed for forwards- > > and > > backwards-compatibility with older libraries, which is why we see > > things > > like erasure-based generics, `@FunctionalInterface`, virtual threads > > as > > `java.lang.Thread`s, etc. > > > > I think the biggest open question at the moment is: do virtual > > threads make > > the async client obsolete? > > There is absolutely no guarantee there is a way to build a reasonable > HTTP/2 transport using classic i/o given its nature and inherent > limitations. If one ends up having to have a dedicated thread per H2 > stream it is not going to work and scale well no matter how cheap > virtual threads are. > > > > Some of my own suggestions for future development: > > > > * Improved support for custom transports (consider the existing > > third-party > > support for UDS, Windows named pipes, and the other stuff we found in > > `docker-java`) > > * Add optional Netty integration for advanced, proprietary, or > > platform-specific transports: QUIC, io_uring, kqueue, IOCP etc > > * Drop the usage of the legacy Socket API in favor of SocketChannel > > * Drop Conscrypt support > > * Integrate the reactive module into core and use the standard > > library > > interfaces instead of `org.reactivestreams` > > * Improve baseline memory efficiency (pooling, off-heap allocation, > > value > > types, etc) > > * Reduce the coupling between core and client, or consolidate the two > > projects (we may reconsider whether we want to continue supporting > > server-side use cases) > > I understand that Amazon has no interest in our server-side components. > That is fine. This proposal however directly conflicts with the > project's charter however outdated it is these days. You will have to > start off by drafting a new charter, getting it voted upon and > approved. One should also consider dropping `HttpComponents` name as no > longer reflective of the project scope and purpose and re-branding it > back as `HttpClient` as it originally was prior to the year 2005. > > In this case one should also _seriously_ consider dropping the entire > core module except for protocol code and porting it to Netty. > Rationally that would be the best decision to ensure there is a future > for the project long-term. At the same you would likely need to attract > new people to the project as some of the old project members may not be > willing to stick around. > > Oleg > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
