Support for jakarta annotations

[hejcz]

Do 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.

[kashike]

#1383

[hejcz]

#1383 mentions only jakarta.inject so I don't know if it adresses the same scope of changes.

[GedMarc]

You can also use
https://search.maven.org/artifact/com.guicedee.services/guice

which is a compiled guice (from master branch/5) with all references on jakarta -

[nsoft]

I have a "quickfix" support for this which was done by the ugly but expedient strategy of copying a bunch of classes into new packages and editing them, not guaranteed to work for everything, and I'm not committing maintaining it, but my Shiro/Guice integrated application seems to be running fine with it on Tomcat 10. https://github.com/nsoft/guice/commits/jakarta-servlet. guicedee is probably great, but if you have things other than your own code that depend on guice in your stack, it's not really an option. (shiro 1.8 hacked to use my fork of guice is here: https://github.com/nsoft/shiro/tree/SHIRO-814_1_8)

Posting these mostly to encourage the Guice maintainers to do something about this.

[onacit]

@GedMarc Check this out, yo.

[docent]

Bumping this for visibility. We have to recompile Guice in order to move to to the new jakarta.inject and jakarta.servlet packages. Not ideal...

[krisso-rtb]

Logback switched from javax.servlet-api to jakarta.servlet-api in version 1.4.0.
We have guice 5.1.0 which (still) doesn't have support for jakarta.servlet-api.
It basically means we're blocked with upgrading to the newer logback.

Could we somehow fix the World? 😄

[froque]

@krisso-rtb there is logback 1.3 to solve that problem https://logback.qos.ch/news.html

But your point remains, the lack of Jakarta support in Guice is a show stopper for us

[ben-manes]

@sameb could we get something simple and low effort to be forward compatible? Maybe a new extension, guice-jakarta-servlet, that forks the old one with the updated imports? I don't think the community is asking for much, just a little support so that we can update our http servlet engines (tomcat, jetty, etc).

[sameb]

I haven't followed the discussion... but I think you'll find that if we bundled a different servlet extension, it would suffer from a lack of maintenance. While basically ~every java server in Google depends on Guice (and thus we're careful to keep it stable and working well), nothing would depend on this new extension. Very few servers even depend on the existing servlet extension (as we primarily use a different technology internally). Other folks are in a better position to ensure a new servlet extension exists and is maintained. If you're just looking for a fork of the servlet extension, there shouldn't be anything special about the existing one that requires co-bundling/shipping privileges. OTOH, if you're looking for a fork of core Guice itself, that's unlikely to happen.

…

On Wed, Sep 28, 2022, 5:01 PM Ben Manes ***@***.***> wrote: @sameb <https://github.com/sameb> could we get something simple and low effort to be forward compatible? Maybe a new extension, guice-jakarta-servlet, that forks the old one with the updated imports? I don't think the community is asking for much, just a little support so that we can update our http servlet engines (tomcat, jetty, etc). — Reply to this email directly, view it on GitHub <#1490 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQLWERF56N6JEPQRRE65P3WASW4LANCNFSM4X3Y6AIA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ben-manes]

I don't think there is an ask for on going maintenance beyond what is done today. The existing extension is perfect. The problem is that Eclipse hard forked the namespace and forced the community to transition from javax to jakarta so that they did not have to participate in JEP / JCP (an IBM vs Oracle tantrum). In that transition all that is required is a find-and-replace of the import.

Since Guice is still broadly used but lacks an active community having something in core is useful for trust reasons. A random github user's non-discoverable, unmaintained dependency is not as attractive as a frozen Google dependency. Otherwise it's a forcing function to drop Guice externally to Google, so just a tiny bit of help would keep this excellent library alive for us otherwise very happy users (e.g. see #1630 where the work was done).

[sameb]

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.

[techwhizbang]

To echo what others have said our team recently went to upgrade from Jetty 9.x to Jetty 11.x. We realized that we were blocked because the newer Jetty depends on the new jakarta.servlet-api and Guice is using the older javax.servlet API.

A large swath of the most widely used libraries in the Java community have moved on and have adopted jakarta.servlet-api. Some well known projects that use the servlet APIs maintained two versions during the transition pointing at the old and new servlet API. Honestly though when you look at the adoption it becomes clearer there is no looking back.

As this continues to shake out can the Guice community get a version of Guice servlet extension with jakarta.servlet-api(one that isn't forked)?

What a lovely Christmas present this would be 🎄🎅 😄

[ryru]

We can't update to Tomcat 10 at the moment because Guice still has dependencies on javax.servlet.*. As others have pointed out, a Guice fork is not an option for us.

@sameb, any news from the internal team?

[ben-manes]

fwiw, for gradle users we can maybe use gradle-jakartaee-migration-plugin as a stop gap. I haven't tried it yet.

[JKomoroski]

There is also this option: #1383 (comment)

[sameb]

Duplicate of #1383