I've been working on this since 2017, the last release has been much slower than usual due to changing circumstances in my personal life, so very happy to finally get it out!
If I would be using something like `ctx.result(inputStream)` - would it block the [lightweight] thread until all data is written. Or would the handler return and the data transfer happen in the background?
There is no difference between OS threads and virtual threads in this scenario, and everything in Javalin is blocking (by default).
The `ctx.result()` method doesn't actually write anything directly, it sets a result that will be written later. If you add an "After" handler, this also happens before the request is written. When the request is finally written, it's written on the same thread, and it is a blocking operation.
There is a `RequestLogger` you can hook into that fires after the response has been written.
Thanks! We had some interest in running Javalin on GraalVM in the past, but no one has updated the tutorial in many years. It used to work though, so I bet it still would, if you really wanted it to.
are you using an already-existing HTTP engine, like Jetty or Tomcat?
Yes, Javalin is built on top of Jetty.
- how do virtual threads fit into a web framework?
Most JVM web frameworks (Jetty included) have a thread based request lifecyle (one thread handles one request from beginning to end). The java.lang.Threads are extremely expensive (~1mb memory), while Virtual Threads are very cheap (~0mb memory). We also have another ThreadPool for JSON streaming, and one for writing async responses. Using Virtual Threads for these things reduces overall memory pressure.
- do virtual threads make debugging more difficult? (A more general JVM question, I suppose)
Not that I know, but I've never used this in production myself.
- any performance / readability benefit, or just a coolness factor?
The alternative here is java.lang.Threads, so primarily the memory footprint. There is no readability difference. When developing, you don't see this at all.
Thank you! The Vue support is the thing in Javalin I'm the most proud of. There are a hundred web frameworks for the JVM, but none of them have anything close to the Vue support Javalin has. Some people think it's trash, but for me it's perfect.
> Just a minor nitpick (for those who care about the details of OpenJDK's development): virtual threads are not Project Loom, but rather one of the JEPs contributed to the JDK by Project Loom.
Thanks for clearing that up. Would adding a "from" be sufficient?
and it uses Virtual Threads (“Project Loom”) by default
and it uses Virtual Threads (from “Project Loom”) by default
Rebuild and restart. Javalin itself starts in milliseconds (the test suite starts and stops servers across 600+ tests in less than 10 seconds). If you run in debug mode in IDEA, or use some hot-swapping tool like dcevm or jrebel, you won't always need to restart. I don't think there will ever be a dedicated tool provided by Javalin for this.
Yes, disagree on needing a library. The way your comment was worded made it seem to me like you were saying all serious Java applications need a DI library, I'm sorry if I misunderstood you. I prefer doing my ID manually, so no recommendation :)
I mean, it sort of doesn't? Coroutines is a whole concept, Virtual Threads can in most cases just replace java.lang.Threads, which is how it's implemented in Javalin. We just swap out the OS Threads for Virtual Threads.
I've been dogfooding it hard, which is a great incentive to keep working on it. I think we have 20 Javalin projects where I work. It's also gotten pretty popular lately (3m downloads last 12months), which of course helps a lot :)
If you run this on JDK19 with *--enable-preview*, Javalin will use Virtual Threads for the Server ThreadPool (as well as all other ThreadPools it has).
I respect Vert.x a lot, so I'm flattered, but Vert.x is a huge beast with focus on performance. Javalin is basically a tiny UX layer on top of Jetty. I don't think they are very similar frameworks. Javalin's focus is on being "good enough" all around, but with the best possible developer experience.
> Closures defined only by the arrow are a Java thing... or so I thought. :D
In fairness, I think you did copy the Java version. There's a little switch in the code boxes where you can toggle the language, if you switch to Kotlin you get the version with trailing closures :)
Edit: I'm an idiot, I see the snippet you mean now. It's been updated now, give it a minute.
I'm not super sure what you're asking, but Javalin doesn't care at all about your directory structure. You can add it as a dependency to any existing gradle project you have, and import it like any other Java library (like java.lang.String).