From mark.reinhold at oracle.com Wed Apr 1 15:58:57 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 01 Apr 2015 08:58:57 -0700 Subject: Module-system requirements, draft 2 In-Reply-To: References: <20150325225212.B8AB0534D7@eggemoggin.niobe.net>, Message-ID: <20150401085857.608727@eggemoggin.niobe.net> 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 From niftiness at gmail.com Thu Apr 2 06:23:07 2015 From: niftiness at gmail.com (Tim Boudreau) Date: Thu, 2 Apr 2015 02:23:07 -0400 Subject: Module-system requirements, draft 2 In-Reply-To: <20150401085857.608727@eggemoggin.niobe.net> References: <20150325225212.B8AB0534D7@eggemoggin.niobe.net> <20150401085857.608727@eggemoggin.niobe.net> Message-ID: On Wed, Apr 1, 2015 at 11:58 AM, wrote: > 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. > I wonder if "total order" is actually too strong a statement. I think in the extremely long run, arbitrary version numbers invented by fallible humans may become attractive, while commit-hashes from SCMs such as git or hg have a number of desirable attributes: - The exact state of the source tree is recoverable from a hash - Assuming the compilation environment includes enough metadata to reconstruct it, this can act as a very-expensive-to-compute HMAC - you can determine if the bits you received are an exact match for the bits you build (modulo a bunch of things that could break that) I can imagine a versioning scheme which used partial order - Instead of 1.0, bae62770d3ba Instead of 1.1, bae62770d3ba / d452b222d78 Instead of 1.2, bae62770d3ba / d452b222d78 / 3c4a81666a4 Instead of 1.3, bae62770d3ba / d452b222d78 / 3c4a81666a4 / 3ec0e3bb788cb Instead of 1.4, d452b222d78 / 3c4a81666a4 / 3ec0e3bb788cb / 79792b0779 such that determining if 1.3 is newer than 1.1 is still a fast test (scan left to the first common known ancestor hash), but in fact, given two disjoint version strings, total order cannot be determined (some threshold number of parent hashes are required so as to make this a non-problem unless you don't upgrade libraries for a decade, but which can be solved by acquiring an intermediate version that overlaps the other two, or acquiring all known versions and topologically sorting them). I realize that's a bit hypothetical, but we have today the ability to generate far more reliable (if less intuitive) version strings than arbitrary dewey-decimal. So the point I'm trying to make is that you don't actually need total order to answer this-comes-after-that questions, so perhaps we don't want to insist on it. -Tim