[cdi-dev] Is the concept of mutable event payload specified

[José Paumard]

There's defnitely a bug in the spec on that point, because nowhere it is
stated that the event are consumed in the same thread as the one that fired
the event. So, the spec allows for mutable event payload and does not state
that this event should be consumed in the same thread. It is thus possible
to have concurrency (incl. but not limited to visibility) issues.

While introducing async events, we definitely need to do some clean up
here. And be careful about not breaking existing code, of course.

José


2014-12-17 17:53 GMT+01:00 Peter Muir <pmuir at redhat.com>:
>
>
>
> ----- Original Message -----
> > Ok guys,
> >
> > Let’s do it again. I didn’t say we have to forbid the mutability I said
> we
> > have at least to explicitly write that it’s mutable and seriously think
> of
> > having it immutable for event fired asynchronously.
> >
> > > (Pete) I don’t think it’s specified. As objects are, by default in
> Java,
> > > mutable, I would assume that payloads are implicitly mutable.
> >
> >
> > Sorry @Pete I don’t agree with your point. Yes, in Java object are
> mutable
> > but firing an event is not a standard Java feature : you send your
> object to
> > a black box and let this box dispatch your object to listeners
> transforming
> > one call to multiple call : it’s far from standard Java rules. Even if
> it’s
> > not written it’s an observer pattern and there are people out there
> thinking
> > that introducing mutability in observer is an anti-pattern since some
> > listener will receive a different payload than the one that was sent to
> > them.
>
> I agree it should be tidied up. I'm simply stating that currently I would
> interpret the spec as allowing mutable payloads.
>
> > It’s like making a method call and having no guarantee that the parameter
> > received in the callee has the same value that in the caller...
> > I won’t start discussion on bad practice or anti pattern  as I also use
> > mutability in event but there as much reason for user to assume their
> > payload will be mutable than the other way around.
> > I can assure you that when I give a talk on CDI, this payload mutability
> is
> > often a surprise for attendees...
> >
> > > (Romain) why isn't it portable?
> >
> >
> > So yes @Romain it’s not portable (in theory of course, since both
> > implementations support mutability). Someone could write a CDI
> > implementation with event payload immutability without any issue with the
> > spec and TCK.
> >
> > Most of you are so dependent of this feature that you only reacted to the
> > idea or forbidding it (which wasn’t the content of my mail) ;). So we all
> > agree that it’s an important feature. Therefore what’s the issue to
> specify
> > this mutability and add TCK test for it ?
> >
> > Now I don’t deal with that subject for nothing, we are planning to
> introduce
> > Async events. I think that it’ll bring extra complexity if we support
> > mutability in async events. And even if I’m wrong and we finally go for
> > mutability in async events, this will lead to possible side effect (lock)
> > that could have impact on perf, so it should be explicitly written IMO.
> >
> > Antoine
> >
> >
> >
> >
> >
> >
> >
> >
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>


-- 
Java le soir <http://blog.paumard.org> Cours Java en ligne
<http://blog.paumard.org/cours-tutoriaux/>
Twitter <http://twitter.com/#!/JosePaumard> Paris JUG
<http://www.parisjug.org> Devoxx France <http://www.devoxx.fr>
M : +33 6 76 82 91 47
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141217/0ffb9811/attachment.html