DO I NEED TO WORRY ABOUT THIS???
That depends entirely on what types of programs you’re writing and for what kind of an architecture.
If you’re distributing a software component called foo.jar to the people of the world, you’re completely at their mercy anyway. They could modify the class definitions inside your .jar (through reverse engineering or direct bytecode manipulation). They could run your code in their own JVM, etc. In this case worrying will do you no good.
If you’re writing a web-application that only interfaces with people and systems via HTTP and you control the application server, it’s also not a concern. Sure the fellow coders at your company may create code that breaks your singleton pattern, but only if they really want to.
If your future job is writing code at Sun Microsystems/Oracle and you’re tasked with writing code for the Java core or other trusted components, it’s something you should be aware of. Worrying, however, will just make you lose your hair. In any case they’ll probably make you read the Secure Coding Guidelines along with internal documentation.
If you’re going to be writing Java applets, the security framework is something you should be aware of. You’ll find that unsigned applets trying to call setAccessible will just result in a SecurityException.
setAccessible is not the only thing that goes around conventional integrity checks. There’s a non-API, core Java class called sun.misc.Unsafe that can do pretty much anything at all it wants to, including accessing memory directly. Native code (JNI) can go around this kind of control as well.
In a sandboxed environment (for example Java Applets, JavaFX), each class has a set of permissions and access to Unsafe, setAccessible and defining native implementations are controlled by the SecurityManager.
“Java access modifiers are not intended to be a security mechanism.”
That very much depends on where the Java code is being run. The core Java classes do use access modifiers as a security mechanism to enforce the sandbox.
What are the truly legitimate uses for setAccessible?
The Java core classes use it as an easy way to access stuff that has to remain private for security reasons. As an example, the Java Serialization framework uses it to invoke private object constructors when deserializing objects. Someone mentioned System.setErr, and it would be a good example, but curiously the System class methods setOut/setErr/setIn all use native code for setting the value of the final field.
Another obvious legitimate use are the frameworks (persistence, web frameworks, injection) that need to peek into the insides of objects.
Debuggers, in my opinion, don’t fall into this category, as they normally don’t run in the same JVM process, but instead the interface with the JVM using other means (JPDA).
Could Java has been designed as to NOT have this need in the first place?
That’s a pretty deep question to answer well. I imagine yes, but you’d need to add some other mechanism(s) that might not be all that preferrable.
Can you restrict setAccessible to legitimate uses only?
The most straight-forward OOTB restriction you can apply is to have a SecurityManager and allow setAccessible only to code coming from certain sources. This is what Java already does – the standard Java classes that come from your JAVA_HOME are allowed to do setAccessible, while unsigned applet classes from foo.com aren’t allowed to do setAccessible. As was said before, this permission is binary, in the sense that one either has it or not. There is no obvious way to allow setAccessible to modify certain fields/methods while disallowing others. Using the SecurityManager you could, however, disallow classes from referencing certain packages completely, with or without reflection.
Can I write my classes to be setAccessible-proof regardless of SecurityManager configuration? … Or am I at the mercy of whoever manages the configuration?
You can’t and you most certainly are.