2/18/2026 at 1:17:15 AM
Not many people know this, but you can also write public int x, y;
private int x, y;
public int getX() {return x;}
public void setX(int x) {this.x = x;}
public int getY() {return y;}
public void setY(int y) {this.y = y;}
by gzread
2/18/2026 at 3:16:54 PM
In many cases, yes, public fields are fine. But there are limitations:- Can't synchronize access. `synchronized` keyword is not applicable to fields, only to methods and code blocks.
- Can't proxy. Not possible in public fields, therefore can't intercept calls before state is changed. This is useful for example in mocking frameworks, and telemetry libraries.
- Can't evolve. Methods allow encapsulation, which allows evolution of the implementation detail. For code base where the public field is accessible by consumers only within the same code base, this may be fine. But for shared libraries, it can easily become a problem.
by brunoborges
2/18/2026 at 6:11:38 PM
but...1. Synchronizing on trivial properties (otherwise you couldn't use `public` anyway!) is an anti-pattern, as it's a too fine-grained unit of concurrency and invites race conditions.
2. Can't proxy without rewriting byte code, you mean.
3. Of course you can evolve, it's just a breaking ABI change so it requires a trivial code migration on the side of the callee. If the cost of that migration is too high, something else is wrong.
by jaen
2/19/2026 at 1:51:34 AM
> a trivial code migration on the side of the calleeIf your library is used by multiple consumers, forcing all them to migrate is not trivial, no matter how simple the change is.
If your income comes from these customers, it is not a good idea to put every one of them in the situation of having to choose between updating their code or stoping being your customer.
by uniq7
2/18/2026 at 6:01:37 AM
And the second you have anything other than a toy application you'll find out why getters, setters, and validation were invented, and why we them just moved everything to have consistent interfaces.by happymellon
2/18/2026 at 6:30:08 AM
This is the meme where the Padawan exposes public fields, the intermediate says you must use setters and getters, and the Jedi just exposes public fields.(Records kind of made this moot, and for the better)
by tadfisher
2/18/2026 at 10:54:29 AM
Except records are immutable and have getters and setters as builtins to replicate what we've been doing with Lombok.So enforces what I was saying.
by happymellon
2/18/2026 at 3:02:12 PM
To be clear, Records don't have setters. They are immutable.by brunoborges
2/19/2026 at 10:44:27 AM
Yeah, sorry, typo.Still they institutionalise getters, which is the opposite of what their argument was.
by happymellon
2/19/2026 at 7:08:09 PM
Well, they don't have "getters" either, they have accessors; x() instead of getX(). It's still bad, but at least it doesn't enforce JavaBeans conventions, which is where getters and setters actually originate [0].by tadfisher
2/18/2026 at 2:05:05 PM
>immutable>setters
sigh
by throwA29B
2/18/2026 at 1:00:32 PM
I think getters and setters had more value when IDEs and refactoring tools were worse (or non-existent).A free-for-all accessing some public field is now less of a risk because it’s trivial to find all references and change them.
by dwroberts
2/18/2026 at 5:29:39 PM
Have worked on many a non-toy java application. Have never used things like Lombok hiding getters/setters behind the covers. Never found this to be a real world problem.by jghn
2/18/2026 at 10:41:04 AM
I'm from the ancient years of Java, surely this must have started at some point ?Do you get getters and setters ?
I left Java around version 5.
by stuaxo
2/18/2026 at 5:28:28 PM
The more modern take is to not bother with getters & setters for most things. People were cargo-cutting getters/setters on every variable without thinking about the implications.First off, there's the question of if most things should even *allow* updates or just be immutable.
Second, what's the discernable difference between `public final int foo` and `private final foo` w/ `public int getFoo()`. Nothing really. The claim was always "but what if you want to update `foo` to be something more complex? The pain that these advocates always suggested never really wound up being much of a real world problem.
by jghn
2/18/2026 at 6:20:02 PM
Anything relying on beans for (de)serialization via reflection (XML; JSON) were the big incentive in the J2EE space if I recall correctly.by leapingdog
2/19/2026 at 1:18:49 AM
Yes. And I believe it kept going with Spring.But those were mistakes imposed by frameworks. Not a necessity for good language usage.
by jghn
2/18/2026 at 5:26:40 PM
Records [0] are a modern form of data transfer object. They are immutable though.[0] https://docs.oracle.com/en/java/javase/17/language/records.h...
by leapingdog