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