[gzread]

Not many people know this, but you can also write

    public int x, y;

instead of

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

this is compatible with any language version

[brunoborges]

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.

[jaen]

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.

[uniq7]

> a trivial code migration on the side of the callee

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

[happymellon]

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.

[tadfisher]

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)

[happymellon]

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.

[brunoborges]

To be clear, Records don't have setters. They are immutable.

[happymellon]

Yeah, sorry, typo.

Still they institutionalise getters, which is the opposite of what their argument was.

[tadfisher]

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

0: https://en.wikipedia.org/wiki/JavaBeans

[throwA29B]

>immutable

>setters

sigh

[dwroberts]

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.

[jghn]

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.

[stuaxo]

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.

[jghn]

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.

[leapingdog]

Anything relying on beans for (de)serialization via reflection (XML; JSON) were the big incentive in the J2EE space if I recall correctly.

[jghn]

Yes. And I believe it kept going with Spring.

But those were mistakes imposed by frameworks. Not a necessity for good language usage.

[leapingdog]

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