Just one question: Who is on charge and is able of managing this unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. when dealing with closures)? Functional programming and DI seem to be somehow disjunct in this case. E.g. manually setting up observers seem to better fit extension than normal application code. On the other side, specifying producer methods or fields, that are injectable and return lambda expressions seems to be a no brainier for CDI, is not it? As long as they are not scoped in a serializable context. Have a nice weekend Sven -- sent by phone Am 17.10.2015 um 11:06 schrieb David Blevins <david.blevins(a)gmail.com&gt;: In brainstorming mode about fun that could be made possible with Java 8 and Java EE. Question in my mind is: is there some way we could make it possible for Lambdas or Method Refs to be CDI beans? It goes against the grain obviously as CDI creation is very much a “Don’t call us, we’ll call you” kind of thing. The VM dynamically creates a wrapper object around the Lambda or method reference and it implements the given interface. To make it work, there would need to be some non-producer method way of saying “put this thing in the context with these qualifiers”. Imagine a method somewhere that would allow you to: public <T> void addObserver(java.util.function.Consumer<T> observer, Annotation... qualifiers); Then you could take advantage as follows: final List<URI> uris = new ArrayList<>(); // @Observes URI addObserver((Consumer<URI>) uris::add); // @Observes Thread addObserver(Runtime.getRuntime()::addShutdownHook); // @Observes Runnable addObserver((Consumer<Runnable>) Executors.newFixedThreadPool(3)::submit); // @Observes URI addObserver((Consumer<URI>) System.out::println, new AnnotationLiteral<Fine>() { }); // @Observes Handler final Logger logger = Logger.getLogger("somewhere"); addObserver(logger::addHandler); // add handlers via event // @Observes @Fine String addObserver((Consumer<String>) logger::fine, new AnnotationLiteral<Fine>() {}); } -David -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com _______________________________________________ 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.

Am 17.10.2015 um 15:03 schrieb John D. Ament <john.d.ament(a)gmail.com&gt;: Sven, I'm a little curious, why do they need to avoid serializable contexts? In all honesty, I use app scoped functions, predicates in my code, at least in a couple of places. Lambdas are specifically meant for operations, not data, so they should be in a highly reusable scope (in my opinion at least). On the flip side, I have a hard time justifying needing to provide injectable beans for lambdas since good encapsulation should indicate they're only used in a single spot. John On Sat, Oct 17, 2015 at 7:51 AM Sven Linstaedt <sven.linstaedt(a)gmail.com&gt; wrote: > Just one question: Who is on charge and is able of managing this unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. when dealing with closures)? > > Functional programming and DI seem to be somehow disjunct in this case. E.g. manually setting up observers seem to better fit extension than normal application code. > > On the other side, specifying producer methods or fields, that are injectable and return lambda expressions seems to be a no brainier for CDI, is not it? As long as they are not scoped in a serializable context. > > Have a nice weekend > Sven > > -- sent by phone > >> Am 17.10.2015 um 11:06 schrieb David Blevins <david.blevins(a)gmail.com&gt;: >> >> In brainstorming mode about fun that could be made possible with Java 8 and Java EE. >> >> Question in my mind is: is there some way we could make it possible for Lambdas or Method Refs to be CDI beans? >> >> It goes against the grain obviously as CDI creation is very much a “Don’t call us, we’ll call you” kind of thing. The VM dynamically creates a wrapper object around the Lambda or method reference and it implements the given interface. >> >> To make it work, there would need to be some non-producer method way of saying “put this thing in the context with these qualifiers”. >> >> Imagine a method somewhere that would allow you to: >> >> public <T> void addObserver(java.util.function.Consumer<T> observer, Annotation... qualifiers); >> >> >> Then you could take advantage as follows: >> >> final List<URI> uris = new ArrayList<>(); >> // @Observes URI >> addObserver((Consumer<URI>) uris::add); >> >> // @Observes Thread >> addObserver(Runtime.getRuntime()::addShutdownHook); >> >> // @Observes Runnable >> addObserver((Consumer<Runnable>) Executors.newFixedThreadPool(3)::submit); >> >> // @Observes URI >> addObserver((Consumer<URI>) System.out::println, new AnnotationLiteral<Fine>() { >> }); >> >> // @Observes Handler >> final Logger logger = Logger.getLogger("somewhere"); >> addObserver(logger::addHandler); // add handlers via event >> >> // @Observes @Fine String >> addObserver((Consumer<String>) logger::fine, new AnnotationLiteral<Fine>() {}); >> } >> >> >> >> -David >> >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >> _______________________________________________ >> 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.

2015-10-17 18:54 GMT+02:00 Sven Linstaedt <sven.linstaedt(a)gmail.com <mailto:sven.linstaedt@gmail.com>>: Hi John most, if not all Java 8 lambda types are not serializable afaik (sure, one can specify custom serializable lambdas, but I guess this happens rather rarely), so assigning a lambda typed bean a serializable context will probably always cause problems. Even the lamda type itself is serializable, it does not mean it's closure is. Even though application scoped lambda beans are in general no problem at all, most other contexts are. So the question is, whether to allow lambda typed bean to have any serializable scope at all. java.lang.invoke.SerializedLambda is done for that so should be Don't get me wrong. I am a huge fan of Java 8 and functional programming in general, but I think FP's way of expressive design somehow collides with CDI's rather declarative style. At least for non-SPI code. Same here, I think a good API should deserve it. Being able to bind in an extension or through an event not needed a SPI file a lambda would be great but I think we are out of CDI - as backbone - scope there. Maybe doing a proto using custom events can help to play with it and see what we can do of it. Best regards Sven -- sent by phone Am 17.10.2015 um 15:03 schrieb John D. Ament <john.d.ament(a)gmail.com <mailto:john.d.ament@gmail.com>>: > Sven, > > I'm a little curious, why do they need to avoid serializable > contexts? In all honesty, I use app scoped functions, predicates > in my code, at least in a couple of places. Lambdas are > specifically meant for operations, not data, so they should be in > a highly reusable scope (in my opinion at least). > > On the flip side, I have a hard time justifying needing to > provide injectable beans for lambdas since good encapsulation > should indicate they're only used in a single spot. > > John > > On Sat, Oct 17, 2015 at 7:51 AM Sven Linstaedt > <sven.linstaedt(a)gmail.com <mailto:sven.linstaedt@gmail.com>> wrote: > > Just one question: Who is on charge and is able of managing > this unmanaged instances, e.g. lifecycle, serialization, > concurrency (e.g. when dealing with closures)? > > Functional programming and DI seem to be somehow disjunct in > this case. E.g. manually setting up observers seem to better > fit extension than normal application code. > > On the other side, specifying producer methods or fields, > that are injectable and return lambda expressions seems to be > a no brainier for CDI, is not it? As long as they are not > scoped in a serializable context. > > Have a nice weekend > Sven > > -- sent by phone > > Am 17.10.2015 um 11:06 schrieb David Blevins > <david.blevins(a)gmail.com <mailto:david.blevins@gmail.com>>: > >> In brainstorming mode about fun that could be made possible >> with Java 8 and Java EE. >> >> Question in my mind is: is there some way we could make it >> possible for Lambdas or Method Refs to be CDI beans? >> >> It goes against the grain obviously as CDI creation is very >> much a “Don’t call us, we’ll call you” kind of thing. The >> VM dynamically creates a wrapper object around the Lambda or >> method reference and it implements the given interface. >> >> To make it work, there would need to be some non-producer >> method way of saying “put this thing in the context with >> these qualifiers”. >> >> Imagine a method somewhere that would allow you to: >> >> public <T> void >> addObserver(java.util.function.Consumer<T> observer, >> Annotation... qualifiers); >> >> >> Then you could take advantage as follows: >> >> final List<URI> uris = new ArrayList<>(); >> // @Observes URI >> addObserver((Consumer<URI>) uris::add); >> >> // @Observes Thread >> addObserver(Runtime.getRuntime()::addShutdownHook); >> >> // @Observes Runnable >> addObserver((Consumer<Runnable>) >> Executors.newFixedThreadPool(3)::submit); >> >> // @Observes URI >> addObserver((Consumer<URI>) System.out::println, new >> AnnotationLiteral<Fine>() { >> }); >> >> // @Observes Handler >> final Logger logger = Logger.getLogger("somewhere"); >> addObserver(logger::addHandler); // add handlers via event >> >> // @Observes @Fine String >> addObserver((Consumer<String>) logger::fine, new >> AnnotationLiteral<Fine>() {}); >> } >> >> >> >> -David >> >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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.

In CDI 2.0 we propose to support lambdas in the bean builder API - currently available as a weld experimental feature in AfterBeanDiscovery and Weld SE - see also [1] and [2]. For observers a similar builder might be useful. Martin [1] http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api [2] https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/o... Dne 17.10.2015 v 13:51 Sven Linstaedt napsal(a): > Just one question: Who is on charge and is able of managing this > unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g. > when dealing with closures)? > > Functional programming and DI seem to be somehow disjunct in this case. > E.g. manually setting up observers seem to better fit extension than > normal application code. > > On the other side, specifying producer methods or fields, that are > injectable and return lambda expressions seems to be a no brainier for > CDI, is not it? As long as they are not scoped in a serializable context. > > Have a nice weekend > Sven > > -- sent by phone > > Am 17.10.2015 um 11:06 schrieb David Blevins <david.blevins(a)gmail.com > <mailto:david.blevins@gmail.com>>: > >> In brainstorming mode about fun that could be made possible with Java >> 8 and Java EE. >> >> Question in my mind is: is there some way we could make it possible >> for Lambdas or Method Refs to be CDI beans? >> >> It goes against the grain obviously as CDI creation is very much a >> “Don’t call us, we’ll call you” kind of thing. The VM dynamically >> creates a wrapper object around the Lambda or method reference and it >> implements the given interface. >> >> To make it work, there would need to be some non-producer method way >> of saying “put this thing in the context with these qualifiers”. >> >> Imagine a method somewhere that would allow you to: >> >> public <T> void addObserver(java.util.function.Consumer<T> >> observer, Annotation... qualifiers); >> >> >> Then you could take advantage as follows: >> >> final List<URI> uris = new ArrayList<>(); >> // @Observes URI >> addObserver((Consumer<URI>) uris::add); >> >> // @Observes Thread >> addObserver(Runtime.getRuntime()::addShutdownHook); >> >> // @Observes Runnable >> addObserver((Consumer<Runnable>) >> Executors.newFixedThreadPool(3)::submit); >> >> // @Observes URI >> addObserver((Consumer<URI>) System.out::println, new >> AnnotationLiteral<Fine>() { >> }); >> >> // @Observes Handler >> final Logger logger = Logger.getLogger("somewhere"); >> addObserver(logger::addHandler); // add handlers via event >> >> // @Observes @Fine String >> addObserver((Consumer<String>) logger::fine, new >> AnnotationLiteral<Fine>() {}); >> } >> >> >> >> -David >> >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic _______________________________________________ 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.

Dne 19.10.2015 v 08:44 Romain Manni-Bucau napsal(a): > would be super cool to not have to write an extension for that, cant we > use applicationscope init event or an prioritized event at this moment - > avoiding the spi is a must for end user usage IMO? > Not possible, it's too late. ApplicationScoped init event is fired after the deployment validation. Well, maybe it's not that explicitly defined but it wouldn't make much sense to fire it before validation as you have to resolve a set of validated observers, usually declared on validated beans.

> > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-10-19 8:40 GMT+02:00 Martin Kouba <mkouba(a)redhat.com > <mailto:mkouba@redhat.com>>: > > In CDI 2.0 we propose to support lambdas in the bean builder API - > currently available as a weld experimental feature in > AfterBeanDiscovery > and Weld SE - see also [1] and [2]. > > For observers a similar builder might be useful. > > Martin > > [1] > > http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api > > [2] > > https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/o... > > > > Dne 17.10.2015 v 13:51 Sven Linstaedt napsal(a): > > Just one question: Who is on charge and is able of managing this > > unmanaged instances, e.g. lifecycle, serialization, concurrency > (e.g. > > when dealing with closures)? > > > > Functional programming and DI seem to be somehow disjunct in this > case. > > E.g. manually setting up observers seem to better fit extension than > > normal application code. > > > > On the other side, specifying producer methods or fields, that are > > injectable and return lambda expressions seems to be a no brainier > for > > CDI, is not it? As long as they are not scoped in a serializable > context. > > > > Have a nice weekend > > Sven > > > > -- sent by phone > > > > Am 17.10.2015 um 11:06 schrieb David Blevins < > david.blevins(a)gmail.com <mailto:david.blevins@gmail.com> > > <mailto:david.blevins@gmail.com <mailto:david.blevins@gmail.com > >>>: > > > > >> In brainstorming mode about fun that could be made possible with > Java > >> 8 and Java EE. > >> > >> Question in my mind is: is there some way we could make it > possible > >> for Lambdas or Method Refs to be CDI beans? > >> > >> It goes against the grain obviously as CDI creation is very much a > >> “Don’t call us, we’ll call you” kind of thing. The VM dynamically > >> creates a wrapper object around the Lambda or method reference > and it > >> implements the given interface. > >> > >> To make it work, there would need to be some non-producer method > way > >> of saying “put this thing in the context with these qualifiers”. > >> > >> Imagine a method somewhere that would allow you to: > >> > >> public <T> void addObserver(java.util.function.Consumer<T> > >> observer, Annotation... qualifiers); > >> > >> > >> Then you could take advantage as follows: > >> > >> final List<URI> uris = new ArrayList<>(); > >> // @Observes URI > >> addObserver((Consumer<URI>) uris::add); > >> > >> // @Observes Thread > >> addObserver(Runtime.getRuntime()::addShutdownHook); > >> > >> // @Observes Runnable > >> addObserver((Consumer<Runnable>) > >> Executors.newFixedThreadPool(3)::submit); > >> > >> // @Observes URI > >> addObserver((Consumer<URI>) System.out::println, new > >> AnnotationLiteral<Fine>() { > >> }); > >> > >> // @Observes Handler > >> final Logger logger = Logger.getLogger("somewhere"); > >> addObserver(logger::addHandler); // add handlers via event > >> > >> // @Observes @Fine String > >> addObserver((Consumer<String>) logger::fine, new > >> AnnotationLiteral<Fine>() {}); > >> } > >> > >> > >> > >> -David > >> > >> > >> > >> -- > >> David Blevins > >> http://twitter.com/dblevins > >> http://www.tomitribe.com > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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 > &gt;cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. > > > -- Martin Kouba Software Engineer Red Hat, Czech Republic