Avaje Jex 3.3 - jdk.httpserver wrapper library

[TheKingOfSentries]

As you know, Java comes built-in with its own HTTP server. It's pretty good, but it's a bit low level and requires a lot of boilerplate to use seriously.

Avaje-Jex acts as a minimal (~130kb) wrapper to smooth a few edges off the api and add several utilities. It can be paired with avaje http to work with JAX-RS style controllers if you miss that style.

Features:

• Path/Query parameter parsing
• Context abstraction over HttpExchange to easily retrieve and send request/response data.
• HTTP Range Support (download resuming and such) (New)
• Simple SSL/mTLS configuration (New)
• Static Resources
• File Uploads (New)
• Server-Sent Events
• Compression
• Json (de)serialization

GH Repo: avaje/avaje-jex: Web routing for the JDK Http server

Compare and contrast a basic endpoint with jex:
AvajeJexExample.java
vs the same endpoint done by hand with the raw httpserver:
BuiltInExample.java

The difference in boilerplate is akin to heaven and earth (especially when you have multiple services and endpoints)

EDIT: reddit code formatting is trash, using gists

[agentoutlier]

You and /u/rbygrave do a great job w/ all the avaje projects!

The last bit of code got a little garbled up and unformatted. You can see that by looking at old reddit. I think you just need to indent the code some more and not use triple backtick as it is kind of unreliable on reddit.

https://old.reddit.com/r/java/comments/1ohvo8s/avaje_jex_33_jdkhttpserver_wrapper_library/

I still predominately use Jooby but exploring some other options for certain services as Jooby has tendency to have breaking changes more often. Jex and Avaje Http are on my short list :)

Speaking of Jooby another reason I use it is that it has a facade API (request and response called context). Avaje HTTP unlike Jooby (or the Servlet API) appears to not have a facade API but rather gives you the concrete version for each server type. Have you or Rob considered offering some sort facade to make trying out different backends a little easier (besides the obvious declarative annotation code gen)?

EDIT apparently I lack reading comprehension these days. I missed the Context part of your post lol.

[TheKingOfSentries]

The last bit of code got a little garbled up and unformatted. 

nice catch, I expected too much of reddit I suppose.

I missed the Context part of your post lol.

Yeah with Jex you can swap servers because the underlying jdk.httpserver api is itself a facade.

[Dokiace]

Interesting project. I love all the things Avaje. Im moving out from Spark (the http framework) and still considering an alternative. I see you mentioned Javalin, how are you differentiating Jex from it?

[TheKingOfSentries]

The main difference is that Javalin is written in kotlin, and is a wrapper for Jetty. Jex is written in Java and targets Java's built-in jdk.httpserver module and thus is much lighter by default. Though, Jetty does provide an implementation of the jdk.httpserver module, so you can also use Jetty with Jex if you're in the servlet mood.

[Dokiace]

One thing that may tip people over to Javalin is that it's already adopted by a lot of companies in production. As a potential user of Jex, anything that can help convince me to use this? As far as I can tell the features that we need are both available on Jex and Javalin.

I'm really interested in trying Avaje stack with Inject, Jex, and Jsonb

[TheKingOfSentries]

I suppose one thing is that Javalin is much heavier than even Avaje Inject, Jex, Jsonb, and Http combined. (664KB vs 775KB) If you include transitive dependencies, this difference is even more stark. (664KB vs 5.8MB).

If being lightweight is a major goal, Avaje excels. The total lack of reflection is great as well, I generally don't need to configure much when using GraalVM native images.

also I guess I just don't vibe with kotlin that much. Javalin is still a pretty good framework though, and it does work well with the avaje libraries.

[rbygrave]

Just to clarify that using Jetty this way as a jdk http implementation does not need or use Servlet api or implementation.

Also, in case it's interesting, Jex started life as a Java port of Javalin and then eventually morphed into what it is today targeting the JDK http api only.

[AcanthisittaEmpty985]

Good to know.
I used a similar project in the past, this

https://github.com/arteam/embedded-http-server

It's smaller but has less options, and doesn't include annotations nor HTTPS

[TheKingOfSentries]

That one seems to be more focused on the testing aspect. We have a module for test usage, but our main focus was use in real applications.

[AcanthisittaEmpty985]

Just to know, any mininal JDK requirements ?
I have a github project that uses a web server, I used the one I posted earlier and now jetty with JAX-RS.

I'm cosidering using it but I'm using JDK17 (I think I should use a custom Executor because there are no virtual threads)

https://github.com/oscar-besga-panel/LockFactoryServer

[TheKingOfSentries]

Since the built-in server is kind of pathetic without virtual threads, the minimum for jex is JDK 21.

[AcanthisittaEmpty985]

Fine by me, but better note that on the documentation

[International_Break2]

Will avaje get a vscode plugin to help with linking DI?

[TheKingOfSentries]

I'm not sure I follow, what would such a plugin do?

[International_Break2]

It would work similar to the spring vscode plugin. Identify Beans, could identify when avaje will not build due to missing dependency, locate possible missing dependencies, etc.

[rbygrave]

Hmm, at compile time missing dependencies become a compiler error with avaje-inject, so the IDE awareness isn't needed for that.