You didn't want to couple your task to the Runnable interface, so instead you coupled it to an entire HTTP server? And in order to avoid the complexity of calling CompleteableFuture.runAsync, you're using an HTTP client? Could you explain in more detail how you think this is a simplification, because I don't get it?

ETA: I'm genuinely baffled by the proposed solution, and I struggled to phrase my comment in a way that didn't come off as confrontational. So please accept my apologies if it still appears overly negative; it's entirely possible I've not understood what your goals and constraints are.

Why not simply:

    var input = new HashMap<Integer, String>();
    var results = new ConcurrentHashMap<Integer, Document>();
    var futures = input.entrySet().stream().map(entry ->
        CompletableFuture.runAsync(() -> {
            var sentiment = getSentiment(entry.getValue());
            results.put(entry.getKey(), new Document(entry.getKey(), sentiment));
        })
    );
    CompletableFuture.allOf(futures.toArray(CompletableFuture[]::new)).join();

Let us know what the speedup is :)

You may want to look at project loom's virtual threads, that are designed to address almost exactly your problem:

https://openjdk.java.net/jeps/8277131 https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.... https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.... https://youtu.be/KG24inClY2M

I think I don't completely understand from the blog your aversion to using standard concurrency tools like Executors.

It's a bit unclear on why you're using JSON to pass things between main code and the task itself. I can imagine serializing/deserializing that takes quite a bit of CPU time compared to if you just passed native data structures, or at least something binary instead of a format meant for human introspection.

It might be worth looking at a generic Callable with your own generic response type, maybe something like Either where Left is an error and Right is your response type.

I'd wrap an executor into a provider. Make it accept a WorkItem and the method accepting WorkItem would construct the Callable.

I would suggest looking into an optimal way of doing this in, say, Scala and try to replicate some of those learnings in Java. Mind you - I didn't say "write it in Scala". I did say "try in a different language" and take the learnings from there. Scala Future is a good thing to look at.

ThreadPool and Queues are my personal preference here