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

[Anatole Tresch]

Hi all

I would say we can also see mutability/immutability as simply two options..
In general it is a decision of the event/payload designer, If the event is
mutable or not, and if it is mutable, it should be implemented in a thread
safe way with (hopefully) minimal locking/synch efforts. To mention the
ladder somewhere in the spec might be useful.

I would hereby tend to follow the same policy for synch and asynch events
(you never know what else payload consumers do with the event). I think it
is sufficient to warn users that mutable asynch events basically can create
race conditions and locks if thread-safety is not given, but I would not
generally disable/disallow it.

-Anatole


2014-12-17 17:49 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:
>
> 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.
> 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.
>


-- 
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

*Switzerland, Europe Zurich, GMT+1*
*Twitter:  @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*

*Google: atsticksMobile  +41-76 344 62 79*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/8118c813/attachment.html