Support for jakarta annotations
See original GitHub issueDo you have any time estimations for supporting jakarta.* annotations? We want to migrate to Jersey 3 but it’s impossible because GuiceFilter
implements javax.servlet.Filter
. Another problem is #1383.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:7
- Comments:12 (3 by maintainers)
Top Results From Across the Web
Jakarta Annotations
The PostConstruct annotation is used on a method that needs to be executed after dependency injection is done to perform any initialization.
Read more >Jakarta Annotations - Eclipse Foundation
Jakarta Annotations ™ defines a collection of annotations representing common semantic concepts that enable a declarative style of programming that applies ...
Read more >Support for Jakarta EE 9 (annotations and interfaces ... - GitHub
Our upcoming Spring Framework 5.3 generation will be compatible with Java 8+ and based on the javax-namespaced EE 8 APIs still, for immediate...
Read more >Jakarta Annotations Reference (v6.0) - DataNucleus
Jakarta Persistence provides the ability to use annotations to define the persistence of entities, and DataNucleus Jakarta supports Jakarta, ...
Read more >Support jakarta Nullability annotations : KT-54205
Support jakarta Nullability annotations · In short, javax.annotation. · This is a smaller request than https://youtrack.jetbrains.com/issue/KT-54081/Support- ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
#1383
Ugh, what a horrible mess. Silly IBM.
The proposed pull request is both invasive (on the core guice side), and a huge pit of code duplication (on the servlet extension side).
For servlet, I honestly think the best outcome is for someone else to create and host it. I’d be happy to point to it from any “official” docs. But us bundling it seems like a bad idea. The existing servlet extension already has bugs, and we don’t really maintain it except for keeping it compiling. Someone could probably fork it and make it much better already. I’m loathe to copy/paste and search/replace a large swathe of code, especially when it will have zero ongoing usages that we can validate.
As for the annotation/provider support… it adds a bunch of SPI classes and API methods. It’s not all that appealing.
@mcculls – what are y’all doing with Maven? Is this impacting you?
Let me talk to a few folks internally and see what the deal is. I imagine this impacts Dagger too?
What a gross situation.