why not both Future and CompletionHandler?

[Alan Bateman]

Sangjin Lee wrote:
> Yes, I think it can come very handy if you want to add some 
> cross-cutting concerns in the completion handlers but allow the end 
> users to interact with the result via Future.
>
> For example, suppose I build a framework/library for others using the 
> async channels (HTTP app, ssh app, etc.). I want to allow my users 
> freedom to choose between the "pull" (future) and the "push" 
> (completion handler). However, *regardless* of what my end user choose 
> to interact with the result, I want to be able to inject some concerns 
> like logging, instrumenting, etc. in the form of a completion handler 
> (can be completely internal to the framework).
>
> With the current APIs, if the user wants a future, the framework 
> cannot use the completion handler and I would need to find another way 
> to inject such logic. Or if I want to retain the completion handler 
> for the framework, then I would need to create my own future objects 
> to provide to the end users. Either approach is doable, but it would 
> be so much easier if the NIO.2 APIs provide both mechanisms in a 
> single method call. My 2 cents. Thanks!
For high performance applications using completion handlers then we 
don't want to future Future objects that won't be used. In your 
framework/library then won't it return your own Future type anyway?

-Alan.