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.
Are Java's public fields just a tragic historical design flaw at this point?
java;design;history;api;languages
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?