Clarify observability for primitive types

[manovotn]

The specification does not say what works and what doesn't if there is a combination of primitive and wrapper types between observed type and fired event.

Note that type arguments cannot be primitive and for that reason I will assume that event payload is a wrapper type here:

@Inject
Event<Integer> intEvent;

public void primitiveObserver(@Observes int i) {
  // some logic
}

public void wrapperObserver(@Observes Integer i) {
  // some logic
}

Assuming the event is fired, which observer(s) should be notified?

IMO, both - which is what Weld currently does. Although the specification does not seem to cover this, nor have I found a TCK test for it.

---

For completeness a more details, see the weld-dev mailing list where this question was asked - https://lists.jboss.org/archives/list/[email protected]/thread/IDWNDAJLY57OE6MJNNRVW5HSOV3MJLPJ/

[Ladicek]

This seems reasonable to me. We probably want to copy https://jakarta.ee/specifications/cdi/4.1/jakarta-cdi-spec-4.1.html#primitive_types_and_null_values to somewhere in the Events chapter. Not sure about null behavior though. Can an event object even be null?

[Ladicek]

For the record, I just wrote a test for this that verifies that ArC behaves the same as Weld (that is, both primitive and wrapper observers are notified).

[ljnelson]

(Tiny point to @manovotn that I think you want your wrapperObserver method in your example to accept an Integer rather than an int, since otherwise it would be no different from primitiveObserver.)

[ljnelson]

The only additional input I have is: I haven't kept up with Valhalla at all, but suppose there is some kind of future where you could fire a primitive type. Maybe it would be OK to leave this as unspecified behavior to permit such a state of affairs in the future?

[Ladicek]

Re Valhalla: generics specialization is still in the distant future, and we're already in a "problem" with bean assignability anyway (we treat primitives and their wrappers as identical), so I wouldn't bother too much about this.

Technically, even though I couldn't find this specified anywhere, all implementations of CDI check that the event object is not null (either explicitly or implicitly), so Event<Integer> is practically identical to Event<Integer!>, which should for all means and purposes be identical to Event<int>, IIUC. So we should be fine.

[ljnelson]

Another note: events cannot be null; the specification says: "An event object is an instance of a concrete Java class". I don't believe null is considered to be an instance of a class.

[Ladicek]

Fair enough :-) Thanks!