3. Use Java 25 IO.println() to simplify console output
4. Instead of throwing a fatal exception on interruption, return "Interrupted" immediately.
5. Use future.join() so the main method waits for the future to complete and the "Data fetched" output is printed.
This program can be run directly from source with `java Example.java`. (If you're using Java 24 or a version of Java 25 prior to EA 22, you need to use `java --enable-preview Example.java`)
Here is a modified version of the example that interrupts the thread:
void main() {
ExecutorService executor = Executors.newSingleThreadExecutor();
CompletableFuture<String> future = CompletableFuture.supplyAsync(this::asyncMethod, executor);
future.thenAccept(result -> IO.println(result));
IO.println("Prints first"); // prints before the async result
executor.shutdownNow();
future.join(); // Wait for future to complete
}
String asyncMethod() {
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
return "Interrrupted";
}
return "Data Fetched";
}
Does no.js still limit you to a single core/CPU use?
Or as a node successfully been able to start utilizing more cores underneath its JavaScript single thread model. It presents the programmer?
I just remember early node.js from like 15 years ago and the single background task limitation of JavaScript running in a web page.
Cuz you got async code is nice, but what you really wanted to be able to harness in modern CPUs is multi-core
That said, I've been looking for an article like this for a while, although I think there are other associated libraries that also had steps in here. I do think the jvm adopted a lot of those, but I'm not sure if they actually are better than the original extension libraries.
I don't get it. The first example in JS vs Java looks very similar. Now all those other code blocks, they certainly have more going on but idk how that compares to JS. And to answer the questions:
A completable future is something that in the future may complete. I think that's self explanatory. A promise seems equally vague.
Boilerplate looks the same. JS is just a function, Java they put a class around it. Java requires exception handling which is annoying but having fought errors in async JS, I'll take all I can get.
API is eh. Sure. But that's not even shown in this example so I have no idea.
So JS saves like 3 lines? Is that really so much better?
Yeah that first example is rather poor. And it uses the word boilerpate to seemingly refer to the stuff unrelated to the async code (class declaration, exception handling, main method).
I don't use Java async much, but I guess if you have a utility method named "setTimeout" than the example can simply be:
public CompletableFuture<String> fetchData() {
return setTimeout(() -> "Data Fetched", 10000);
}
public void loadData() {
fetchData().thenAccept(System.out::println);
}
> A completable future is something that in the future may complete. I think that's self explanatory.
But not the reason for the name :).
It's called "completable" because these futures have a method on them `future.complete("value")`. Before their introduction, there was a `Future` API that java had.
Also, arguably, the wrong way to do something like this.
The author uses `setTimeout` for javascript. The equivalent for Java is either the `Timer` class or a `ScheduledExecutorService`. Doing a `Thread.sleep` simply isn't how you should approach this.
With that in mind, if you want to use both these things and keep the completable future interface you'd have to do soemthing like this.
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
var future = new CompletableFuture<String>();
scheduler.schedule(()->future.complete("Data Fetched"), 10, TimeUnit.SECONDS);
future.thenAccept(result -> System.out.println(result));
System.out.println("Prints first"); // prints before the async result
scheduler.shutdown();
In Java 24, new features support educational and demonstration use. You don't need a class to wrap your main method, which also has a simpler signature. To compare JavaScript with Java examples, one should make use of these features.
While the examples may need some work, I enjoyed this post, it nicely shows the evolution of Java concurrency.
The Java 1 example uses lambdas, which were introduced in Java 8.
It’s probably intentional, because it allows showing the Java 1 Thread approach succinctly.
But as long-term Java person, I find it jarring.
I simplified the first example to:
I made the following changes:1. Move the asynchronous function called in the CompletableFuture to its own method
2. Use Java 25 "instance main method" (see JEP 25: https://openjdk.org/jeps/512)
3. Use Java 25 IO.println() to simplify console output
4. Instead of throwing a fatal exception on interruption, return "Interrupted" immediately.
5. Use future.join() so the main method waits for the future to complete and the "Data fetched" output is printed.
This program can be run directly from source with `java Example.java`. (If you're using Java 24 or a version of Java 25 prior to EA 22, you need to use `java --enable-preview Example.java`)
Here is a modified version of the example that interrupts the thread:
Does no.js still limit you to a single core/CPU use?
Or as a node successfully been able to start utilizing more cores underneath its JavaScript single thread model. It presents the programmer?
I just remember early node.js from like 15 years ago and the single background task limitation of JavaScript running in a web page.
Cuz you got async code is nice, but what you really wanted to be able to harness in modern CPUs is multi-core
That said, I've been looking for an article like this for a while, although I think there are other associated libraries that also had steps in here. I do think the jvm adopted a lot of those, but I'm not sure if they actually are better than the original extension libraries.
I don't get it. The first example in JS vs Java looks very similar. Now all those other code blocks, they certainly have more going on but idk how that compares to JS. And to answer the questions:
A completable future is something that in the future may complete. I think that's self explanatory. A promise seems equally vague.
Boilerplate looks the same. JS is just a function, Java they put a class around it. Java requires exception handling which is annoying but having fought errors in async JS, I'll take all I can get.
API is eh. Sure. But that's not even shown in this example so I have no idea.
So JS saves like 3 lines? Is that really so much better?
Yeah that first example is rather poor. And it uses the word boilerpate to seemingly refer to the stuff unrelated to the async code (class declaration, exception handling, main method).
I don't use Java async much, but I guess if you have a utility method named "setTimeout" than the example can simply be:
Which is simpler or equivalent to the JS example.> A completable future is something that in the future may complete. I think that's self explanatory.
But not the reason for the name :).
It's called "completable" because these futures have a method on them `future.complete("value")`. Before their introduction, there was a `Future` API that java had.
Java's had `var` since Java 10 but apparently the author deliberately ignored that to make the example as wordy as possible.
It's a little tiring to read a Java example with an entry-point (the public-static-void bit) and then a JavaScript example without one.
If you strip that out the original Java is:
which is only obtuse due to checked exceptions.Arguably it's still a different thing you're doing, because it's not scheduling a task on a pool, it's creating a thread which sleeps for 10 seconds.
Also, arguably, the wrong way to do something like this.
The author uses `setTimeout` for javascript. The equivalent for Java is either the `Timer` class or a `ScheduledExecutorService`. Doing a `Thread.sleep` simply isn't how you should approach this.
With that in mind, if you want to use both these things and keep the completable future interface you'd have to do soemthing like this.
`var` is very unhelpful in situations where the reader might not be entirely familiar with the context, especially when using factory methods.
I don't think the author was trying to make the example "wordy" so much as "clear".
In Java 24, new features support educational and demonstration use. You don't need a class to wrap your main method, which also has a simpler signature. To compare JavaScript with Java examples, one should make use of these features.
While the examples may need some work, I enjoyed this post, it nicely shows the evolution of Java concurrency.