Po, sergio, tu me decepciona desse jeito, pensei que vc ia dar uma olhada no Spring, como havia me dito 
Eu não tenho certeza, mas acho que no falecido projeto Apache Avalon, as dependências eram injetadas desse jeito, usando interfaces. Mas os containers IoC ‘modernos’ (Spring, Pico, HiveMind) usam reflection sim, você não precisa declarar uma interface pra cada dependência. As interfaces surgem apenas como boas práticas, mas é perfeitamente possível usar classes que não estendem de interface alguma. Aliás, eu acho que os setters de dependências não deveriam sequer serem declarados em interfaces, pois estas representam na maioria das vezes funções de negócio, enquanto dependências são detalhes de implementação.
Quanto às diferentes formas de injeção de dependências, Martin Fowler escreveu um artigo interessante que explica bem três formas de injeção - por construtores, por setters e por interfaces -, que há algum tempo atrás eu traduzi para o português.
Eu lembro de ter lido em um blog no java.net (faz tempo), de uma outra forma de injeção, a getter injection (!). Essa abordagem também é bastante interessante, apesar de ser meio viajante 
Consistiria em declarar getters (abstratos ou que retornassem um valor default) para as dependências, que seriam sobrescritos pelo container, fazendo-os retornar as referências dos objetos injetados.
Uma grande vantagem que eu vejo nessa abordagem é que, ao contrário da setter injection (e das outras também), não haveria a necessidade de se criar métodos públicos para a injeção (como serão sobrescritos, os getters poderiam ser apenas protected), evitando ‘sujar’ a interface pública das classes.
Como desvantagem, eu penso que as pessoas já tem dificuldade o bastante para entender a injeção usando reflection simples, imagine usando herança com geração automática de bytecode (ainda mais ‘indireto’, a meu ver)! Outro ponto seria que, por essa abordagem, seria mais difícil usar o objeto sem um container (num test-case, por exemplo), já que os métodos injetores não são públicos. Você teria que estender cada classe para injetar a depenência (argh). Além disso, essa manipulação de bytecodes necessitaria de um framework adicional como a CGlib, BCEL ou Javassist, aumentando o número mínimo de jars empacotados junto da sua aplicação.
Bom, mas já estou viajando demais… voltando à pergunta: dá pra alterar atributos privados via reflection, sem que o security manager do java reclame (sinceramente eu nunca tentei)? Via policies talvez… Mas isso seria recomendável?
Como eu já disse (e outras pessoas também) , não é preciso criar uma interface para injeção de dependências, pelo menos nos containers de Dependency Injection mais usados por aí. O uso de interfaces já foi utilizado no passado, mas acho que a morte desse projeto dá uma indicação de que a abordagem não foi muito bem aceita (também, credo, uma interface pra cada dependência???). Acessar diretamente atributos privados é perigoso, quebra completamente o encapsulamento e expõe suas classes a bugs indetectáveis (por exemplo, se você declarar um atributo privado que não deve ser injetado, que é um caso bastante comum, creio). Sobrescrever getters tem vantagens, mas não acho que elas acrescentem valor suficiente para ignorar as desvantagens.
Eu continuo ‘partidário’ da injeção via setters construtores, que não são tão invasivas ao código, não requerem malabarismos muito grandes (só reflection simples), não têm problemas com security managers, e são relativamente fáceis de compreender.
