Clarify ambiguity resolution during dynamic lookup

[Ladicek]

This attempts to clarify the current specification of Instance.iterator(),
Instance.stream() and Instance.handles() in presence of dependency
ambiguity. My understanding is that this modification is what has always
been intended and how current implementations already work.

[Ladicek]

Also the ambiguity resolution process is described in a way that it always, unconditionally, eliminates all non-alternative beans -- which would technically mean that dynamic lookup of an ambiguous dependency for which no alternative exists should always end up empty. Which is clearly not what happens in existing implementations :-)

[mkouba]

Also the ambiguity resolution process is described in a way that it always, unconditionally, eliminates all non-alternative beans -- which would technically mean that dynamic lookup of an ambiguous dependency for which no alternative exists should always end up empty. Which is clearly not what happens in existing implementations :-)

I tend to disagree. The spec is clear that "When an ambiguous dependency exists, the container attempts to resolve the ambiguity."

[manovotn]

Also the ambiguity resolution process is described in a way that it always, unconditionally, eliminates all non-alternative beans -- which would technically mean that dynamic lookup of an ambiguous dependency for which no alternative exists should always end up empty.

I think you are reading too much into it :)
The container attempts to resolve it but if you were to observe the state after attempted ambiguity removal which failed, you wouldn't be able to tell the difference between ambig. and unsatis. dependency since the set might just be empty.
If the resolution fails, you simply get to view all candidate beans that are valid picks for given type/qualifier combination

[Ladicek]

Also the ambiguity resolution process is described in a way that it always, unconditionally, eliminates all non-alternative beans -- which would technically mean that dynamic lookup of an ambiguous dependency for which no alternative exists should always end up empty. Which is clearly not what happens in existing implementations :-)

I tend to disagree. The spec is clear that "When an ambiguous dependency exists, the container attempts to resolve the ambiguity."

Exactly! And the first step of the ambiguity resolution process is elimination of non-alternative beans. If ambiguity exists but no eligible bean is an alternative, the ambiguity resolution process ends with no candidate.

I'm trying to describe Instance.iterator() in terms of the ambiguity resolution process, but its wording isn't exactly friendly :-)

I think you are reading too much into it :) The container attempts to resolve it but if you were to observe the state after attempted ambiguity removal which failed, you wouldn't be able to tell the difference between ambig. and unsatis. dependency since the set might just be empty.

Right. As a spec lawyer wannabe, I still find that deeply disturbing 😆

If the resolution fails, you simply get to view all candidate beans that are valid picks for given type/qualifier combination

No, you get all the eligible beans after the elimination process, that's what we investigated yesterday. (Unless all beans are eliminated :-) )

[mkouba]

If ambiguity exists but no eligible bean is an alternative, the ambiguity resolution process ends with no candidate.

Not really, the ambiguity resolution process ends with an unresolvable dependency ;-). But yes, the behavior is undefined.

[manovotn]

No, you get all the eligible beans after the elimination process, that's what we investigated yesterday. (Unless all beans are eliminated :-) )

Yes, that's what I tried to describe but worded it imprecisely.

Right. As a spec lawyer wannabe, I still find that deeply disturbing

Uff, you'd have to then make the spec even harder to read and expand on what's eligible bean while talking resolution process and then go in depth on describing the various outcomes you can have when interacting with Instance. Which might just bring more confusion than clarity in the end :)

[Ladicek]

No, you get all the eligible beans after the elimination process, that's what we investigated yesterday. (Unless all beans are eliminated :-) )

Yes, that's what I tried to describe but worded it imprecisely.

This is important though ;-) For example, the specification of Instance.handles() currently says that it must "allow iterating over contextual reference handles for all beans that have the required type and required qualifiers and are eligible for injection." Though I believe handles() should really hand out handles to the same set of beans as iterator() or stream(), right?

Uff, you'd have to then make the spec even harder to read and expand on what's eligible bean while talking resolution process and then go in depth on describing the various outcomes you can have when interacting with Instance. Which might just bring more confusion than clarity in the end :)

I actually think I can fix that by adding one more sentence to the description of Instance.iterator(), I'll update this PR in a bit.

[manovotn]

Had some off-list discussion with Ladislav and I think this state of PR is fine.

Just for the sake of clarity, this doesn't change any of current behaviors, it is purely a clarification of existing state.

[Ladicek]

Thanks! I'll check the TCK and possibly submit a PR there, then.

[manovotn]

Going to merge this one so that it doesn't linger.

I'll check the TCK and possibly submit a PR there, then.

@Ladicek if there is any PR needed on TCK side, please create a tracking issue so that it is not forgotten.