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;}
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.
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.
> 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.
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.
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)
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.
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.
Great idea, although it is quite inconvenient that you have to tap/swipe to show the modern version (at least on mobile). Makes it difficult to compare.
As others have stated, there is no point in a "reveal". Simply show the comparison upfront. User interaction should not be necessary as it only needs to be a plain old html document. You didn't need to write any script. When I got through a bit of it, I wasn't sure if I accidentally skipped something or missed a nuance.
Maybe `ArrowLeft`/`ArrowRight` or `j`/`k` to flip through all of card pairs? Or just allow us to scroll through all the pairs. In either case, both old and new should be visible.
Anyone else getting annoyed by these statistics AI generated websites are adding to everything? Like in this example, “0 lines of Python”. What does that even mean?
Cool site though, but is it an ad for Copilot? Seems like it, and should be disclosed as such if that’s the case imo.
Re the Python thing, not really. I made that joke because originally yes the HTML generator was written in Python, but I deliberately asked to rewrite in Java.
Some of the improvements on that site were introduced in Java more than a decade ago.
Your attitude is exactly why I don't want to have to deal with the Kotlin ecosystem. The difference between Java and Kotlin in 2026 is negligible and the benefits don't weigh up to having to listen to Kotlin evangelists proclaiming it's superior the whole time.
Typeclasses are coming. And they will use them for growing the language such as operator overloading, collection literals, narrowing & widening types, etc.