Am 2024-03-11 um 15:11 schrieb Oleg Kalnichevski:
HttpClient 5.4 is going to be the most feature rich minor release
probably since 4.3. There are plenty of small and not so small features
and improvements in it. Overall it is going to be a great release.
It will likely take a few more months to stablize it but somethime
around mid Summer we should be able to release the first GA. That is
the plan.
However beyond 5.4 our development plans are unclear. We can settle for
no particular plan and simply react to feature requests from our users
or we could invest some efforts and time proactively. Both approaches
are perfectly valid given the scarcity of project resources.
If we choose a more proactive stance there are several potential
features we could work on
core:
* Better / more efficient implementation of channel (socket) timeout
handling in the async i/o reactor. What we currently have is quite bad
for a large number of concurrent sessions
* CONNECT method support and connection tunneling for HTTP/2
* HTTP/2 for the classic transport (now with introduction of virtual
threads (fibers) in Java 21 we could revisit the issue of the classic
i/o model not working well for multiplexing protocols and try to solve
the problem by utilizing two fibers per HTTP/2 data stream)
* JRE level upgrade
client:
* Multipart entity support for the async transport
* Transparent content compression / decompression for the async
transport
* Query timeout / request deadline support
* JRE level upgrade
The real 1'000'000 USD question for us as a project however what the
hell we are going to do about HTTP/3?
HTTP/3 and QUIC dwarfs everytihng we have done so far in terms of
complexity. Do we have resources to pull it off? Do we attempt to build
our own QUIC layer or do we wait until QUIC is supported and provided
by JRE? Is QUIC even in scope for us?
The subject of HTTP/3 support is so big that it probably deserves a
separate discussion.
What do you, guys, think? How shall we proceed?
Although Ryan pretty much said everything and well balanced, I'd like to
add a few notes personally:
* The Java upgrade madness is only then justified if you can
substantially benefit from compile time features, except virtual threads
which require quite some programming effort. Let 5.x stay on Java 8.
* I would only stabilize the libraries until end of fall because a lot
of changes have happened and they need to soak in everyhwere. A lot of
people still use 4.x.
* We need to keep to stay realistic. Calling out for fancy features with
a little amount of volunteers is just not honest. This regards h2 on
classic, QUIC + h3. Not feasable at all at the moment if at all with
Java 8. SunJSSE does not even have TLS 1.3 PHA.
Upshot: I prefer high quality stablity and consistency over a plethora
of halfcooked features.
Michael
