Are Java's public fields just a tragic historical design flaw at this point? [closed]

Question

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?

Thanks!

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.

Answer 1

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?

Answer 2

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.

Answer 3

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.

Answer 4

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 {
    SUNDAY, MONDAY, TUESDAY, WEDNESDAY, 
    THURSDAY, FRIDAY, SATURDAY 
}

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;
    }
}

Answer 5

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.

Answer 6

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).