[deleted]
Java.evolved: Java has evolved. Your code can too
21–30 of 40 posts
Re: Java.evolved: Java has evolved. Your code can too
#22Not 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
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.
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.
Re: Java.evolved: Java has evolved. Your code can too
#23What's still missing: - typeclasses/implicits - HKTs - for comprehension - macros/quasiquotes powerful enough to implement my custom reflection
I was bored so I came up with my own for comprehension: https://github.com/pivovarit/for-comprehension4j
Re: Java.evolved: Java has evolved. Your code can too
#24Earlier quoted context omitted.
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)
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.
>immutable
>setters
sigh
Re: Java.evolved: Java has evolved. Your code can too
#25Great 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.
Hey mate, what UX would you suggest? Happy to explore ideas! For a better visualization to compare old/new, just click on the card and it will open that particular pattern in a new page.
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.
Re: Java.evolved: Java has evolved. Your code can too
#26Earlier quoted context omitted.
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)
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.
To be clear, Records don't have setters. They are immutable.
Re: Java.evolved: Java has evolved. Your code can too
#27Not 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
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.
Re: Java.evolved: Java has evolved. Your code can too
#28Why is "modern approach" changing user threads to virtual threads?
To not worry about system threads. Just create VTs freely without concerns with memory, pooling, etc.
Re: Java.evolved: Java has evolved. Your code can too
#29What's still missing: - typeclasses/implicits - HKTs - for comprehension - macros/quasiquotes powerful enough to implement my custom reflection
I will be happy to take in new patterns: https://github.com/javaevolved/javaevolved.github.io/issues
Re: Java.evolved: Java has evolved. Your code can too
#30Not 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
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.
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...