IMHO, Java combines the worst of statically typed and dynamically typed programming languages. To paraphrase Rob Pike, programming in Java is like dotting all the i's and crossing all the t's in a fairly complex contract but at runtime, the contract can be overridden by dynamic classloading. So you do not get the efficiency of a statically typed language (because the compiler cannot make certain assumptions about the types / classes) nor do you get the expressiveness of a dynamically typed language.
In the case of DI, I would observe that no programs in other languages seem to require or even use this pattern. If you need to implement LGPL at the language level, a better abstraction is modules with contracts... or even better a proper metaobject protocol a la Lisp.
DI is also used quite heavily in C#. And in most - if not all - functional languages, one of the flavors of dependency injection (what a C# programmer would call method injection) is so pervasive that it doesn't even have a name. People just think of it as an idiom rather than a design pattern.
If I may speculate, I suspect that the reason why DI is discussed so much more in the big enterprise programming languages isn't because of the languages so much as the problem space. Enterprise software has a tendency to be enormous, live for a very long time, and involve stitching together components from a variety of sources, none of which are being modified or replaced on exactly the same schedule. Hard-coded dependencies always have the potential to be a maintenance hassle, but that kind of situation compounds the problem immensely. The promise of DI - that if you follow it scrupulously you can produce software that's so easy to modify that you might even be able yank out and replace entire modules without so much as a recompile - becomes very attractive in that kind of situation.
It's also a huge win for huge teams. If you make good use of dependency injection then it's easy for different teams to develop different modules that depend on each other in parallel. All you have to do is whip up some stub implementations of the modules that aren't available and get to work.
In the case of DI, I would observe that no programs in other languages seem to require or even use this pattern. If you need to implement LGPL at the language level, a better abstraction is modules with contracts... or even better a proper metaobject protocol a la Lisp.