141–150 of 294 posts
Earlier quoted context omitted.
It can be done in theory, but the JVM does nothing of the sort right now.
False. The JVM already does quite a good job with escape analysis, and record types just add extra semantic information to potentially further improve the situation.
Earlier quoted context omitted.
You are supposed to create a new copy with some of the fields changed. Just like you do it with the java.time.* classes and others.
Instead of changing few bytes, now I have to copy hundreds of bytes around and add more stuff for GC to collect. Well, they have to obey Wirth's law, I guess.
Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?
Earlier quoted context omitted.
It can be done in theory, but the JVM does nothing of the sort right now.
False. The JVM already does quite a good job with escape analysis, and record types just add extra semantic information to potentially further improve the situation.
Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?
I personally never had to do this so I'm not sure if this is a real benefit.
IF you're not on Java 14 yet (70% of industry?[1])... this post shows two other alternatives for Lombok: https://medium.com/@vgonzalo/dont-use-lombok-672418daa819 Autovalue & Immutables [1] https://snyk.io/wp-content/uploads/jvm_2020.pdf pg 5
Unfortunately AWS Lambda doesn't support 14 yet :/
Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?
Earlier quoted context omitted.
1 million is not a lot. I'd begin by asking myselves "can I afford to chase those pointers?", because maybe you can.
No, because my competitors who are attempting to fill the same orders I am attempting to fill are not chasing pointers.
Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?
The only answer that makes any sense is this one from Brian Goetz.[1] Namely, that it's a workaround to support mutable fields of otherwise immutable objects.
To be honest, allowing you to override the methods on an immutable, auto-generated class to inject custom accessor logic feels like an immediate retreat from the conceptual goal of providing an immutable record implementation in the first place.
[1] https://stackoverflow.com/questions/66702223/why-do-java-rec...
Earlier quoted context omitted.
Sure of what? If your code is not garbage it takes two seconds to see where things change. It should be very places in the code.
It takes two seconds in a hello world demo. It takes probably more in a millions of lines project.