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

[Rony G. Flatscher]

Thanks to everyone who commented and/or shed some light about the situation for objects that need to
invoke/access protected members in superclasses. The conclusion is, that nothing will change as
protected members are still regarded to be public members for subclasses or objects of subclasses.
In my case that is fine as I have adhered to allowing access to public members (and protected ones
from subclasses or subclass instances) in the Java bridge.

Being in the process of tidying up various development threads in the beta version of the bridge
(including adding javax.script/jsr-223 support) of the past two years, I want to make sure that the
GA-version scheduled for April will be able to be fully usable with Java 9 that will appear
thereafter (currently in July). Therefore I have been lurking around jdk9-dev and jigsaw-dev and
reading the informal description I was unsure how non-public members get treated in this particular
case. Or with other words, there is nothing I have to take into account for and/or need to change
because of #AwkwardStrongEncapsulation which is great! :)

Of course, other tooling, JVM languages and other bridges may meet different needs and employ
different techniques, so it has also been interesting to see and to learn about them and what
changes for them with Java 9, what problems they have to master and what means are being explored to
do so. (And BTW it has been very interesting and motivating to see the constructive communication
culture in these lists from all involved parties!)

---rony


On 14.12.2016 09:07, Alan Bateman wrote:
>
>
> On 14/12/2016 07:30, Peter Levart wrote:
>> Hi David,
>>
>> On 12/14/2016 07:17 AM, David Holmes wrote:
>>>> But let me explain why .setAccessible(true) can't be allowed for
>>>> protected members in general.
>>>
>>> I'm confused as to what is being argued for/against here. 
>>
>> Rony asked why .setAccessible(true) can't be used for protected members even if called from a
>> subclass of the member's declaring class.
> Right, I think it would be helpful if Rory could paste in a stack trace from where setAccessible
> is failing so that there are specifics to discuss.
>
> -Alan