Disclaimer: This is not an official EE4J PMC opinion.

This document is a product of my discussion with Oracle Prague development team consisting of engineers actively working on EclipseLink, Yasson. JSON-P, JPA, Metro, Jersey and other projects about technical directions each EE4J project should follow to make Jakarta EE successful.

• Move stand-alone TCK from CTS to API projects
  Each API project should have TCK tests repository included in the project. I am putting it on top of the list because this effort is not trivial. All projects have to use the same standard mechanism for TCK. We don’t want to face a situation when different projects use different frameworks and it’s a challenge to run TCK tests for each of them. It will require some agreements and PMC statements about how new TCK tests are organized, what testing frameworks used, etc.  
   
  
• Embrace Java 9 modules
  Despite the fact that the first release of Jakarta EE will be JDK8 based, projects should start preparation for JDK9+ support. First step would be adding automatic-module-name in MANIFEST.MF. If it’s possible to provide a correct module-info.java, it should be done. If not, it can wait for the next project release.
   
  
• Embrace Java SE
  If it’s possible, components should work natively in Java SE environment.
   
  
• Switch to maven and use it properly
  Maven is a de facto standard build system for Java projects. There are some older EE4J projects which use Ant. It may be worth investing some time to their mavenization. Also, projects should use default maven directory structure and build process that doesn’t depend on Ant. Project build should produce standard Maven artifacts (sources.jar, binaries.jar, javadoc.jar) and be as simple as running ‘mvn clean install’ without providing complicated properties. Also, it would be nice to agree on recommended version of Maven (and plugins) which should be used for next Jakarta EE release.
   
  
• Deprecate old and unused technologies
  All components preserving backwards compatibility is growing in size and complexity. We should extract old and rarely used technologies to optional modules and leave it up to users if they want to use it. Good sample is SDO and JPA-RS in EclipseLink.
   
  
• Prefer soft dependencies
  Think carefully before adding dependencies. Components depending on half of the world are heavy and not suitable for microservices development. Use modular approach allowing users to include only functionality needed in their application.
   
  
• Integration with CDI and Config
  Dependency injection and configuration should be a base core included in all projects. It will provide a nice consistency between all Jakarta EE components if they are configured the same standard way.
   
  
• Focus on testing
  I am not claiming that projects are not doing it. I am putting it here to remind developers that tests is very important part of every project. Specifications and APIs should be designed the way that applications implementing them can be easily tested.
   
  

If you have any questions, suggestions or not agree with statements above feel free to add comments or write me directly.

Thanks to Lukas Jungmann and Tomas Langer who helped me preparing this article.