Re: [jakarta.ee-spec.committee] [SUMMARY] Implementations requirements

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Mike Milinkovich wrote on 06/23/18 08:02 AM:

• I notice Bill Shannon's comments that Oracle's formal position is different than Dmitry's personal one. But Dmitry did state that "Many projects implementations were maintained by Oracle and it’s an open question who will support them after moving to EE4J." Which leads me to a question: as the code is moved into EE4J from Oracle, is this a "dump and run"? I.e. Is Oracle planning to contribute sufficient resources to keep these projects moving forward? I do understand the business pressures that incent the movement of resources to other needs, but I wasn't under the impression that the "community" was going to be wholly responsible for all future maintenance of these projects effective immediately.
  

This is definitely not a "dump and run".  Oracle intends to continue to contribute to the EE4J projects.

One of the major motivations (in addition to providing a more vendor neutral process, etc.) of Oracle contributing all of this work to the Eclipse Foundation was to spread the load of developing enterprise Java standards across the wider community of vendors and users who benefit from enterprise Java standards, and let others take over the leadership of this work.  Already other members of the community have stepped up to take over some of the work that Oracle did previously, so we're off to a good start at turning this into a true community effort.  Ideally, each of the Strategic Members would contribute equally to making EE4J and Jakarta EE successful.

In general, we're expecting that others who have taken over some of the specifications will also be providing implementations of those specifications, as well as TCK tests for those specifications.  It was definitely not Oracle's intent that others would take over the "fun" part of evolving the specifications while Oracle was left behind to do the hard work of implementing the specifications.

While Oracle is contributing implementations (and TCKs) for all of the specifications for which Oracle was the lead, the community can choose whether to continue with these implementations or replace them with other implementations.

Oracle believes that defining the Java EE platform that combined all the Java EE specifications was key to its success, and that we should continue that for Jakarta EE.  A significant part of the work that Oracle did previously was in combining the implementations for all the Java EE specifications into a single implementation for the Java EE platform - GlassFish.  Assuming the community continues to want to provide GlassFish as an implementation of the full Jakarta EE "platform" specification, other members of the community who have taken over some of the specifications will need to help with with work of combining the implementations (whether the original Oracle implementations or replacement implementations) into the GlassFish implementation.  As anyone who has built an application server knows, there's a lot more to this than simply copying a jar file.

The community might decide that GlassFish as it exists now is not the best approach for providing a complete Jakarta EE implementation. Perhaps GlassFish needs to be simplified, or re-engineered to make integration of components easier.  Or perhaps it needs to be replaced entirely.  As a member of the EE4J community, Oracle will be an active participant in any such discussions, and an active contributor to any proposed changes.  The future of GlassFish will be determined by the community and implemented by the community; this will not be an Oracle-only effort.

What will definitely not work is for the community to decide what needs to be done and expect Oracle to go off and do it.  To make this community successful, the people deciding what work should be done need to be the people who will do the work.  And the big change here is that neither of those is exclusively Oracle anymore.