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
