On 26/08/2014 14:22, David M. Lloyd wrote:
We've found that when it comes to deciding when to or when not to
re-export an API dependency of another API module, the criteria comes
down to whether the importing API makes use of the imported API's
types directly in its API classes. If not, then re-exporting is
generally counter-productive. By this standard, there may be more
re-exporting going on than strictly necessary or desirable in this
document.
I think you are touching on design principle #3 in the JEP.
Do you have any specific examples where you see needless re-exporting
(in the graph then it's the darker edges)?
As a matter of principle I'm generally opposed to exporting specific
module packages only to specific other modules. I think this
indicates that a module split is required. I'm guessing that at the
root of this problem is an attempt to avoid circular dependencies
during compilation, but I would rather that issue not be punted to the
runtime.
For legacy code bases such as a JDK then this is useful and important.
There are some areas that are more tightly coupled that would be if
starting afresh. The most obvious example of where you might export
something to only specific modules is sun.misc. It's JDK-internal but
used in many areas of the JDK.
-Alan.
