Hi Igniters,
I'd like to start a discussion about replacing our custom IgniteFuture
class with CompletableFuture - existed JDK class
or rework it's implementation (like some other products done) to a
composition of CompletionStage and Future interfaces.
or maybe other option if you have any ideas. Do you?
1. The first approach pros and cons are
+ Well-known JDK class
+ Already implemented
- It is a class, not an interface.
- Expose some potentially harmful methods like "complete()".
On the other side, it has copy() method to create defensive copy and
minimalCompletionStage() to restrict harmful method usage.
Thus, this look like an applicable solution, but we should be careful
exposing internal future to the outside.
2. The second approach is to implement our own interface like the next one:
interface IgniteFuture<T> extends CompletableStage<T>, Future<T> {
}
Pros and cons are
+ Our interfaces/classes contracts will expose an interface rather than
concrete implementation.
+ All methods are safe.
- Some implementation is required.
- CompletableStage has a method toCompletableFuture() and can be converted
to CompletableFuture. This should be supported.
However, we still could wrap CompletableFuture and don't bother about
creating a defensive copy.
Other project experience:
* Spotify uses CompletableFuture directly [1].
* Redis goes the second approach [2]
* Vertx explicitly extends CompletableFuture [3]. However, they have custom
future classes and a number of helpers that could be replaced with
CompletableStage. Maybe it is just a legacy.'
Any thoughts?
[1]
https://spotify.github.io/completable-futures/apidocs/com/spotify/futures/ConcurrencyReducer.html
[2]
https://lettuce.io/lettuce-4/release/api/com/lambdaworks/redis/RedisFuture.html
[3]
https://javadoc.io/static/org.jspare.vertx/vertx-jspare/1.1.0-M03/org/jspare/vertx/concurrent/VertxCompletableFuture.html
--
Best regards,
Andrey V. Mashenkov
