StructuredExecutor API and wildcards

Remi Forax forax at
Sun Nov 21 18:02:45 UTC 2021

I've noticed that the current API has some signatures that are not correct,
either a widlcard is missing, or there is a type parameter instead of a wildcard, etc.

I know that the Executor/Future has similar issues so there is perhaps a weird tradition ... sorry kidding.

In StructuredExecutor:
  <V> Future<V> fork(Callable<V> task)
should be
  <V> Future<V> fork(Callable<? extends V> task).

For all functional interface, the result should be ? extends R and the parameters should be ? super P.

For the other fork(), you can see that someone struggle to get the correct signature :)
<U, V extends U> Future<V> fork(Callable<V> task, BiConsumer<StructuredExecutor,Future<U>> onComplete)

It should be
<V> Future<V> fork(Callable<? extends V> task, BiConsumer<? super StructuredExecutor, ? super Future<V>> onComplete)

U does need to be named, Future<V> can be a Future<? extends V> because there is no methods taking a V as parameter,
but given that FutureTask has methods that takes a V, so i think it's better to keep Future invariant.

In ShutdownOnFailure,
usually we use Void instead of Object to represent the type of a value that can only be null, so
the class should be declared
  class ShutdownOnFailure implements BiConsumer<StructuredExecutor,Future<Void>> { }

  void accept(StructuredExecutor executor, Future<Object> future)
is now
  void accept(StructuredExecutor executor, Future<Void> future)

  <X extends Throwable> void throwIfFailed(Function<Throwable, ? extends X> esf)
should be
  <X extends Throwable> void throwIfFailed(Function<? extends Throwable, ? extends X> esf)

In ShutdownOnSuccess<V>
  <X extends Throwable> V result(Function<Throwable, ? extends X> esf)
should be
  <X extends Throwable> V result(Function<? super Throwable, ? extends X> esf) throws X

for ShutdownOnSuccess<V>, i think it's better to just have a method that returns a Future instead of trying to invent another API very similar to Future.


More information about the loom-dev mailing list