Language model only returns runtime-retained annotations in build compatible extensions #554
Conversation
…patible extensions The language model API itself doesn't specify what annotations are accessible. In the CDI context, only runtime-retained annotations make sense, because that's the only way all implementation strategies can be consistent. That's because: - purely runtime implementations, such as Weld, only have access to runtime-retained annotations; - bytecode-based implementations, such as ArC, only have access to runtime-retained and class-retained annotations, but don't have access to source-retained annotations; - annotation processing-based implementations, such as ODI, have access to all annotations. An alternative would be to specify that the language model _always_ returns only runtime-retained annotations. That would be just fine strictly from the CDI perspective, but unforeseen cases may exist where the language model API would be useful, but nothing would prevent providing access to class-retained or even source-retained annotations. Hence, I believe it is better to make the restriction on the CDI level, and not on the language model level.
|
FTR the support for |
|
I think CDI is just built around runtime-retained annotations and I don't see a reason why (or even a way how) to change that. It's true that Jandex ignores class-retained annotations right now (in version 2.x), and hence ArC does too, so my statement above is factually incorrect (until Jandex 3.0). But it's correct in principle :-) |
|
Since we process the source those annotations are visible and we have methods in our metadata to differentiate whether an annotation is source or runtime. It would add overhead to filter out these annotations, I am not sure if there is any value if doing so. However I have no issue with the wording of only supporting runtime retention |
|
My reasoning is that different CDI implementations should all present the same view of the world -- in this case, the same set of annotations. This happened to me recently: I created an annotation, ran a test with it in the development version of Jandex and everything was fine. So I backported the test to Jandex 2.4, and it started failing for no obvious reason. Took me a little while to realize that the annotation didn't have a I'd like to avoid similar situation between different CDI implementations. |
|
I'm not sure we reached consensus on this, so just want to say that I'm open to changes. While I'd obviously prefer to specify it the way this PR did, I could probably be persuaded to softening the requirement to something like:
|
The language model API itself doesn't specify what annotations are
accessible. In the CDI context, only runtime-retained annotations
make sense, because that's the only way all implementation strategies
can be consistent. That's because:
to runtime-retained annotations;
to runtime-retained and class-retained annotations, but don't
have access to source-retained annotations;
access to all annotations.
An alternative would be to specify that the language model always
returns only runtime-retained annotations. That would be just fine
strictly from the CDI perspective, but unforeseen cases may exist
where the language model API would be useful, but nothing would
prevent providing access to class-retained or even source-retained
annotations. Hence, I believe it is better to make the restriction
on the CDI level, and not on the language model level.