3 ms·

Another person commented the same, but a "project loom" virtual threads based HTTP server implementation would be very desirable right now. A new NIO based serv

Another person commented the same, but a "project loom" virtual threads based HTTP server implementation would be very desirable right now. A new NIO based server probably doesn't add a whole lot of value to the ecosystem. But note, I'm not discounting the effort here. 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).

mooreds 4y ago
Thanks for the feedback. Full disclosure, I work for the company which open sourced this project. 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/ https://www.infoq.com/news/2022/09/java19-released/ 1: https://www.oracle.com/java/technologies/java-se-support-roadmap.html https://www.oracle.com/java/technologies/java-se-support-roa... 2: https://github.com/FusionAuth/java-http/issues https://github.com/FusionAuth/java-http/issues 3: https://github.com/rokon12/project-loom-slides-and-demo-code https://github.com/rokon12/project-loom-slides-and-demo-code 4: https://github.com/nipafx/loom-lab https://github.com/nipafx/loom-lab 5: https://twitter.com/nipafx/status/1567448335367151616 https://twitter.com/nipafx/status/1567448335367151616
- taftster 4y ago
  Not FUD, these are good questions. In my opinion, since you asked, writing an http server using Loom (preview mode and all) is the only reasonable way to get ahead of the market, so to speak. It's not like I am an insider or have any special access, nor do I have any personal proofs to my statements, but I do believe that Project Loom / virtual threads will hold up well in production. I think there will be lots of interesting improvements and use-cases that will be drawn out of loom, and using it now in preview mode would be a reasonable way to get ahead. 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.
  - brokenwren 4y ago
    I wrote most of the server code for the project and I actually looked extensively at Loom. 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.
- vips7L 4y ago
  > 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] 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?
  - brokenwren 4y ago
    I think that's actually what most people are waiting for with Loom. They want it to be fully baked into the JDK and ready for production first. Then they will start using it. 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! :)
vips7L 4y ago
> a "project loom" virtual threads based HTTP server implementation would be very desirable right now Oracle is doing this with Helidon Nima: https://helidon.io/nima https://helidon.io/nima

mooreds 4y ago

Thanks for the feedback. Full disclosure, I work for the company which open sourced this project. 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/ https://www.infoq.com/news/2022/09/java19-released/ 1: https://www.oracle.com/java/technologies/java-se-support-roadmap.html https://www.oracle.com/java/technologies/java-se-support-roa... 2: https://github.com/FusionAuth/java-http/issues https://github.com/FusionAuth/java-http/issues 3: https://github.com/rokon12/project-loom-slides-and-demo-code https://github.com/rokon12/project-loom-slides-and-demo-code 4: https://github.com/nipafx/loom-lab https://github.com/nipafx/loom-lab 5: https://twitter.com/nipafx/status/1567448335367151616 https://twitter.com/nipafx/status/1567448335367151616

taftster 4y ago
Not FUD, these are good questions. In my opinion, since you asked, writing an http server using Loom (preview mode and all) is the only reasonable way to get ahead of the market, so to speak. It's not like I am an insider or have any special access, nor do I have any personal proofs to my statements, but I do believe that Project Loom / virtual threads will hold up well in production. I think there will be lots of interesting improvements and use-cases that will be drawn out of loom, and using it now in preview mode would be a reasonable way to get ahead. 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.
- brokenwren 4y ago
  I wrote most of the server code for the project and I actually looked extensively at Loom. 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.
vips7L 4y ago
> 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] 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?
- brokenwren 4y ago
  I think that's actually what most people are waiting for with Loom. They want it to be fully baked into the JDK and ready for production first. Then they will start using it. 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! :)

vips7L 4y ago

> a "project loom" virtual threads based HTTP server implementation would be very desirable right now Oracle is doing this with Helidon Nima: https://helidon.io/nima https://helidon.io/nima