6:10 a.m.
Present
======
Pete Muir
Mark Struberg
Jozef Hartinger
Martin Kouba
Jason Porter
Joe Bergmark
Fabien Marsuad
Minor items
=========
Mark ran us through https://github.com/jboss/cdi/pull/58 and we agreed with his
approaches. These are principally clarifiactions.
Mark ran us through https://issues.jboss.org/browse/CDI-247 and we agreed that
Martin's proposal of using the default value, as defined by the JLS, could be injected
if a a producer returned null for a primitive type wrapper. This is a backwards compatible
change, as previously attempting to return null on such a producer resulted in a runtime
exception.
Action: Pete to review and apply pull requests
Multiple Annotated Types
====================
We then moved on to discuss https://issues.jboss.org/browse/CDI-58. This concerns whether
there can be greater than one annotated type per class instance in the JVM. Gavin intended
there should be, principally to support an XML configuration dialect, which could
introduce multiple versions of a class, each with a different qualifier. However, this is
not TCK tested, and implementations vary in how they support this.
We discussed that this makes an implementation considerably more complex (as there is no
easy way to uniquely identify an annotated type e.g. for serialization), and also is
pretty confusing for a user (as you now get multiple ProcessAnnotatedType events for each
class, making it hard to know which one you want to change).
We looked at alternative solutions, and concluded that if all use cases can be satisfied
by adding a new bean, rather than a new annotated type, we would like to explicitly
specify that there is only one annotated type per class instance. In CDI 1.1 it is already
much easier to add and manipulate beans from annotated types, so we believe that the
correct thing here is take this route.
Action: Pete to contact extension authoring groups, and verify that this approach will
work and have minimum impact on existing extensions
Visibility of container invoked methods
==============================
Currently the CDI specification does not limit the visibility of container invoked methods
(observers, producers, initializers). We propose that this should be limited to
non-private methods, as otherwise we run into extensive incompatibles with other specs
such as EJB, and VMs (such as IBM JDK). Furthermore, having the container invoke private
methods deliberately breaks the intended purpose of visibility in Java.
Action: Pete to propose change to spec
Lack of symmetry between AnnotatedType hierarchy and class hierarchy
========================================================
CDI exposes a flat (merged) annotated type hierarchy whilst Java specifies a hierarchical
model. We concluded this doesn't matter, as the identity of all elements on an
AnnotatedType is it's signature, which includes the declaring class. In most cases the
declaring class is not relevant, the only case in which it is, is injected private fields.
We believe the clearly specifying what makes up an AnnotatedType (public methods with
overrides resolved, public constructors, all fields) in addition to the addressing the
visibility issue will resolve this issue. We need to do this analysis taking into account
the inheritance rules specified in CDI and @Inject specs.
Action: Pete to draft up proposal