Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

[John Rose]

Thanks, Andrew, for a good summary of the practicalities behind
access overrides.

On Jul 18, 2016, at 2:34 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> The wider the access, the more scope for complex interfaces.
> 
> Also, making a method or field globally accessible may mean that the
> author of the code can no longer guarantee its correctness.
> 
> … we can reduce risk and the size of attack surfaces

I especially agree with these parts, from bitter experience.  When you
widen an interface, you add attack surface.  If you widen an interface
with clear documentation and buy-in from the author of the interface,
and can add both negative and positive tests for the new API surface,
then you can sleep at night.  Meanwhile, the best attack surfaces are
implicitly defined (e.g., privates which aren't really private after all)
and are activated by remote control (e.g., setA), without the buy-in
of the library author.

I'm not saying this to condemn frameworks which perform polymorphic,
pattern-driven access overrides, but to explain their special risks.  And
I think in the future we will have a much more explicit and robust set
of rules for opt-in and opt-out into such frameworks, including optioning
which is delegated to third parties, yet is still limited to a small subset
of what is available to root privileges (aka. setA).

Finally, as JIT guy, I'd like to note that one way to crisply evaluate
the "weight" of an API surface given away by some "fancy feature"
(ubiquitous override-ables, dynamic loading, monitor-per-object, AOP,
access overrides, …) is to see how many optimizations it makes difficult
or impossible.  Yes, Java is wonderfully plastic, and yes, we need to
supply hardening transformations so the plastic can be made durable.

— John