For data records that do not change, and where you need a unique object instance per record, Java Records can work fine. They have less overhead than regular Java objects. However, if you only need to process one record at a time from a serialized stream of records, it is still much more efficient to deserialized each record into a reused object instance. That way you only ever have one object in memory, regardless of how many records are in the stream. However, for that to be possible the reused object must be mutable - and Java Records are immutable. Thus, Java Records are such a semi-nice language addition, but if you want max performance / optimal memory usage, Records come with some annoying limitations. Yes, I know that these limitations enable more compact memory usage in some situations, but not in all (as outlined above).
I know that these limitations enable more compact memory usage in some situations Jakob, would you consider writing a blog to explain these situations. I would like to read your thoughts on this. Thanks for all the work on Jekov Tutorials
I am truly amazed when thinking how much effort and thought is put just into this one proposal to bring records live. Honestly, I will feel very much grateful to the life when I reach that level of awareness of Java ecosystem to be able to think of the same level and details about proposals. Awesome work, awesome feature. Thank you for explanation!
Records components are accessed using *accessor methods*. An accessor is a method whose name is the component name itself. That method is by design a no-param method and hence the `()`. It's a bit unfair to call those `()` boilerplate, no ? ;-)
@@delabassee I know what an accessor method is. It's absolutely boilerplate, and given that records require all fields to be final, it's absolutely a blunder. I would rather use a normal class with real natural fields. Then I only have to write the boilerplate once, within that class, instead of on every use.
@@cmyanmar13 I think we are comparing apples to oranges... Records are a special kind of classes with some well defined constraints (vs. plain-old regular classes) and in exchange, you get benefits (ex. simpler and safe serialisation as explained in this video). In the end, the boilerplate reduction is just a (very nice) side-effect. Records are data-carrier, if you can't live with the constraints they have (ex. immutability), you should use regular classes, I agree. But it's hard to say that there's no boiler-plate reduction, no? **YT removed a link to nice example in JDK17 :( ** Also, and that's important, let's not forget that Records are part of a more global plan (inc. Records patterns
Java does not support hidden features like property listeners in C# by design. If you don't like boilerplate code in Java, you need to check out Lombok framework. But I must warn you, that if you build something more or less complex with Lombok, maintainers of this project will not remember you with good words =)
@@askarkalykov While Java is notorious for lacking properties and instead inflicting horrible setter/getter fluff, records are immutable. So they could have trivially made the fields public. Complete blunder.
For data records that do not change, and where you need a unique object instance per record, Java Records can work fine. They have less overhead than regular Java objects. However, if you only need to process one record at a time from a serialized stream of records, it is still much more efficient to deserialized each record into a reused object instance. That way you only ever have one object in memory, regardless of how many records are in the stream. However, for that to be possible the reused object must be mutable - and Java Records are immutable. Thus, Java Records are such a semi-nice language addition, but if you want max performance / optimal memory usage, Records come with some annoying limitations. Yes, I know that these limitations enable more compact memory usage in some situations, but not in all (as outlined above).
I know that these limitations enable more compact memory usage in some situations
Jakob, would you consider writing a blog to explain these situations. I would like to read your thoughts on this. Thanks for all the work on Jekov Tutorials
I am truly amazed when thinking how much effort and thought is put just into this one proposal to bring records live. Honestly, I will feel very much grateful to the life when I reach that level of awareness of Java ecosystem to be able to think of the same level and details about proposals. Awesome work, awesome feature. Thank you for explanation!
Thank you very much for the video. Well explained.
Glad it was helpful!
wow records in Java
TL;DR: Java safely serializes and deserializes records using knowledge of their components.
Do Java records really impose this annoying boilerplate of forcing you to add `()` every time you want to read a field??? What a design blunder.
Records components are accessed using *accessor methods*. An accessor is a method whose name is the component name itself. That method is by design a no-param method and hence the `()`.
It's a bit unfair to call those `()` boilerplate, no ? ;-)
@@delabassee I know what an accessor method is. It's absolutely boilerplate, and given that records require all fields to be final, it's absolutely a blunder. I would rather use a normal class with real natural fields. Then I only have to write the boilerplate once, within that class, instead of on every use.
@@cmyanmar13 I think we are comparing apples to oranges... Records are a special kind of classes with some well defined constraints (vs. plain-old regular classes) and in exchange, you get benefits (ex. simpler and safe serialisation as explained in this video). In the end, the boilerplate reduction is just a (very nice) side-effect. Records are data-carrier, if you can't live with the constraints they have (ex. immutability), you should use regular classes, I agree.
But it's hard to say that there's no boiler-plate reduction, no? **YT removed a link to nice example in JDK17 :( **
Also, and that's important, let's not forget that Records are part of a more global plan (inc. Records patterns
Java does not support hidden features like property listeners in C# by design. If you don't like boilerplate code in Java, you need to check out Lombok framework. But I must warn you, that if you build something more or less complex with Lombok, maintainers of this project will not remember you with good words =)
@@askarkalykov While Java is notorious for lacking properties and instead inflicting horrible setter/getter fluff, records are immutable. So they could have trivially made the fields public. Complete blunder.