Fix of #700

[nineninesevenfour]

Ensure the order of calls to Binder.bind(...) in combination with @ does not affect whether classes are bound explicitly or with jIT binding.

Signed-off-by: Harald Fassler harald.fassler+9974@gmail.com

[nineninesevenfour]

Hello, I am a new contributor 👋, let me explain, what I did an why.

The issue popped up through https://stackoverflow.com/questions/73901723.

After some tests I found out that the issue did surprisingly not occur in combination with @ProvidedBy. After some debugging I came to the conclusion that the solution would involve delayed initialization with DelayedInitialize. I hesitated to create a distinct LinkedImplentedByBindingImpl and instead extended LinkedBindingImpl letting it implement DelayedInitialize. Also I did not change the way the binding is initialized and kept the call to ProxyFactory.notify(...), but changed it to a lambda expression. I ignored the fact, that DelayedInitialize might receive a different Injector instance. But through temporary added code (removed before committing again), I found no test that would come up with a different Injector instance here. Maybe you could guide me to find a case, where this could happen.

Unfortunately the change made InjectorImpl.cleanup() fail in context of ImplicitBindingTest.testCircularJitBindingsLeaveNoResidue(). This was because the cleanup method relied on the order of encountered dependencies of injectees. Therefor I changed encountered from a set to a map, additionally remembering if a previous encounter failed or not.

In total I tried to make the change as unobtrusive as possible.

[sameb]

Thank you for contributing this, @nineninesevenfour ! The change is in a somewhat tricky area of the code that I wrote many many years ago, so I will review it more closely next week and potentially tweak it a bit before submitting the fix.