DRAFT: Project Jigsaw: The Big Picture (part 1)

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

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

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.