[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jpa-dev] [jakarta.ee-community] [jakartaee-ambassadors] Re: Java Records and Jakarta EE
|
Not sure where we had this discussion before, but AFAIR we
concluded that records might be interesting for embeddables, but
for entities it's not possible to use records as the entity
lifecycle builds on the concept of mutability. Records could be
used for DTOs though, but to me that is a concept/layer on top of
entities. FWIW, Blaze-Persistence Entity-Views, which is such a
layer on top, supports records.
Having said that, Jakarta Persistence is a standard that
standardizes what has been proven good in implementations. So far,
correct me if I am wrong, there is no implementation that has out
of the box support for embeddable records. In Hibernate, we plan
to implement support for this and even have APIs for users to
actually implement this themselves until we come up with a generic
solution that works out of the box. We are not there yet, but
don't foresee any obstacles. It's just a matter of doing the work.
Even though I am very optimistic about making this possible, I
don't see this being added to the specification until we have a
compatible implementation. You can prepare TCK tests and
specification text for this though, and once an implementation is
ready for this, we can start integrating the changes into the TCK
and spec.
Cheers
Am 04.08.2022 um 11:36 schrieb Otavio
Santana:
Bring this discussion alive again.
This time, I put JPA and NoSQL on a copy as well.
IMHO:
As we agreed, the record feature is not a POJO, but it does not
mean it is irrelevant to support Jakarta EE, mainly on JPA or
NoSQL.
As Oliver already said, the current support brings some
limitations, mainly when we talk about OOP design. I'm not
talking only about records but aspects such as Data-oriented
programming.
Brian Goetz wrote about
Data-Oriented Programming in Java.
I also wrote my opinion about it.
If it's part of the Java Language then why
would there be a need to "adopt" something, we also don't
explicitly adopt enums or generics ;-)
Werner
Keil | JCP Award Winner,
JSR 354, 385 Maintenance Lead | Jakarta EE
Specification
Committee,
Ambassador
Leadership
Council Member
Twitter @wernerkeil | @UnitAPI | @JSR354 | @OpenDDR
|
#JakartaEE
Skype werner.keil
This is the nature of the Java language's
constructor chaining that we simply cannot circumvent.
I'm just thinking here after reading everybody's
comments that we need to change the behaviour of Java on
the language level before we can optimally adopt the
concept of Records in the Java enterprise
ecosystem, like the Jakarta EE specifications.
No, dear Guillermo, CDI requires a noarg
constructor even if you annotate a constructor
with args with @Inject! That's my point.
The reason is that CDI has to be
able to create a subclass, which has to call the
super constructor. So, if you use a constructor
with args with @Inject, you have to define an
additional separate empty constructor to satisty
CDI. So you have to write 2 constructors. If you
only use a noarg constructor, you don't have to
write any constructor - the JVM will create a
noarg constructor for you. But it won't create it
if you provide your own constructor. That
naturally makes it very cumbersome to write CDI
beans with constructor injection and softly forces
people to using field injection with noarg
constructor. Often not a best practise for many
Java developers.
Correct me if I'm wrong, but I
think CDI doesn't requre a no-arg
constructor, as long as you annotate @Inject
an alternative constructor with the required
dependencies.
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
Awesome, thanks for that, Reza!
--
Sent while on the run…
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.
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.
--
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/CACZTZYXHkQ6H58W-6kRhVF_%2B1gSNNdNYux-AFi3bbBfK_AVGoA%40mail.gmail.com.
--
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/CACZTZYUp%3Dt5zus2kdb32XdVXAavCjDhgE1oKZrRmgNMf373BBg%40mail.gmail.com.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
_______________________________________________
jpa-dev mailing list
jpa-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jpa-dev