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.
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.
// Bryan
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
Custom import policies cannot leverage any other modules; this would be
a severe limitation for an initialization mechanism.
There are good reasons why there is such restriction. When the module is
being initialized, its imported modules might also be in the process of
initialization. If one module accesses another module while both are in
the middle of initialization, the result could be problematic. Also,
suppose two modules have cyclic dependencies and each has its own
initializer, what happens when an initializer is called in one module
and that initializer wants to access the other module, while the other
module's initializer wants to do the same?
We could either prevent this from happening by saying the initializer
could only access code in the standard SE modules and the code within
its own module, or we could say that the initializer could access the
module itself and all its imported modules - but developers need to be
aware that there is a possibility that the imported module is only
half-initialized when it is called by the importer's initializer. The
latter could be very error-prone, and I'm not sure how useful it is to
provide it to the developers.
On the other hand, if we restrict which modules the initializer could
access, then the initializer is not much different from the custom
import policy - it's still a piece of code that is executed during
module initialization, and exception would cause the module
initialization to fail. In fact, the custom import policy was called
ModuleInitializer in the original JSR 277 strawman, and the intention is
to allow a module to do everything it needs to initialize itself properly.
- Stanley
