improve specification of InjectionPoint
#931
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
I will submit a TCK PR in the next few days, but the spec text should be done IMHO. |
Ladicek
changed the title
InjectionPoint
Member
Author
|
For the record, I'm not entirely sure if this perhaps doesn't somehow interact with passivation. I looked at the relevant part of the spec and what implementations do and didn't find anything obvious, but I admittedly don't know much about the topic, so I might be missing something. |
Ladicek
force-pushed
the
improve-injection-point
branch
2 times, most recently
from
828fba5 to
cf48a70
Compare
Azquelt
reviewed
Feb 2, 2026
Member
Azquelt
left a comment
Azquelt
left a comment
There was a problem hiding this comment.
Other than the comments, this looks good to me.
Comment on lines
26
to
28
| * An initial required type of the {@code Instance} is {@code java.lang.Object} and there are | ||
| * initially no required qualifiers. If no qualifier is passed to {@code Instance.select()}, | ||
| * there is one required qualifier: {@code @Default}. |
Member
There was a problem hiding this comment.
Suggested change
| * An initial required type of the {@code Instance} is {@code java.lang.Object} and there are | |
| * initially no required qualifiers. If no qualifier is passed to {@code Instance.select()}, | |
| * there is one required qualifier: {@code @Default}. | |
| * The initial required type of the {@code Instance} is {@code java.lang.Object} and there are | |
| * initially no required qualifiers. If no qualifier is passed to {@code Instance.select()}, | |
| * there is one required qualifier: {@code @Default}. |
Also in other places where this text is used.
Member
Author
There was a problem hiding this comment.
Makes sense, will change.
manovotn
reviewed
Feb 2, 2026
|
|
||
| `CDI` implements `jakarta.enterprise.inject.Instance` and therefore might be used to perform programmatic lookup as defined in <<dynamic_lookup>>. | ||
| If no qualifier is passed to `CDI.select()` method, the `@Default` qualifier is assumed. | ||
| An initial required type of the `Instance` is `java.lang.Object` and there are initially no required qualifiers. |
Contributor
There was a problem hiding this comment.
Suggested change
| An initial required type of the `Instance` is `java.lang.Object` and there are initially no required qualifiers. | |
| Initially, the required type is `java.lang.Object` and there are no required qualifiers. |
Just trying to avoid saying "initial" twice in one sentence.
The specification of `InjectionPoint` contains a small number of holes that are arguably corner cases, but they should be specified nevertheless. The most important one is dynamically obtained instance (`Instance`) that is not injected. This can happen through several means: - `BeanContainer.createInstance()` - `CDI.current()` - `SeContainer` The specification didn't say what multiple methods should return in this case; it didn't even explicitly say that an `InjectionPoint` should exist and indeed it doesn't on one existing implementation. With this commit, the behavior is clear: an `InjectionPoint` must exist and all methods besides `getType()` and `getQualifiers()` return `null` (or `false`). Further, it is not clear what the `getBean()` method should return in case of a synthetic bean. Such injection points should, in portable extensions, be created using `BeanManager.createInjectionPoint()`, but these methods do not take a `Bean` and cannot figure out on their own which bean is the injection point created for. So on all existing implementations that support portable extensions, this method returns `null`. This is now explicitly allowed. Finally, this commit allows synthetic beans to have injection points that do not correspond to a field or parameter. Currently, such injection points should never exist, because injection points of synthetic beans should be created using `BeanManager.createInjectionPoint()`, but it is not hard to imagine people implementing `InjectionPoint` manually and returning `null` from `getMember()` or `getAnnotated()`. We also plan to introduce specifying injection points for synthetic beans in the build compatible extensions API, where one is supposed to only specify the required type and required qualifiers and it is entirely conceivable that no field or parameter can possibly be determined upfront. So an `InjectionPoint` of a synthetic bean is now explicitly allowed to return `null` from the `getMember()` and `getAnnotated()` methods.
…not injected An `Instance` that is not injected (or, in other words, that is obtained programmatically) has initially a required type of `java.lang.Object` and has initially no requried qualifiers. If no qualifier is passed to `Instance.select()`, there is one required qualifier: `@Default`. This has all been previously specified implicitly or using slightly imprecise wording. This commit is more explicit and more precise.
Ladicek
force-pushed
the
improve-injection-point
branch
from
cf48a70 to
c9a8544
Compare
Azquelt
approved these changes
Feb 3, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The specification of
InjectionPointcontains a small number of holes that are arguably corner cases, but they should be specified nevertheless.The most important one is dynamically obtained instance (
Instance) that is not injected. This can happen through several means:BeanContainer.createInstance()CDI.current()SeContainerThe specification didn't say what multiple methods should return in this case; it didn't even explicitly say that an
InjectionPointshould exist and indeed it doesn't on one existing implementation. With this commit, the behavior is clear: anInjectionPointmust exist and all methods besidesgetType()andgetQualifiers()returnnull(orfalse).Further, it is not clear what the
getBean()method should return in case of a synthetic bean. Such injection points should, in portable extensions, be created usingBeanManager.createInjectionPoint(), but these methods do not take aBeanand cannot figure out on their own which bean is the injection point created for. So on all existing implementations that support portable extensions, this method returnsnull. This is now explicitly allowed.Finally, this commit allows synthetic beans to have injection points that do not correspond to a field or parameter. Currently, such injection points should never exist, because injection points of synthetic beans should be created using
BeanManager.createInjectionPoint(), but it is not hard to imagine people implementingInjectionPointmanually and returningnullfromgetMember()orgetAnnotated(). We also plan to introduce specifying injection points for synthetic beans in the build compatible extensions API, where one is supposed to only specify the required type and required qualifiers and it is entirely conceivable that no field or parameter can possibly be determined upfront. So anInjectionPointof a synthetic bean is now explicitly allowed to returnnullfrom thegetMember()andgetAnnotated()methods.Fixes #779
Related to #833