[jakarta.ee-spec.committee] Options for Jakarta EE 9

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

(Starting a new thread so this doesn't get lost under the "agenda" thread...)

There's a multi-dimensional decision tree here.  Should we lay out all the choices and prune the tree where there's agreement?  If there isn't agreement (yet), we can just describe the choices we're considering.

Some choices are:

• Move over the entire platform and follow the existing pruning process, vs. immediately pruning some set of specifications when creating EE 9.
• Move all APIs to jakarta.* immediately in EE 9, vs. move only evolving APIs to jakarta.* in EE 9 and moving others later as needed.
• Require some method for providing some level of compatibility for Java EE applications, vs. leaving it to implementations whether and how to provide any Java EE compatibility.
• Continue to define an overall "platform", vs. only define a collection of APIs that can be mixed and matched a la carte.
• Continue to define only the platform and Web Profile, vs. define some additional profiles for Jakarta EE 9.
  
• Require that implementations "run on" JDK 11 or newer, vs. require that implementations be delivered as a set of JPMS modules that are defined by the specifications.

(Not all of these choices are binary, but that seemed like a good place to start.)

Without describing which choice you prefer, what are some of the other choices we have to make related to javax.* or Jakarta EE 9 in general?

If we can reach consensus on some of the choices before we need to announce this to the community, that would be great.  Otherwise we can describe the choices we're considering, recognizing that there may be other choices that we haven't considered.

Can someone volunteer to be an "editor" to collect all this information and any decisions we make and present it in a coherent form for the community?  (And no, I'm not volunteering.  I'm trying to respect Oracle's commitment to let the rest of you lead this effort going forward.)