Support basic Java Executor interface

Currently you can provide either ExecutorService, ScheduledExecutorService or implement custom Failsafe Scheduler. It would be good if it would also accept java.util.concurrent.Executor interface since it is a common interface returned by other libs. My current use case is in gRPC, when splitting context for multi-threading, and gRPC methods #fixedContextExecutor return base Executor.

[Tembrel]

Yes, I understand the semantic predicament, but you could have a wrapper similarly like you have for the ExecutorService and use the CompletableFuture.supplyAsync(Supplier, Executor) to return the value?

Seems reasonable to me. At the very least, couldn’t the use of ExecutorService.submit in lines like this be replaced by something like:

promise.delegate = es instanceof ExecutorService ?
    ((ExecutorService) es).submit(completingCallable) :
    supplyAsync(callableToSupplier(completingCallable), es);

when es is an Executor but not an ExecutableService? I realize that I’m glossing over an important detail with the following simple implementation of callableToSupplier, but the general idea seems feasible:

static <T> Supplier<T> callableToSupplier(Callable<? extends T> callable) {
    return () -> {
	try {
	    return callable.call();
        } catch (RuntimeException ex) {
            throw ex;
        } catch (Exception ex) {
            throw new RuntimeException(ex);
        }
    };
}

[jhalterman]

@paulius-p So there are two options for approaching this problem:

1. One way is to have the Executor call the user-provided Supplier/Runnable directly, then the result of the Executor is recorded. Of course this result would always be null or an exception. This is what the current Failsafe implementation does.
2. Another way is to have the Executor call a Runnable that wraps not just the user-provided Supplier/Runnable, but also the Failsafe code that records its result. This way the result from the Executor doesn’t matter, it’s just there for performing side-effects if needed, almost like an event listener. Also, if the Executor throws an exception, it won’t be recorded as part of the Failsafe handling since recording a result happens before the Executor completes. This is what your commit does.

I’m guessing you’d prefer the second option? When you say things partially works now, is that because using an Executor returns null currently? Maybe you could share your thoughts on the options.