The rationale for runtime modularization

Reinier Zwitserloot reinier at
Fri Dec 4 14:55:57 UTC 2015

On Fri, Dec 4, 2015 at 1:19 AM, <mark.reinhold at> 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

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

More information about the jigsaw-dev mailing list