On Fri, Dec 4, 2015 at 1:19 AM, <mark.reinh...@oracle.com> wrote: > Strong encapsulation at run time greatly improves both > * security* and maintainability. (Strong encapsulation at compile time > makes it much easier to prepare for strong encapsulation at run time.) >
Is there a blogpost or documentation I can peruse that explains why you say this? Because I don't see it. How does strong encapsulation improve security in any meaningful way that isn't already covered by the 'private' keyword? The one and only way you're ever going to access (execute / read / set) a private member is with the explicit fiat of the securitymanager. Therefore, if there IS a security manager, it is trivial to just blanket deny this access. If there is NO security manager, then there is no security to speak of anyway – free to access the file system, open network ports to almost anything, and more. With reflection I can still list private members, but it is unlikely that mere knowledge of the names of the fields and methods is a security issue. Even if it is, trying to call for example .getDeclaredFields() on a j.l.Class instance that did not originate from your own loader will also require consent from the security manager. What am I missing? --Reinier Zwitserloot
