Firing event objects with wildcards?

[ljnelson]

(I'm pushing hard on CDI events to fully understand them all the way down.)

I've found these tests to be interesting. The only difference is in the TypeLiteral used to select the Event. The first one succeeds; the second one fails:

@Test
final void testFireSubtypeWithWildcards0() {
  final Event<? super List<String>> e = this.c.select(new TypeLiteral<Event<List<String>>>() {}).get();
  e.fire(new ArrayList<String>());
}

@Test
final void testFireSubtypeWithWildcards1() {
  final Event<? super List<String>> e = this.c.select(new TypeLiteral<Event<? super List<String>>>() {}).get();
  e.fire(new ArrayList<String>()); // fails
}

The specification does not seem to prohibit wildcards:

An event type may not contain an unresolvable type variable. A wildcard type is not considered an unresolvable type variable.

I'm not sure whether this is correct behavior or not. By default, I presume it is. If so, what reading of the specification supports this failure?

[manovotn]

In summary, here's what happens in your case:

• Event payload is ArrayList, a class with type parameter
• Hence Weld needs to look at the declaring Event to try and infer the type parameter
• Specified type is a wildcard which has no type arguments
• This therefore ends with an unresolved type parameter, and we throw IAE

Specification only says the following on the matter:

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.

Which says nothing on how you should treat wildcards, i.e. you could interpret it as one of these:

• wildcard has no type arguments, you move on
  • This is what Weld currently does
• wildcard has no type arguments but wildcard bound could, so you try to inspect the bound
  • In this case I am not even sure making the leap to the bound would always be "safe"

[ljnelson]

Do you think that the specification should say that the specified type (the type argument supplied to Event) cannot contain wildcards? You've made a strong case for not being able to support them.

[manovotn]

I don't think I made a strong argument for either way, at least I didn't mean to.
Specification seems to explicitly enable that and for many cases that might be just fine.

According to specification, you can do:

@Inject
Event<?> wildEvent;

@Inject
Event<? super Foo> extendsFooEvent;

public void someMethod() {
    wildEvent.select(String.class).fire(new String);
    extendsFooEvent.fire(new Bar());
}

public class Foo {}
public class Bar extends Foo{}

So long as you don't need to look at the Event<T> to infer type parameters, there is no harm in it and you can use the same object to fire various events.

The unanswered part is what happens if you need to infer type variables and there is a wildcard with a bound. To that, I have no definitive answer.
I am not against it, I am just unsure if there isn't a case in which making such assumption would be wrong.
If you wish to try and implement it, I'll be happy to review and possibly expand on the tests to see if we can spot any reason why it shouldn't work.

---

BTW Weld is ATM stricter and will not allow you to use the code above (as you might have noticed in your attempts), I have created https://issues.redhat.com/browse/WELD-2818 for that as I didn't find any reason as to why it should be forbidden.

[manovotn]

Actually my previous comment is partially wrong.
Event<?> is pretty useless as you cannot really fire any type from it, nor can you #select(String.class) from it - that just won't compile. Upon further digging, any event with ? extends Something won't do any good either, so the only real use case is with super clause in it 🤔

[manovotn]

@ljnelson So, I have come a full circle and I think we might want to forbid this on the specification level.
That is, I think what Weld does is correct and we shouldn't change it.

I have created jakartaee/cdi#888 to track it. Feel free to chime in with your findings.

[ljnelson]

wildEvent.select(String.class).fire(new String);

You undoubtedly know this but: this won't work not because of the CDI specification, but because of the Java language (and the way the select method is defined on Event). The type variable U declared by select is declared as U extends T. Here String does not extend capture#1 of ?, so compilation fails.

the only real use case is with super clause in it 🤔

That's right. But it seems to me at first glance that this should be permitted, or at least I can't really come up with a good reason for why not other than "this is weird; I really wish we didn't have to support this".

[manovotn]

You undoubtedly know this but: this won't work not because of the CDI specification

Yes, I pointed out in my later comment (#3214 (reply in thread)) that I was wrong.

That's right. But it seems to me at first glance that this should be permitted, or at least I can't really come up with a good reason for why not other than "this is weird; I really wish we didn't have to support this".

I wonder what others will say on the CDI issue I created for it (for both, Event and Instance).
Supporting it isn't really difficult by the way (that is, to not fail if you declare it) but I am not sure there are any real benefits to it compared to declaring the type without wildcard.

[manovotn]

Closing this discussion as the ongoing discussion in the specification issue should provide a clear statement on what should and shouldn't work.