Module system notification mechanism
Stanley M. Ho
Stanley.Ho at sun.com
Tue Jul 17 14:48:34 PDT 2007
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.
More information about the jsr277-eg-observer