Jakarta EE Technical Directions

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.

One thought on “Jakarta EE Technical Directions

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s