Some views from a programmer [1/3: requirements]

[Stephen J. McConnell]

On Thu, 2009-09-17 at 13:58 +0200, Daniel Latrémolière wrote:
> To be simple, an inversion of control requirements are: 
>       * Injection of services (like by example a Logger instance) in
>         constructors, fields, parameters tagged with an annotation of
>         the module classes. This will occur at given times defined by
>         the given scope of the annotation and definition of this scope
>         in the application manager. 
>       * Allow the module to provide objects (like by example services
>         implementations) to the application manager from returned
>         results of methods tagged with an annotation giving possible
>         states of calling. 
> Module starting, stopping are only module-specific scopes defining
> module times (like some others largely used scopes: HTTP request life
> cycle, HTTP session life cycle, etc.), then does not need big changes
> (only a newly defined scope).
> 

Daniel:

I enjoyed reading through your 1-3/3 messages.

The subject of interconnection of classloaders was front and canter in
my mind while doing so. My own experience is that the hardness of
interconnections between consumers and suppliers across classloaders
(which comes into play on supply of services *and* potential
dependencies between a framework and the components it supports) can be
mitigated by things like proxies and such (combined with a lot of
management code).  However, you mentioned an important point relating to
classloader hierarchies which should not be discounted.  

Under the Jigsaw implementation classloaders are no loger hierarchical
which is a major step forward.  In fact the pre-module programming
models have been constrained by the classloader hierarchy model.  Under
the existing specifications we have a network of classloaders - although
I would also note that we are not totally out of the woods yet.  As
things stand (based on the java.lang.module API) I don't see a clear
path to the delivery of a module management platform without duplication
or direct reference to Jigsaw code (but that's just an early indicator -
I'm still digging into the current codebase and assessing implications).

I would suggest taking a look through the documents posted on the Jigsay
project page as that material is much more up-to-date than anything on
the JSR 294 spec page, and also taking a look at the code in Jigsaw
itself.  There is a lot to be gleaned from the code and internal
comments.

Cheers, Steve.