module-info.java just causes problems

Gunnar Morling gunnar at hibernate.org
Wed May 11 14:57:55 UTC 2016


Recompiling entire modules might not be an option in cases where you don't
have the sources of your dependencies. It might even be that you are not
allowed to javap a module's module-info.java, depending on its licensing
terms.

But also leaving such cases aside, having to re-compile module-info
descriptors for the sake of overriding required modules seems very tedious.

E.g. imagine you hadn't the means of dependency exclusions in Maven (in
your application's pom.xml) but were required to patch the pom.xml files of
your dependencies in order to converge to a consistent set of logging
dependencies.

Having an (external) mechanism allowing to override module requirements
appears very desirable to me.



2016-05-11 16:14 GMT+02:00 David M. Lloyd <david.lloyd at redhat.com>:

> 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
>


More information about the jigsaw-dev mailing list