title: Best way to inject a class whose instantiation cannot be controlled?
body: <p>I'm fairly new to Guice so hopefully this isn't an obvious question...</p>
  
  <p>I'm dealing with a framework which dynamically instantiates one of my application classes  (let's call it <code>C</code>) using reflection, so I have no control over its instantiation.  Furthermore, there is no easy way for me to access a newly created <code>C</code> after the framework has instantitated it.  HEre's what <code>C</code> would look like:</p>
  
  <pre>
      public class C implements I {
  
          public C() {
              // this ctor is invoked by the framework so can't use DI here?
          }        
  
          public void initialize() {
              // this is a post instantiation hook which the f/w will invoke
          }
  
          private void m() {
              Dependency d = Dependency.getInstance();
              d.doSmth();
          }
      }
  </pre>
  
  <p>I would like <code>C</code> to acquire <code>Dependency</code> using DI.  Here <code>Dependency</code> is clearly a singleton but this needn't be the case generally.</p>
  
  <p>I have come up with two possible solutions, neither of which feels very tidy, so I thought I'd ask the experts:</p>
  
  <ol>
  <li><p>Static injection.  I struggle to see how this improves drastically over the service locator anti-pattern though - I end up with non final static fields which could be manipulated externally... hmmm.</p></li>
  <li><p>The framework supports a hook for <code>C</code> to initialize itself post instantiation (the <code>initialize()</code> method shown above).  This method could self-inject the newly created instance using setter injection.</p></li>
  </ol>
  
  <p>With 2, I guess this means more external alterability but at least exposes the dependency a little more explicitly for things like unit tests.  Trouble is: how do I get my hands on the Guice Injector in that case (short of relying on yet another service locator)?  I've also read (and tend to agree with) that explicitly referring to the Injector throughout app code is dubious practice.</p>
  
  <p>Your insight would be really appreciated.</p>
  
  <p>Many thanks,<br>
  Christian</p>