Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

[Alan Bateman]

On 26/09/2016 12:36, Andrew Dinn wrote:

> :
> I addressed that in the text you snipped. The one point of relevance is
> that which the original poster asked about:
>
>    -- Why do we need Jigsaw to constrain access control when we can do so
> using a security manager?
>
> Do you (or anyone else involved in defining and implementing Jigsaw)
> have an answer to that question?
This project updates the Java Language to support modules. The access 
checks that we are talking about happen at compile time and run time. 
The access checks happen irrespective of whether there is a security 
manager or not (and of course there is no equivalent at compile time). 
I'm not sure that there is much more to say on this, the security 
manager is not really relevant to what we are doing here.


>
> Also, you have used the phrase twice now so I have to ask. Where does
> the notion that the "legacy security manager mechanism" is actually a
> legacy mechanism come from? Is it to be retired? Or are you just saying
> that you think it ought to be legacy because you think Jigsaw makes it
> redundant?
Sandboxing with a security manager is legacy and has been highly 
problematic for a long time. It has not been retired although I think a 
good discussion for elsewhere on whether it should be deprecated. The 
only connection to modules is that strong encapsulation makes the 
platform more secure. Modules is not a replacement for the security manager.


> :
> I find your account of the specification to be very misleading then. Of
> course code employing reflection has to protect against IAE because the
> methods it uses include it as a checked exception. But the core
> reflection API is also specified to provide setAccessible and it has
> always been possible to rely on that method to ensure that IAE does not
> actually get thrown in a large and well-defined set of cases.
I was trying to point out that core reflection has always been specified 
to do the same access checks as the Java Language..

The setAccessible method is for suppressing Java Language access checks. 
As I've said elsewhere, then changing this to align with the proposal 
for #AwkwardStrongEncapsulation is a very disruptive change and there 
many issues to work through.

> :
>
> To describe a severe reduction of that set of cases with the words
> "there is nothing really here" seems to be even more misleading than
> your partial account of the specified API. Given that this has been the
> topic of intense discussion and debate here for the last few months I
> find it hard to understand how you expect to wave it away with such
> light words. Perhaps it would be better if you provided those who are
> concerned by this change with a better account of why it really is
> needed -- or maybe even considered working towards some more limited
> change that attempt to meet both their needs and yours.
>
There is is nothing being waved away or taking lightly. This project has 
a stated goal to provide support for strong encapsulation. This has a 
lot of implications that we've trying to work through. We of course know 
that strong encapsulation isn't for all modules, hence the proposal on 
the JSR list to provide a simple means to get the benefits of reliable 
configuration without opting in to strong encapsulation.

-Alan