Module-system requirements, draft 2

[mark.reinhold at oracle.com]

2015/3/31 6:57 -0700, tim_ellison at uk.ibm.com:
> Last few comments:
> 
> (a) Just to ensure this is not misinterpreted, perhaps consider rephrasing
> 
> |  - _Protection domains_ --- At run time it must be possible to associate
> |    the code in modules with protection domains, for the purpose of
> |    granting security permissions.
> 
> as
> 
>   - _Protection domains_ --- At run time it must be possible to associate
>     modules with protection domains, for the purpose of granting security
>     permissions to code in those modules.

The existing wording is intentional, to allow for an approach (as we
discussed) that's based on associating class loaders with protection
domains rather than mandate an extension of the protection-domain
concept to associate specific modules with protection domains.  The
former approach is simpler and may be adequate, but the latter is
not ruled out.

> (b)
> |  - _Non-prescriptive version strings_ --- Version strings must have a
> |    precisely-defined syntax and be totally ordered, but otherwise their
> |    format should be as general as possible in order to accommodate
> |    existing popular version-string schemes.
> 
> 
> I'm trying to reconcile the requirement for version strings to be
> "non-prescriptive" and have a "precisely-defined syntax".  The need
> for a defined syntax is not reflected elsewhere, so is it sufficient
> that they are simply totally ordered, and otherwise left to the needs
> of the configuration management systems that assemble coherent sets of
> modules?

Yes -- that's exactly what this requirement is trying to capture.
To define a total order requires a precise syntax, but otherwise the
specification shouldn't force a specific interpretation of version
strings.

> (c) This version doesn't incorporate the "Overrideable encapsulation"
> requirement described here
> 
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-February/000020.html

Good catch -- I'll add that in the final version.

> or the clarification suggested for _Referential integrity_ to read
> "that each module can be configured only to reference" rather than
> "each module can only be configured to reference"

Will fix.

- Mark