[brokenwren]

I'm not clear why there is a distinction here. Any HTTP server can easily use a non-blocking Selector to handle the I/O operations and then perform the application logic on Threads or Fibers. My point is that Loom fundamentally is a threading model that works well for blocking I/O.

What is unclear is whether or not Loom will increase performance of the server I/O (not the application logic code) that is already working well with non-blocking Selectors. I doubt it. But if someone has a Loom implementation of a plain HTTP server (nothing complex or JEE), I'd be up for some benchmarking exercises.

Overall though, I don't think Loom negates the usefulness of java-http. We built a super simple API, with no dependencies, that works with Java 17 and above, supports TLS natively, and is insanely fast.

Am I missing something?