Java Records and Jakarta EE

[Reza Rahman]

I am changing the subject line and expanding the audience. I hope that is OK.

There are a number of specifications that should do due diligence with regards to alignment with Records in detail such as: JSON Binding, XML Binding, Persistence, Faces, Bean Validation and CDI.

Otherwise, someone should undertake the effort to write a series of tests to ensure things work correctly with scenarios involving these APIs and even perhaps throughout others too such as Jakarta REST and Messaging. This has been in my to-do list but frankly my bandwidth is not infinite for a middle aged developer with a demanding day job and a family. Some help would be most welcome.

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.

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@eclipseorg> on behalf of Ivar Grimstad <ivar.g...@eclipse-foundation.org>
Sent: Saturday, December 4, 2021 3:32 AM
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] [jakartabatch-dev] Proposal - Use Java 11 source/target level for Batch 2.1

 

So, I'm kind of interested in turning this discussion around a little.

Given:

- You can develop your application with Java 17

- You can deploy your application to a Jakarta EE implementation that is certified and runs on Java 17

- This means that your application can use all Java 17 features you want, compile, and run on Java 17

What Java 17 features would improve the Jakarta EE APIs, and which specification does it make sense to add them?

Here's one example: Full support for Records in Jakarta JSON Binding

Today, you can simulate the Java Bean pattern by prefixing the field names with "get", but this is kind of an annoying workaround:

public record Greeting(String getName, String getMessage) {} is serialized to { "name": "", "message": "" }

Anything else?

Ivar

On Sat, Dec 4, 2021 at 6:51 AM Adam Bien <ab...@adam-bien.com> wrote:

Reza -> IMO Java 17 is a must!  My clients are already using Java 17. LTS reasons.

--adam

> On 3. Dec 2021, at 01:47, Reza Rahman <reza_...@lycos.com> wrote:
>
> I think this is fine.
>
> This is a bit of an aside but not sure if you would like to consider it:
>
> I am hearing a lot of grumbling about Jakarta EE 10 not base-lining on Java SE 17 while keeping Java SE 11 and Java SE 8 optional. The precedent for Java EE had been that it always supported the newest Java SE version possible at the time of finalization of a release. This expectation could be a possible source of the grumbling.
>
> I am curious to see if others have opinions on this?
>
> 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.
>
> On 12/2/2021 11:50 AM, Scott Kurz wrote:
>> We need to decide what Java level to target for Batch 2.1.   Java 11 is the recommendation for the EE 10 platform, however since we still have not added any new APIs at this point we could still decide to go with our Java 8 level binaries from 2.0.
>> (This option is outlined in the platform release plan:   https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan )
>>
>> I propose we use Java 11 for source/target to stay in synch with the platform.    If a user wants to remain on Java 8 they can just use the existing 2.0 API JAR. 
>>
>> Note in terms of language features I'm not sure we depend on anything more than Java 6 ?? still.   
>>
>> Any objections?
>>
>> If not, then, to add a bit of a further thought, I think we end up with this table worth keeping in mind:
>>
>>
>> Language Features:  Java 6?
>> javac target:  Java 11
>> TCK execution:   Java 11 + 17
>>
>> Thanks,
>> ------------------------------------------------------
>> Scott Kurz
>> WebSphere / Open Liberty Batch and Developer Experience
>> sk...@us.ibm.com
>> --------------------------------------------------------
>>
>>
>>
>>
>> _______________________________________________
>> jakartabatch-dev mailing list
>>
>> jakartab...@eclipse.org
>>
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jakartabatch-dev
> _______________________________________________
> jakarta.ee-community mailing list
> jakartaee...@eclipse.org
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

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

--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration. 

[Reza Rahman]

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@eclipseorg> on behalf of Oliver Drotbohm <odro...@vmware.com>
Sent: Saturday, December 4, 2021 12:11 PM

To: Jakarta EE community discussions

Cc: jakartaee-...@googlegroups.com
Subject: Re: [jakarta.ee-community] Java Records and Jakarta EE

 

Hi,

> Am 04.12.2021 um 17:46 schrieb Reza Rahman <reza_...@lycos.com>:
>
> 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

[Oliver Drotbohm]

Hi,

> Am 04.12.2021 um 17:46 schrieb Reza Rahman <reza_...@lycos.com>:
>

> 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.

[Reza Rahman]

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-com...@eclipse.org> on behalf of Oliver Drotbohm <odro...@vmware.com>

Sent: Saturday, December 4, 2021 12:11 PM
To: Jakarta EE community discussions
Cc: jakartaee-...@googlegroups.com
Subject: Re: [jakarta.ee-community] Java Records and Jakarta EE

 

[Oliver Drotbohm]

Awesome, thanks for that, Reza!

--

Sent while on the run…

Am 04.12.2021 um 19:39 schrieb Reza Rahman <reza_...@lycos.com>:



[Ondro Mihályi]

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 <odro...@vmware.com> napísal(a):

--
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-ambass...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/69E3C2B5-27DA-4681-845D-58875A101736%40vmware.com.

[Reza Rahman]

Feel free to create an issue at the platform level and link the one I created? It's certainly a worthy discussion at the platform level. As long as CDI, etc. can deal with Records in a sensible number of scenarios, I think it's fine. The default no-arg constructor requirement is an issue there too, but again I don't think a very big issue in practice.

[Guillermo González de Agüero]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CACZTZYXHkQ6H58W-6kRhVF_%2B1gSNNdNYux-AFi3bbBfK_AVGoA%40mail.gmail.com.

[Ondro Mihályi]

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. 

[Edwin Derks]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CACZTZYUp%3Dt5zus2kdb32XdVXAavCjDhgE1oKZrRmgNMf373BBg%40mail.gmail.com.

[Kito Mann]

Edwin, what change do you propose?

___

Kito D. Mann | @kito99 | Java Champion | Google Developer Expert | LinkedIn

Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Web Components, Angular

Virtua, Inc. | virtua.tech 

+1 203-998-0403

* Enterprise development, front and back. Listen to stackdpodcast.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CAE35TCOuvMugqOZpGOq%3DMH-SPGDuKZ-Y0t8s40Wdzc10ONFnOw%40mail.gmail.com.

[Edwin Derks]

Ok, here are my thoughts:

1. First we need to define the exact way how we would like to handle records in Jakarta EE (or even enterprise Java in general). Also, including how that should work on a specification level, like for CDI and JPA.

2. Define the exact problem(s) we see, e.g. regarding constructor chaining

3. Define solution(s) for these problem(s) and propose them as a JEP

4. If the JEP(s) are accepted and available in future versions of Java SE, we can adopt these changes with the plans we made for the specifications etc

What are your thoughts? Does it make sense?

Edwin

[Reza Rahman]

Do you want to get the ball rolling on #1? I would start on GitHub and donate what actually already works as use cases to the Jakarta EE Examples project?

[Edwin Derks]

Yes, please do, Reza. This way, we can polish the use case to the point where it illustrates what the problem is, so it can be a base for #2

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/9fadb0ce-85f7-1741-0138-e9dd7a3ca564%40lycos.com.

[Reza Rahman]

I have this on my backlog but honestly probably won’t get to it for several months. If someone else could lead this, it would be ideal.

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: jakartaee-...@googlegroups.com <jakartaee-...@googlegroups.com> on behalf of Edwin Derks <eder...@gmail.com>
Sent: Thursday, January 13, 2022 3:05:49 AM
To: Jakarta EE Ambassadors <jakartaee-...@googlegroups.com>; Jakarta EE community discussions <jakarta.ee...@eclipse.org>
Subject: Re: [jakarta.ee-community] [jakartaee-ambassadors] Re: Java Records and Jakarta EE

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CAE35TCOdNkUbbryRoij2XtkpdZRdMUcs097vjjyoyeVBF1Rr4A%40mail.gmail.com.