[spullara]

All blocking IO when run in fibers will be potentially non-blocking. That is literally the point of Loom. Also, non-blocking IO is almost never faster than blocking IO but you can handle way more connections with it. You use NIO for scale not for latency. Due to fairness concerns you will also want to hand off heavy computation to native threads vs fibers. Fibers are for IO.

[brokenwren]

I don't think this is accurate. The Loom documentation says specifically that it is a concurrency model to replace native threads with fibers. It says very little about non-blocking IO, except that it is a use-case that it assists with:

https://openjdk.org/jeps/425

The NIO section covers a bit about how the fibers release the channels, but the OS will not know that. Non-blocking IO is about interrupts at the hardware level that let the application code know when bytes are ready to be read or written. Fibers help by fanning out the work, but they don't replace this concept.

[throwawayisize]

FTA, it's pretty clear.

  Typically, a virtual thread will unmount when it blocks on I/O or some other blocking operation in the JDK, 
  such as BlockingQueue.take(). When the blocking operation is ready to complete (e.g., bytes have been 
  received on a socket), it submits the virtual thread back to the scheduler, which will mount the virtual 
  thread on a carrier to resume execution.

  The mounting and unmounting of virtual threads happens frequently and transparently, and without blocking any 
  OS threads. For example, the server application shown earlier included the following line of code, which 
  contains calls to blocking operations: response.send(future1.get() + future2.get());

  These operations will cause the virtual thread to mount and unmount multiple times, typically once for each call to get() and possibly 
  multiple times in the course of performing I/O in send(...).

> Non-blocking IO is about interrupts at the hardware level

This isn't relevant. We only care from the perspective of userspace.

[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?