Module system notification mechanism

[Bryan Atsatt]

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
>