Introduce MonoFromFutureSupplier{,Boolean} Refaster rules
#1244
Conversation
|
Looks good. No mutations were possible for these changes. |
Venorcis
changed the title
Mono#fromFuture
| * Prefer {@link Mono#fromFuture(Supplier, boolean)} over {@link | ||
| * Mono#fromFuture(CompletableFuture, boolean)}. | ||
| */ | ||
| static final class MonoFromFutureSuppressCancel<T> { |
There was a problem hiding this comment.
@Stephan202 according to our undocumented naming scheme, we would now call this MonoFromFutureBoolean right?
There was a problem hiding this comment.
Strictly speaking even MonoFromFutureSupplierBoolean 😄
Stephan202
force-pushed
the
vkoeman/mono-from-future
branch
from
3561c90 to
a005e37
Compare
| * Prefer {@link Mono#fromFuture(Supplier, boolean)} over {@link | ||
| * Mono#fromFuture(CompletableFuture, boolean)}. | ||
| */ | ||
| static final class MonoFromFutureSuppressCancel<T> { |
There was a problem hiding this comment.
Strictly speaking even MonoFromFutureSupplierBoolean 😄
| @BeforeTemplate | ||
| Mono<T> before(CompletableFuture<T> future) { | ||
| return Mono.fromFuture(future); | ||
| } |
There was a problem hiding this comment.
I'll add an XXX to later apply @NotMatches(IsIdentityOperation.class). Cause as-is this code will also rewrite Mono.fromFuture(someVariable), which isn't great.
Stephan202
changed the title
Mono#fromFutureMonoFromFutureSupplier{,Boolean} Refaster rules
|
Looks good. No mutations were possible for these changes. |
|
Futures subscribe eagerly. This means that
Mono#fromFuture(CompletableFuture)already executes the contents of the future on assembly time (even when thatFutureis constructed from aMonoas we do in our reactive Caffeine caches).I therefore suggest instead to always use
Mono#fromFuture(Supplier), which will only instantiate (and thus execute) the future on subscription, i.e. much closer to how we usually do everything 😄