What is the purpose of access modifiers if they can be bypassed with reflection?

Question

I understand that using access modifiers is an important practice when writing Java (or most) code, but isn't it effectively made redundant by the fact that you can bypass these modifiers using reflection?

For example, if I want to protect my objects sensitive variables by setting them to private and providing accessor methods, someone can still easily come in and bypass this using reflection, and potentially set unsafe values. Why does Java provide access modifiers, and then a tool to bypass them? It seems it would just be easier to not use either.

Antebellum

Why do you lock your door when I still can break in? – Natant

You can also configure a SecurityManager to prevent reflection. – Gates

You'll find that a lot of the big Java frameworks out there, like Hibernate and Jackson use reflection under the hood to analyse your objects and work out how to handle them without you needing to specify their behaviour in minute detail. If you really, really want to prevent reflection accessing the internals of your objects you can always create a security policy that stops it. – Thunderpeal

Access modifiers mostly prevent people from accidentally doing things they are not supposed to. You can't really prevent a determined "attacker" from deliberately doing something they are not supposed to. If they set a value by reflection and the library/framework/whatever doesn't work as intended then tough. – Dingman

@Natant I see your point - to make it harder? But is this not like locking the door and giving you the spare key? – Antebellum

Makes a lot of sense, thanks @Dingman – Antebellum

Like Michael explained, making it harder is really a reason, but you can prevent accidents and you show how you intend how your code is supposed to be used by "whom" (classes) and "where" (the packages). – Natant

“…you can bypass these modifiers using reflection” —Not if the targeted class is in a different, unopened module. – Saffron

@Saffron with the current version, you can still do it when the accessing code is in the unnamed module. – Campball

@Campball you can't, like java internal modules do not expose anything even via reflections to other modules - as they are not open, and you can't access them without hacking stuff with unsafe or other magic. – Tall

@Tall as long as the default of the –illegal-access option is permit, code in the unnamed module can access these internals via Reflection. In JDK 11, this is still the case. You only get a warning printed on the command line. – Campball

@holger just tested and I got error when accessing fields of unsafe field accessor that internal.reflection module is not open for unnamed module – Tall

@Campball java.lang.reflect.InaccessibleObjectException: Unable to make field protected final java.lang.reflect.Field jdk.internal.reflect.UnsafeFieldAccessorImpl.field accessible: module java.base does not "opens jdk.internal.reflect" to unnamed module @39fb3ab6 With default jvm 11, you can still use reflections to access typical internals of java API, like private fields of Field class, but other internal classes that are not part of api are not open. – Tall

@Tall there is no internal.reflection module. Perhaps, you mean the internal.reflection package within the java.base module. As you noted yourself, some artifacts are specially protected, some are even hidden. But this doesn’t change the fact that the general module protection is disabled by default (otherwise, that special protection was not necessary). – Campball

Answer 1

A significant purpose of access modifiers is to structure the code and help users of that code understand and use it effectively and correctly. This is different from serving as a tamper-proof security mechanism. For this reason, it is not contradictory to have both access modifiers and reflection. Writers of the code can express their intent using access modifiers, and code that needs to bypass them, for whatever reason, can do this with the usual risks and implications.

Aghast

Answer 2

I think the advantages of modifier is that you know much faster how to use a file/library. You can't access private fields/methods without reflection.

For the case you want to prevent attackers to use reflection the JVM has a security mechanism that allows you to define restrictions to code through a Java security policy file. It will use the default one unless you specify otherwise.

Run your application using a SecurityManager and a sufficiently restrictive security policy, policy can be found here.

You may find this tutorial useful: http://docs.oracle.com/javase/tutorial/essential/environment/security.html

Inebriety