Only if you upcast and for _some_ Lambdas. Lambdas can create multiple different forms of bytecode.
In our case it did create an inner class of the Extension which then still gets referenced as $0. So even if the Lambda implements Serializable it still references back to the Extension which is not Serializable. LieGrue, strub > Am 08.08.2017 um 13:06 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > @Mark: lambda are serializable (java.lang.invoke.SerializedLambda) > > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory > > 2017-08-08 13:03 GMT+02:00 John D. Ament <johndam...@apache.org>: > On the subject of serializable. We fail one of the comments in the MP Spec > (but not in the TCK!) our injected Config class is *not* serializable. But > for that to work, all config sources and all converters must be serializable. > > > On Tue, Aug 8, 2017 at 6:57 AM Mark Struberg <strub...@yahoo.de> wrote: > Another thing I noticed: > > While using a Lambda as impl for Provider is very elegant, it still misses an > important functionality: it is not Serializable, and thus injecting a > @ConfigProperty Provider<String> into a @SessionScoped bean would blow up at > runtime. > > > LieGrue, > strub > > > > Am 08.08.2017 um 12:35 schrieb Mark Struberg <strub...@yahoo.de>: > > > > I fear that's exactly not possible. CDI resolves with type + qualifier. > > Since the type is not unique (mulitple Provider<String>) you would need to > > make the Qualifier unique. Means for each of them you need to dynamically > > create a new binding ConfigProperty Implementation. > > There are 2 problems: > > a.) I have no clue how you can dynamically remove the @Nonbinding from the > > ConfigProperty annotation. > > b.) you have to register tons of such qualifiers, which makes the whole > > resolving slower again. You just moved the effort from the Bean#create to > > BeanManager#getBeans, that's all > > > > LieGrue, > > strub > > > >> Am 08.08.2017 um 12:16 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > >> > >> b.) the default naming (name="") would break it anyway. You again would > >> need to create dynamic qualifiers for each of those injection points. > >> > >> Not true since you handle it in the extension precomputing it > >> > > > >