Relax requirements around Java SE and specification ratification

[starksm64]

There is contention between supporting the latest LTS Java SE version and supporting customers who do not want to move at the current Java SE cadence. The requirement that a Jakarta platform/profile specification verify a compatible implementation for ratification against more than one Java SE version is really an implementation detail and an issue with the TCK.

The current Jakarta processes really don't capture this requirement. It is simply a concern that has been voiced by various project/committees.

A more agile approach would allow for ratification of a specification by any Java SE version within the scope of the current release plan. For example, say Glassfish ratified the Web Profile using Java SE 21. If some other vendor comes along and wishes to certify using Java SE 17, any problem can just be viewed as TCK challenges that need to be resolved.

[dblevins]

This seems pragmatic to me:

• Step 1 "Hope": We say at the START of a major Jakarta EE version we want as the base, it will often (or always) be the latest version of Java case we really want to innovate. Example: Jakarta 12 targeting Java 25.
• Step 2 "Reality": We look at what was actually done at the END of the major version cycle. If no specs leveraged the newer Java version, we update the certification requirements to reflect what happened in practice. Example: Jakarta 12 targeting ~Java 25~, Java 21.

I understand and agree with the desire to sync Jakarta EE releases with the latest Java LTS release. That's a great goal.

If we fall short of that goal and no one contributes API features that actually require that Java version, then we should shift to being pragmatic and support the widest market we can.

[smillidge]

Sounds pragmatic and reasonable on the surface but ignores the impact on compatible implementations under development and other product roadmaps. What happens if a product targetted the hoped for JDK and built their implementation using this JDK then we switch on them at the last minute. For example nobody in the present debate has sought agreement from the GlassFish project team that they are prepared to switch baseline target JDK.

[Emily-Jiang]

I am not keen on this. I would like to see the proof before we release something as I don't think we should perform a release with fingers crossed.

[starksm64]

There had been conversations with Arjan about whether the switch could be done, and the example I gave in the issue was that GlassFish should be able to choose SE 21 and still be used to ratify the specification.

On Wed, Feb 7, 2024 at 2:22 AM Steve Millidge @.***> wrote:

Sounds pragmatic and reasonable on the surface but ignores the impact on compatible implementations under development and other product roadmaps. What happens if a product targetted the hoped for JDK and built their implementation using this JDK then we switch on them at the last minute. For example nobody in the present debate has sought agreement from the GlassFish project team that they are prepared to switch baseline target JDK.

— Reply to this email directly, view it on GitHub https://github.com/jakartaee/specification-committee/issues/77#issuecomment-1931508179, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACRDMSN4GK2OYVBAAWUPH3YSM2STAVCNFSM6AAAAABC5BQ7CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZRGUYDQMJXHE . You are receiving this because you authored the thread.Message ID: @.***>

[starksm64]

Yes, there is an additional risk, but if there are not compatible implementations for all Java SE versions, that should not stop the release. Any issues with the missing Java SE versions will be dealt with when the first compatible implementation targeting said version shows up. If they don't even show up, it is a non-event.

We have to be more practical with the engineering release aspects of Jakarta or it will collapse under the weight of its process and lack of resources.

On Wed, Feb 7, 2024 at 6:14 AM Emily Jiang @.***> wrote:

I am not keen on this. I would like to see the proof before we release something as I don't think we should perform a release with fingers crossed.

— Reply to this email directly, view it on GitHub https://github.com/jakartaee/specification-committee/issues/77#issuecomment-1931922418, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACRDMQQD6XILKBJMHNE6X3YSNV2VAVCNFSM6AAAAABC5BQ7CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZRHEZDENBRHA . You are receiving this because you authored the thread.Message ID: @.***>

[dblevins]

Sounds pragmatic and reasonable on the surface but ignores the impact on compatible implementations under development and other product roadmaps. What happens if a product targetted the hoped for JDK and built their implementation using this JDK then we switch on them at the last minute. For example nobody in the present debate has sought agreement from the GlassFish project team that they are prepared to switch baseline target JDK.

IMO those who want to focus on Java 21 should be allowed to still focus on Java 21.

I had thought we eliminated the need for one implementation to implement all optional features. Are there still some limitations/restrictions we need to address?

[smillidge]

Not sure on limitations/restrictions in the EFSP.

I was also thinking of products that are not compatible implementations e.g. a 3rd party product that needs to deploy to a Jakarta EE runtime. We state we are targeting a JDK LTS as a baseline in our launch marketing for Jakarta EE.next. They develop to that JDK then we switch at the last minute and now they have to switch or only support a potentially limited number of Jakarta EE runtimes. This is not the best optics.

[paulbuck]

The Spec Committee discussed and the consensus is to not releax the TCK requirement.