As discussed on the mailing list thread "Appeal to jersey developers for
better+reliable javax.inject/cdi/weld support", jersey's own legacy dependency
manager is becomming a big problem. Jersey's own dependency injector was
originally a good feature but now is highly problematic.
What changed the situation? Well now we have javax.inject and CDI in the Java 6
standard + many good implementations in spring, weld, guice etc. Developers
using new Java 6 SE/EE technology is or will be using other dependency injection
managers and it is a PAIN to get it to interoperate with jersey.
The situation now is that we have a "feature" that is hard to maintain and a
stone around the neck for java users that use JEE6 or guice/spring/weld/etc.
Normally, I do not recommend removing features but for a feature that subtracts
value for everybody and is costly to maintain I would say get rid of it as soon
Hence, It would be much better if Jersey's own legacy dependency manager would
be completely removed and for Jersey just to ride on top of any standard
javax.inject and/or CDI implementation. This would give great benefits for both
users of jersey and jersey developers.
As for compatibility, the biggest problem with java is the unwillingness to
cleanup things because of a 100% mindset on "backwards compatibility" that
overcomplicates Java. If users want the old api then they should not upgrade
their jersey libs. However, if you insist on some compatibility you could for
example introduce a annotation processor that would convert existing source code
at runtime to use standard annotations ? But maybe a clean cut would be much
better for everybody ?