I noticed that ListenableFutureAdapter, introduced in Spring 4, does not handle ListenableFuture.completable(), introduced in Spring 5. I'm not sure if this is a problem or not, but I've noticed the latter has some implementations.
Comment From: jhoeller
It seems that the default method in ListenableFuture would work fine for this adapter since there is no additional state to adapt to. Am I missing something?
Comment From: codefromthecrypt
ah sorry I should have clarified my concern is if adaptee has overridden ListenableFuture.completable(), as far as I can tell, those special casing would be masked by not overriding in our adapter, right?
Comment From: jhoeller
Good point in general about honoring a custom implementation on the delegate... However, since this class is about adapting the result type from S to T, we'd need to manually adapt the result value in an overridden CompletableFuture case. Since ListenableFuture.completable() is mostly meant as a convenience method, it seems preferable to reuse the adapter's general logic and simply build a CompletableFuture<T> for the adapter itself, even in case of a custom completable() implementation on the delegate (which semantically only applies to its own S case then).
Comment From: codefromthecrypt
fair enough. I agree!