Every single JSR has gone through a rigorous process of both public and JSR Expert Group scrutiny before being voted on by the JCP EC, for all Java EE APIs. Every JSR is weighed in terms of backward compatibility, benefit to the Java platform as a whole, etc. This painstaking JSR approval process ensures that every feature is accepted based on certain well-defined technical criteria. Similarly, every API of the new Jakarta EE platform will go through a well-defined specification process to ensure whatever API is included in the platform is going to be there for the long haul.

As discussed earlier, the new Jakarta EE specifications are going to be developed using a code-first approach through the Eclipse Foundation Specification Process. The EFSP is an open process that anyone can be part of. The entire specification process is developed in the open.

Jakarta EE development is effortless. All that’s needed is an application server or a Jakarta EE compliant runtime and one Maven dependency. It requires minimal configuration, follows convention over configuration, and leads to no XML hell. It also has sensible defaults. For example, EJBs are transactional by default, use default data-source, and are CDI-enabled by default.

This code snippet is the only dependency you need to have the entire Jakarta EE platform available at your fingertips. Moreover, because you are abstracted from the implementation of the standard, you only package your application with your code and any other third-party libraries used. Your chosen application server will provide the implementation and all the other heavy lifting required to run an application.

Jakarta EE as a standard means that your application should work with minimal to no configuration across various implementations of the standard, as long as you code against the standard. This is compelling because you don't get locked into one Jakarta EE application runtime vendor. Your code is portable across various application servers as long as you use the standard Jakarta EE APIs.

Jakarta EE is a huge platform that may appear intimidating at first. However, you can pick and choose whatever API your application requires. You can use the platform as a tank or as a pistol—you decide. All the various APIs are integrated as a whole if you choose to use Jakarta EE as a tank, or they can stand alone individually if you choose to nitpick. Also, as the application server provides the runtime implementation, whether you choose to use the entire platform or just select APIs, you still ship your application with just your code. Either way, your application is always shipped as a lightweight bundle.

Jakarta EE is a well organized community project that has an amazing amount of documentation. Chief among this is the Java EE Tutorials¹, the official Java EE handbook. There are also lots of community and corporate organized conferences—like Devoxx and Oracle CodeOne—that place a lot of emphasis on server-side Java development. There are also books written by individual developers like this one you are reading, all focused on helping you become a well-grounded enterprise Java software developer.

These points are just a few of the reasons why you should give Jakarta EE a try. I know in the J2EE days, the platform was a unwieldy thing for a lot of people. However, today, Jakarta EE is a nimble, elegant, deceptively simple but compelling software development platform, as you will see in the second part of this book.