Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] [servlet-spec] New features in EE9 for Servlet-API 5.0?

I agree with Arjan.  If there's an absolute need (not just a "want"), then Projects are welcome to create, review, and vote on a separate Release Plan.  But, we really are trying to keep Jakarta EE 9 focused on the javax - > jakarta rename.

FYI, the JAX-RS Project is in the same boat as Servlet.  Their current thinking is to do the javax -> jakarta rename first and then do another 3.1 release immediately after their 3.0 Release for Jakarta EE 9.

Hope this helps.

Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    

From:        arjan tijms <arjan.tijms@xxxxxxxxx>
To:        servlet-spec@xxxxxxxxxxxxxxxx
Cc:        Jakarta specification disccusions <>
Date:        01/20/2020 06:47
Subject:        [EXTERNAL] Re: [] [servlet-spec] New features in EE9 for        Servlet-API 5.0?
Sent by:


My understanding is that if we absolutely want, we can. But then we do have to diverge from the EE 9 release plan and create our own plan (and engage in review for that etc).

As we can followup with a 5.1 immediately after 5.0 (there's no time limit, could even be days), my preference would be for 5.0 to be a rename release only.

Kind regards,

On Mon, Jan 20, 2020 at 8:16 AM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

Dear ee spec group.

The servlet-api project is trying to come up with our project plan for our 5.0 and 5.1 releases.

The 5.0 release will be our javax->jakarta rename release and the key question we have is can we also put some new features into that release?  Or does it have to be exactly like 4.0, but with only the name changed?

There are some minor features that we really need to add to stay relevant to current browser and specifications.  A key example is sime-site cookie support as proposed in the matching schema change

If changes like these cannot be in a 5.0, then we will need a 5.1 as soon as possible after 5.0.

I understand that have a pure renaming release would give some degrees of simplicity when porting,  but I'm not sure that helps much if soon afterwards we have to deal with demand for 5.1

Thus our question is - can we make some minimal additions to the API in 5.0 on the basis that they will be reviewed against the criteria of not hindering any automated porting tools of 4.0 to 5.0?


Greg Wilkins <gregw@xxxxxxxxxxx> CTO
_._,_._,_ Links:

You receive all messages sent to this group.
View/Reply Online (#83) | Reply To Group | Reply To Sender | Mute This Topic | New Topic

Your Subscription | Contact Group Owner | Unsubscribe[arjan.tijms@xxxxxxxxx]
_._,_._,________________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top