Just to throw my small spin on this, but what gives us the need for EE4J standards to be JCP approved standards?
If we were trying to create JavaâÂStandards, right now our only legal/valid choice would be the JCP. Ans, as you posted, it would be up to Oracle to extend this capability to any new standards organization.
However, we could easily have a standardization org for EE4J (or, at least, the currently unnamed specs project).
Under such an org, we could standardize any spec or API as "EE4J compliant" or "EE4J compatible", or whatever term we'd prefer.
The very fact that EE4J (at least the specs and kits projects) are going to be, from now on, the ones to set what future versions of the Java EE (replace this by whatever name we end up deciding for our projects) must contain pretty much implies that the standard for NewJavaEE will be set by EE4J, not the JCP (which will continue to handle standards for Java SE, and all Java EE versions), since it will be our specs that implementers will have to follow to be "EE4J compatible/certified", the same way that current standardization for Java pretty much means being JSR compliant and passing the TCKs.
My view on the current state was something like:
JCP outputs JSRs with TCKs, your implementation is compliant, and gets the "Javaâ Standardized" bling, which means it will run correctly on the JRE.
EE4JSpecs (or whatever) outputs ESDs (EE4J Spec Doc, or similar) with ECTs (EE4J Compat. Tests, etc), your implementation is compliant, and gets the "EE4J Standardized" bling, which means it is EE4J compliant (and should run correctly within any EE4J Compliant Server).