Re: [jakarta.ee-community] [jakartaee-ambassadors] Re: Java Records and

[Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx>]

I definitely agree with Oliver:

JPA requiring default constructors pretty much everywhere *is* a severe limitation to the entity design for dozens of reasons. Records make that pretty obvious. So while of course you can argue Persistence doesn't "need " to do anything regarding this aspect, but I think it should. Because improving on this would broadly benefit Persistence, not only in persisting records

And this isn't only in JPA, also CDI requires no-arg constructors and virtually any specification which uses the concept of POJOs. It's good that you, Reza, raised this as an issue on JPA github, I commented there. But I think this should be addressed for the whole platform so that we have a unified solution on how to approach it and apply it through all the related specs.

I agree it's a different topic, but it's almost as important not only to address new Java features but also improve support for old features. Objects with no-arg constructors are a completely valid Java construct and there's little reason not to support them if it's possible. And I believe there are legitimate solutions with hacks to support them as I outlined on the JPA github issue.

Moreover, it seems to me that no-arg constructors aren't the only issue with Java records and JPA (and most Jakarta EE specs). The more profound problem is immutability and no inheritance, which prevents creating subclasses to create proxy classes / interceptors. JSON-B doesn't care as it only cares about creating objects. JPA needs that entities are not final but that's only to support for lazily loaded fields, which isn't required to be supported by implementations. On the other hand, CDI heavily relies on creating proxies, I don't see how a Java record instance could have any CDI scope other than Dependent or Application. I think there's no way around it and we have to live with that. 

So, to summarize, compared to what most Jakarta EE specifications expect from POJOs, java records:

• Don't have a no-arg constructor
• Are final (that doesn't matter to some specifications but is really an issue to some other specifications)

The first can be dealt with, the second can be only worked around - I don't see any transparent way to work with final classes in some specifications like CDI.

Ondro

so 4. 12. 2021 o 19:56 Oliver Drotbohm <odrotbohm@xxxxxxxxxx> napísal(a):

Awesome, thanks for that, Reza!

--

Sent while on the run…

Am 04.12.2021 um 19:39 schrieb Reza Rahman <reza_rahman@xxxxxxxxx>:



At any rate, I have filed this (mostly as a way to not forget about the discussion): https://github.com/eclipse-ee4j/jpa-api/issues/338.

On 12/4/21 12:24 PM, Reza Rahman wrote:

While I think of it as a separate issue, I definitely think the default constructor requirement should be revisited. It does make domain models more awkward sometimes. I do however look at it as a low priority issue.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

 

---

From: jakarta.ee-community <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Oliver Drotbohm <odrotbohm@xxxxxxxxxx>
Sent: Saturday, December 4, 2021 12:11 PM
To: Jakarta EE community discussions
Cc: jakartaee-ambassadors@xxxxxxxxxxxxxxxx
Subject: Re: [jakarta.ee-community] Java Records and Jakarta EE

 

Hi,

> Am 04.12.2021 um 17:46 schrieb Reza Rahman <reza_rahman@xxxxxxxxx>:
>
> Here is some preliminary analysis and discussion for Persistence: https://github.com/kalgon/jpa-records/issues/1. The gist is that I don’t think Persistence needs to do anything right now, but there may be value in looking into a standard utility that can convert to and from Records.

There are a couple of misconceptions in the README of the project, which I've commented on here [0].

JPA requiring default constructors pretty much everywhere *is* a severe limitation to the entity design for dozens of reasons. Records make that pretty obvious. So while of course you can argue Persistence doesn't "need " to do anything regarding this aspect, but I think it should. Because improving on this would broadly benefit Persistence, not only in persisting records.

Cheers,
Ollie

[0] https://github.com/kalgon/jpa-records/issues/3

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

--
You received this message because you are subscribed to the Google Groups "Jakarta EE Ambassadors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jakartaee-ambassadors+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/69E3C2B5-27DA-4681-845D-58875A101736%40vmware.com.