Are private, public, protected modifiers still essential in Java?

Question

With the introduction of Reflection API we now can freely access any private fields as we wish.

For example :

Field f = obj.getClass().getDeclaredField("stuffIWant");

So now, what if we eliminate all modifier and set a common rule for Java developers to not access field directly but via getter/setter ? Obviously one can violate the rule but even if we have modifiers, we can still access them without using modifiers.

By "now" you mean "basically forever" right? Why would you want to throw away abstract/encapsulation, just because it *can* be circumvented? Reflection is a powerful tool but should be used rarely. Access modifiers make our lives more productive (and less risky) in the 99.9% case. — Jon Skeet, Jul 14 '17 at 06:42
Just because you _can_ do something doesn't mean you _should_. The API designer probably decided to add the modifiers they did for a reason. — NilsH, Jul 14 '17 at 06:43
Alternatively: "Cars *can* exceed the speed limit. So why do we have speed limits at all? Shouldn't we just legally allow everyone drive as fast as they like, and hope that people actually limit themselves?" — Jon Skeet, Jul 14 '17 at 06:43
If the majority of developers agree on the common rule, say, access fields via getter/setter only then there is no need for modifiers. I'm not saying they are useless, I just wonder what happen if we eliminate them ? — Kha Nguyễn, Jul 14 '17 at 06:46
You do know that access modifier can be used on much more methods, not only getter and setter? And you do know that people are extremely lazy and when a setter validates the value, the developer wouldn't care about providing valid values and use the field directly. It's like saying, let's remove all laws, because everyone knows certain things are illegal/"unwelcome" and trust no one would do bad things. That obviously doesn't work. Neither in general nor in programming only. — Tom, Jul 14 '17 at 06:49
@Jarrod: Is this really a duplicate? It seems clear to me the OP isn't asking for the different between the visibility modifiers? — Matt, Aug 08 '17 at 12:11

GhostCat · Answer 1 · 2017-07-15T15:37:03.310

Wrong mindset.

The fact that you can override certain protection levels at runtime doesn't mean that you are suddenly supposed or allowed to write bad source code now (or in the future).

You don't use these keywords to establish guarantees at runtime. That is a desired side effect, but not the real point of these keywords. You mainly use them to express intention! To make your source code better to understand for human readers. That has nothing to do with what you can do at runtime using reflection.

Giving another example: the javac compiler will turn your source code into byte code; and the JVM just-in-time compiler will turn the java byte code into machine code at some point. When we follow your logic - should we stop writing programs in Java, and instead write machine code directly? You know, because at runtime, there will be only machine code anyway? ( I know, not the greatest comparison, it is only meant to underline the fact that runtime features have nothing to do with source code content).

Beyond that: there is still a Security Manager around that might prevent you from disabling this protection.

And I hope you understand that using reflection should only be done in very specific corner cases. Reflection is a performance killer; it is extremely cumbersome to use, and also very error prone. It is one of these features of Java that you only use when you have no other choice. It is not in the set of "normal" tools that you pick for "everyday tasks".

Finally: the module concept that java 9 introduces will no longer allow you to access anything inside a module - only the public exported elements will be accessible. And that is true for reflection as well. It is a bit more complicated, and there are command line switches to change behavior - but the times when could easily get anywhere are basically numbered.

“there is still a Security Manager”—[it won't last](https://bugs.openjdk.java.net/browse/JDK-8264713)… Seems, the module system will be the last resort for controlling Reflection. A module can access another module’s private members via Reflection if the particular package has been *opened* to the accessing module. — Holger, Nov 10 '21 at 18:40

score 0 · Answer 2 · edited Jun 20 '20 at 09:12

With the introduction of Reflection API we now can freely access any private fields as we wish.

Just because reflection is there, doesn't mean that you have access to it.

No you cannot. Unless you distributed your code without any Security Manager (with defined secure policy) one can do these kind of unsafe/slower operations. However you can still stop them to do so as well.

The security manager is a class that allows applications to implement a security policy. It allows an application to determine, before performing a possibly unsafe or sensitive operation, what the operation is and whether it is being attempted in a security context that allows the operation to be performed. The application can allow or disallow the operation.

Permissions fall into these categories: File, Socket, Net, Security, Runtime, Property, AWT, Reflect, and Serializable. The classes managing these various permission categories are java.io.FilePermission, java.net.SocketPermission, java.net.NetPermission, java.security.SecurityPermission, java.lang.RuntimePermission, java.util.PropertyPermission, java.awt.AWTPermission, java.lang.reflect.ReflectPermission, and java.io.SerializablePermission.

Are private, public, protected modifiers still essential in Java?

2 Answers2