Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing annotation literal in @Asynchronous annotation #176

Open
arjantijms opened this issue Feb 14, 2022 · 5 comments
Open

Missing annotation literal in @Asynchronous annotation #176

arjantijms opened this issue Feb 14, 2022 · 5 comments
Labels
good first issue Good for newcomers
Milestone

Comments

@arjantijms
Copy link
Contributor

It's general a good practice to add annotation literals to annotations that are used in CDI environments. We forgot these for the Faces 2.3 spec, and got quite a bit of feedback about those.

We added them in 4.0 as per e.g. this example:

https://github.com/eclipse-ee4j/mojarra/blob/master/impl/src/main/java/jakarta/faces/annotation/ApplicationMap.java#L52

Would be good for Concurrency to do the same.

@smillidge
Copy link
Contributor

What's the thinking behind it? Would be good to know to understand whether to push to get in this release?

@arjantijms
Copy link
Contributor Author

Annotation literals are essential when adding annotations programmatically to beans in CDI. This is the exact reason why all CDI's own annotations (where applicable) have literals.

Omission of literals in annotations is still one of the reasons why the programmatic API in CDI feels sub-par, hence why, in principle, all annotations intended to be used in a CDI environment should have them.

@njr-11
Copy link
Contributor

njr-11 commented Feb 17, 2022

Adding the annotation programmatically seems like a more obscure scenario for @Asynchronous given that the asynchronous method implementation really ought to have awareness of itself being used as an asynchronous method. (It must follow specific patterns in terms of either returning a completion stage that is different from the one the caller receives or otherwise obtaining the resulting completion stage from the Asynchronous API itself which will only ever work if running as an asynchronous method). I'd be fine to add the literal for these cases, but it doesn't seem like a necessity for 3.0, and is something that could be added on in 3.1.

@arjantijms
Copy link
Contributor Author

Adding the annotation programmatically seems like a more obscure scenario for @asynchronous given that the asynchronous method implementation really ought to have awareness of itself being used as an asynchronous method.

I hear you, though it's perhaps less obscure for when you translate between the give or take 7 existing @Asynchronous annotations.

@arjantijms
Copy link
Contributor Author

p.s. annotation literals are not just for adding them programmatically, you also use them for look-ups.

@smillidge smillidge added this to the 3.1 milestone May 19, 2022
@smillidge smillidge added the good first issue Good for newcomers label Feb 8, 2023
@KyleAure KyleAure modified the milestones: 3.1.0, 3.2.0 Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants