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.

Jakarta EE Projects Summary

Some people were complained that it’s difficult to find information about all Jakarta EE projects and their transfer status. I collected this information in the table below. For today it’s the most complete and accurate data. Links points to a project home page if the project is created and to a proposal if the project has not been created yet.

Project Description Status
Eclipse GlassFish GlassFish and satellite projects Created
Eclipse Grizzly Grizzly and satellite projects Created
Eclipse Jakarta EE Platform Jakarta EE Spec, schemas, etc. Pending
Eclipse Jakarta EE TCK CTS testing suite Pending
Eclipse Implementation of JAXB JAXB reference implementation + satellite projects Pending
Eclipse Jersey Jersey + WADL Created
Eclipse Metro JAX-WS reference implementation, SAAJ reference implementation, WSIT + satellite projects Pending
Eclipse Mojarra JSF reference implementation Created
Eclipse OpenMQ JMS reference implementation Created
Eclipse ORB ORB related repositories Pending
Eclipse Ozark MVC API reference implementation Pending
Eclipse Project for Common Annotations Common Annotations for the Java Platform, starting from the specification defined by JSR-250. Created
Eclipse Project for Concurrency Utilities Concurrency Utilities for Java EE, starting from the specification defined by JSR-236. Created
Eclipse Project for EJB Enterprise JavaBeans, starting from the specification defined by JSR-345. Pending
Eclipse Project for Enterprise Security Java EE Security API, starting from the specification defined by JSR-375. Created
Eclipse Project for Expression Language Java Expression Language, starting from the specification defined by JSR-341. Created
Eclipse Project for Interceptors Interceptors API, starting from the specification defined by JSR-318. Pending
Eclipse Project for JACC Java Authorization Contract for Containers, starting from the specification defined by JSR-115 Created
Eclipse Project for JAF JavaBeans Activation Framework, starting from the specification defined by JSR-925. In Review
Eclipse Project for JASPIC Java Authentication Service Provider Interface for Containers, starting from the specification defined by JSR-196. Created
Eclipse Project for JavaMail JavaMail, starting from the specification defined by JSR-919. Created
Eclipse Project for JAX-RS Java API for RESTful Web Services (JAX-RS), starting from the specification defined by JSR-370. Created
Eclipse Project for JAX-WS
  • Java API for XML-Based Web Services (JAX-WS) 2.0 (starting from the specification defined by JSR-224)
  • Java APIs for XML Messaging (starting from the specification defined by JSR-67)
  • Web Services Metadata for the Java Platform (starting from the specification defined by JSR-181)
In Review
Eclipse Project for JAXB Java Architecture for XML Binding (JAXB), starting from the specification defined by JSR-222. In Review
Eclipse Project for JCA Jakarta EE Connector Architecture, starting from the specification defined by JSR-322. Pending
Eclipse Project for JMS Java Message Service (JMS) API, starting from the specification defined by JSR-343. Created
Eclipse Project for JPA Java Persistence starting from the specification defined by JSR-338. Pending
Eclipse Project for JSON Processing Java API for JSON Processing, starting from the specification defined by JSR-374 + reference implementation. Created
Eclipse Project for JSON-B Java API for JSON Binding, starting from the specification defined by JSR-367. Created
Eclipse Project for JSP JavaServer Pages, starting from the specification defined by JSR-245. Created
Eclipse Project for JSTL JavaServer Pages Standard Tag Library, starting from the specification defined by JSR-52. Created
Eclipse Project for JTA Java Transaction API, starting from the specification defined by JSR-907. Created
Eclipse Project for Servlet Java Servlet API starting from the specification defined by JSR-369. Created
Eclipse Project for Stable EE4J APIs Legacy APIs. Currently contains

  • Enterprise Management API
  • Enterprise Deployment API
  • JAX-RPC API
  • JAXR API
Created
Eclipse Project for WebSocket Java API for WebSocket, starting from the specification defined by JSR-356. Created
Eclipse Soteria Enterprise Security API reference implementation Created
Eclipse Tyrus WebSocket API reference implementation Created
Eclipse Yasson JSON-B reference implementation Created
EclipseLink JPA reference implementation Created

I’ll try to keep this table updated when projects status is changed.

EclipseLink repository is moved to GitHub

As part of a process of transferring Java EE 8 to the Eclipse Foundation, EclipseLink source code repository was moved from Eclipse git to eclipse-ee4j organization on GitHub. It aligns EclipseLink with other EE4J projects and makes it more open to the community.

If you are a committer don’t forget to update your local copy!

New Location Old Location
Repository EE4J GitHub Eclipse git + Mirror
Issues Tracker EE4J GitHub + Eclipse BugZilla Eclipse BugZilla

From now on GitHub repository becomes a main working repository. All pull request and code reviews must be done there. Old repository on Eclipse git is switched to read only mode and will be eventually deleted as well as it’s mirror on GitHub.

I am also recommending using GitHib issues tracker for bugs submission the same way as other EE4J projects are doing. The old issues tracker is still active though.

Other project repositories (examples, etc.) will be also moved to EE4J GitHub in the nearest future.

JSON-P Sources are Transferred to Eclipse Foundation

Screen Shot 2018-01-11 at 21.43.24

Today is a big date. I just pushed JSON Processing sources to Eclipse EE4J GitHub repository.

See it live here: https://github.com/eclipse-ee4j/jsonp

It’s first sources which are actually transferred from Oracle to Eclipse. First two projects (Yasson and EclipseLink) were already in Eclipse Foundation, but under different root project.

More project coming soon! The firsts make history. And the first one was JSON-P!

First two EE4J projects

Screen Shot 2017-12-19 at 23.45.11

I am happy to announce that today EclipseLink and Yasson have been transferred under EE4J and officially became first two EE4J projects! EE4J now contains some real Java code and it’s a big step forward!

New projects URLs are:

Yasson: https://projects.eclipse.org/projects/ee4j.yasson
EclipseLink: https://projects.eclipse.org/projects/ee4j.eclipselink

Committers list, mailing list and forum URLs are not changed.

Yasson and EclipseLink go to EE4J

I am happy to announce that we are planning to transfer Yasson and EclipseLink projects to EE4J. These will be one of the first projects transferred because they are a part of Eclipse Foundation already. I already posted announcement in EE4J community mailing list here:

https://dev.eclipse.org/mhonarc/lists/ee4j-community/msg00341.html

The transfer will not affect any committer rights, but it may introduce some changes in web site URL, mailing lists, etc.
I’ll keep you updated about the progress.