Project Jigsaw: Phase Two

[mark.reinhold at oracle.com]

2014/7/7 3:43 -0700, david.lloyd at redhat.com:
> Great document!

Thanks!  Glad you like it.

>                  Overall this set of requirements is almost a perfect 
> match with the requirements we derived for our own module system, which 
> makes me feel that it is hopeful that (a) this project has found the 
> right course and (b) we also have found the right course. :-)

Or else we're all on the wrong course!

> I also agree with all of the non-requirements, with a few small caveats 
> given below.
> 
> Firstly, in many places the document refers to versions of modules, 
> including specifying that the module system cannot support more than one 
> version of a given module.  But I believe this is somewhat misleading. 
> If you think about what this really means, you have to answer the 
> question: What does it mean to be a different version of a module?  Or, 
> at what point do two versions of one module really conceptually become 
> two separate modules?

When is the Ship of Theseus no longer the Ship of Theseus?

> ...
> 
> My intent with this example isn't to start talking about implementation 
> though - it's just to use a real-world example to illustrate the idea 
> that "multiple versions" is a sort of human concept that doesn't really 
> have an equivalent that can be mapped concisely to specification - 
> something that didn't really click for me right away, retrospective 
> obviousness notwithstanding.  The specification as given here does seem 
> to match my experience, if you read between the lines a little (and 
> deduce that a module must be identified uniquely within a configuration 
> (if not globally), and that the spec-defined module version can not be a 
> direct part of that identification), but I think (if not here than in 
> the final specification) it will be worth having a non-normative section 
> that discusses the idea versus the technical reality of multiple version 
> "support", and that not supporting multiple versions as a first-order 
> concept doesn't really mean you *can't have* multiple versions, per se; 
> it just means that the module version constraint mechanism cannot be 
> used in this way.  This will at the least have a big impact on community 
> perception, as the naive user might be somewhat affronted by what they 
> view as a key feature not being directly provided (even if it is 
> technically still possible - perhaps even easy - to accomplish in 
> practice, though perhaps in a slightly less obvious way).

I agree that giving guidance here will be important.

> Secondly, I have a minor concern about this statement:
> 
>      "Enforced version constraints — The process of configuring a set of 
> modules must, in all phases, satisfy every version constraint of every 
> module except for constraints that are overridden, in which case the 
> overriding constraint must be satisfied."
> 
> I note that the definition of phases was even more well-hidden compared 
> to the previous incarnation of the requirements doc, but it can be 
> deduced from the "Upgradeable modules" item to be the set of compile 
> time, build time, and run time.

It wasn't my intent to hide the phases concept or definitions, but I see
how the document can read that way.  I'll fix that in the next draft.

> My question, however, relates to run time.  I don't think one has to get 
> too far into speculating about implementation to deduce that the only 
> form that this constraint can take (and still be a constraint) is 
> throwing an exception of some sort when a non-satisfying module is 
> loaded.  My gut feeling is that once you get to run time, it might be 
> more damaging to enforce this constraint than to let it slide (though 
> maybe with a warning of some kind, if possible).  ...

The "Overrideable version information" requirement allows both
developers and deployers to fix broken version strings or constraints.

Whether the run-time system should force you to use that mechanism when
a constraint is violated, or just issue a helpful warning message, is a
design decision we can make further down the line.

- Mark