[cdi-dev] Adding Lambdas as CDI beans
Carlo de Wolf
cdewolf at redhat.com
Mon Oct 19 14:20:22 EDT 2015
There is a cave-at serializing a lambda, the capturing class must be the
exact same on both ends.
See also
https://github.com/wolfc/jboss-beach-lambchops/blob/d4677021899dc945c3acb1b7eb73ff7cc901b223/client/src/main/java/org/jboss/beach/lambchops/client/Client.java#L111
In my case I just serialize the capturing class as well and ensure the
other end has a defining class loader. :-)
Carlo
On 10/17/2015 06:57 PM, Romain Manni-Bucau wrote:
>
> 2015-10-17 18:54 GMT+02:00 Sven Linstaedt <sven.linstaedt at gmail.com
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/20151019/7bf93947/attachment-0001.html
More information about the cdi-dev
mailing list