On Wed, 2024-03-13 at 15:06 -0700, Ryan Schmitt wrote: >
> > So in conclusion, I suggest that we stay the course with JDK8. Some > things > we can work on include: > > 1. We should find backwards-compatible ways to expose new JDK > features, > such as Unix-domain sockets. Techniques we can use for this include > optional extension libraries, multi-release jar files, and optional > polyfill libraries for older JDKs (e.g. junixsocket [3] for Unix- > domain > sockets). This is similar to what we did with Conscrypt before JDK8 > MR3 > backported ALPN support to JDK8. > 2. We should ensure that HTTP/1.1 works well with JDK21 virtual > threads, > and resolve any bottlenecks we discover (e.g. thread pinning). > 3. We should experiment with virtual threads in the context of > HTTP/2, > since multiplexed protocols are a non-trivial problem with the > blocking IO > abstraction as Oleg mentioned. (I've never understood how this can be > done > without a multiplexed blocking feature in the language itself, such > as the > `select` statement in Go.) The JDK maintainers always appreciate > useful > feedback from library developers, and we may be able to help inform > future > work on virtual threads. > > [1] https://www.youtube.com/watch?v=2y5Pv4yN0b0&t=1577s > [2] https://openjdk.org/jeps/8307341 > Ryan et al I personally think there is nothing in Java 11, Java 17 and Java 21 that we truly need to keep the project active and relevant. Virtual threads in Java 21 is the only new feature I consider useful, but only if we decided to invest efforts into building an HTTP/2 protocol handler for the class transport, which is not certain. Otherwise it is not much use. If any of our long-time upstream consumers require Java 8 compatibility we should listen, because ultimately we develop the library for them. I can live with keeping Java 8 compatibility for a few more development cycles (5.5, 5.6). Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
