Project Jigsaw goals and requirements
David M. Lloyd
david.lloyd at redhat.com
Wed Jun 1 13:55:54 PDT 2011
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 . 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  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.
More information about the jigsaw-dev