To give a quick example of what this will allow, it will be possible to declare an injector for Single<Foo> and inject it via @Context Foo and the response will be automatically made asynchronous and the resource method will only be invoked once the Single<Foo> is resolved (non-blocking) to Foo and we can proceed. That's very huge for async users who want injection of async types.

• New @Provider type ContextInjector which allows users to declare pluggable injectors that can be injected with @Context.
• These injectors can be declared to provide injection of async types, such as CompletionStage<X>.
• If trying to inject @Context X and we have an async injector for CompletionStage<X> we properly wait for its resolution before injecting the resolved X (non blocking).
• Async injection supports pluggable async types using existing (unmodified) * AsyncResponseProvider system to wrap pluggable async types into CompletionStage. We may have to rename it, though?
• Onjection had to be rewritten to use CompletionStage everywhere. I initially wrote this using callbacks in order to avoid using CompletionStage but the API was not at all cleaner, and the implementation was just terribly fragile and error-prone. Using CompletionStage is invasive, but clean and trustworthy. I did verify that performance would not suffer, crudely, by measuring difference of running all Maven tests, and there's zero difference. Obviously that's not a real benchmark, but if you can point me to one, I'll measure it.
• Async injection is only attempted at points where async injection is permitted, such as for resource creation and resource method invocation. It is not enabled at points where the API does not allow for suspending the request (via ResourceContext.getResource for example).