On 04/26/2017 11:27 AM, mark.reinh...@oracle.com wrote:
2017/4/25 5:08:21 -0700, Stephen Colebourne <scolebou...@joda.org>:
On 24 April 2017 at 19:54, <mark.reinh...@oracle.com> wrote:
An explicit module that depends upon one or more modules that are
automatic today is, itself, no more stable than those automatic modules.
It could be broken when those automatic modules are modularized
explicitly, and if it `requires transitive` an automatic module then any
modules that depend upon it could be broken when that automatic module
is modularized explicitly.
I find this to be a completely artificial pure view of the world. Most
projects do not have internal packages, and if they do, most end-users
do not use them. When developers upgrade an artifact in Maven, they
expect to have incompatibilities, so a smaller set of packages is just
fine. Its a normal part of software development today, not an
aberration.
If developers expect to have to fix incompatibilities when they upgrade
to a newer version of an artifact then what's wrong, after all, with
publishing an explicit module that depends upon non-modularized
components in the form of automatic modules?
If one of those automatic modules is modularized later on, and given a
different name, then how is having to fix that materially different from
having to fix code that was using a package that's no longer exported?
I'd say the primary difference is that it is almost guaranteed that the
artifact will have a new name, whereas it's far, far less likely that
code will be using packages that are not then exported when the
automatic module is modularized. The chain of logic where it's OK to
introduce minor problems because people are used to fixing minor
problems doesn't hold up. Minor problems are minor in large part
because they don't occur frequently.
If anything it might actually be easier to cope with a module-name
change, since all you have to do is edit a `requires` directive; code
that refers to a package that's now encapsulated might require a
non-trivial rewrite.
I think I need to reconsider my previous conclusion that explicit modules
that depend upon automatic modules should never be published for broad
use [2]. Sure, they have unstable names and unstable APIs but if, as you
say, people are generally used to fixing minor problems when they upgrade
then this instability may well be tolerable -- especially since it would
allow maintainers to modularize whenever they want to rather than only
after all of their dependencies have been modularized.
Essentially it means that a fully modularized module *must* publish a
new version every time an automatic dependency is properly modularized.
This is an unreasonable extra burden to place on developers.
But, I don't believe that any of the pitfalls of automatic modules will
really matter in practice, particularly as better migration tooling
(than automatic modules) emerges.
--
- DML
