4 ms·
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 lik
by ffsm8 2y ago
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 2y agoStructured concurrency is still being developed: https://openjdk.org/jeps/453 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 2y ago> and just use java.net.HttpClient. No.
- no_wizard 2y agoit might be obvious to others, but why the 'No'?
- vips7L 2y agoThe 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.