Question ad #AwkwardStrongEncapsulation (Re: Moving the changes in jake to jdk9/dev
blackdrag at gmx.org
Wed Dec 14 14:30:05 UTC 2016
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.
More information about the jigsaw-dev