Conflicting module versions

[Martijn Verburg]

On 5 February 2015 at 13:00, <mark.reinhold at oracle.com> wrote:

> 2015/2/5 12:40 +0000, david.lloyd at redhat.com:
> > I agree that working dependency resolution is a necessity for a working
> > software system.  But, it is my opinion that run time is far too late
> > for this to occur (and I intend to carry this opinion into the JSR
> > working group).  Ultimately it is up to the module distributor to ensure
> > that their distribution contains a cohesive module set.  While it is
> > possible to efficiently add certain types of validation checks at run
> > time, by this time it is far too late to do anything about a violation
> > other than just fail.
>
> Broadly speaking, I agree.  At run time a module system should prevent
> broken situations such as conflicting module versions.  It need not,
> however, attempt to solve them -- that's really hard, and it generally
> requires human intervention in order to identify the correct version.
> Simply failing in such scenarios (with a good error message, of course)
> is perfectly acceptable.
>

I'll add my +1 to this - we also run across this situation on numerous
occasions and
for me I have strong preference to choose myself how to resolve the clash
as I have
the best knowledge of what versions I want in my app.

At the moment we run careful Maven dependency scans at build time and other
interesting
classloader hacks at runtime to do this detection (when we operate with 3rd
libs at runtime
that we didn't provide).

It would be awesome to have the module system tell me about these clashes
as opposed to
our runtime classloader hacks which are prone to all sorts of edge case
failures anyhow.

Cheers,
Martijn



>
> - Mark
>