Reza -> IMO Java 17 is a must! My clients are already using Java 17. LTS reasons.
> 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
>> Scott Kurz
>> WebSphere / Open Liberty Batch and Developer Experience
>> jakartabatch-dev mailing list
>> To unsubscribe from this list, visit
> jakarta.ee-community mailing list
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.
At any rate, I have filed this (mostly as a way to not forget
about the discussion):
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, SpeakerPlease 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
Subject: Re: [jakarta.ee-community] Java Records and Jakarta EE
Am 04.12.2021 um 19:39 schrieb Reza Rahman <reza_...@lycos.com>:
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
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CACZTZYXHkQ6H58W-6kRhVF_%2B1gSNNdNYux-AFi3bbBfK_AVGoA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CACZTZYUp%3Dt5zus2kdb32XdVXAavCjDhgE1oKZrRmgNMf373BBg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CAE35TCOuvMugqOZpGOq%3DMH-SPGDuKZ-Y0t8s40Wdzc10ONFnOw%40mail.gmail.com.
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?
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/9fadb0ce-85f7-1741-0138-e9dd7a3ca564%40lycos.com.