Field access methods are not called when persisting Java 16 records
See original GitHub issueWhen new Java record is persisted using repository’s save
method field access methods of the record are not called to read state of the passed record.
Minimal reproducible example: hajdamak/spring-data-jdbc-record-access
Requires Maven and JDK17.
Call mvn spring-boot:run
.
Relevant output:
Saving record ...
Constructor is accessed: (null, 0, test)
Constructor is accessed: (5f5b5ea0-3c8c-4ea3-88d1-b02142d2b9b3, 1, test)
Constructor is accessed: (5f5b5ea0-3c8c-4ea3-88d1-b02142d2b9b3, 1, test)
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (5 by maintainers)
Top Results From Across the Web
5 Record Classes - Java - Oracle Help Center
A record's fields are final because the class is intended to serve as a simple "data carrier". For example, here is a record...
Read more >Java Records - How to use them with Hibernate and JPA
Hibernate can persist final classes and doesn't require any accessor methods for mapped entity attributes. But it still requires a default constructor and...
Read more >Why do Java Records have accessor methods instead of ...
It's generally best practice to use accessor methods instead of direct field access. Even with records, it makes sense to continue that ...
Read more >A closer look at Java 16 Records in practice - Patrik Fredriksson
Instances are immutable, so there are no mutators. Also, records are implicitly final and cannot be subclassed. Except for static fields, it is ......
Read more >Java 16 and IntelliJ IDEA - The JetBrains Blog
IntelliJ IDEA Configuration. Access sample code used in this blog post · Implicit members added to a record · Why use records ·...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
There are efforts to optimize these accesses even more by generating Java code ahead of time with Spring Native/Spring AOT. These efforts could help to avoid runtime class generation in the first place but performance-wise it would lead to the same profile and it would not change the amount of classes loaded at runtime.
I suppose I wanted to have cake and eat it too. 😉 Have standard calls and at the same time avoid manual
Converter
implementation. But I guess if fields are accessed using generated bytecode then all performance benefits are already in. And Java is not expressive enough to have standard calls without manualConverter
implementation and without additional bytcode magic.