Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta nam

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Greg Wilkins wrote on 5/14/19 6:13 AM:

So if we went incremental, then what kind of change would necessitate changing to the name space?

• Adding JPMS meta data to the jars?

No.

• Fixing mistakes in API docs?

Define "mistake".  Fixing typos is certainly fine, but changing anything that has the effect of changing the requirements on implementations of the API would not be allowed.

• Deprecating methods?

Definitely.

It's hard to consider how much impact incremental will have if we don't know how often APIs will cross the threshold and need to change names.    

For the servlet spec, JPMS meta data is really needed 6 months ago, so if that is a breaking change then servlets will increment either in EE9 or soon after.  Being able to maintain the API doc is also valuable, but I'm not sure it would force an increment on it's own.  Of course deprecating methods in anticipation of a future release would also be desirable with a good lead time before any release of an updated spec.  So if we start work on servlet changes in 2020, then we'd probably want to deprecate methods in 2020.        So my fear with incremental is that with the rate of EE releases, it may just become a few medium bangs.. ie make the EE10 & EE11 just as painful as EE9.

Also, can somebody confirm that no matter what, not all javax APIs are included in this.  Specifically things like javax.sql and javax.naming are part of the JRE and thus wont be renamed.   Is there a good definitive list somewhere of what APIs are affected?

Only the javax APIs for the specs contributed to the Eclipse Foundation are eligible to be renamed.  That includes all the APIs in Java EE 8, plus a few of the "Java EE" specs that had migrated to Java SE and were remove by JEP 320.

Any javax.* APIs still in Java SE 11 are out of bounds.