JEP 200: The Modular JDK

[Alan Bateman]

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.