Book Image

Cloud-Native Development and Migration to Jakarta EE

By : Ron Veen, David Vlijmincx
Book Image

Cloud-Native Development and Migration to Jakarta EE

By: Ron Veen, David Vlijmincx

Overview of this book

Cloud-Native Development and Migration to Jakarta EE will help you unlock the secrets of Jakarta EE's evolution as you explore the migration and modernization of your applications. You’ll discover how to make your code compatible with the latest Jakarta EE version and how to leverage its modern features effectively. First, you’ll navigate the realm of cloud-native development as you demystify containers and get introduced to the Eclipse MicroProfile, a powerful tool in your toolkit. Next, you’ll take the bold step of transitioning your applications from local hardware to the limitless possibilities of the cloud. By following the author’s expert guidance to deploy your Jakarta EE applications on Microsoft Azure, you’ll gain hands-on experience in managing cloud resources. In the final leg of your journey, you’ll explore the world of serverless architecture. You’ll learn to design and run services that are truly serverless, harnessing the potential of the event-driven paradigm for scalability and cost-efficiency. By the end of this book, you’ll have mastered Jakarta EE and become a proficient cloud-native developer. Join us on this exciting journey of transformation and innovation as you pave the way for the future of Jakarta EE and cloud-native development.
Table of Contents (18 chapters)
1
Part 1: History of Java EE and Jakarta EE
4
Part 2: Modern Jakarta EE
8
Part 3: Embracing the Cloud
Appendix A: Java EE to Jakarta EE names
Appendix B: As a Service

Java EE 5, the first user-friendly version

This thing that hampered Java EE most of all was the sheer amount of configuration that you had to provide. All of these configurations had to be done in so-called XML deployment configuration files. We refer you to the documentation at https://docs.oracle.com/cd/E13211_01/wle/dd/ddref.htm, should you be interested in the content of the files.

For a container-managed entity bean, for instance, you had to specify each of the methods that were exported, its type parameters, and the return value.

It was not uncommon to have these configuration files being more than 300–400 lines of XML. This was called configuration hell, and this is where Java EE (back then still called J2EE) got its reputation in the developer community for being bloated.

Developers got so frustrated with this type of configuration that alternatives arose. The rise of the now very famous Spring Framework can be attributed to exactly these feelings. The Spring Framework itself required some XML configuration, but it wired up a lot of parts automatically for developers. Back then, what the Spring Framework did mostly, next to adding dependency injection, was wiring up the different components.

In 2005, version 5 of Java EE was released. This was the first time that J2EE was rebranded Java EE, but more importantly, it introduced annotations for the first time. Annotations allowed you to specify certain configuration options already in the code, thus providing a reasonable default setting. Now, it only was required to specify the situations where the configuration should divert from these default values. This is called convention over configuration, and it immensely reduces the amount of configuration required.

Another improvement was that you could now simply annotate a bean with, for instance, @Local, to define it as a local EJB. Again, dozens of lines of configuration were saved.

This was actually part of the introduction of the EJB3 specification. It was revolutionary in that sense that it deprecated the traditional entity beans in favor of the Java Persistence API(JPA).

JPA was heavily influenced by frameworks such as Hibernate, which provided an object-relational persistence approach. This meant that the mapping between database fields and Java fields was done by the framework now; no longer was application code required to achieve this mapping. This is known as Object-Relational Mapping (ORM).

With Java EE version 5, a very competitive and, maybe for the first time, very developer-friendly version of the specification became available. Suddenly, developing Java EE applications was not something just for very experienced developers anymore.