On 27/08/2014 15:36, David M. Lloyd wrote:
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.
java.sql.Driver.getParentLogger() and methods defined by java.sql.SQLXML
are the reasons for this.
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.
There are several JEPs in progress or coming that that should reduce
over time the need for some applications and libraries to make direct
use of JDK-internal APIs. This should help with some of the
implementation sharing in the JDK too but it won't eliminate it completely.
The details on how encapsulation will be done is not this JEP. I think
it would be reasonable to assume that if someone is using Core
Reflection and has permission to use setAccessible(true) then access
checks will be suppressed.
-Alan.
