JEP 200: The Modular JDK

[Alan Bateman]

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.