JAVA-131: Proposed direction for resolution

OK, I am finally biting the bullet on this one!  I found something
in the spec that has caused me to reverse my previous position.
Section 9.17 (@Reference) says that an unwired reference of
multiplicity 0..1 is presented to the implementation code by the
SCA runtime as null, and an unwired reference of multiplicity 0..n
is presented as an empty array.

This implies that unwired references of multiplicity 0..n are
explicitly injected.  Unwired field references of multiplicity 0..1
don't need to be injected, because Java will provide a null value.
Unwired setter references of multiplicity 0..n are explicitly
injected.  For unwired setter references, whether or not to inject
will be decided by this issue.  Constructor references are never
0..1 or 0..n, so there will always be a non-null value for these.

It may be useful to summarize the valid combinations in a table:

                         0..1 unwired      0..n unwired

Field injection          not needed        empty array

Field reinjection           null           empty array

Setter injection             ?             empty array

Setter reinjection          null           empty array

The right-hand column is a model of consistency.  The left-hand
column is all over the map.  For simplicity and consistency,
I think we should put "null" all the way down the left-hand column.

Now let's consider callbacks.  I can't think of any good reason
why unwired callbacks should be treated differently from unwired
references.  A reasonable model is to think of callbacks as having:
  a) multiplicity 1..1 if all services of the component are
     bidirectional and have a callback interface that matches
     the callback field or setter
  b) multiplicity 0..1 if some but not all services of the
     component are bidirectional and have a callback interface
     that matches the callback field or setter
  c) multiplicity 0..0 if no services of the component are
     bidirectional and have a callback interface that matches
     the callback field or setter

We can simplify the number of combinations by saying that c) is an
error, as the callback field or setter could never be injected.
For a), a callback proxy is always injected.  For b), I think
we should be consistent with references and inject null into fields
or setters when there is no callback.  This is something of a
corner case, so performance overhead shouldn't be an issue.

At present, callbacks can't be constructor parameters.  I think
we should allow this for case a) but not for case b).  This is
consistent with references.

For properties with mustSupply=false, it's possible for no value
to be configured.  However, the Java implementation might have
set a default value in the code, so injecting null or an empty
array would wipe out the implementation's default value.
This would be a common source of errors, so we should say that
properties are only injected if they have a value configured
in the component type or component definition.  This is the
exact opposite of how we would treat unwired references, but
I think people will understand the reason for the difference.

Comments, questions?

   Simon