Encapsulation, Exports and Non-interference

[Petter Måhlén]

Given my recent concern on the jigsaw-dev mailing list, I was really happy
to see the non-interference requirement. I wonder if that could be
strengthened further, together with exports and encapsulation.

As things currently work, if you add a jar file to the classpath, any
packages/classes defined in that jar file 'clobber' the global class
namespace, potentially leading to versioning mismatches. Would it be
feasible to strengthen the requirements on encapsulation, exporting and
non-interference so that:

1. Exporting becomes recursive: modules must export also which modules they
require in their API.
2. Non-interference is extended to include not just packages defined in a
module (let's call it A), but also modules that are required but not
exported by A.
3. Encapsulation is extended in a similar way to non-interference.

That is, if module A uses classes from module B in its exported API, users
of module A are also necessarily users of module B. But if module A uses
module C internally, but not in its exported APIs, a user of module A
doesn't need to know about C at all. Most importantly, classes defined in C
don't automatically become globally available.

If a module requires two other modules and both those modules export
different versions (both source module and version should agree) of the
same package, then the linker should raise a warning at least.

A concern I have is that point 1 might become onerous for module
maintainers and thus not done well. It seems like it could be automated as
it should be perfectly possible for a tool to determine which transitive
dependencies should and should not be exported.

Another concern is regarding how common warnings/errors due to version
mismatches will be. If there are too many, warnings will be disregarded and
errors would make the system unusable. I suppose the frequency depends on
how often required modules are implementation details vs actually used in
the published API. I have a feeling the former is more common.

Regards,
Petter