The provided example to replace the deprecated dependency chain method doesn't provide enough context about which field or parameter is being injected. I tried to replace dependency chain method, but the most accurate I got was knowing which method/constructor/class is being injected.
Knowing which field/parameter is being injected allowed Provider
s to return values based on the annotated elements, without having to bind each possible combination.
The dependency chain solution can be found in the following PR changes: https://github.com/SpongePowered/SpongeCommon/pull/1435/files/1bd19db6f0b2363b8bc72960df0b0947e04cc1e0
A custom InjectionPoint
is constructed from the information in the dependency chain, this object only exposes the annotations/type/target type of the field/parameter. There is also a small example available in the PR.
Then I was looking for a different solution for the dependency chain and ended up stuck in the following changes:
https://github.com/LanternPowered/LanternServer/commit/f67d3e86af549b7e64c43f5f0de85d6fe5aaf211
Not sure what the best solution could be to resolve the issue, undeprecating the getDependencyChain
method is an option. Or similar to the InjectionPoint
injection, could it also be done for the Dependency
by guice itself, making it unnecessary to scan the chain. Maybe you guys can find a better solution for this issue. Maybe there is even a different solution that I haven't been able to find.
I'm going to give this a bump - any solution known? If not, is it possible to have this reverted?
I hate to be one of those people who bumps so often, but it'd be great to get a response on this - @dimo414?
@kashike sorry, I'm afraid I don't have any insights here.
The DependencyChain got deprecated in the following commit: https://github.com/google/guice/commit/99c1047b23af62d17b41bda03947a54f581b21c8
And one of the reasons it being depecrated was not being "popular" enough and guice being more performant when removing it (A benchmarking experiment* shows that maintaining the dependency stack costs about 10% of guice performance. Anecdotally this feature also isn't very popular, so eliminating it seems reasonable.
). Maybe a opt-in solution would be better instead of removing it?
Or maybe a method to retrieve the dependency chain without the source (would reduce the internal dependency stack size by half: https://github.com/google/guice/blob/master/core/src/com/google/inject/internal/InternalContext.java#L46).
@lukesandberg - input?
another poke, @lukesandberg - input?
I'm going to give this yet another poke - @lukesandberg?
Most helpful comment
another poke, @lukesandberg - input?