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
