In Java 9's module declaration there are 2 constructs:
exports com.foo;
And
opens com.foo;
Where exports grants compile-time access, while opens allows runtime access, as reflection and resources.
opens has one leniency over exports that you can define the whole module as open, resulting the same as explicitly opening every package:
open module com.mod {
But there's no similar construct
exported module com.mod {
My Question: Why is it so; what decisions has been made to allow opening the whole module at once but not with exporting?
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.