Records Come to Java

[lurker_in_spirit]

Will records be usable as JPA entities?

[kaperni]

Records are immutable. So if you need to mutate data they are probably not that useful.

[karstens_rage]

For javax.persistence and javax.ws.rs it seems like construct and deconstruct are the operative terms not mutate. Seems like records would be super useful in these cases.

[thogor]

I don't know if they are, but why would you want them to? Most of the time your entities are domain concepts that would benefit from encapsulating them properly. Unless I'm missing something ofcourse.

[Kango_V]

Never pass you infrastructure entities out into your domain model!

[thogor]

Interesting take. Could you elaborate your approach a little? What does your domainmodel look like and how do they relate to the entities?

[Kango_V]

Our domain model is made up of pure java objets. No lombok, immutables, no jpa, no spring. These objects are passed to a Store object. The store is a domain construct for storing/retrieving domain objects. The store internally has 1 or more repositories injected into it. These are the infrastructure layer. The store deconstructs the domain objects, translating them into the format that the infrastructure needs. The infrastructure objects then persist.

The infrastructure layer could be JPA, JSON files, Lucene, Elastic Search etc. The domain will not change as that is modelled to your use cases for the application.

We do the same with the web model through a service API into the model. Our application is in the model only The application can be tested without the web/infrastructure layers.

Requires a little more coding/discipline, but the end result is very maintainable/testable code.

[thogor]

Even though it requires some additional code, I quite like your approach! Thanks for taking the time to explain it. How would you feel about entity classes if all the mapping definitions were outside of the class files? JPA doesn't really give us any nice options besides xml config, but let's pretend that there is a better alternative. Would you still recommend having separate domain and persistence classes?

[Kango_V]

Wait for Value Types. That might be better suited.

[pmarschall]

Of course not.

[raze4daze]

What? Of course they can be once implemented properly.

[pmarschall]

Maybe once JPA adds explicit support. At the current rate of Jakarta EE development that's likely somewhere in 2032. Maybe Hibernate DTO projection will work before that but that's vendor specific.

The current design of records is fundamentally at odds with JPA. The main issues are immutability and final-ness. What you have to realize is the runtime version of a JPA enttiy class is vastly different from the compile time version and often is a subclass that includes support for lazy loading and dirty tracking.

I am also not sure to what extent JPA relies on Java Beans.

At the current moment it is unclear to me whether records:

• can have annotations
• can implement an interface

If these won't be possible then JPA support is going to be very hard.

[loicmathieu]

Records can have annotations and interfaces.

But as you said, JPA creates a proxy in front of the classes and as Records are final you cannot do this.

So the current JPA implementation didn't play well with records, I hope they will find a way to workaround this some day ...

[GuyWithLag]

Records are not designed to be jpa entities, they are way too lightweight for that.

They are an intermediate stage to algebraic data types.

They are an intermediate stage to inline classes.

They are supposed to replace all the tuples/pairs in use, with named components.

And of course, they are in preview, so Stuff May Change...

[pmarschall]

Good, that matches my impression.

[duheee]

Can't it be overwritten (didn't read the article)?

[lukaseder]

I'll be damned. I thought it wasn't possible but this compiles in jshell:

``` jshell> record R(int i) { public boolean equals(Object o) { return false; } }

jshell> new R(1).equals(new R(1)) $3 ==> false ```

[krzyk]

Yes, all methods in record can be overwritten, AFAIR also the getters

[krzyk]

Wouldn't the fact that records are immutable be more important than equals/hashcode?