Refactor move jetty into separate module, add JDK http service implementation module

[rbygrave]

JDK comes with a basic http service. Adds a separate jex implementation based on that with some current limitations (no multipart file upload support, no session support, currently no cookie support although we should be able to add that).

[tipsy]

Interesting stuff. Is the long term goal to get rid of jetty completely, or to offer multiple jex flavors for different needs?

[rbygrave]

multiple jex flavors for different needs?

The Jex JDK server is approx 80K + JDK http server + the only other dependency being logging (logback or log4j etc) so it is very lightweight. The use cases where we will look to use this is for services that are largely doing messaging (ActiveMQ / Kafka etc). For these services we are effectively only using the http endpoints for kubernetes liveness, readiness probes + metrics reporting.

The Jex JDK server does not support file uploads, websockets, sse and sessions but that is ok for these services.

The other potential use case I have in mind would be small graal native-image rest servers.

[rbygrave]

get rid of jetty completely

I did some quick performance tests of Jetty, Undertow and Netty. Undertow was just a touch faster than Jetty with Netty (using Helidon SE) the slowest for my test. All pretty similar really. The summary is that Jetty is still imo a really really good choice when we want a serious http server - especially with the way Loom is going to work. With Undertow, Netty we need a separate second thread pool beyond their worker pools which is ok but Jetty is just going to be easy with Loom.

[tipsy]

The Jex JDK server is approx 80K + JDK http server + the only other dependency being logging (logback or log4j etc) so it is very lightweight. The use cases where we will look to use this is for services that are largely doing messaging (ActiveMQ / Kafka etc). For these services we are effectively only using the http endpoints for kubernetes liveness, readiness probes + metrics reporting.

Makes sense!

I did some quick performance tests of Jetty, Undertow and Netty. Undertow was just a touch faster than Jetty with Netty (using Helidon SE) the slowest for my test. All pretty similar really. The summary is that Jetty is still imo a really really good choice when we want a serious http server - especially with the way Loom is going to work. With Undertow, Netty we need a separate second thread pool beyond their worker pools which is ok but Jetty is just going to be easy with Loom.

Glad to see you arrive at this conclusion too. As much as I dislike Jetty's API, I think it's a solid general purpose webserver, and I'm pretty much married to it at this point :)