[ffsm8]

I don't think that this would be a good showcase for Virtual Threads. The "async" API for Java is CompletableFutures, right? thats been stable for something like 10 years, so no real change since Java 8.

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<String> getNews(@PathVariable("page") Integer page);
    }

    @RequiredArgsConstructor
    @Service
    class HnService {
        private final HnClient hnClient;
        List<String> getNews() {
            var requests = IntStream.rangeClosed(1, 4)
                                    .boxed().map(hnClient::getNews).toList();
            return requests.stream().map(CompletableFuture::join).toList();
        }
    }

[vips7L]

Structured concurrency is still being developed: https://openjdk.org/jeps/453

Also, I wouldnt consider that the equivalent Java code. That is all Spring and Lombok magic. Just write the code and just use java.net.HttpClient.

[ffsm8]

> and just use java.net.HttpClient.

No.

[no_wizard]

it might be obvious to others, but why the 'No'?

[vips7L]

The standard http client doesn’t have as great of UX as other community libs. Most of us (including me) don’t like to use it.

That being said, imo you can’t call something equivalent when doing a bunch of spring magic. This disregards that OPs logic isn’t equivalent at all. It waits for each future 1 by 1 instead of doing something like CompletableFuture.allOf or in JS: Promise.all.