On 12/03/2015 07:03 PM, Alex Buckley wrote:
On 12/3/2015 4:47 AM, David M. Lloyd wrote:
On 12/02/2015 04:49 PM, Alex Buckley wrote:
Now we reach the disagreement. We don't think the module declaration
will be as fluid as you do. Yes, frameworks and other tools will want to
modify module declarations (usually by addition of dependencies or
exports) but that's a handful of actors, all of whom are perfectly
capable of using ASM. 99.99% of humans have no business modifying
someone else's module declaration by hand, so there is no reason for it
to be easy.
I am baffled as to the basis for this assertion. This kind of change in
fact happens (present tense) frequently - very frequently if you have
any kind of system for updates. Modules get split or merged,
implementations from one vendor get swapped out for another, multiple
versions of things are introduced. I honestly can say that I do not
understand how the Jigsaw team arrives at this kind of conclusion with
literally zero production experience!
If you're splitting or merging modules -- especially someone else's! --
then you need to let the compiler check that the newly factored modules
are well-formed: they export packages that they actually contain, and
they don't read anything that would lead to a split package. (The
constraints in j.l.m.Configuration::resolve, basically.)
So you're saying that if I have C depending on A, then update A or I
split A and B in my distribution, I need to recompile C? I don't think
that's a realistic proposition. Do I then have to recompile things that
depend on C? Or things that depend on those things? How would updates
work in such a scenario? Do I need to put the dependency versions of
every dependency in my version string so that I can tell the difference
between C compiled with the original A versus C compiled with the new A/B?
It should not be necessary (and indeed it is not necessary today) to do
this kind of cascading recompilation; I don't think that is something
reasonable to ask of users. If they have to recompile such large
swathes of their project any time anything has changed, the point of
modules has been at least partially defeated.
Java has a fairly clear ABI contract; a better approach would be for
users to know if they've changed compatibility when they compile A, or
when they split A into A and B, etc. If the ABI is the same or is
forwards-compatible (i.e. only adding members), then why would a user
want to recompile everything else? Is this not a red flag that the
encapsulation rules are unrealistic?
Similarly, if you're changing a module to require a module by Vendor X
rather than Vendor Y, then you'll want the compiler to check that your
module isn't led by Vendor X's module to read anything that would lead
to a split package.
Better to modify module-info.java and recompile it and catch these
issues up front, than modify MANIFEST.MF and run the main module and
hope the tests catch them.
Alex
--
- DML
