Why this change is required? Currently Options.java is effectively mutable and can be misused in the following way The EventLoop constructor uses the options by reference. So while an options is passed to this constructor, it could also be updated later with any of the with methods such as withHost resulting in unpredictable behavior.

How does this change solves the above problem? This change aims to make the Options immutable using a builder OptionsBuilder. All the fields of Options are marked as final and an instance is only created after invoking the build method on the builder. Post this, none of the fields in Options are mutable. This prevents the code from ending up in any of the unpredictable scenarios where an option is updated post being passed to the event loop.

A getDefaultInstance method is also added for use cases where we don't want to set any of the properties of Options and just use the default properties.

I presume that we are aware of jdk.httpserver so I am having a quick look at the features of jdk.httpserver and just opening this as a discussion point to see / confirm if there are any features in there that might be considered desirable for microhttp.

Glancing at the jdk.httpserver code and the thing that popped out was the management of idle connections. It has a background timertask to manage idle connections (plus an optional one to manage request exceeding MAX_REQ_TIME and MAX_RSP_TIME).

Are there any features in jdk.httpserver that are desired to be added to microhttp?

So instead of having this style ...

    public static void main(String[] args) throws IOException, InterruptedException {

        Options options = new Options()
                .withPort(8080)
                .withSocketTimeout(Duration.ofSeconds(60))
                .withReadBufferSize(1_024 * 64)
                .withMaxRequestSize(1_024 * 1_024);

  
        Handler handler = ...;

        EventLoop eventLoop = new EventLoop(options, new DisabledLogger(), handler);
        Thread eventLoopThread = new Thread(() -> {
            try {
                eventLoop.start();
            } catch (IOException e) {
                // thread terminates
            }
        });
        eventLoopThread.start();

       ...
        
        eventLoopThread.join();
    }

Have a MicroHttp.Builder where we with the optional config options, pass the mandatory params to a start() ... under the hood create the event loop etc.

Return a MicroHttp with a stop() method?

    public static void main(String[] args) throws IOException, InterruptedException {

        Handler handler = ...;

        var microHttp = new MicroHttp.newBuilder()
                .withPort(8080)
                .withSocketTimeout(Duration.ofSeconds(60))
                .withReadBufferSize(1_024 * 64)
                .withMaxRequestSize(1_024 * 1_024)

               .withLogger(...)

               .start(handler);  // creates event loop, starts
  

       microHttp.stop();

    }

Just using "defaults" would be like:

public static void main(String[] args) {

  Handler handler = ...;

  var microHttp = new MicroHttp
      .newBuilder()
      .start(handler);
  

    // programmatically stop ..
    microHttp.stop();

}

The thinking would be to make the "usual use" a little bit more obvious (in theory).

There are currently two releases of Microhttp on Maven Central:

https://search.maven.org/artifact/org.microhttp/microhttp

v0.1 and v0.2 appear to have no corresponding Git tags:

https://github.com/ebarlas/microhttp/tags

There are also no GitHub releases:

https://github.com/ebarlas/microhttp/releases

Here are some release examples from a personal project:

https://github.com/beatngu13/pdf-zoom-wizard/releases

PR #6 will add a basic GitHub Actions build. Based on this, another workflow could be created to automatically set the project's version, tag the commit, and create a GitHub release. It is also possible to use something like JReleaser.

What do you think? I'm happy to help if you are interested.

Change the source baseline to be Java 8.

The IntelliJ support for using different source versions in source and test is still not available in their latest 2021.3 release. However, there is an open issue IDEA-85478, which seems to have gained some traction and there is something working in the 2022.1 EAP (I tested it and it works good).

Almost all changes are due changing the convenience of the usage. However, the change in the ByteTokenizer might affect the performance, a multi release jar could be used here to in order to not lose any performance on Java 9+.

This PR addresses some (IMHO justified) IntelliJ IDEA warnings. Feel free to throw away specific commits if you don't the like the corresponding changes.

Side question: Is there a reason why you use CRLF instead of LF in Response and RequestParser?

Exception in thread "main" java.lang.UnsupportedOperationException: 'SO_REUSEPORT' not supported at java.base/sun.nio.ch.ServerSocketChannelImpl.setOption(ServerSocketChannelImpl.java:212) at org.microhttp.EventLoop.(EventLoop.java:80)

Split event loop into (1) single passive-server-socket event loop and (2) many active-socket events loops.

Each event loop is single-threaded and independent. Still no locking or synchronization.

This design is facilitated by Selector, which permits select on one thread and register on another.

I could be wrong or low on caffeine but it looks to me like there is effective buffer recycling with readBuffer but not with writeBuffer at the moment? Am I reading that incorrectly or maybe it doesn't matter?

That is, it looks like with writeBuffer there is a decent amount of copying in Response.merge() and then wrap(). I get a sense we could avoid the byte[] result = new byte[size]; and look to recycle writeBuffer instead?

https://todobackend.com/ is a an initiative to show that a bunch of REST services can pass a known frontend test suite.

That test suite is a Jasmine suite and runs in the browser. There' a series of requests performed in order. GET, POST and others. It is very cool. Can microhttp stand in the middle and delegate requests to one of the other backends, and still pass the test suite.

Or maybe a native TodoBackend using microhttp. Easiest to fork one of the existing Java ones perhaps - and there's no DB requirement - a HashMap would do.