Module system notification mechanism

Stanley M. Ho Stanley.Ho at
Wed Jul 25 03:47:10 PDT 2007


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!
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.

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.

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.

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

More information about the jsr277-eg-observer mailing list