Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Netty 5] More composable Future API #8523

Closed
normanmaurer opened this issue Nov 13, 2018 · 6 comments · Fixed by #11607
Closed

[Netty 5] More composable Future API #8523

normanmaurer opened this issue Nov 13, 2018 · 6 comments · Fixed by #11607
Assignees
@chrisvest
Milestone
[Netty 5] Future...

Comments

@normanmaurer
Copy link
Member

Netty’s Future API has an addListener method which is the primary means of asynchronous notification. However this API is not composable and can lead to manually moving/aggregating/manipulating data. For example providing a map API to transform data from one type to another, and also methods like onSuccess and onFailure which allows Futures to be chained and results to be modified along the way.

We need to investigate case by case. That said if we provide “converter” methods to obtain a CompletionStage from Future we may be able to use let people use this and keep our Future implementation lightweight.
@Bennett-Lynch
Copy link
Contributor

Is there any consideration of using Java's CompletableFuture exclusively?

I actually prefer Netty's Future in a lot of cases (less verbose, more readable error checking), but there's still something to be said for standardization.

@normanmaurer
Copy link
Member Author

normanmaurer commented Nov 13, 2018 •
edited
Loading

@Bennett-Lynch I must say I am not the biggest fan of CompletableFuture and CompletationStage for various reasons. Also I think our "execution" guarantees are much more restrictive. That said I think it would be good to allow to get a CompletationStage from a netty Future for easier interopt.

@trustin
Copy link
Member

trustin commented Nov 21, 2018

My experience with CompletionStage was pretty good. How about implementing CompletionStage with strict execution guarantee, rather than maintaining a large set of methods by ourselves?

@He-Pin
Copy link
Contributor

He-Pin commented Nov 21, 2018

I like to see a more functional API like https://github.com/vavr-io/vavr/blob/master/vavr/src/main/java/io/vavr/concurrent/Future.java . One thing I'm not that like CompletionStage is that the nearly all methods are renamed. the map became thenApply and thenApplyAsync :(.

normanmaurer added a commit that referenced this issue Apr 2, 2019
@normanmaurer
Introduce Future.toStage() which allows to obtain a CompletionStage a…
82aa80b 
…dapter for a Future.

Motivation:

CompletionStage is the new standard for async operation chaining in JDK8+ that is supported by various of libs. To make it easer to interopt with other libs and to allow users to make good use of lambdas and functional programming style we should allow to convert from our Future to a CompletionStage while still provide the same ordering guarantees.

The reason why we expose this as toStage() and not jus have Future extend CompletionStage is for two reasons:
 - Keep our interface norrow
 - Keep semantics clear (Future.addListener(...) methods return this while all chaining methods of CompletionStage return a new instance).

Modifications:

- Merge implements in AbstractFuture to Future (by make these default methods)
- Add Future.toStage() as a default method and a special implemention in DefaultPromise (to reduce GC).
- Add Future.executor() which returns the EventExecutor that is pinned to the Future

Result:

Easier inter-op with other Java8+ libaries. Related to #8523.
@normanmaurer normanmaurer mentioned this issue Apr 2, 2019
Merged
@normanmaurer
Copy link
Member Author

PTAL #9004

normanmaurer added a commit that referenced this issue Apr 3, 2019
@normanmaurer
Introduce Future.toStage() which allows to obtain a CompletionStage a…
4dc0e93 
…dapter for a Future.

Motivation:

CompletionStage is the new standard for async operation chaining in JDK8+ that is supported by various of libs. To make it easer to interopt with other libs and to allow users to make good use of lambdas and functional programming style we should allow to convert from our Future to a CompletionStage while still provide the same ordering guarantees.

The reason why we expose this as toStage() and not jus have Future extend CompletionStage is for two reasons:
 - Keep our interface norrow
 - Keep semantics clear (Future.addListener(...) methods return this while all chaining methods of CompletionStage return a new instance).

Modifications:

- Merge implements in AbstractFuture to Future (by make these default methods)
- Add Future.toStage() as a default method and a special implemention in DefaultPromise (to reduce GC).
- Add Future.executor() which returns the EventExecutor that is pinned to the Future

Result:

Easier inter-op with other Java8+ libaries. Related to #8523.
normanmaurer added a commit that referenced this issue Apr 3, 2019
@normanmaurer
Introduce Future.toStage() which allows to obtain a CompletionStage a…
83b1fdb 
…dapter for a Future.

Motivation:

CompletionStage is the new standard for async operation chaining in JDK8+ that is supported by various of libs. To make it easer to interopt with other libs and to allow users to make good use of lambdas and functional programming style we should allow to convert from our Future to a CompletionStage while still provide the same ordering guarantees.

The reason why we expose this as toStage() and not jus have Future extend CompletionStage is for two reasons:
 - Keep our interface norrow
 - Keep semantics clear (Future.addListener(...) methods return this while all chaining methods of CompletionStage return a new instance).

Modifications:

- Merge implements in AbstractFuture to Future (by make these default methods)
- Add Future.toStage() as a default method and a special implemention in DefaultPromise (to reduce GC).
- Add Future.executor() which returns the EventExecutor that is pinned to the Future

Result:

Easier inter-op with other Java8+ libaries. Related to #8523.
normanmaurer added a commit that referenced this issue Apr 4, 2019
@normanmaurer
Introduce Future.toStage() which allows to obtain a CompletionStage a…
e7fb6c6 
…dapter for a Future.

Motivation:

CompletionStage is the new standard for async operation chaining in JDK8+ that is supported by various of libs. To make it easer to interopt with other libs and to allow users to make good use of lambdas and functional programming style we should allow to convert from our Future to a CompletionStage while still provide the same ordering guarantees.

The reason why we expose this as toStage() and not jus have Future extend CompletionStage is for two reasons:
 - Keep our interface norrow
 - Keep semantics clear (Future.addListener(...) methods return this while all chaining methods of CompletionStage return a new instance).

Modifications:

- Merge implements in AbstractFuture to Future (by make these default methods)
- Add Future.toStage() as a default method and a special implemention in DefaultPromise (to reduce GC).
- Add Future.executor() which returns the EventExecutor that is pinned to the Future
- Introduce FutureCompletionStage that extends CompletionStage to clarify threading semantics and guarantees.

Result:

Easier inter-op with other Java8+ libaries. Related to #8523.
normanmaurer added a commit that referenced this issue Apr 10, 2019
@normanmaurer
Introduce Future.toStage() which allows to obtain a CompletionStage a…
fa14e3f 
…dapter for a Future.

Motivation:

CompletionStage is the new standard for async operation chaining in JDK8+ that is supported by various of libs. To make it easer to interopt with other libs and to allow users to make good use of lambdas and functional programming style we should allow to convert from our Future to a CompletionStage while still provide the same ordering guarantees.

The reason why we expose this as toStage() and not jus have Future extend CompletionStage is for two reasons:
 - Keep our interface norrow
 - Keep semantics clear (Future.addListener(...) methods return this while all chaining methods of CompletionStage return a new instance).

Modifications:

- Merge implements in AbstractFuture to Future (by make these default methods)
- Add Future.toStage() as a default method and a special implemention in DefaultPromise (to reduce GC).
- Add Future.executor() which returns the EventExecutor that is pinned to the Future
- Introduce FutureCompletionStage that extends CompletionStage to clarify threading semantics and guarantees.

Result:

Easier inter-op with other Java8+ libaries. Related to #8523.
normanmaurer added a commit that referenced this issue Apr 11, 2019
@normanmaurer
Introduce Future.toStage() which allows to obtain a CompletionStage a… (
81244e1 
#9004)

Motivation:

CompletionStage is the new standard for async operation chaining in JDK8+ that is supported by various of libs. To make it easer to interopt with other libs and to allow users to make good use of lambdas and functional programming style we should allow to convert from our Future to a CompletionStage while still provide the same ordering guarantees.

The reason why we expose this as toStage() and not jus have Future extend CompletionStage is for two reasons:
 - Keep our interface norrow
 - Keep semantics clear (Future.addListener(...) methods return this while all chaining methods of CompletionStage return a new instance).

Modifications:

- Merge implements in AbstractFuture to Future (by make these default methods)
- Add Future.toStage() as a default method and a special implemention in DefaultPromise (to reduce GC).
- Add Future.executor() which returns the EventExecutor that is pinned to the Future
- Introduce FutureCompletionStage that extends CompletionStage to clarify threading semantics and guarantees.

Result:

Easier inter-op with other Java8+ libaries. Related to #8523.
This was referenced Aug 19, 2021
Merged
Merged
@chrisvest chrisvest linked a pull request Aug 25, 2021 that will close this issue
Add a Futures class with static map() and flatMap() methods #11607
Merged
chrisvest added a commit that referenced this issue Aug 26, 2021
@chrisvest
Add a Futures class with static map() and flatMap() methods (#1…
445f747 
…1607)

Motivation:
Making futures easier to compose, combine, and extend is useful to have as part of the API, since implementing this correctly and efficiently can be tricky.

Modification:
Add `Future.map(Function<V,R>) -> Future<R>` and `Future.flatMap(Function<V,Future<R>>) -> Future<R>` default methods to the `Future` interface.
These methods return new Future instance, that will be completed when the original future completes, and the result will be processed through the given mapping function.
These two methods take care to propagate cancellation and exceptions correctly:
Cancellation propagates both ways between the new and original future.
Failures only propagate from the original future to the returned new Future instance.

Result:
A few convenient methods for modifying and composing futures.

This PR fixes #8523, and perhaps also #2105
@chrisvest
Copy link
Contributor

map and flatMap methods have been merged into master — closing this.

@k-wall k-wall mentioned this issue Apr 12, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@chrisvest chrisvest

Labels
None yet
Projects
None yet
Milestone
[Netty 5] Futures / Promises enhance...
Development

Successfully merging a pull request may close this issue.

Add a Futures class with static map() and flatMap() methods chrisvest/netty
5 participants
@chrisvest @trustin @normanmaurer @He-Pin @Bennett-Lynch