rest VS avaje-jex

The Response class is part of the Java Jakarta RESTful Web Services library.

There are very few frameworks that I would personally recommend: the Servlet API and JAX-RS are pretty much the only ones I consider decent. I personally avoid JAX-RS because of https://github.com/jakartaee/rest/issues/468 and because you can replace most of its functionality using ~5-10 custom classes.

Have you never used the Servlet API? JPA? Those validation annotations from the javax.validation package? JAX-RS to define REST Endpoints? CDI for dependency injection?

Take a look at https://github.com/jakartaee/rest/issues/468

I created https://github.com/avaje/avaje-jex ... with the hope of helping to move Javalin more in the Java direction but yeah, Javalin isn't going in that direction. So avaje-jex now will follow it's own path (as pretty much a web routing layer that abstracts over various http servers like jetty, grizzly etc with a java and loom focus).

Well, ultimately I instead ended up creating jex - https://github.com/avaje/avaje-jex

The Jetty ones use Jex and Loom based Jetty ThreadPool implementation ... and note that this isn't how the Jetty folks themselves have been playing around with Loom (see their loom branch). However, testing this just now against the latest 19 EA in what I think is the worst case scenario for Loom has: Loom at 80 rps and Traditional at 90 rps. Worse case scenario for loom meaning there is NO WAIT AT ALL in the response and that we do not exceed the Traditional Jetty thread pool size (testing at 100 concurrent clients which is less than default 200 max Jetty thread pool). As soon as we introduce IO wait + exceed the traditional thread pool size in terms of concurrent activity is when we see loom win out.