Прежде всего, я бы не советовал просто аннотировать произвольные методы с помощью @Inject. Сохраняйте его для конструкторов, а иногда и для дополнительного ввода и / или полевого ввода.
То, что вы пытаетесь сделать, звучит немного странно, и я не уверен, что это именно то, что вы хотите. Не могли бы вы предоставить больше информации о том, что вы пытаетесь сделать, потому что, возможно, другой подход лучше. Здесь определенно есть некоторые проблемы с безопасностью потоков и с тем, как вы управляете ссылками.
Исходя из того, что вы описали, подход, подобный тому, что упоминал @meverett, вероятно, будет работать. Если у вас есть объекты Foo
s, это будет выглядеть примерно так:
// Later on be sure to bind(Foo.class).toProvider(FooProvider.class);
final class FooProvider implements Provider<Foo> {
private final Provider<Foo> unboundFooProvider;
private Foo currentInstance;
@Inject FooProvider(@Unbound Provider<Foo> unboundFooProvider) {
this.unboundFooProvider = unboundFooProvider;
}
@Override public Foo get() {
if (currentInstance != null) {
currentInstance.unbind();
}
currentInstance = unboundFooProvider.get();
currentInstance.bind();
return currentInstance;
}
}
Обратите внимание, что ваш @Unbound Foo
провайдер сгенерирует Foo
s без вызова каких-либо специальных методов. Обычный FooProvider
отслеживает состояние и решает, когда bind()
и unbind()
экземпляры. Пожалуйста, будьте осторожны с тем, как вы управляете несколькими экземплярами и используете их с несколькими потоками.
Кроме того, просто для ясности: я использую @Unbound
, поскольку методы, которые вы хотите вызвать, называются bind()
и unbind()
. Я не использую «связанный» в смысле Guice.
Также обратите внимание ... на макушке головы я почти уверен, что провайдеры рассматриваются как одиночные, поэтому поддержание такого состояния будет работать. Если этого не произойдет, вы, очевидно, можете просто создать уровень косвенности с какой-то синглтон-фабрикой (но в этом нет необходимости).