Thanks, Andrew, for a good summary of the practicalities behind access overrides.
On Jul 18, 2016, at 2:34 AM, Andrew Haley <a...@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
