One of the most important things that you need to know about Jakarta EE is that it is a standard, formerly managed by the Java Community Process (JCP) and now managed by the Eclipse Foundation.
A standard... for what? Well, for an application server! A Jakarta EE application server, for instance. This means that you can develop your Jakarta EE application knowing it will run in an environment that provides a bunch of resources that you can rely on. It also means you can easily move from one application server to another, as long as you stick to the Jakarta EE patterns instead of some vendor-specific feature (which is considered bad practice). Your application should have the same behavior no matter what Jakarta EE-compatible server you are using.
Beyond being a standard, Jakarta EE is also a certification. For a Jakarta EE server to be considered compatible, it has to pass a number of tests to guarantee that it implements every single point of the specification (JSR (short for Java Specification Requests)).
This amazing ecosystem means less coding of your application and gives you the chance to focus on what really matters to you or your client. Without a standard environment, you would need to implement your own code for request/response management, queues, connection pooling, and other stuff. You can definitely do that if you want, but you don't have to. Actually, you can even write your own Jakarta EE application server if you want to.
Having said that, let's move on with the chapter! In the following recipes, you are going to learn how to take advantage of some cool features already implemented on your favorite Jakarta EE application server.
Examples will be based on Eclipse GlassFish 5.1, but, as I mentioned before, they should have the same behavior for any other compatible implementation.
This chapter covers the following recipes:
- Preparing your application to use a connection pool
- Using messaging services for asynchronous communication
- Understanding a servlet's life cycle
- Transaction management