Multi-version was [DRAFT: Project Jigsaw: The Big Picture (part 1)]

[Sebastian Sickelmann]

Am 22.12.2011 18:51, schrieb Jesse Glick:
> On 12/22/2011 10:17 AM, Sebastian Sickelmann wrote:
>> module baz {  // [you wrote bar initially but I think you meant baz]
>>   requires public foo @ 1.0;
>> }
>> module buz {
>>   requires baz; // Can also use foo's exported types
>>   requires foo @>= 2.0;
>> }
>>
>> The use case is: buz want to use functionality of baz.
>> baz also provides some functionality for which foo must be 
>> reexported. But buz is not using this functionality.
>> But buz uses some functionality in foo that is only supported since 
>> version 2.0 of foo.
>> Can buz override the reexported dependency of foo at 1.0 to foo@>=2.0?
>
> I guess this cannot work and the module system would just refuse to 
> load (or even install) this version of buz. The module system does not 
> "know" that buz is not using the part of baz referring to foo, so it 
> must assume that it is. And baz has declared that it cannot be used 
> with foo at 2.0, so you are out of luck. This is why the author of baz 
> needed to be as lenient as possible about the acceptable versions of 
> foo - or at least offer to publish a new version of baz based on foo at 2.0.
I'am knowing that trying to resolve that buz doesn't not need foo at 1.0 
cannot be made automatically. I see the reexport more than a "service" 
of the implementor/publisher/programmer of buz. If buz uses types of 
foo at 1.0 in it's public API than an reexport is a nice feature, so that 
the users of buz are not forced to require foo explicit.
>
> The situation is no different if baz does not use the 'public' 
> modifier on its import; buz still explicitly imports foo, and may 
> legally call those parts of baz referring to foo, with the expectation 
> that the class space is consistent. In other words, the "reexport" 
> feature is a mere convenience, and the underlying problem would exist 
> without it.

>
> Since Jigsaw does not normally support loading multiple versions of a 
> single module at once, the situation is no different even if baz's 
> public signature makes no mention of foo's types - if it merely uses 
> foo internally. A module system supporting parallel loading of old and 
> new versions of a single module could fix this if it could ensure that 
> all static linkages between modules passed consistent versions of 
> imported types. (An OSGi expert should discuss whether it can handle 
> this case and how.)
But what is the following design principle mean?

/>Static, single-version module resolution is usually sufficient/ — Most
 >applications do not need to add or remove modules dynamically
 >at run time, nor do they need to use multiple versions of the same
 >module simultaneously. The module system should be optimized
 >for common scenarios but also support narrowly-scoped forms of
 >dynamic multi-version resolution motivated by actual use cases
 >such as, /e.g./, application servers, IDEs, and test harnesses.

How can i achieve multi-version resolution?

>
> Jigsaw could also of course offer a mechanism for manually overriding 
> unsatisfied dependencies, in which case someone - either the author of 
> buz, or the author of the root module (the final app using buz), or 
> the user running the app - has to investigate _why_ the author of baz 
> did not advertise foo at 2.0 compatibility, what the actual compatibility 
> impact will be in the context of this app, and whether it is safe to 
> proceed anyway.
This is the minimum i would expect. As a user i need a way to override 
wrong decisions of the module author.

-- Sebastian