| Re: [jpa-dev] [jakarta.ee-community] [jakartaee-ambassadors]Re:Java Records and Jakarta EE |
Hi, Several in this thread including myself spoke about records being Transfer Objects like DTOs as a good usecase and what you said here backs that ;-) So it seems that Spring Data or other Frameworks do just that, but not use a record as an Entity. That does not mean records have to be a dependency of that actual Spec or API, any Jakarta EE 10 implementation is more than welcome to do that including Spring which plans to implement „some“ specs in the near future. If you think of any improvement to the spec itself, then propose it, from Jakarta EE 11 onward it is likely the minimal Java version could be 17 or similar, and there even in the API records might be used, if there is a strong Benefit. Regards, Werner Von: Oliver Drotbohm via jpa-dev Hi, > On 4. Aug 2022, at 15:50, Werner Keil <werner.keil@xxxxxxx> wrote: > > What do you mean by „and happily read and write records“? They’re immutable, so how does Spring Data or other Frameworks outside Jakarta EE make them writeable? Exactly what I wrote: you can read data into records and write data with records as input. It seems you're conflating two different things here: whether *data* is immutable or whether the *data structure* that data is loaded into is immutable. These are different things. You can – and it often makes sense – load mutable data into immutable data structures. What is considered a "mutation" in mutable thinking would simply result in a new instance of the object with the new state. That having the benefit of both old and new state being able to exist at the same time to e.g. compare the states of one with the other in domain code. Take that in contrast with for example a JPA-managed entity: once you change the state of an instance loaded, entityManager.find(id, MyType.class) will return that changed instance, which is terribly confusing to a lot of developers as they run into this pretended "the object is the state of the database" which it sort of is but at the same time isn't as the change might not be persisted eventually. I am not even saying that this is terribly wrong. There are lot of developers that are expert enough on JPA to know about this and who are fine working with mutable types, i. e. the way JPA works and was designed. I was just arguing that working with immutable types to access data is neither rocket science nor unchartered territory at all and the lack of ability to use JPA with those is one (not necessarily the primary) reason for teams I see moving away from it. Cheers, Ollie |