On 14/12/2016 14:30, Jochen Theodorou wrote:
:
I don't intend to get access to hidden API after all... just exported.
If you only interested in accessing the types and members that you have
access to in these exported packages then you don't need setAccessible
of course. We have seen a few cases, not many, where code uses
setAccessible for performance reasons but I don't know if this is what
you are thinking about here.
Which leaves us with: you want this change and I am unhappy with it. I
don't see a technical reason for the limit.
Strong encapsulation has always been a goal of this project. If you let
setAccessible be used to suppress access and get at any member of any
type then it makes a mockery of that. The initial attempt at a
compromise in 2015 was to have it fail when attempting to break into any
member of any type in non-exported packages. That is what has been in
JDK 9 for some time. The problem with this compromise is that it makes
it impossible to encapsulate the internal implementation that is in
exported package - if you read the JSR issue then you'll see the example
of code breaking into java.lang.invoke.MethodHandles.Lookup to get at
its private constructor and using that to create full power lookups with
a lookup classes in non-exported packages. You'll also see the
unworkable concern that module authors will be forced to move all their
internals to non-exported packages. This is what
#AwkwardStrongEncapsulation is about. Hopefully it's a bit clearer now.
-Alan
