In Java 9\'s module declaration there are 2 constructs:
exports com.foo;
And
opens com.foo;
Where
A module's exports define its API, which should be deliberately designed and kept stable. An "exported module" could easily and inadvertently change its API by adding, removing, or renaming packages, which would go against the stability goal. (This is essentially the same reason why there are no "wildcard exports" like exports foo.bar.*
).
Open packages, on the other hand, do not really define a module's API. Sure, code can depend on functionality that is only accessible via reflection, but the Java community generally sees reflection as a "hack" when used to access internals.
Its much wider (and more beneficial) use is to access an artifact to provide a service for it (XML/JSON serialization, persistence, dependency injection, ...). In such cases, the code reflecting over the module does not depend on it and is hence not broken by moving stuff around. There is hence less reason to keep the opened packages stable, which makes a free-for-all approach like open modules feasible.