[spuz]

I wonder if someone can recommend a lightweight http server library? I like Javalin but it's based on Jetty which is a fully JavaEE compliant framework and includes support for things like OSGI which I don't need. With the whole Log4j situation, I'm re-evaluating some the libraries I've previously relied on.

[AmpsterMan]

If you have Java 11+ I presume you can't get any simpler than a standard library module:

https://docs.oracle.com/en/java/javase/17/docs/api/jdk.https...

[nayuki]

This comes from way before SE 11. I was using it in 7. The doc says it comes from 6. https://docs.oracle.com/javase/7/docs/jre/api/net/httpserver...

[AmpsterMan]

Oh neat. I erroneously thought it might have come in part with the http module in 11.

[vips7L]

That server is no where near production ready.

[14u2c]

Vert.x

It's built on top of Netty but has some additional niceties that make it more practical to use. It's also one of the fastest things out there: https://www.techempower.com/benchmarks/#section=data-r18&hw=...

[mooreds]

We looked around since we wanted to move off Tomcat and decided on Netty: https://netty.io/

I'm not on the engineering team so can't speak to the cost/benefit, but it seems to have been a pretty successful transition.

[winrid]

EDIT - it seems maybe I was wrong here

Netty copies the response body when sending to each client, so it's not as lightweight as I've found. For streaming large response bodies, it does not work well. I haven't found a good Java alternative yet (probably will switch to C++ and uWS...)

[WatchDog]

Netty core is about as close to the metal as networking gets on the JVM. It's abstractions are built over a zero-copy capable byte buffer, and there is generally a lot of care taken to avoid copying where possible. I haven't used the websocket codec, but I'm sure the maintainers would welcome a patch that removes unnecessary copying.

[winrid]

Here's what I was thinking of, under "Vert.x Memory Usage": https://www.tikalk.com/posts/2018/04/30/vertx-memory-usage-w...

Quote: "But how does Netty do things so fast ? One of the reasons is that it is using native memory pool to store network buffers. If you did some file reading or network action with Vert.x you probably used io.vertx.core.buffer.Buffer class. This class is actually a wrapper around Netty io.netty.buffer.ByteBuf class. Why am I telling you all this ? Let assume that you have a service where clients are downloading 20Mbyte files. Netty will have to allocate at least 20Mbyte for every connected client."

Although this may be an issue with how Vert.x is using Netty. I have to dig into it more.

[WatchDog]

FWIW, here is a fairly minimal example[0] of broadcasting over websockets reusing the same buffer.

I'm not very familiar with vert.x(not a netty expert either), but I think the author of that article is ascribing blame to the wrong place.

[0]: https://github.com/juggernaut/netty-websocket-broadcast-exam...

[winrid]

Not using websockets, but thanks! I have to look into it again. Right now the service is working fine so I haven't been motivated to work on it again. (in-memory CDN based on vertx-web + Caffeine + custom on-disk LRU cache)

[mycall]

> zero-copy capable byte buffer

This is similar to .NET Standard 2.1 Span<T>?

[bullen]

https://github.com/tinspin/rupy

[inyorgroove]

Very Sinatra like: https://sparkjava.com/

[xmodem]

also not actively maintained sadly.

[vbezhenar]

https://github.com/NanoHttpd/nanohttpd

A bit outdated and not actively maintained, but it's truly small.

If you like async stuff, take a loot at Helidon.

[pabl0rg]

If you’re on Kotlin, consider http4k

It can use netty, undertow, and others under the hood

[dopidopHN]

OkHTTP or netty.

[grishka]

Okhttp is a client, but a good one.

[dopidopHN]

My bad, absolutely, not sure where my head was.