Some enhancement like that, yeah. A similar solution was already stated in CDI-493 and CDI-516. This new API enhancement should accept any java.lang.reflect.Type, that does not contain a TypeVariable, but will throw an IllegalArgumentException otherwise. Of course only the raw type of the event object could only be checked against the type parameter for consistency, so we loose a good amount of type safety here. But as these API is primary meant to be used by extensions like the majority of BeanManager methods, at least I am fine with it.

In addition the original methods (fireEvent(event, qualifiers) and resolveObserverMethods(event, qualifiers)) must be kept for backward compability and probably will keep the use the event object's class for resolution, which implies the event class must not have any type variable as this will cause the documented IllegalArgumentException.

I see, you cannot do anything with Event before deployment validation phase, so it won't help.
Since you only have BM at that point, the solution would be to add another BM method, which would allow to explicitly state the type as well, is that correct?
Something along these lines:

BeanManager#fire(type, event, qualifiers)

To be a more concrete: I tried to write a meta-extension allowing "binding" of beans by (e.g. like in "interceptor binding") firing custom events during container initialization, similar to ProcessAnnotatedType<T>, that may be handled by other extensions. The type parameter T is not known statically, but rather reflectively as java.lang.reflect.Type. So even being able to retrieve an Event<T> before AfterDeploymentValidation }} does not help in this case, as {{Event<T> was meant for use with a concrete type parameter T either via Class or TypeLiteral.

This proposal does not supersedes it's linked duplicates imho.

manovotn Not completely: javax.enterprise.event.Event<T> is meant for application driven event triggering. In order to narrow down the event type, you can either specify a java.lang.Class<T> or a for generics a javax.enterprise.util.TypeLiteral<U>.

As an extension developer, Event<T> is not sufficient as you can neither

1. resolve Event<T> before AfterDeploymentValidation nor
2. narrow down the event type by an extension-resolved java.lang.reflect.Type, which can not be hardcoded using TypeLiteral<U> as the static type is not known to the extension and TypeLiteral was not meant for being created out of some unknown Type.

So there is still a need for extending the existing method BeanManager#fire and of course keeping it backwards compatible as mentioned in CDI-493.

tzwoenn what you describe is what this proposal solves. BeanManager#fire cannot handle narrowing and does not allow to fire events asynchronously - and we cannot change that because of the famous backward compatibility.

Having BeanManager#event as a new method on BM will grant you acces to Event<Object> where you can narrow the type with select(...) and then fire() or fireAsync.

For the current more extension-related BeanManager API (BeanManager#fire), which is not capable of handling event type narrowing by a specific java.lang.reflect.Type, a similar solution would be nice too.