Possible clarification needed in specification section on event types

[ljnelson]

The CDI 4.1 specification reads, in part:

An event object is an instance of a concrete Java class with no unresolvable type variables. The event types of the event include all superclasses and interfaces of the runtime class of the event object.

Given this:

Object eventObject = new ArrayList<String>();

…if the part of the specification that reads "the event types of the event [object] include all superclasses and interfaces of the runtime class of the event object" is true, then the event types would not include ArrayList<String>, but only what eventObject.getClass() returns (ArrayList.class) and its transitive supertype closure.

Does this section of the specification therefore need to be rewritten/clarified, since Weld, at least, (properly, IMHO) includes the parameterized type ArrayList<String> in the collection of event types for this example?

(Clearly the event types in real-world CDI implementations such as Weld are actually derived from the type argument supplied to the "broadcaster" (e.g. the ArrayList<String> in jakarta.enterprise.event.Event<ArrayList<String>>), not "the runtime class of the event object" (which cannot yield ArrayList<String> by itself), no matter what the specification says. It would be nice to bring the specification into line with real-world implementations.)

[Ladicek]

This is for historical reasons, I believe. The original CDI specification was written when the latest Java version was something like 6 or so, and in that version, the JLS didn't make a distinction between superclass and superclass type (dtto for interfaces). If written today, the sentence would refer to superclass types, not superclasses.

[Ladicek]

Also, this doesn't apply just to events, this "mistake" occurs in the whole CDI spec.

[manovotn]

(Clearly the event types in real-world CDI implementations such as Weld are actually derived from the type argument supplied to the "broadcaster" (e.g. the ArrayList<String> in jakarta.enterprise.event.Event<ArrayList<String>>), not "the runtime class of the event object" (which cannot yield ArrayList<String> by itself), no matter what the specification says. It would be nice to bring the specification into line with real-world implementations.)

FTR, Weld actually starts with the runtime class of event (getClass() on the payload), but if you encounter a type variable, it then tries to look into the Event<T> field. For future references, that part of code can be find around here.

I agree that we could clarify this plus I also looked into TCK and it seems we have this exact case covered - see ParameterizedEventTest.

[manovotn]

This is for historical reasons, I believe. The original CDI specification was written when the latest Java version was something like 6 or so, and in that version, the JLS didn't make a distinction between superclass and superclass type (dtto for interfaces). If written today, the sentence would refer to superclass types, not superclasses.

One other thing I can think of is that there used to be BeanManager#fireEvent method where you had nothing but the runtime object, so it was impossible to infer anything else (and hence to mention that in spec).
These days we should always be able to see the "broadcaster" type and use that.
That said, we still need to define it in a way where we prioritize the runtime object types and only fallback to inspecting the underlying Event<T> if there are type variables.

[Ladicek]

Another thing we noticed on the call today: instead of runtime class of the event object, we should say runtime type of the event object. This is because a "runtime class" of ArrayList<String> is just ArrayList and then suddenly all superclass types and interface types are also erasures, which we don't want.

[ljnelson]

Another thing we noticed on the call today: instead of runtime class of the event object, we should say runtime type of the event object. This is because a "runtime class" of ArrayList is just ArrayList and then suddenly all superclass types and interface types are also erasures, which we don't want.

Right, that's exactly what this issue is trying to report. Good.

I'm not sure that "runtime type" is a good substitute though, since if you're starting from getClass() you can't "reach" any type arguments that may be buried in there.

That is, if all you have is an Object in your hand and you are trying to discover magically that you actually have an ArrayList<String> in your hand, you can't do it without extra information, as I know you all know. The only types "reachable" from an arbitrary Object are those "reachable" from the return value of an invocation of its getClass() method, and those will never produce ArrayList<String>. So talking about an object's "runtime type" doesn't get you any closer.

My guess is that the event area anyway needs to be tweaked to indicate that you have to look at the "broadcaster" type in some way to discover type arguments. I haven't thought hard about what this wording might look like.

[manovotn]

We wanted to avoid spelling out the "algorithm" which the impl should follow in order to allow for other approaches.
And the "runtime type" is mostly a way of avoiding application of type erasure to inherited types, as Ladislav pointed in his last comment. While it doesn't make it explicitly clear how to identify the types, note that further down in the spec, there is also this:

If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.

[ljnelson]

What does "to infer the parameterized type of the event types" mean? Does it mean, simply, "instead"?

[Ladicek]

A lot of terminology in the CDI spec is fairly old and non-standard, as acknowledged here: #682 (comment) We should do an editing pass over the whole spec, but it's been a low priority for obvious reasons.

The events section of the spec uses both terms "runtime type" and "runtime class" and it looks like they're used in the same meaning. The meaning, as far as I can tell, is: the class type as obtained by getClass(), if it is not a generic class/interface; otherwise, a parameterized type with the generic class/interface as obtained by getClass() and type arguments as substituted from the Event injection point. If some type arguments cannot be substituted, IAE is thrown.

EDIT: I'm actually not sure what happens about primitive types and array types. Primitive types are probably not valid event types and when it comes to array types, it depends on how strictly or leniently you read the spec.

[manovotn]

What does "to infer the parameterized type of the event types" mean? Does it mean, simply, "instead"?

I am not sure I understand. To me the sentence I quoted pretty clearly states that implementations are supposed to use the underlying Event<T> to deduce the type parameters if the information from the event runtime payload isn't enough 🤷

[Azquelt]

What does "to infer the parameterized type of the event types" mean?

Say you have an Event<List<String>> event and you call event.fire(new ArrayList<String>())

The container knows that the runtime type is ArrayList, that ArrayList<T> extends List<T>, and that the specified type of the event is List<String>. From that information, the container has to infer that the actual event type is ArrayList<String>.

You can see this behaviour being tested in the ParameterizedEventTest that manovotn linked above.

[ljnelson]

Thanks. Yes, I understand the types involved. I'm focused on the language. It seems to me that:

If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.

…could simply be:

If the container is unable to resolve the parameterized type of the event object, it uses the specified type instead.

…since we know what "specified type" means (the type argument in question).