Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for eliminating Optional aspects of Specifications

Was this going to be sent to the jakartaee-spec-project-leads list as well?


On Jun 17, 2021 at 3:50:28 AM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
I am also in favour of dropping Optional aspects of specifications as I think they harm application portability. A developer could easily use an optional portion of a specification inadvertently and then find they can't run their application on a different compatible implementation. As application portability across multiple compatible implementations is a key selling point of Jakarta EE Profiles I think anything we do to improve that is a good thing.

I think the JMS issue described could be resolved through use of Profiles, JMS-lite as Scott says, within the JMS specification project or formally as a second spec within the remit of the JMS project overall. Personally though I wouldn't carve out a profile of a spec on the hope that some implementation will then certify unless that implementation team is involved in the process. IMHO Java EE has done that in the past and left many inconsistencies in the overall platform as a result. There's a huge balancing act between shipping standalone lowest common denominator specifications and building a consistent platform that is functionally rich and delivers application portability. 

Steve


From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of David Blevins <dblevins@xxxxxxxxxxxxx>
Sent: 17 June 2021 5:02 AM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for eliminating Optional aspects of Specifications
 
Great replies, thanks Scott and Kevin.  I'm 100% on board with the goal of making it so other implementations beyond GlassFish can serve as the CI for Jakarta EE Platform & Web Profile votes.

I'd like to give more thoughts on how the union of compatible implementations approach could work and see if there aren't some non complicated ways we can approach it.  I think really any idea is unattractive if we take it too far.  Disallowing optional features is perhaps too far as would having a complex web of several compatible implementations.  There might be ways we can do a bit of both; i.e. take a position that both are fine within reason.  Perhaps some bounds we can put in place.

I appreciate the spirit that we do want to continue to allow implementations to in practice continue supporting features that are currently optional.  I do see a potential new kind of complexity that can occur if those things are removed from specifications and tcks, yet still shipped and used.  Users would have to potentially look at 2 or 3 versions of a specification to find where something is defined and work out for themselves how things should behave in the cases were rules may appear to be in conflict or ambiguous.   As well implementors who want to keep supporting removed-but-still-shipped would have to run potentially several TCK versions to ensure the old tests are passed.  This could get very uncomfortable as we're likely to overhaul the TCK harnesses over the coming years.

This is a great conversation.  I wrote double this email and didn't send it as I don't want to overload everyone.  I'm happy with the discussion, happy we're mixing in some text to balance our meetings, and happy we intend to widen the audience at some point.


-- 
David Blevins
310-633-3852

On Jun 16, 2021, at 2:44 PM, Scott Stark <sstark@xxxxxxxxxx> wrote:

As Kevin said, the problem of having a defacto default RI in order to meet all optional aspects of a specification is the issue we are trying to remove. To me what you are describing is JMS-lite, and is something that can be a separate specification that the standard JMS implementation extends. It could also be viewed as two platforms where the TCK tests are the cloud platform + the Jakarta platform and the cloud platform has lower requirements. This is not dissimilar from CDI having a set of tests for the Java SE environment and additional tests for using CDI in the presence of the web container, etc.

The road we did not go down in addressing this optional problem is allowing for a union of compatible implementations that fulfill all of the levels of requirements. This was more complex and also did not address the problem of legacy or simply no longer wanted features. If there is not majority support for a given feature of a specification, pull it out into a separate specification that is outside of the platform profiles and let those vendors who want to support it do so. We are no longer bound by the JCP requirements of not extending the features available in a compatible implementation of a profile.

On Wed, Jun 16, 2021 at 3:01 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
Today we had our first meeting of the Jakarta Messaging project and discussed making several aspects optional.  Specifically some of the messaging guarantees such as durable topics, explicit acknowledgement, message ordering and transactions.  These are already options for users, but currently implementations must support them even if the user does not use them.

The motivation for allowing them to also be optional to implementors is to encourage more implementations; specifically from cloud providers and to make room for Kafka-like implementations.  There was explicit discussion that the guarantees planned to be optional are still valid, not flawed or legacy, critically needed by some, not planned be removed and that new versions of the API such as the proposed annotation based API will cover and account for these optional features.  The spirit we discussed for the API design is that anything optional would effectively be off by default and could be turned on via annotations/api calls by users who need them on implementations that support them.

How would this proposal map to our scenario we the planned use of optional is not because of legacy and simply to make room for more implementations?


-- 
David Blevins
310-633-3852

On Jun 16, 2021, at 12:27 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

David,
Short answer -- to avoid always being dependent on Glassfish as the Compatible Implementation.
Longer answer -- read through the referenced document.

---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)




From:        David Blevins <dblevins@xxxxxxxxxxxxx>
To:        Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        06/16/2021 14:08
Subject:        [EXTERNAL] Re: [jakarta.ee-spec.committee] Discuss proposed Resolution for eliminating Optional aspects of Specifications
Sent by:        "jakarta.ee-spec.committee" <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>




What is the issue with optional features that we're trying to avoid?


--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On Jun 16, 2021, at 11:59 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

On our Specification Committee call today, we discussed a proposed Resolution (prepared by Dan and Paul) about eliminating the use of Optional features in Jakarta EE Specifications.  We decided that we should discuss the Resolution via the private mailing list for the next seven days (max).  At that time, hopefully enough input would produce a version of the Resolution to post to a wider audience (Spec Project Leads and/or public Spec Committee mailing lists).  Again, hopefully, we would get enough input from these two mailings to allow for a ballot on the Resolution at our next Spec Committee meeting on the 30th.  

First, for background, if you are not familiar with the back story for this Resolution, please review this document:

https://docs.google.com/document/d/1O5MnbQRn8RWkM4BpJth9VqGfhKLBZfFzK_fpIyZ_2vw/edit

(BTW, before we externalize that document to the Spec Project Leads and/or public Spec Committee mailing list, we should resolve any outstanding comments...  Dan,I will leave you in charge of that activity.)


The proposed resolution is just a slightly re-worded version of option #1 in the referenced document.
  • DRAFT RESOLUTION: To eliminate marking any Jakarta EE Specification feature as optional in some future release of each Jakarta EE Working Group Specification, including and possibly starting with the Jakarta EE Platform Specification Release 10.  All remaining features would be required.
    • Clarifying text to the proceeding resolution: The process would be to mark all optional features in the current release as “Deprecatedâ€� in a new Minor release (Release 9.2), and in a subsequent Major release (not necessarily the very next Major release) eliminate the Deprecated feature completely from the Jakarta EE Platform Specification. Eliminating these Deprecated features is not retroactive to earlier released specifications, which will continue to exist. As implied, “Deprecatedâ€� will be defined as a way of marking a feature as on the path to complete elimination from some future release, and it indicates to the public “this feature is going awayâ€�.   This two-step process provides a formal communication mechanism within the specification itself for the Working Group to signal to the community that a feature will definitely be removed from a future release. The intent is to mark current features marked as “Optionalâ€� as “Deprecatedâ€�, but in the future even “Requiredâ€� features could be marked as “Deprecatedâ€� should the Working Group decide to prune little used features from the platform. This two-step process will take longer but will also give consumers of the platform a longer runway to plan for and deal with the elimination of the feature should they wish to consume that future platform release.

Comments and suggestions are welcome!  Thanks!

---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM

e-mail:  sutter@xxxxxxxxxx    Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)


_______________________________________________
jakarta.ee-spec.committee mailing list

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




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

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

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

Back to the top