Hi Bryan,
Bryan Atsatt wrote:
Um, I'm not arguing about the restriction in custom import policies, I
certainly understand why that is present.
I'm saying that an initializer *should* be able to rely on imported
modules, so we need a separate mechanism. And that separate mechanism
would kick in *after* resolution/validation had completed.
And yes, there is potentially a pathological case even here, if two
initializers have cyclic dependencies (not the Class kind ;^), but...
Seems to me that this has to be discovered and eliminated in
development; this is a variation on the "order of static initialization"
problem, and one that we can't solve here.
I think we agreed that in the presence of circular dependencies a module
cannot rely on its initializer being called before other code in the
module is called. The problem is that a module may not know if it is
part of a cyclic dependency chain because that depends on its imports,
their imports, etc. I don't think we can assume that this is a
pathological case that never occurs in the real world.
If a module cannot rely on its initializer to access other modules
safely or in the right order, then it is unclear to me if such support
would be very useful in practice. Instead, a module could rely on the
existing custom import policy or alternatively on other measures, for
example explicit checks in the code or infrastructure provided by the
container.
Are you just suggesting that we add start()/refresh() type methods to
ImportPolicy, rather than invent a new class/annotation? And that we
might then want to rename this class? For example, rename ImportPolicy
to ModuleInitializer, and add to it:
public abstract class ModuleInitializer {
public abstract List<ModuleDefinition> getImports(...);
public abstract void initialize(Module) throws Exception;
public abstract void release(Module);
}
If so, I'm OK with that approach as long as the class loading
restrictions during getImports() are made clear and the module state at
initialize() is clearly specified.
I'm fine with changing the name of the ImportPolicy class into
ModuleInitializer if it makes things more obvious to developers.
I think what you suggested is not unreasonable, but I want to make sure
this is something we really need to support, especially outside the
container environments. Specifically, I'm not yet convinced we should
provide an initialize() method that allows access to the imported
modules (excluding the standard SE modules) because of the potential
problems. Could you provide use cases for this outside a container
environment?
It is also unclear to me if providing the release() method would be
useful outside a container environment as well. As I hinted before, you
probably want to do the clean up in the finalizer or something similar
when nobody uses the module instance anymore, rather than when the
module instance is released from the module system while other existing
users could still access it.
- Stanley
