module readability and exceptions in api

[Michał Zegan]

Hello,
I have following 2 questions:
1. Reflection and MethodHandles throw exceptions deriving from
java.lang.ReflectiveOperationException, that are checked exceptions.
However, the whole module related api throws unchecked exceptions. What
is the actual reason/motivation for using unchecked exceptions? Are
checked exceptions being discouraged, or what?
2. What is the use for Module.addReads and
ModuleLayer.Controller.addReads methods? Module a can access module b
only if a reads b, however:
- in normal cases, the module graph is statically determined, and when
code in module a calls code in module b, then module b probably should
not be optional with a readability edge added at runtime, because we
risk things like IllegalAccessError or NoClassDefFoundError... or
whatever else when code in a calls code in b when b either does not
exist or we have no readability edge. Also such dynamic addition of
readability edges would require special support from module class
loaders to update their... package to class loader mappings to cover the
new module
- in case of such an optional dependency, I believe module a would
access b either through some public api defined in another module, but
reachable from both (and that would not require adding readability
edge), or through reflection (but in this case readability edge is
implied), or both