Show HN: I finished v5 of a JVM framework I've spent spent half a decade making

> but with a very persistent project manager

Your partner? :D

I have to see I’m pleased to see Java moving fast those days.

I’m still digesting 17 and 18, but that give me a reason to look at 19.

I honestly project loom was far from reaching that level of “standardness” … so I haven’t looked into it in years

What is nu-programming? And why would Java deserve a comeback?

I'd love to hear more on this as well. While I've done some minor stuff with Ktor, because JetBrains, I too would love some insight related to these as well.

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

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.

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.

1. It's built natively on Jetty - very tight integration, not just some libs running in a Jetty container.

2. Web is inherently Request/Response - all of this can be handled with dramatically less resource requirements using Virtual Threads. Web is sort of the absolutely-best-use-case for Virtual Threads where as a Game Engine would be the opposite of that (one critical rendering thread and MAYBE a few extra long-lived threads for processing physics, audio, etc.)

3. I haven't tried debugging a Loom project but it's been in incubation for just under 100 years so I have to imagine this has been figured out.

4. About twice the throughput and 1/2 the latency of full OS threads - https://github.com/ebarlas/project-loom-comparison

https://expressjs.com/en/starter/hello-world.html

Edit: looks like its alive and kicking : https://sparkjava.com/news

    wsHandler := func(w http.ResponseWriter, r \*http.Request) {
        conn, err := upgrader.Upgrade(w, r)
        if err != nil {
            w.SendStatus(http.StatusInternalServerError)
            return
        }

        ctx, ctxCancel := context.WithCancel(context.Background())
        var wg sync.WaitGroup

        wg.Add(1)
        go func() {
            defer sync.Done()

            for {
                msg, err := conn.ReadMessage()
                if err != nil {
                    return
                }
            }
        }()

        msgPipe := make(chan []byte, 1024)
        wg.Add(1)
        go func() {
            defer wg.Done()
            for {
                select {
                case <-ctx.Done():
                    return
                case msg := <- msgPipe
                    if err := conn.WriteMessage(msg); err != nil { return }
                }
            }
        }()

        go func() {
            <- ctx.Done()
            wg.Wait()
            close(msgPipe)
        }()
    }

Edit: I was looking at the wrong snippet, the offending snippet has been fixed.

Sinatra, also Ruby, predates Express and is based on Rack (in a similar way to Express, which used to be based on Connect if I’m not mistaken).

I’m not sure what inspired Sinatra, but that’s probably the influence you’re seeing in these frameworks.