So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility.

Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ?

Pros :

- it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one

- it could have new members related to async behavior (context propagation, concurrent scenario, etc…)

- As it won’t be in legacy code no risk to see old observers called asynchronously  

Cons :

- Still not clear for users when fire() is called to see @AsyncObserves launched synchronously

- Yet another annotation added

wdyt ?

Antoine