Question ad #AwkwardStrongEncapsulation (Re: Moving the changes in jake to jdk9/dev

[Jochen Theodorou]

On 13.12.2016 23:17, Peter Levart wrote:
[...]
> You might have access to a protected method, but you can not delegate
> that access to a 3rd party unless you make the Method object
> .setAccessible(true) and pass it to the 3rd party as a capability. (I
> recommend using MethodHandle(s) for such delegation of rights instead of
> reflection though).

that is unlikely to happen

> But let me explain why .setAccessible(true) can't be allowed for
> protected members in general.
>
> Jigsaw establishes strong encapsulation. What that means is that even
> without a SecurityManager present, code should not be allowed to gain
> access to a member beyond what is allowed by accessibility rules of Java
> language unless that member is in a class in an open package or such
> access is willingly delegated to code by some other code.

I am aware of this. For me it is more a question of how far strong 
encapsulation is supposed to go and you can understand strong 
encapsulation in a module system in different ways as well.

I don't intend to get access to hidden API after all... just exported.

[...]
> You can't perform the access check for a protected
> instance member without knowing the 'targetClass' (the runtime class of
> the target instance).

sure, I already commented on this part with: why do access checks for 
this at all? Your answer is because of strong encapsulation and my 
comment for that is that you guys are maybe overdoing it a bit. Which 
leaves us with: you want this change and I am unhappy with it. I don't 
see a technical reason for the limit.

bye Jochen