JEP 200: The Modular JDK

[mark.reinhold at oracle.com]

2014/8/27 7:36 -0700, david.lloyd at redhat.com:
> On 08/26/2014 09:05 AM, Alan Bateman wrote:
>> 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)?
> 
> The "java.sql" module seems to export "java.logging" though I can't find 
> a reason for it.

java.util.logging.Logger appears in the types of a few public methods in
java.sql, e.g., java.sql.Driver::getParentLogger [1].

>                   Also it's not super clear that the dependency on 
> "java.xml" is necessary (though I guess it's probably harmless) since I 
> would say *most* users are not using the XML functionality of JDBC, and 
> if they are, they're going to be importing this API anyway.

The java.sql.SQLXML interface references types in the java.xml module.

>>> 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.
> 
> We actually had a similar capability for similar reasons but found that 
> it fails for a couple reasons:
> 
> 1. It fails as a security mechanism, as the security is trivially defeated
> 2. It has always been possible to solve these abstraction issues in a 
> simpler way
> 3. If users want access to a module, they will get it, one way or 
> another (this bar is after all far lower than language-level access 
> controls)

Perhaps it's not clear in the JEPs but our intent is, in fact, to
enforce module boundaries via access-control checks in the VM rather
than simple visibility checks in class loaders (which are, as you point
out, trivially defeated).

- Mark


[1] http://docs.oracle.com/javase/8/docs/api/java/sql/Driver.html#getParentLogger--