[webbeans-dev] event type with type variable
Pete Muir
pmuir at redhat.com
Sat Jul 25 07:13:33 EDT 2009
On 24 Jul 2009, at 22:03, Dan Allen wrote:
> I'm going to tread carefully when arguing this point because I am
> far from a master at generics. Unfortunately, it seems that the non-
> normative section of the generics documentation is not consistent
> with the generics API. For instance, in the documentation, a type
> parameter is described as a special kind of type variable. But in
> the generics API, they are two separate things (ParameterizedType
> and TypeVariable). But I may be mistaken.
I would advise using the JLS which clearly describes type variables
and type parameters as two separate things which don't form a parent-
child structure.
>
> With that said, the example I gave fails in Web Beans. Let me give a
> full example:
>
> public class Artist<T> { ... }
>
> public class Solo { ... }
>
> public class TuneSelect {
> @Any Event<Artist<Solo>> soloArtistEvent;
>
> public void soloArtistPlaying(Artist<Solo> artist)
> {
> soloArtistEvent.fire(artist);
> }
> }
>
> Here's the exception Web Beans spits out.
>
> java.lang.IllegalArgumentException: Event type
> org.jboss.jsr299.tck.tests.event.eventTypes.Artist is not allowed
> because it is a generic
> at
> org.jboss.webbeans.BeanManagerImpl.fireEvent(BeanManagerImpl.java:798)
> at org.jboss.webbeans.event.EventImpl.fire(EventImpl.java:76)
>
> => same result for soloArtistEvent.fire(new Artist<Solo>())
>
> If you believe that should be valid, then I will simply mark it as
> ri-broken.
Right this should pass. Please make sure you also file a WBRI - every
time you mark something ri-broken, it needs an associated WBRI...
BTW this is quite easy to fix - we need to upgrade events to use the
type parameter resolution stuff that Takeshi wrote for us.
>
> I see what you are saying though in that what is not allowed is a
> type which is tied to the method parameters, hence acting as a type
> variable.
>
> -Dan
>
> On Fri, Jul 24, 2009 at 12:46 PM, Pete Muir <pmuir at redhat.com> wrote:
> No, the spec prohibits type variables in event objects and event
> types, it doesn't prohibit type parameters.
>
> This isn't legal
>
> public class Foo{
>
> @Produces <T> Bar make(@Any Event<T> event) {
> ...
>
> }
>
> and we do need to error at deployment time for such a declaration.
> Do we?
>
> What you show *is* valid.
>
> It's also not valid to actually pass an event object with a type
> variable, but it's extremely hard to actually find code that will
> compile and pass the above deployment test, but still do this and do
> this so I can't find an example right now ;-)
>
>
>
> On 24 Jul 2009, at 17:28, Dan Allen wrote:
>
> In several places, the specification reiterates that an event type
> may not contain a type variable. However, it appears that this
> restriction is only enforced at runtime when the event object is
> passed to either Event#fire() or BeanManager#fireEvent() method. I
> would suggest that an validation check be added so that the
> container detects an illegal Event definition at deployment type.
> Here's an example of an illegal definition (from my understanding):
>
> public class VoterRegistration<T> { ... }
>
> @Any Event<VoterRegistration<Democrat>> democratRegisteredEvent;
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://in.relation.to/Bloggers/Dan
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
>
>
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://in.relation.to/Bloggers/Dan
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
More information about the weld-dev
mailing list