Are private members really more “secure” in Java?

Question

Learning Java I was sometimes taught to use the private access modifier so as not to expose "sensitive information" to other classes, as if this could open a legitimate security hole. But I've never encountered a situation in which restricting member visibility was more than a convenience for modelling a program in an object-oriented fashion.

Are private fields and functions in Java classes actually more "secure" than otherwise?

---

EDIT -- Compilation of best answers.

Why private does not mean "secure":

• decompilers allow static look at bytecode
• reflection library allows runtime access to private members

What private is good for:

• maintainability of code due to forcing method-level access
• modularity of code by hiding implementation details

Answer 1

I think the meaning of "security" by your instructor was not about keeping hackers out, but rather keeping bugs out. By making everything as private as possible, you limit the ways that one class can mess with another class without it knowing. This is an example of Modular Programming.

Answer 2

Btw: reflection in Java actually allows you to override access modifiers of fields of objects. See javadoc and an example.

Answer 3

I've never heard of it -- in any serious sense -- as a security issue. I mean, decompilers work. You can use them to figure out what's going on inside the bytecode.

Having private members is a maintainability issue. If I only give you method-level access to my internals, then my only responsibility is to ensure that my API methods continue to work. I'm not locked into using a Double versus a BigDecimal on the insides, so long as my methods continue to return Doubles (for instance).

Answer 4

Obviously the principles of making everything private where possible only apply if you adhere to the open-closed principle otherwise if people get used to the idea of editing the internals of existing classes instead of extending them they may well change the encapsulation of private member variables be it through making them accessible through mutators and accessors or changing the access modifier.

Answer 5

private isn't really for security, since reflection can bypass it (modulo classloader/secure classloader stuff). It serves as an indication of intent, and as barrier to one type of programming error.

But consider a third-party API--API users don't even see the private properties or methods. It's not just about your own code, it's about what code is exposed to others. (Again looking at it from a "I'm not trying to break in to the code" standpoint.)

Answer 6

As far as security goes, the answer is "not really": determined hackers could get to your private fields and call your private functions with a little bit of reflection; all they need is a JAR with your code in it.

Although hiding "sensitive" information does not make your class more secure, it makes it (along with systems built from it) a lot more maintainable. So this answer is not an excuse for making all members of your classes public.