> > 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. 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? Today, we have to implement everything twice, once in the classic client (blocking, imperative threads) and once in the async client (continuation-passing style). The whole aspiration of virtual threads is to solve this duplication (aka the function coloring problem) by treating asynchrony as an implementation detail and using blocking, imperative threads as the basic abstraction for all Java development. If we moved to Java 21/25, we would have *guaranteed* access to virtual threads, so in principle we could vend a single, unified client with both sync and async APIs backed by the classic transport. Async APIs could be implemented as a simple VT-based facade over the classic codebase, basically the reverse of the classic-to-async adapter we have today. If this is what you mean by your third bullet point, then I'm fully on board. This is a stupendous simplification that is only possible by *natively* targeting a modern version of Java. 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) * General API consolidation and simplification (e.g. full vs "minimal" client variants, the separate `fluent` module, etc)
