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
