Concurrency in Java – I came up with a design I feel comfortable with
nocodefunctions.com
nocodefunctions.com
You can implement Callable in a lambda now, so a wrapper can be conjured up easily when you need it. https://www.concretepage.com/java/jdk-8/java-8-runnable-and-... (I agree implementing Callable in the business logic was naff)
There's no reason to assign methodology or context to a software process. It's useful or it is not, for qualities of utility that are unique to use cases. With such soft terms as "adapter" and "business logic" you can rationalize anything anyway, so I'm not sure that's a compelling statement on it's face. Across various languages, this methodology has been used since the 90s. It's "an oldie but goodie".
[1]"should" is a weasel word, that typically is a stand-in for "I believe this". It's unlikely that I subscribe to your specific belief.
It doesn't seem like they we're writing an HTTP Service.
Payload serialisation and deserialization.
An http client
An http server
Not only this has nothing to do with the domain of the problem you are solving, it is very likely be less performant then direct in-memory method calls.
This makes absolutely no sense.
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.
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.
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
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 :)That's why the blog post is about using a private, local HTTP API to make a task asynchronous. I mean you're already on the same machine, there must be easier way to create a background process instead of going to your network card and back...