Hi, I found an issue in either the spec or the tck, which I would like to discuss: The TCK-Test org.jboss.cdi.tck.tests.event.fires.FireEventTest.testTypeVariableEventTypeFails uses the following bean to fire an event by calling the method fireWithTypeVariable() publicclassBar { @Inject private Event<Foo<? extends Number>> event; public <T extends Number> void fireWithTypeVariable() { event.fire(new Foo<T>()); } } The TCK expects this test to fail because of the type variable in the instance created by new Foo<T>() However, the spec states in 10.3.1 "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." Imho in this case the container is able to resolve T to "? extends Number" and the spec does not prohibit an event to have a wildcard type. So since T is not unresolvable, this test case should not expect the container to throw an exception. If we consider T not to be resolved, because it resolves to a wildcard type, we should mention this somewhere in the spec. Or am I missing something? Cheers, Arne _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Hi Jozef, In this case the type variable can be resolved to a wildcard type. Should this be legal or not? For now, I find to wording in the spec that forbids the event type to resolve to a wildcard type. So this may be a spec issue AND a tck issue. Shall I create a ticket for it? Cheers, Arne Von: Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>> Datum: Freitag, 2. Mai 2014 16:20 An: Arne Limburg <arne.limburg(a)openknowledge.de <mailto:arne.limburg@openknowledge.de>> Cc: &quot;cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>" <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>> Betreff: Re: [cdi-dev] Events and Type Variables in CDI 1.1 Hi, I think this is a spec issue. The spec should make it clearer that a "resolvable type variable" means a type variable that can be resolved to a reference type other than a type variable. Jozef On 04/30/2014 09:32 PM, Arne Limburg wrote: > Hi, > > I found an issue in either the spec or the tck, which I would like to > discuss: > The > TCK-Test org.jboss.cdi.tck.tests.event.fires.FireEventTest.testTypeVariableEventTypeFails > uses the following bean to fire an event by calling the method > fireWithTypeVariable() > > publicclassBar { > > > @Inject > > private Event<Foo<? extends Number>> event; > > > public <T extends Number> void fireWithTypeVariable() { > > event.fire(new Foo<T>()); > > } > > > } > > > The TCK expects this test to fail because of the type variable in the > instance created by new Foo<T>() > However, the spec states in 10.3.1 „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.“ > Imho in this case the container is able to resolve T to "? extends > Number“ and the spec does not prohibit an event to have a wildcard > type. So since T is not unresolvable, this test case should not > expect the container to throw an exception. If we consider T not to > be resolved, because it resolves to a wildcard type, we should > mention this somewhere in the spec. Or am I missing something? > > Cheers, > Arne > > > _______________________________________________ > cdi-dev mailing list > cdi-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev

Hi, I may be wrong, but I always thought a wildcard represents an unknown type and cannot be used for instance creation. So I believe "T" is not resolvable in this use-case. The spec states in 10.1: "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.". In other words an event type may not contain a wildcard. Note that a parameterized type that contains a wildcard type parameter is not a legal bean type either. Still the spec should clarify what "resolvable" means and maybe explicitly forbid wildcards in event types. Martin Dne 5.5.2014 08:46, Jozef Hartinger napsal(a): > Yes, go ahead with the spec issue. > > Jozef > > On 05/04/2014 10:24 PM, Arne Limburg wrote: >> Hi Jozef, >> >> In this case the type variable can be resolved to a wildcard type. >> Should this be legal or not? For now, I find to wording in the spec >> that forbids the event type to resolve to a wildcard type. So this may >> be a spec issue AND a tck issue. Shall I create a ticket for it? >> >> Cheers, >> Arne >> >> Von: Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>> >> Datum: Freitag, 2. Mai 2014 16:20 >> An: Arne Limburg <arne.limburg(a)openknowledge.de >> <mailto:arne.limburg@openknowledge.de>> >> Cc: &quot;cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>" >> <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>> >> Betreff: Re: [cdi-dev] Events and Type Variables in CDI 1.1 >> >> Hi, >> >> I think this is a spec issue. The spec should make it clearer that a >> "resolvable type variable" means a type variable that can be resolved >> to a reference type other than a type variable. >> >> Jozef >> >> On 04/30/2014 09:32 PM, Arne Limburg wrote: >>> Hi, >>> >>> I found an issue in either the spec or the tck, which I would like to >>> discuss: >>> The >>> TCK-Test >>>org.jboss.cdi.tck.tests.event.fires.FireEventTest.testTypeVariableEvent >>>TypeFails >>> uses the following bean to fire an event by calling the method >>> fireWithTypeVariable() >>> >>> publicclassBar { >>> >>> >>> @Inject >>> >>> private Event<Foo<? extends Number>> event; >>> >>> >>> public <T extends Number> void fireWithTypeVariable() { >>> >>> event.fire(new Foo<T>()); >>> >>> } >>> >>> >>> } >>> >>> >>> The TCK expects this test to fail because of the type variable in the >>> instance created by new Foo<T>() >>> However, the spec states in 10.3.1 „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.“ >>> Imho in this case the container is able to resolve T to "? extends >>> Number“ and the spec does not prohibit an event to have a wildcard >>> type. So since T is not unresolvable, this test case should not >>> expect the container to throw an exception. If we consider T not to >>> be resolved, because it resolves to a wildcard type, we should >>> mention this somewhere in the spec. Or am I missing something? >>> >>> Cheers, >>> Arne >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> >>>cdi-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev >> > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev >