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
