On 05/11/2016 08:15 AM, Alan Bateman wrote:
On 11/05/2016 13:52, David M. Lloyd wrote:
In practice this happens a lot. A module's dependency graph depends
just as much on the environment as it depends on the classes in the
module (if not more so). Modules are merged and split, replaced with
compatibility stubs, renamed, etc. If you have to recompile every
module for every environment, a lot of the benefit of modularity and
compatibility-by-ABI is lost; changes to a module in an environment
would lead to a massive cascade of recompilation.
The module system can support many refactoring scenarios, including
merging and splitting. I can see myself refactoring modules that I
maintain, I'm less sure that I want to refactor modules coming from
other projects. If I found myself refactoring modules from elsewhere
then I would expect to have to build and test those modules, it would be
strange not to do and I don't understand how you can get away with this
when changing code in those modules. It might be useful if you could lay
out a specific scenario as it may be that we are talking completely
different things.
We package several hundred JARs in our modular environment today, only
some of which originate in-house. The dependency information for these
modules is established not by the author of these JARs, but by us. The
Maven artifact for such a JAR might stipulate certain things, like Log4j
or a certain version of ASM. When we distribute that JAR though, we
don't package the exact artifacts and versions of the dependencies that
were stipulated in the Maven POM; instead we package single consistent
versions which are ABI-compatible with all of its dependents, or maybe
even a completely different artifact that meets the same ABI but
performs its functions in a different manner.
Over time the environment we distribute evolves, and we split or join
modules, or we rename old modules to introduce a new major version of
the same module in parallel, or we replace one implementation with
another. When we do this we may chose to deprecate or eliminate a
module from our environment. Thus we update all the module descriptors
that reference the deprecated module, and set new dependencies on them,
and after a certain amount of time, we delete the old module name.
None of the artifacts that we package are impacted by this process, and
generally no recompilation is necessary: after all, many of these
artifacts come directly from Maven or are otherwise built independently
at an earlier time outside of the context of our target environment.
It's the ABI that matters; as long as that doesn't change (in an
incompatible way), recompilation should never be necessary. I think
"recompile just to be safe" puts us squarely into "turn it off and on
again" territory, logically speaking.
--
- DML
