JEP 200: The Modular JDK

[David M. Lloyd]

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.  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.

>> 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)

In other words, none of the above points make this functionality 
*necessary*.  As long as code is shipped in the JDK, someone is going to 
want to use it.  If you mark it as "unsupported", maybe migrating over 
the existing "proprietary API" warning, it will be of far more practical 
use to far more users than trying to turn this into a security 
mechanism.  The historically better way (IMO) to get users to not use 
proprietary APIs is to provide equivalent or better functionality in the 
language and/or SDK.

-- 
- DML