Module system notification mechanism

[Bryan Atsatt]

Stanley M. Ho wrote:
> Hi,
>
> Let's briefly recap. The arguments for the initializer I heard so far
> are (correct me if I miss anything):
>
> 1. It's not custom import policy!
Yes, as far as the class name goes. But it can still serve that role if
the developer chooses to implement getImports().

> 2. It provides developers a way to perform initialization in a module
> after validation succeeds but before the module instance is ready.
> 3. It provides developers a way to be informed when a module is
> released, so the module could potentially deny future requests, if it
> chooses to.
Right.

> As I mentioned already, I think what has been suggested so far is not
> unreasonable. What I was arguing is not whether such support is useful
> at all by any means, but more specifically whether such support is
> useful outside the container environment. What I am concerned with in
> particular are a few issues:
>
> a. whether initialize() can access other imported modules
>
> As we briefly mentioned, this could be problematic in some situations,
> e.g. cyclic dependencies. Because of that, I don't think the module
> system should/could guarantee that an initializer will always be able to
> access its imported modules. To be more specific, which imported modules
> are accessible by the initializer will likely be determined by the
> states of the module instances in the module system and will also depend
> on the actual module system implementation (and things get much more
> complicated if there are other module systems in the picture). In some
> situations, the set of accessible imported modules from the initializer
> could be none. I suggest that we should not make such guarantee in the
> module system at all.

Sorry, but this makes no sense to me. When a module transitions from
RESOLVED to READY, it is, by definition, prepared to execute any of its
code, including calls into dependent  modules. And this is true even in
the case of cyclic dependencies; otherwise, we could not hand out a
module for use at this point either!

So all we have to do is call initialize() as the last step before
transitioning to READY. If it fails, we go to ERROR, else go to READY.

> b. cleanup resources in release() when the module instance is released
>
> As we also discussed, this could be problematic if a module cleans up
> itself while its classloader is still accessible by other modules. It is
> possible that some developers might want to do implement something like
> (3) above in their modules, but I don't think this is what most modules
> outside the containers should do. I suggest we should make the potential
> issues obvious to developers in the documentation, and also discourage
> developers to use it as a general cleanup mechanism, unless they know
> what they are doing of course.
We definitely need to document this with some care. But, again, the only
real potential issue here is with cycles, just as it is during
initialization. In the absence of cycles, the release() calls will occur
in the correct order, right? That is, if

   A --depends--> B --depends--> C

And C is released, the importers will be released first: A, then B, and
finally C.

As long as we guarantee this ordering, the potential issues will be
reduced to those due to cycles. And, again, just as with
order-of-static-initialization, developers must be aware of the pitfalls
of cycles and code around them.
>
>
> If the EG still thinks that the initializer support is important and
> also if we have consensus on the suggestions I made above, I will
> incorporate this into the next revision of the specification.
>
> - Stanley
>