Skip to main content
[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 
Hey, answers inline

Am 04.08.2022 um 15:44 schrieb Oliver Drotbohm via jpa-dev:

If you narrow your view to exactly that, JPA with exactly one implementation dominating the real-world deployments, sure. This is a slightly delicate situation as, if we apply your line of thinking, we're at the mercy of this team's idea of deciding what's worth building to decide when we can ask for stuff to be added to JPA.
I understand that the Spring team might not have to care about other parties that try to implement Spring APIs, but this is a specification implemented by a few compatible implementations from different parties, so my approach to this is, that we have to find some common ground first before putting something into a standard. The Hibernate team is and will work on innovations like this, but I personally don't think the Jakarta Persistence standard is the place for these innovations. Also, the standardization process AFAIU demands a compatible implementation, because what's the point of a standard if there is no proof that it can be implemented? I guess we also don't want to specify features that turn out to be impossible to implement efficiently.
AFAIU any compatible implementation can serve as basis for a new feature in the specification. So even if you think there is only Hibernate out there, you have to understand that it doesn't have to be Hibernate that provides support for this first in order for this feature to be eligible for inclusion into the standard. If you really want this feature in the standard, I think it's best to participate in one of the communities of the compatible implementations to make this happen as proprietary extension first, and then you can point to that as proof for doability when working on the standard. 


It's also ignoring that large parts of the persistence space outside of JPA (in particular Spring Data) have seen support for fully immutable types for both entities and embeddables for up to a decade and happily read and write records since their official release over two years ago.
Well, Spring Data or other technologies might not have this concept of an entity lifecycle which requires entity mutability, so it is easy to say that these "newcomers" which don't inherit this mutability requirement "happily read and write records".
I guess these "other large parts of the persistence space" usually implement some sort of active record style which can easily support immutability due to the lack of a transaction scoped persistence context. I don't have an opinion on this topic as I haven't thought about how this could fit into JPA yet, but if that is what you are aiming at, then please make that clear and then we could talk about this specifically. 


I guess you can imagine what impression this makes to the outside world if a JakartaEE specification as central as JPA needs more than two years to support a core language feature, when the entire world around it already does (not talking only Spring Data here, but the Jacksons and other data binding frameworks).
No idea what impression you think this makes. I personally didn't hear a lot of demand for immutable entities, but maybe this bubble of people doesn't communicate this demand to the developers of the ORMs clearly enough? 
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.




On Thu, Jan 13, 2022 at 3:15 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
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




On Wed, Dec 29, 2021 at 3:48 PM Edwin Derks <ederks85@xxxxxxxxx> wrote:
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.

On Sun, 5 Dec 2021 at 21:58, Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
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.

On Sun, Dec 5, 2021, 20:41 Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
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.

El dom., 5 dic. 2021 18:53, Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> escribió:
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.
--
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


--
Otávio Santana


twitter: http://twitter.com/otaviojava
site:     http://about.me/otaviojava



_______________________________________________
jpa-dev mailing list

jpa-dev@xxxxxxxxxxx

To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jpa-dev

⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.

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


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

Back to the top