<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi all</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">-Anatole</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-17 17:49 GMT+01:00 Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Ok guys,</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite">(Pete) I don’t think it’s specified. As objects are, by default in Java, mutable, I would assume that payloads are implicitly mutable.</blockquote></div><div><br></div><div>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. </div><div>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...</div><div>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.</div><div>I can assure you that when I give a talk on CDI, this payload mutability is often a surprise for attendees...</div><div><br></div><div><blockquote type="cite"><span style="font-family:Menlo-Regular;font-size:11px">(Romain) why isn't it portable?</span></blockquote></div><div><br></div><div>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.</div><div><br></div><div>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 ?</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Antoine</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></font></span></div><br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br></blockquote></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="font-family:arial;font-size:small"><b>Anatole Tresch</b></span><div style="font-family:arial;font-size:small">Java Engineer & Architect, JSR Spec Lead<br>Glärnischweg 10<br>CH - 8620 Wetzikon</div><div style="font-family:arial;font-size:small"><br></div><div style="font-family:arial;font-size:small"><i>Switzerland, Europe Zurich, GMT+1</i></div><div style="font-family:arial;font-size:small"><i>Twitter: @atsticks</i></div><div><i style="font-family:arial;font-size:small">Blogs: </i><font face="arial"><i><a href="http://javaremarkables.blogspot.ch/" target="_blank">http://javaremarkables.blogspot.ch/</a></i></font></div><div style="font-family:arial;font-size:small"><i>Google: atsticks<br>Mobile +41-76 344 62 79</i></div></div></div>
</div>