Jakarta EE Challenges

Do you know that many famous people were born at the end of April? I’ll give you some samples. April 21 is the birthday of Queen Elizabeth II; Vladimir Lenin was born on April 22,  William Shakespeare on April 21, and Adolf Hitler on April 20. Maybe I shouldn’t include Hitler here, but he had a huge influence on 20th century history. Why do I mention this? Because on April 24, 2018, Jakarta EE was born. Using mathematical induction, we can predict that this newborn child will have a great influence on the Java world.

What’s the progress so far? There will be 39 projects under the umbrella EE4J project. 26 of them are already created. Others are in different states, but all them have been submitted for creation review. I made a table with a list of all of the projects, but it is quite big, so I included it in another article.

There are approximately 110 repositories to transfer, and about half of them have already been transferred.

Transferring projects may sound like an easy and straightforward process, but it’s not. It requires a lot of effort to transfer a project accurately. To help you understand, I’ll describe the steps to do it, and the challenges faced during this process. This should answer your “Why is it taking so long” questions that I often see in Twitter and on mailing lists.

  1. Internal license check

    We check all source files license headers to make sure they are correct. If not, we fix them. For old files it can be difficult to find an original file in a third party project.

  2. Internal third party analysis

    We run a third-party dependency analysis to identify which the dependencies should be replaced with their latest versions to fix major bugs and security issues. If these newer versions are not backward compatible with the older versions, then this requires some adoption work.

  3. Proposals creation

    In parallel with the steps above, we create project proposals in the Eclipse Foundation. The first challenge that we faced here is project granularity. We cannot (and don’t want) to create a project for every single repository. The Project Management Committee (PMC) decided to separate API and implementation projects and combine all satellite subprojects in the main project.
    Another challenge was how to name newly created projects. Names must not violate any required legal requirements and trademarks. It took quite a while to agree to use the “Eclipse Project for XXX” pattern for API projects (which typically used a name based on the Java trademark) and the “Eclipse XXX” pattern for implementation projects.
    The third challenge is to find contributors and leads. No one wants to contribute to old projects such as Enterprise Management.

  4. Initial Contribution

    When the proposal is created, approved, and has passed all required reviews, the project is created by the Eclipse Foundation. This allows us to start making an initial contribution and work with the Eclipse IP team to approve it. We submit one CQ (Contribution Questionnaire) for the initial contribution and one CQ for each project’s third party dependency. The Eclipse IP team often needs some clarification and may request changes. But if the license and third party work in steps 1 and 2 was done correctly, this step usually runs smoothly.

  5. Issues Transfer

    We created a special script to transfer issues. Our goal was to preserve issue numbers while doing the transfer to simplify the future work of updating web sites and issue links. The script took 8 hours just to transfer all of the Jersey issues.

  6. Build Environment

    We have to prepare a new build environment on Eclipse Foundation infrastructure. To help you understand the amount of work, the Compatibility Technology Kit (CTS) runs on a master machine with 50 slaves. CTS also requires a mail server and a JWSDP server, which are configured in a separate machine. To build GlassFish, we use 50 servers, and each server has 2 to 4 executors. So there are up to 200 executors in total. This configuration supports processing of up to 4 simultaneous pull requests. This is fine for normal development but not enough to process the intensive changes that usually happen at release time.
    For each EE4J project, we need to create Jenkins jobs to build the project, run unit tests, run TCK tests, and make nightly builds and Maven central releases. The Eclipse build infrastructure is different than what we use in Oracle, so all these jobs cannot be simply copied, they have to be reworked.

  7. Old projects shut down

    Java EE projects which have been transferred to the Eclipse Foundation have to be properly shut down. This requires updating project GitHub repositories and web sites with a message that this project has been transferred to the Eclipse Foundation. The message includes links to the new repository, issues tracker and project page. We are maintaining active Java EE communication channels, but we may shut them down in the future.

There were dozens of smaller challenges I didn’t put in the list. It was more difficult at the beginning. With experience, we know what to do and it goes faster. But we still have many challenges. One of them is transferring the CTS suite. It has never been open sourced, it’s full of third party dependencies, it’s in an SVN repository, and it’s huge. Maybe I should write another article about it. Another challenge is updating CI/CD jobs to use the new cloud-based build system recently introduced by the Eclipse Foundation.

I’d like to use this opportunity to ask the community to be more active and to contribute. Jakarta EE is a part of the open source foundation, and it belongs to the community. Your contributions are needed!

Subscribe to Jakarta EE community mailing list: jakarta.ee-community@eclipse.org
Contribute to EE4J projects: https://github.com/eclipse-ee4j
Jakarta EE on Twitter: @JakartaEE
Jakarta EE web site: https://jakarta.ee

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
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.