Earlier quoted context omitted.
It should be pointed out, that the main reason they didn't go further was because of added complexity in .NET, when async/await already exists. > Green threads introduce a completely new async programming model. The interaction between green threads and the existing async model is quite complex for .NET developers. For example, invoking async methods from green thread code requires a sync-over-async code pattern that…
This FAQ is a bit outdated in places, and is not something most users should worry about in practice. JVM Green Threads here serve predominantly back-end scenarios, where most of the items on the list are not of concern. This list also exists to address bad habits that carried over from before the tasks were introduced, many years ago. In general, the perceived want of green threads is in part caused by misunderstand…
You'd jsut have to define a ThreadPool with n Threads before, where each request would've blocked one pending thread. Now it just keeps going.
So your equivalent Java example should've been something like this, but again: the completeable futures api is pretty old at this point.
@HttpExchange(value = "https://news.ycombinator.com")
interface HnClient {
@GetExchange("news?p={page}")
CompletableFuture getNews(@PathVariable("page") Integer page);
}
@RequiredArgsConstructor
@Service
class HnService {
private final HnClient hnClient;
List getNews() {
var requests = IntStream.rangeClosed(1, 4)
.boxed().map(hnClient::getNews).toList();
return requests.stream().map(CompletableFuture::join).toList();
}
}