Published on 11 Jun 2018
Recently I was tasked with preparing a presentation on an update to Jakarta EE and Eclipse MicroProfile® and it got me thinking about the organisation and structure involved in this huge effort to transform Java EE into a truly open source standard under the Eclipse Foundation. While organising my thoughts I put together a picture showing the structure and tensions of this undertaking to help people understand what various groups do and perhaps how better to get involved. The structure and governance is evolving as I write this so I may not get everything right.
Project EE4J
EE4J was the first name we had when it was announced that Java EE is moving to the Eclipse Foundation. EE4J is a top level project in the Eclipse Foundation, a top level project is a way of structuring open source projects at the Eclipse Foundation. Each project lives under a top level project which is managed by the Project Management Committee (PMC). The PMC of the EE4J is tasked with providing oversight and leadership to its subprojects as well as ensuring they meet the EE4J charter goals and are following the Eclipse Development Process.
Oracle is currently in the process of donating the Java EE code to Eclipse the progress of which can be seen on the project website. This is a huge undertaking when you think that every piece of code, dependency and 3rd party contribution in every project needs to be IP checked and relicensed.
Eventually, under the EE4J project, there will be individual projects for each of the individual APIs; the Reference Implementation (RI); the Technology Compatibility Kit (TCK) and supporting technologies like Grizzly. These projects are where the real work is done and each uses the Eclipse Development Process as the rules of engagement. Each project consists of a set of individual committers with anybody able to become a committer by contributing to the project and being elected. The individual EE4J projects have a lot of autonomy and can evolve and release their projects in a way the committers feel is best for their project while also upholding the top level project charter to create an integrated platform. The source code for the EE4J projects lives under the Eclipse EE4J organisation in GitHub and evolves using standard open source best practices. Anyone can raise a GitHub issue and a corresponding Pull Request (PR) to develop the project.
The outputs of an EE4J project will be an API, an RI and a TCK.
Jakarta EE
Jakarta EE is a working group within the Eclipse Foundation with the goal of promoting the Jakarta EE platform. While the EE4J projects are driven by individual committers, the working group provides a forum where organisations that are committed to Jakarta EE can come together to shape the business aspects of driving the Jakarta EE brand. The working group key goals are to promote the Jakarta EE brand; define a compatibility and certification programme so that implementations can be labelled Jakarta EE compatible and to define and run the specification process that creates Jakarta EE specifications. The working group has three working committees and a steering committee. The key committees are for the Specification process; Marketing and Branding; and Enterprise Requirements.
The outputs of the Jakarta EE working group is the brand, a set of specifications for the Jakarta EE platform and profiles of the platform and a compatibility mark.
Creative Tension: Innovation, Maturity, Consistency and Portability
While the goals of the EE4J project(s) and the Jakarta EE Working Group are close, there is a nice creative tension built into the system. While individual committers in EE4J projects are free to innovate and evolve their APIs within their projects, ultimately they must try and become a part of the Jakarta EE platform. To do that they must produce an API, RI and TCK of sufficient maturity to enter into the specification process and do the work to also deliver a Jakarta EE specification. At this point the project will also have to show it integrates with other Jakarta EE specifications in order to provide a platform that has a lot of internal consistency. This provides a quality gate for organisations that create implementations of the Jakarta EE platform they wish to certify as compliant and for end-users that want to build applications against the Jakarta EE specifications and want portability across implementations. Remember if an EE4J project becomes a Jakarta EE specification and is included in the Jakarta EE platform, every Jakarta EE compatible product will need to create an integrated implementation of the API.
Not every project in EE4J will necessarily become part of Jakarta EE. The EE4J PMC is free to admit any open source project that confirms to the charter of the EE4J project. New innovative APIs may be born and die within EE4J without ever reaching the level of maturity required for proposal to the Jakarta EE working group as a standard. The EE4J top level project can become the engine of innovation for Jakarta EE, new projects can be proposed with relative ease and if they gain traction - graduate to the Jakarta EE platform.
At the same time, Jakarta EE is not just made up of EE4J projects. Key foundation technologies like CDI live outside EE4J along with Bean Validation and JBatch. The Jakarta EE specification committee is free to receive proposals from external open source projects that wish to follow the Jakarta EE specification process and become part of the Jakarta EE platform and brand.
Where Does MicroProfile Fit In?
The MicroProfile project is currently a single project in the Eclipse Foundation with the goal of optimizing Enterprise Java for microservice based architectures. The project has a number of repositories in GitHub one for each API developed under MicroProfile. The MicroProfile project develops Java APIs, a standard document and a TCK for each of the APIs. Currently MicroProfile is a sub-project of the Eclipse Technology project and so is not related to either EE4J or Jakarta EE although many of the organisations and committers are involved in both projects and the foundations of MicroProfile like CDI and JAX-RS will become Jakarta EE specifications.
There are a number of scenarios for the MicroProfile project. The first is that the project could be moved under the EE4J top level project and perhaps split into a number of individual sub-projects one for each API. Secondly the MicroProfile project could remain where it is and approach the Jakarta EE Working Group and seek to have some of the APIs become part of the Jakarta EE platform. Alternatively, MicroProfile may continue as it is and not become part of EE4J or Jakarta EE. Which direction it takes depends on the committers of the MicroProfile project.
What is Payara Doing?
It has been less than a year since Oracle announced they are moving Java EE to the Eclipse Foundation to open up the platform for the future. They have now started the massive undertaking of moving the Java EE code base to the Eclipse Foundation. Since then I personally have become a member of the EE4J PMC and a director of the Eclipse Foundation board. Members of the Payara team have become project leads and committers on a number of the EE4J sub-projects. Payara has also joined the Eclipse Foundation as a Strategic Member; joined the Jakarta EE Working Group and is actively involved in the committees driving Jakarta EE forward.
It is a testament to the openness of the community that Payara, a small company founded just over two years ago, has been welcomed into both EE4J and Jakarta EE. If we can do it anybody can - so I encourage individuals and organisations to become involved.
How Do I Get Involved?
If you are keen to shape the future of Java EE there are a number of ways to get involved. If you are an individual interested in specific APIs, their RIs or the quality and breadth of the TCKs your first port of call is following the relevant EE4J project. Each project has a mailing list join in. Feel free to create, comment, criticise and compromise in issues and PRs on GitHub.
If you represent an organisation that creates implementations or builds applications on Java EE now or Jakarta EE in the future, then get your organisation to join the working group and shape the Jakarta EE platform and brand through the working group mailing lists and committees.