Java.evolved: Java has evolved. Your code can too(javaevolved.github.io) |
Java.evolved: Java has evolved. Your code can too(javaevolved.github.io) |
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;}
- 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.
(Records kind of made this moot, and for the better)
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.
Do you get getters and setters ?
I left Java around version 5.
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.
[0] https://docs.oracle.com/en/java/javase/17/language/records.h...
For a better visualization to compare old/new, just click on the card and it will open that particular pattern in a new page.
I would love to just scroll through a page without having to click on individual cards to see both side by side.
Love the overall idea of what you did!
https://github.com/javaevolved/javaevolved.github.io/tree/ma...
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/implicits
- HKTs
- for comprehension
- macros/quasiquotes powerful enough to implement my custom reflection
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.
But those were mistakes imposed by frameworks. Not a necessity for good language usage.
So enforces what I was saying.
Still they institutionalise getters, which is the opposite of what their argument was.
>setters
sigh