I haven't been following loom closely, but it appears there are still pieces being put in the Java SE for it and it hasn't been fully delivered.
For instance, in java 19, virtual threads are still in preview[0].
If you wanted to build a web server running on a LTS of Java with loom, you'd have to wait until Sep 2023[1] (though of course you could write code against versions 19+ too).
I think it'd be great to file a feature asking for loom support[2], but do you really think loom is ready to be the foundation of a prod ready web server right now?
Sorry if that sounds like FUD, but I truly don't know. the two projects[3][4] linked in the infoq article are explicitly experimental or demo apps.
That said, I did find this thread of projects that support loom now[5].
0: https://www.infoq.com/news/2022/09/java19-released/
1: https://www.oracle.com/java/technologies/java-se-support-roa...
2: https://github.com/FusionAuth/java-http/issues
3: https://github.com/rokon12/project-loom-slides-and-demo-code
That being said, yes everything is very "experimental" right now. But a start-from-scratch no-dependencies project such as yours (or anyone else's for that matter) might be the best approach versus trying to retrofit an existing server.
We decided to anchor the project to LTS Java versions only. The issue with Loom is that as a preview release, you can't use it without introducing compiled code that is hard to deploy on new LTS versions. We ran into this with Java 14 and used a bunch of the preview features in that release. When we upgraded to Java 17, it caused a number of issues and we had to rebuild almost everything.
Once the next LTS has been released and Loom is top-level, we'll definitely look at using it as long as the Java community is willing to make the jump with us.
In the meantime, I think our threading implementation works quite nicely and scales really well. Let me know what you think if you review the code.
People who want LTS inherently do not want change. I highly doubt they would consider adopting this project.
> do you really think loom is ready to be the foundation of a prod ready web server right now?
I think the same can be said about java-http. It’s not even on a 1.0 release. Why choose it over battle tested Netty or Jetty?
For java-http, once it has been tested a bit more, we'll likely release a 1.0.0 version, but it's already in production, so it works right now.
In terms of Netty or Jetty, why pull in all the dependencies and overhead if all you need is an HTTP server? java-http solves the 25 year old HTTP server problem we've had in Java.
In the past, you either had to learn Netty or use Jetty/Tomcat/JBoss/Glassfish/WebLogic/etc. In my opinion, these tools are complex, bloated, and legacy. Most other platform have a simple HTTP server (Node, Ruby, etc). Java has lacked this for a long time and we've been forced to use things like Tomcat when we didn't need JEE or WARs or the complexity.
The JDK team plans to add one in version 20 or 21, I think. But they have specifically stated it won't be production quality (ugh). Not sure why they made that decision honestly.
Need a simple HTTP server that only takes a few lines of code to start, is production quality, requires no dependencies, is crazy fast, scales well, and is only 140k? No problem. Just use java-http! :)
Oracle is doing this with Helidon Nima: https://helidon.io/nima
I do like the fact that this project attempts a no-dependency implementation. That's nice. And of course, there's always room for one more http server implementation, if it offers some alternative to existing solutions (throughput, api, processing model, etc.). But any "new" http server projects wanting to start from scratch today would be wise to base its implementation on virtual threads (in my opinion).