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

[Daniel Latrémolière]

I am sorry for sending you another mail [really shorter than preceding], 
but I promise to stop after this mail.
>
> Simplistically (time dimension omitted), I will tell modularity is 
> allowing better understanding and development of complex software: I 
> think this can mostly be currently achieved by good packages naming 
> and JAR packaging. The only new feature I can found useful for me is a 
> new access right "module" for all types, methods, fields to simplify 
> and enforce API notion (hiding items not in API).
>
I have completely forgotten the small problem of uncoupling each module 
from others at execution time (currently realized by service providing 
and life cycle events received by interfaces for module manager). I 
think it will be a smaller problem than preceding e-mails, because this 
is the classical problem of "Inversion of Control" (between module and 
application manager) and is already partially solved by incompatible 
multiple JSR standards (like, for example, JSR 330 "@Inject" for 
dependency injection, JSR 250 @Resource, etc.).

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

NB: Please note that JSR 250 already includes annotations for declaring 
roles required/allowed for calling a method, giving probably an 
interesting idea for future module evolution by defining roles existing 
in a module and allowing one module to use another module but only with 
a specified (by application manager) role (giving more secure complex 
applications).

End of my e-mail series.
Thank you for reading my bad english,
Daniel Latrémolière.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090917/7b9e415c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daniel_latremoliere.vcf
Type: text/x-vcard
Size: 199 bytes
Desc: not available
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090917/7b9e415c/attachment.vcf>