Project Jigsaw: Phase Two
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Mon Jul 7 20:34:31 UTC 2014
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
More information about the jigsaw-dev
mailing list