generics, factory methods and compiler warnings
Hi all,
I have a parametrized class where new objects are created via a factory. The problem is that I'm getting some compiler warnings. Am I missing something or there's no way to avoid them?
publicinterface Schedulable{
// methods here
}
publicclass Scheduler<Textends Schedulable>{
// should this be parameterized? If yes, how?
// (it's not possible to use T while <? extends Schedulable> gives problems)
privatestatic Scheduler scheduler;
private NodeManager nodes;
private DefaultServiceManager<T> services;
private Timer timer;
private LifecycleManager lifecycle;
publicstaticsynchronized <Eextends Schedulable> QueueScheduler<E> newInstance(){
if (scheduler ==null){
scheduler =new Scheduler();
scheduler.nodes = DefaultNodeManager.newInstance(scheduler);
scheduler.services =new DefaultServiceManager<E>(scheduler.nodes);
scheduler.timer =new Timer(scheduler);
scheduler.lifecycle =new LifecycleManager(scheduler,
scheduler.timer);
// these fields are initialized here and not into the constructor in order to avoid
// the 'this' reference to escape (see//http://www-128.ibm.com/developerworks/java/library/j-jtp07265/index.html
// for example)
}
// all the fields initialized above generate a warning
return scheduler;
}
protected Scheduler(){
// initialization of some fields here
}
// methods here
// methods here
}
Thanks,
Michele
[2962 byte] By [
michele81a] at [2007-11-26 16:35:28]
# 3
I'm sorry, I forgot the type: the instance is actually created as you describe:
scheduler = new Scheduler<E>();
Is it possible, instead, that the problems arise because the static variable is declared without type?
private static Scheduler scheduler;
# 4
Oops, sorry, didn't see the variable actually is a static, raw one. Here you will have a problem, as for once you cannot use the E for the static variable and second you could not guarantee that a previously created Scheduler would have the same type parameter as the one you are going to create:FirstSchedulable a = Scheduler.newInstance();
SecondSchedulable b = Scheduler.newInstance(); // would fail!
The second call would fail, as the first would have created an instance of Scheduler<FirstSchedulable>, which is stored in the static variable scheduler and not compatible to a Scheduler<SecondSchedulable>.
You should rethink you design.
# 6
> No, I think the design is correct. In fact the
> scheduler is created only once (i.e. if the static
> variable is null).
No, it's not. As I said, if you try creating a parameterized scheduler from an inferred generic type, the design would only accidentally work, as long as you always have the same generic type being inferred (or raw usage). The example I wrote before shows when it will definitely fail.
If your Scheduler can only be of one specific type there is either no need to have it parameterized or you should not have a parametrized factory method.
# 8
It depends on your application scenario, which I do not know (and surely will be out of scope to present here).
Do the users of the Scheduler need to parametrized it? That is, will there be places using the Scheduler requiring different arguments as E in the same VM/ClassLoader-Environment? If not, setting the Schedulers type parameter should rather be a configuration issue than a construction issue, i.e., the Scheduler retrieves the type information from some configuration provider.
Do you need separate Scheduler instances differently typed? In this case you should not use a singleton-like approach.
