Eclipse EE4J - My Hopes and Dreams

There have been a lot of really great updates coming out of the EE4J project recently and as far as I can see, the project is progressing nicely given the size and complexity of the undertaking.

Recently, Mike Milinkovich from the Eclipse Foundation wrote a great blog summarising the state of the nation w.r.t to the move of Java EE to EE4J, outlining some of the road map, the desire to ship a Java EE 8 compliant version of Eclipse GlassFish and outlining the creation of a new working group as a first step to creating a new governance mode. Will Lyons also clarified trademark thinking , relating to use of Java EE and javax in EE4J while not everything everybody wished for the position is understandable, workable and pragmatic and allows for evolution of existing APIs under their existing package names and therefore won't result in any breaking changes to people's code during transition. At the same time, the migration of the code has begun in earnest and new EE4J projects are being created as more and more code moves over from Oracle to EE4J. With all that going on, I thought it useful to put together my hopes for the EE4J project and the opportunities it brings.

The Payara Team are heavily involved in EE4J and I am currently a member of the EE4J PMC. While at the moment focusing on the process of choosing a new name (Jakarta EE or Enterprise Profile - vote here until the 23rd of Feb), the PMC will in the future be heavily involved, via the individual projects, in guiding the technical direction of EE4J APIs, pulling together platform releases, creating new projects and determining what is included in an overall platform or profile. I feel the PMC will act as a guiding hand striving to maintain a level of cohesion and consistency across the various sub-projects. Each sub-project though will be in charge of its own destiny and developed through its own group of committers.

I'm really looking forward to the move to an open source code first method for the creation of new and the evolution of existing APIs. This code first process has been pioneered in MicroProfile and the fact you can see the API directly evolve as it heads to a 1.0 release is truly educational and leads to better specifications and implementations. Again, using an open source model, individual enhancements, fixes and API tweaks can all be managed through individual issues with PRs to review, comment on, modify and merge. Using the Eclipse development process APIs, TCKs, RIs and specifications will be developed by the project committers via committed code not by a spec lead asking for +1 in a mailing list. Having the ability to trace individual API changes to the Pull Request and issue with their corresponding discussion of why and how the API is needed will be awesome for future education and understanding. Alongside this, we will be able to create new and more speculative APIs than was possible previously. These can be developed by a core group of committers and if they mature to the point of having an API, TCK , RI and specification document they can be considered by the PMC for inclusion in the overall platform. This will act as a driver for innovation while at the same time acting as a natural filter for new APIs that do not attract enough attention to make it over the line of a 1.0 release.

Overall for the EE4J platform, another thing I would like to see is the move to a release train model similar to but perhaps less frequent than the MicroProfile model. I'm not too hung up on the exact release cadence but I think annually, perhaps to coincide with JavaOne, would be a good balance. The way I see this working is that the API projects can develop at their own pace creating and releasing point releases. Then once a year the EE4J PMC can look to pull together an overall platform release sweeping up the current state of the API projects, ensuring platform cohesion and integration of the various APIs, pulling in the RIs into Eclipse GlassFish and shipping the whole lot as an EE4J platform release with a bill of materials that passes the platform TCK. Obviously, this is non-trivial but I hope an annual release will act as a forcing function to pull everything together and will be often enough to prevent individual APIs diverging too much from the rest of the platform.

Finally, one of the game changers that is sometimes lost in the heat of the debate around naming and trademarks is that within the EE4J project all TCKs and specifications will be freely available and the code will be open source. This is a huge shift from the previous status quo. I am hoping that the opening up of the specifications and TCKs will result in a big influx of additional organisations, individuals and commercial vendors creating independent implementations of EE4J APIs leading to increased innovation through competition, enhanced interoperability via better testing and better quality due to scrutiny and improvement of the TCKs themselves. Having open TCKs and specifications with open issue trackers will mean that anybody will be able to see how something should work in the API, correct and build new tests and ambiguities can be challenged and fixed just by creating a GitHub issue. Having open individual TCKs will enable modularity as people that do not want to be constrained to a full platform or specific profile test suite will still be able to test that their subset of APIs passes the individual TCKs. This is massive and will be a game changer for adoption and standardisation.

Overall, this is a great opportunity and the move to EE4J is a hugely positive thing for the industry. With the openness of open source this is the time to get involved; be heard and influence the current and future state of the EE4J project. Don’t get me wrong, this is a huge undertaking and is a lot of change and we all need your help. The Payara Team will be heavily involved and we are gearing up to put in the man hours required to get all this off the ground alongside the rest of the community.

For starters head over to the EE4J community mailing list and subscribe. Also take a look at the projects on GitHub and see where you would like to get involved. I'm looking forward to seeing you there!