-
Notifications
You must be signed in to change notification settings - Fork 7.6k
3.x: [Java 8] Implement mapOptional, collector, first/last/single stage #6775
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## 3.x #6775 +/- ##
===========================================
+ Coverage 98.2% 98.22% +0.02%
- Complexity 6187 6234 +47
===========================================
Files 681 688 +7
Lines 44776 45041 +265
Branches 6164 6193 +29
===========================================
+ Hits 43971 44243 +272
+ Misses 281 279 -2
+ Partials 524 519 -5
Continue to review full report at Codecov.
|
@BackpressureSupport(BackpressureKind.FULL) | ||
@SchedulerSupport(SchedulerSupport.NONE) | ||
@NonNull | ||
public final CompletionStage<T> firstStage(@Nullable T defaultItem) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if these are actually useful compared to just using the regular Single
-returning operators and then calling a toStage()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, put another way, would you add blockingFirstOptional()
and blockingLastOptional()
and the like or would you expect people to using the Single
-returning operators and then call blockingOptional()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. We have first
and blockingFirst
so in case of a firstStage
-> first().toCompletionStage()
change, wouldn't the API consistency require us dropping blockingFirst
for first().blockingGet()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind that. It keeps you inside the reactive APIs for transforming the data into the shape you want and then you can use a conversion or blocking operator to escape.
Up to you though. Just thinking of how to minimize the number of operators needed to support these new types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd keep them for now and see if I can beef up blockingGet
with macro-fusion (as their backing specific implementation is to be reused there). If it can be done reasonably well, I'm willing to drop blockingX
, and xStage
operators.
This PR implements the following
Flowable
operators:mapOptional
- essentially a map-filter viaOptional
s.collect(Collector)
- use the Java 8Collector
API, seeCollectors
.firstStage
- return the first item or a default value as aCompletionStage
.firstOrErrorStage
- return the first item or error as aCompletionStage
.singleStage
- return the only item or a default value as aCompletionStage
.singleOrErrorStage
- return the only item or error as aCompletionStage
.lastStage
- return the last item or a default value as aCompletionStage
.lastOrErrorStage
- return the last item or error as aCompletionStage
.Related: #6776
Diagrams: