And the most I could think of is to declare such feature optional in a +1 release not the current one, Jakarta EE has stronger compatibility and reliability requirements than say Microprofile or Spring, where Things can change with Little notice O;-)
The spec also points this out quoting Mark Reinhold:
to stabilize and remove technologies from the platform in a careful and orderly way that minimizes the impact to developers using these technologies, while allowing the platform to grow even stronger.
And 2. of 6.1.3 also leaves it up to the platform team:
The Platform Specification Project for release N+1 decides whether to mark the feature as "optional" for this N+1 release, retain it as a required component, or leave it in the "proposed optional" state for the next N+2 release cycle to decide.
So it can be made optional for the next release or "proposed optional". Either way, what Scott mentioned falls under 6.1.4 and there should be some wording for it in the spec document.
Werner
If it is then the spec must be amended.
Werner
Sent from Mail for Windows 10
The issue is that if no runtime implements the optional feature B at Jakarta EE10. I think it can’t be included in the platform Spec as optional feature. Therefore, delaying the removal to Jakarta EE12 does not make sense. This is the reasonable early exit condition.
Remove from the platform or archive entirely?
It seems neither the General EFSP nor the Jakarta EE Extension to it go into great Detail about platforms or Platform Inclusion (or Exclusion) like the JCP does: https://jcp.org/en/procedures/jcp2#3.3.1.4
The EFSP has just one brief sentence:
A Specification Committee may, at its discretion, elect to label one or more Profiles as a “Platform”.
However based on "6.1.3. Optional Jakarta Technologies" EE 10 may decide to mark such feature B "proposed optional", and only EE 12 could officially remove it. That wording wasn’t in the JCP document either but was inherited from Java EE.
Werner
For an optional spec to be included there should be commitment from at least one sponsor to provide a compatible implementation. If no one is able to do that, the spec should be removed. In your example, EE 10 should remove B.
A Compatible Implementation must fully implement all non-optional elements of a Specification Version, must not extend the API (no supersetting), and must fulfill all the requirements of the corresponding TCK. A Specification Version must identify one or more Compatible Implementations under an Open Source License that, in aggregate, implement all optional elements of the Specification and fulfill the requirements of all elements (including optional elements) of the TCK.
I have a minor question about the modification. Let's look at this scenario:
Say we have optional features A, B, C
In Jakarta EE9, Open Liberty implements A and B. TomEE implements C.
In Jakarta EE 10, Open Liberty decides not to support B any more and no other runtime supports B. Should we remove B from the platform Spec? I don't think this is a valid reason to hold off the release because in aggregation we can't cover all optional elements. This is pretty much a natural route from optional to removal.
If we are in agreement, should this be documented somewhere?
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
