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]
