Java.evolved: Java has evolved. Your code can too(javaevolved.github.io)
javaevolved.github.io
Java.evolved: Java has evolved. Your code can too
https://javaevolved.github.io
39 comments
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.
- 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.
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.
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.
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)
(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.
So enforces what I was saying.
To be clear, Records don't have setters. They are immutable.
Yeah, sorry, typo.
Still they institutionalise getters, which is the opposite of what their argument was.
Still they institutionalise getters, which is the opposite of what their argument was.
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
0: https://en.wikipedia.org/wiki/JavaBeans
>immutable
>setters
sigh
>setters
sigh
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.
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.
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.
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.
Do you get getters and setters ?
I left Java around version 5.
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.
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.
Anything relying on beans for (de)serialization via reflection (XML; JSON) were the big incentive in the J2EE space if I recall correctly.
Yes. And I believe it kept going with Spring.
But those were mistakes imposed by frameworks. Not a necessity for good language usage.
But those were mistakes imposed by frameworks. Not a necessity for good language usage.
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...
[0] https://docs.oracle.com/en/java/javase/17/language/records.h...
[deleted]
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.
[deleted]
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.
For a better visualization to compare old/new, just click on the card and it will open that particular pattern in a new page.
Can you add a page where its just a list of all of them in a format like that? https://imgur.com/a/iO42lrs
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!
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!
Done, updated!
Click to toggle. Hard to go back to „old“ version on mobile.
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.
What are you hiding information for? Just show both modes at the same time.
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.
Why 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.
[deleted]
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.
https://github.com/javaevolved/javaevolved.github.io/tree/ma...
https://github.com/javaevolved/javaevolved.github.io/tree/ma...
Cool. Java is catching up with Kotlin at last
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.
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.
What's still missing:
- typeclasses/implicits
- HKTs
- for comprehension
- macros/quasiquotes powerful enough to implement my custom reflection
- typeclasses/implicits
- HKTs
- for comprehension
- macros/quasiquotes powerful enough to implement my custom reflection
Typeclasses are coming. And they will use them for growing the language such as operator overloading, collection literals, narrowing & widening types, etc.
I will be happy to take in new patterns: https://github.com/javaevolved/javaevolved.github.io/issues
I was bored so I came up with my own for comprehension: https://github.com/pivovarit/for-comprehension4j
instead of
this is compatible with any language version