Hi guys, Always working on Async event concept and discussion around mutable payloads. I was looking where in the spec we specified the fact that fired payload are mutable. I red-read chapter 10 ( http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and didn’t found. I also browsed JIRA and TCK to find any ref to this feature and found nothing. On the other hand it is not specified that payload should be immutable ;) I’d be happy if some of you could have a look and see if I missed something. If I’m not wrong, the mutable payload we (including myself) advertise in CDI is a non portable feature (I’m the firs surprised here). So I propose that : 1) We decide to write something in the specification about allowing or forbidding it (I know some people not happy with this mix between observer and visitor pattern) 1bis) Should we decide to forbid it by default, we should provide an alternative mode to allow people using this unspecified feature 2) Forbid it for fireAsync() Thanks for your feedback and your correction if I missed the feature in the spec. Antoine _______________________________________________ cdi-dev mailing list cdi-dev(a)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.

I don’t think it’s specified. As objects are, by default in Java, mutable, I would assume that payloads are implicitly mutable. On 16 Dec 2014, at 16:31, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: Hi guys, Always working on Async event concept and discussion around mutable payloads. I was looking where in the spec we specified the fact that fired payload are mutable. I red-read chapter 10 (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and didn’t found. I also browsed JIRA and TCK to find any ref to this feature and found nothing. On the other hand it is not specified that payload should be immutable ;) I’d be happy if some of you could have a look and see if I missed something. If I’m not wrong, the mutable payload we (including myself) advertise in CDI is a non portable feature (I’m the firs surprised here). So I propose that : 1) We decide to write something in the specification about allowing or forbidding it (I know some people not happy with this mix between observer and visitor pattern) 1bis) Should we decide to forbid it by default, we should provide an alternative mode to allow people using this unspecified feature 2) Forbid it for fireAsync() Thanks for your feedback and your correction if I missed the feature in the spec. Antoine _______________________________________________ cdi-dev mailing list cdi-dev(a)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. _______________________________________________ cdi-dev mailing list cdi-dev(a)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.

We should be careful with making the payload imutable. I know of several applications (and companies) that change the payload to send some information back to to the event producer. We shouldn't break these apps, if we can solve it in a different way. -- *Thorben Janssen* @thjanssen123 <https://twitter.com/thjanssen123> www.thoughts-on-java.org 2014-12-16 18:46 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > > Hi Antoine, > > why isn't it portable? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-16 18:39 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: > > I don’t think it’s specified. As objects are, by default in Java, > mutable, I > > would assume that payloads are implicitly mutable. > > > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand < > antoine(a)sabot-durand.net&gt; > > wrote: > > > > Hi guys, > > > > > > Always working on Async event concept and discussion around mutable > > payloads. I was looking where in the spec we specified the fact that > fired > > payload are mutable. I red-read chapter 10 > > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and > didn’t > > found. I also browsed JIRA and TCK to find any ref to this feature and > found > > nothing. On the other hand it is not specified that payload should be > > immutable ;) > > > > I’d be happy if some of you could have a look and see if I missed > something. > > > > If I’m not wrong, the mutable payload we (including myself) advertise > in CDI > > is a non portable feature (I’m the firs surprised here). So I propose > that : > > > > 1) We decide to write something in the specification about allowing or > > forbidding it (I know some people not happy with this mix between > observer > > and visitor pattern) > > 1bis) Should we decide to forbid it by default, we should provide an > > alternative mode to allow people using this unspecified feature > > 2) Forbid it for fireAsync() > > > > > > Thanks for your feedback and your correction if I missed the feature in > the > > spec. > > > > Antoine > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)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. > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)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. > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)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. > _______________________________________________ cdi-dev mailing list cdi-dev(a)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.

(Pete) I don’t think it’s specified. As objects are, by default in Java, mutable, I would assume that payloads are implicitly mutable.

(Romain) why isn't it portable?

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

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(a)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.

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(a)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.

Same here. For instance we use mutable events to collect data. Just checked EJB 3.1 spec @Asynchronous regarding parameter immutability: As far I can tell it's not defined either. Jens On 16 Dec 2014, at 19:22, Thorben Janssen <thjanssen123(a)gmail.com&gt; wrote: We should be careful with making the payload imutable. I know of several applications (and companies) that change the payload to send some information back to to the event producer. We shouldn't break these apps, if we can solve it in a different way. -- Thorben Janssen @thjanssen123 www.thoughts-on-java.org 2014-12-16 18:46 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > > Hi Antoine, > > why isn't it portable? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-16 18:39 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: > > I don’t think it’s specified. As objects are, by default in Java, > > mutable, I > > would assume that payloads are implicitly mutable. > > > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand > > <antoine(a)sabot-durand.net&gt; > > wrote: > > > > Hi guys, > > > > > > Always working on Async event concept and discussion around mutable > > payloads. I was looking where in the spec we specified the fact that > > fired > > payload are mutable. I red-read chapter 10 > > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and > > didn’t > > found. I also browsed JIRA and TCK to find any ref to this feature and > > found > > nothing. On the other hand it is not specified that payload should be > > immutable ;) > > > > I’d be happy if some of you could have a look and see if I missed > > something. > > > > If I’m not wrong, the mutable payload we (including myself) advertise in > > CDI > > is a non portable feature (I’m the firs surprised here). So I propose > > that : > > > > 1) We decide to write something in the specification about allowing or > > forbidding it (I know some people not happy with this mix between > > observer > > and visitor pattern) > > 1bis) Should we decide to forbid it by default, we should provide an > > alternative mode to allow people using this unspecified feature > > 2) Forbid it for fireAsync() > > > > > > Thanks for your feedback and your correction if I missed the feature in > > the > > spec. > > > > Antoine > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)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. > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)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. > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)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. _______________________________________________ cdi-dev mailing list cdi-dev(a)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. _______________________________________________ cdi-dev mailing list cdi-dev(a)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.