Use-cases for version ranges?

[Brian Pontarelli]

On Nov 21, 2011, at 6:17 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 17/11/2011 23:52, cowwoc wrote:
>> :
>> 
>> Is there a way to get module A to see log4j 1.0 and module B to see log4j
>> 1.1 (using separate ClassLoaders)?
>> 
>> 
> With Jigsaw then the conflict will be caught when you attempt to install/configure a module with an entry point and that module ultimately requires more than one version of a module. Such a scenario is considered a "bug", possibly caused by overly restrictive version constraints. The one scenario where it may make sense is the container case, say a test harness or a web container that requires one version of a module and the test or application running in the container requires a different version. This isn't implemented in Jigsaw (not yet anyway) but is a scenario that is called out in the requirements document [1].

I was referring to this case when talking about module isolation. If module A depends on log4j 1.0 and module B depends on log4j 1.1, they should not conflict if the modules complete isolate that dependency from all other modules. However, if module A or B has a public interface like this one, it breaks down:

public interface ModuleStuff {
  Logger getModuleLogger();
}

This is where version compatibility comes into play. The build and runtime dependency management system would select 1.1 as long as the log4j team has certified that it is compatible with 1.0. In Savant we call this "minor" compatibility. Savant uses a well know versioning scheme and compatibility system.

-bp