On 12/11/2016 8:16 AM, Rony G. Flatscher wrote:
On 23.11.2016 12:55, Alan Bateman wrote:
As people on this mailing list know, jake has the changes for
#AwkwardStrongEncapsulation [1]
where setAccessible has been changed so it can't be used to break into
non-public members/types in
exported packages of JDK modules. It was changed more than a year ago to fail
when attempting to
use it to break into non-exported packages. Dialing it up further is a
disruptive change that will
expose a lot of hacks and issues with existing code that is used to accessing
non-public
fields/methods in JDK classes. It will take some libraries and tools a bit of
time to digest this
change, even with the --add-opens command line option and Add-Opens manifest in
application JAR
files to keep existing code going. I plan to send mail to jdk9-dev in advance
of this integration
to create wider awareness of this change.
-Alan
[1]
http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation
Would #AwkwardStrongEncapsulation inhibit setAccessible to work on protected
methods (in addition to
private and package private members) as well?
As subclasses are allowed to access protected members in their superclasses,
setAccessible should
work for protected methods in classes that are invoked for objects that are
instances of their
subclasses?
The ability of protected members to be accessed from outside their
package means they are essentially public members for the purposes of
inheritance and reflection. So, setAccessible should work for protected
members of exported packages. I know what you mean about the receiver
object being of the correct class, but that's outside the capability of
setAccessible to check, so I don't believe it is checked.
Alex
