2014/8/27 7:36 -0700, david.ll...@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--
