StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <ul> <li>What are the truly legitimate uses for <code>setAccessible</code>?</li> </ul> </blockquote> <p>Unit testing, internals of the JVM (e.g. implementing <code>System.setError(...)</code>) and so on.</p> <blockquote> <ul> <li>Could Java has been designed as to NOT have this need in the first place?</li> <li>What would the negative consequences (if any) of such design be?</li> </ul> </blockquote> <p>Lots of things would be unimplementable. For example, various Java persistence, serialization and dependency injections are reliant on reflection. And pretty much anything that relies on the JavaBeans conventions at runtime.</p> <blockquote> <ul> <li>Can you restrict <code>setAccessible</code> to legitimate uses only?</li> <li>Is it only through <code>SecurityManager</code>? </li> </ul> </blockquote> <p>Yes.</p> <blockquote> <ul> <li>How does it work? Whitelist/blacklist, granularity, etc?</li> </ul> </blockquote> <p>It depends on the permission, but I believe that the permission to use <code>setAccessible</code> is binary. If you want granularity, you need to either use a different class loader with a different security manager for the classes that you want to restrict. I guess you could implement a custom security manager that implements finer grained logic.</p> <blockquote> <ul> <li>Is it common to have to configure it in your applications?</li> </ul> </blockquote> <p>No.</p> <blockquote> <ul> <li>Can I write my classes to be <code>setAccessible</code>-proof regardless of <code>SecurityManager</code> configuration? <ul> <li>Or am I at the mercy of whoever manages the configuration?</li> </ul></li> </ul> </blockquote> <p>No you cannot, and yes you are.</p> <p>The other alternative is to "enforce" this via source-code analysis tools; e.g. custom <code>pmd</code> or <code>findbugs</code> rules. Or selective code review of code identified by (say) <code>grep setAccessible ...</code>.</p> <p><strong>In response to the followup</strong> </p> <blockquote> <p>None of my classes have any semblance of enforceable privacy what-so-ever. The singleton pattern (putting doubts about its merits aside) is now impossible to enforce.</p> </blockquote> <p>If that worries you, then I suppose you need to worry. But really you should not be trying can <em>force</em> other programmers to respect your design decisions. If they are stupid enough to gratuitously create multiple instances of your singletons (for example), they can live with the consequences. </p> <p>And if you mean "privacy" to encompass the meaning of protecting sensitive information from disclosure, you are also barking up the wrong tree. The way to protect sensitive data is not to allow untrusted code into the security sandbox that deals with sensitive data. Java access modifiers are not intended to be a security mechanism.</p> <blockquote> <p><String example> - Am I the only one who thinks this is a HUGE concern?</p> </blockquote> <p>Probably not the <strong>only</strong> one :-). But IMO, this is not a concern. It is accepted fact that untrusted code should be executed in a sandbox. If you have trusted code / a trusted programmer doing things like this, then your problems are worse that having unexpectedly mutable Strings. (Think logic bombs ...)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload