Project Jigsaw goals and requirements

[David M. Lloyd]

On 05/30/2011 07:34 PM, Tom Marble wrote:
> On 05/25/2011 10:55 AM, mark.reinhold at oracle.com wrote:
>> I've posted the latest draft of the requirements document for wider
>> review [4].  Comments are most welcome.
> Thanks Mark!
>
> Many of us, as you point out, are eagerly anticipating the
> new Java Module System.
>
> I have a couple of brief comments and then want to dive
> into version syntax: an area in need of serious attention.
> [...]
> I agree with David Lloyd [18] that the wording and interpretation
> "Fidelity across all phases" is very important.  I also agree that
> "[...] dependency version ranges with a closed upper end cannot be
> a fixed part of the module's internal metadata".  We really don't
> want to have to say "requires public foo @ [2.0,99999);" as a surrogate
> for "versions 2.0 or later".
>
> However I disagree that we want to restrict build dependencies to
> specific versions (and not version ranges). This will cause build
> maintainers endless toil to manage packages when no underlying
> change provokes the rebuild maintenance. I think that fixed build
> dependencies are a poor substitute for functional testing once
> the project has been built in assuring reproducibility.

The two aren't mutually exclusive.  A fixed build dependency version is 
essential to build reproducibility, which does not just mean "make sure 
it still works with new dependency versions" (which is a legitimate 
thing to worry about, but it pertains to runtime dependencies and 
testing, not build dependencies); rather "make sure we get the same 
result that we did the last time we built this".  After the artifact is 
built, testing it in the modular environment is a different problem.

Specifically, if a problem crops up in widget-1.2.5, the widget 
maintainers have to know to a certainty what classes are being used.  If 
build-time version ranges are employed then it's possible that the 
maintainer of widget could end up testing different classes, and 
ultimately be unable to reproduce the problem.

A versioned module has to be defined as the result of building a 
specific set of source code against a specific fixed dependency set, 
else the notion of a version is useless because it doesn't identify an 
artifact, just a sort of category of possible artifacts with no real way 
to know what you really have.

Put another way, if you build against a different dependency set, you 
have changed your artifact as surely as if you have changed the source 
files.  It would be very unwise to ignore this as a requirement.  Yes, 
it is possible to make a dependency change which does not affect the 
final artifact; however the same can be said for source code changes.

Now as for runtime "functional" testing, as new dependency versions are 
released it is important that existing artifacts are tested against the 
new versions of the dependencies to ensure that they continue to 
function in the runtime module environment.  This is definitely an 
interesting problem domain in its own right, however it is at best only 
casually related to build dependencies.
-- 
- DML