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