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