Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

It seems to be Java orthodoxy at this point that one should basically never use public fields for object state. (I don't necessarily agree, but that's not relevant to my question.) Given that, would it be right to say that from where we are today, it's clear that Java's public fields were a mistake/flaw of the language design? Or is there a rational argument that they're a useful and important part of the language, even today?


Update: I know about the more elegant approaches, such as in C#, Python, Groovy, etc. I'm not directly looking for those examples. I'm really just wondering if there's still someone deep in a bunker, muttering about how wonderful public fields really are, and how the masses are all just sheep, etc.

Update 2: Clearly static final public fields are the standard way to create public constants. I was referring more to using public fields for object state (even immutable state). I'm thinking that it does seem like a design flaw that one should use public fields for constants, but not for state… a language's rules should be enforced naturally, by syntax, not by guidelines.

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, jwenting, GlenH7, Kilian Foth Sep 29 '14 at 6:48

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

What is your basis that they are indeed a flaw? – Aaron McIver Feb 21 '11 at 18:48
Is there a different way to create symbolic constant expressions in Java now? – Crazy Eddie Feb 21 '11 at 18:53
@Aaron I wasn't stating that they're a flaw, I was stating that I've perceived it to be orthodoxy at this point that one should never use public fields. That perception may be wrong, but it is indeed what I've perceived. – Avi Flax Feb 21 '11 at 20:44
@Crazy Eddie I forgot about that use, I was thinking more of the more common use of fields, state. I'll edit the question. – Avi Flax Feb 21 '11 at 20:45

6 Answers 6

up vote 10 down vote accepted

I like them, as long as the field is final and is only used internally in the application, not exposed in an API for other applications. This keeps your code shorter and more readable.

You should not expose public fields in an API because by exposing public fields, you also expose the implementation. If you expose it as a getXXX() method instead, you could change the implementation without changing the API interface. E.g. you could change and get the value from a remote service, but the applications that uses the API doesn't need to know this.

This is a viable design for public final fields in immutable classes.

From Effective Java:

Item 14: In public classes, use accessor methods, not public fields

...if a class is package-private or is a private nested class, there is nothing inherently wrong with exposing its data fields. This approach generates less clutter than the accessor-method approach.

While it's never a good idea for a public class to expose fields directly, it is less harmful if the fields are immutable.

See also Why shouldn't I use immutable POJOs instead of JavaBeans?

share|improve this answer
Just wondering, what are your reasons for not exposing it in an API? – Steven Jeuris Feb 21 '11 at 19:20
@Steven: Because by exposing public fields, you also expose the implementation. If you expose it as a getXXX() method instead, you could change the implementation without changing the API interface. E.g. you could change and get the value from a remote service, but the applications that uses the API doesn't need to know this. – Jonas Feb 21 '11 at 19:37
@Jonas: Those are generally not candidates for constants in the first place. – Steven Jeuris Feb 21 '11 at 19:39
@Steven: I'm not talking about constants in the first place but public final fields in immutable classes. E.g. see Why shouldn't I use immutable POJOs instead of JavaBeans? – Jonas Feb 21 '11 at 19:41
@Jonas: That's a nice use case as well! Perhaps it's helpful to update your answer a bit to clarify. – Steven Jeuris Feb 21 '11 at 20:27

Before IDEs became widespread, making all your fields public was a powerful tool to create prototypes/proofs of concepts quickly.

Nowadays there's very little excuse for using them, when you can generate a getter/setter pair with a click of the mouse.

share|improve this answer
But 10 public final fields is more readable than 10 getXXX() methods. – Jonas Feb 21 '11 at 19:44
@Jonas Yeah, but we're not talking about final fields here. If your public final fields are also static, they are constants, and a const keyword would be enough, if they aren't static, they are a serious violation of encapsulation. – biziclop Feb 21 '11 at 20:04
@biziclop according to Wikipedia: "although reserved as a keyword in Java, const is not used and has no function" – Avi Flax Feb 21 '11 at 20:51
@Avi Flax Yeah, but it could have been used to mark constants, thus eliminating the need to declare constants as public fields. – biziclop Feb 21 '11 at 20:59
Assuming a getter/setter pair is at all appropriate, that is. It often isn't. – David Thornley Feb 21 '11 at 21:15

I think public fields are okay for a class that is essentially a value type like a complex number or a point, where the class does little more than group primitive types together like a C-style struct and maybe define a few operators.

share|improve this answer
java.awt.Point and friends are a bit of a nightmare. – Tom Hawtin - tackline Feb 22 '11 at 2:22
@TomHawtin-tackline: The problem with Point is that it's ambiguous whether a variable of type Point is supposed to encapsulate a locations, or is supposed to encapsulate the identity of an entity with a location that can change. Conceptually, I would regard code which passes around Point to be much like code which passes around arrays. – supercat Dec 23 '13 at 20:33
So if I get a Point and modify it, I should expect the object it refers to to cleanly update on screen? No, the problem with Point is that it is mutable. We had String/StringBuffer but the idea didn't seem to get through. / Passing arrays around does have similar problems. – Tom Hawtin - tackline Dec 24 '13 at 8:42

To define public constants it is still useful. E.g.

public static final int DAYS_IN_WEEK = 7;

However, do still prefer enum's where possible. E.g.

public enum Day {

To simulate simple struct classes it is also useful. No reason to create a getter and setter for every field, when they are all public anyhow.

class Point
    public int x, y;
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
share|improve this answer
But then again, many would argue structs have no place in a language like Java... – delnan Feb 21 '11 at 19:22
@delnan: They are almost the same as JavaBeans, but JavaBeans is much more verbose and not threadsafe. See Why shouldn't I use immutable POJOs instead of JavaBeans? – Jonas Feb 21 '11 at 21:20
Some Android specific observations: Enums are slower to evaluate than ints and should be avoided . Also, fields frequently accessed by setters and getters in tight loops can also benefit from being public. – Nailer Feb 22 '11 at 8:37

The use of get/set method pairs is the tragic historical design flaw. I can't think of another language that implements properties as verbosely and inefficiently.

share|improve this answer

This is subjective, but my opinion is that the whole public/private notion is outdated and backwards.

In python there's no public/private; everything is public basically. Hasn't caused many problems.

In Java you tend to create pointless getters/setters for each field to avoid the sin of marking them "public". (IMHO if you find yourself doing that you should just mark them public).

share|improve this answer
Python does allow you to mark things as private by prefixing the names with __. It's not 100% private, since there are still ways to access those variables and methods, but then in C# you can do similar things with reflection. – Adam Lear Feb 22 '11 at 6:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.