[cdi-dev] Adding Lambdas as CDI beans

Romain Manni-Bucau rmannibucau at gmail.com
Sat Oct 17 12:57:24 EDT 2015


2015-10-17 18:54 GMT+02:00 Sven Linstaedt <sven.linstaedt at 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 at 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 at 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 at 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 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.
>>
>> _______________________________________________
>> 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.
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151017/e602f92e/attachment.html 


More information about the cdi-dev mailing list