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.
> 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
> > 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