And then came a crazy month and just now I had the opportunity to write a few lines about it! :-)

So, straight to the point, what you should know about the book (in case you have any interest in it).

Target audience

Java developers working on enterprise applications and that would like to get the best from the Jakarta EE platform.

Topics covered

I'm sure this is one of the most complete books of this field, and I'm saying it based on the covered topics:

• Server-side development
• Building services with RESTful features
• Web and client-server communication
• Security in the enterprise architecture
• Jakarta EE standards (and how does it save you time on a daily basis)
• Deployment and management using some of the best Jakarta EE application servers
• Microservices with Jakarta EE and Eclipse MicroProfile
• CI/CD
• Multithreading
• Event-driven for reactive applications
• Jakarta EE, containers & cloud computing

Style and approach

The book has the word "cookbook" on its name for a reason: it follows a 100% practical approach, with almost all working code available in the book (we only omitted the imports for the sake of the space).

And talking about the source code being available, it is really available on my Github: https://github.com/eldermoraes/javaee8-cookbook

PRs and Stars are welcomed! :-)

Bonus content

The book has an appendix that would be worthy of another book! I tell the readers how sharing knowledge has changed my career for good and how you can apply what I've learned in your own career.

Surprise, surprise

In the first 24 hours of its release, this book simply reached the 1st place at Amazon among other Java releases! Wow!

Of course, I'm more than happy and honored for such a warm welcome given to my baby... :-)

If you are interested in it, we are in the very last days of the special price in celebration of its release. You can take a look here http://book.eldermoraes.com

Leave your comments if you need any clarification about it. See you!

This is the most viewed post of this blog, so I believe it deserves an update now in 2020! Its first version was written back in 2017.

There's a lot of different opinions in this kind of lists, and there will be always somebody or something missing... just don't be too passionate or take things personally, ok?! ;-)

******************************************************

We all have to agree: there are tons of tons of information shared through social media. It's no different on Twitter.

When we talk about staying tuned with some technology, it's important to have some kind of focus. Otherwise, you could end up confused or, worst, getting bad and/or wrong information.

For these reasons I have a small but incredible list of people/accounts that I use to follow on Twitter to get really good information about Jakarta EE.

If you are passionate about Jakarta EE like me, I truly hope this list may be helpful to you. If you are not, I hope you enjoy as well! ;-)

Important: the list isn't a ranking, so don't judge the account by the position at the list. In fact, don't judge anyone by anything...

Jakarta EE - @JakartaEE

The official Jakarta EE handle.

Wayne Beaton - @waynebeaton

Wayne is a Director of Open Source Projects at the Eclipse Foundation. Undoubtedly, Jakarta EE is one of the biggest projects at Eclipse today (if not the biggest one), so it's important to stay tunned with Wayne has to say.

Adam Bien - @AdamBien

Adam works as a freelancer with Java since JDK 1.0, with Servlets/EJB since 1.0 and before the advent of J2EE in several large-scale applications. He is an architect and developer (with usually 20/80 distribution) in Java (SE / EE / FX) projects. He has written several books about JavaFX, J2EE, and Java EE, and he is the author of Real World Java EE Patterns—Rethinking Best Practices and Real World Java EE Night Hacks—Dissecting The Business Tier.

He is also a Java Champion, NetBeans Dream Team Founding Member, Oracle ACE Director, Java Developer of the Year 2010 and has a huge amount of nominations as JavaOne Rockstar.

Kevin Sutter - @kwsutter

Kevin Sutter is the lead architect for the Jakarta EE and JPA solutions for WebSphere Application Server and the WebSphere Liberty Profile. He is also very active with Java and open-source strategies as they relate to IBM’s application middleware.

Ivar Grimstad - @ivar_grimstad

Ivar Grimstad is Java Champion, JUG Leader, JCP Spec Lead, EC and EG Member, NetBeans Dream Team and International Speaker.

He is the PMC (Project Management Committee) Lead of EE4J and Jakarta EE Developer Advocate at Eclipse Foundation.

David Blevins - @dblevins

David Blevins is the founder of Tomitribe and a veteran of open source Jakarta EE. He has been both implementing and defining Enterprise Java specifications for more than 10 years and has a strong drive to see it simple, testable, and as light as Java SE. Blevins is cofounder of OpenEJB (1999), Geronimo (2003), and TomEE (2011). He is a member of the EJB 3.0, EJB 3.1, EJB 3.2, Java EE 6, Java EE 7, and Java EE 8 Security Expert Groups, and a member of the Apache Software Foundation. Blevins is a contributing author to Component-Based Software Engineering: Putting the Pieces Together (Addison Wesley). Blevins is also a regular speaker at JavaOne, Devoxx, ApacheCon, OSCon, JAX, and other Java-focused conferences.

Otavio Santana - @otaviojava

Otávio Santana is a developer and enthusiast of open source. He is an evangelist and practitioner of agile philosophy and polyglot development in Brazil. Santana is a JUG leader of JavaBahia and SouJava, and a strong supporter of Java communities in Brazil, where he also leads the BrasilJUGs initiative to incorporate Brazilian JUGs into joint activities.

He is also the co-creator of Jakarta NoSQL, a Java framework that streamlines the integration of Java applications with NoSQL databases. It defines a set of APIs to interact with NoSQL databases and provides a standard implementation for most NoSQL databases. This helps to achieve very low coupling with the underlying NoSQL technologies used.

Java Champions - @Java_Champions

Well, why the Java Champions handle is here? Because many Java Champions are Jakarta EE experts, so following the official Twitter is nice to be in touch with what they are saying about it.

Alex Theedom - @alextheedom

Trainer, Java Champion, Jakarta EE spec committee, author of Jakarta EE books and courses. Conference speaker and blogger.

OmniFaces - @OmniFaces

OmniFaces is a utility library for JSF 2 that focusses on utilities that ease everyday tasks with the standard JSF API. OmniFaces is a response to frequently recurring problems encountered during ages of professional JSF development and from questions being asked on Stack Overflow.

Dmitry Kornilov - @m0mus

Dmitry has over 20 years of experience in design and implementation of complex software systems, defining systems architecture, team leading and project management. He has worked as project leader of EclipseLink and Yasson and as spec lead of JSON-P and JSON-B specifications.

Steve Millidge - @l33tj4v4

Steve is the Founder and Director of Payara and C2B2 Consulting. Having used Java extensively since pre1.0, Steve has over 15 years’ experience as a field-based Professional Service Consultant along with extensive knowledge of Java middleware.

Before running his own business, Steve worked for Oracle as a Principal Consultant in Oracle’s Technology Architecture Practice, specializing in Business Process Integration and scalable n-tier component architectures.

Emily Jiang - @emilyfhjiang

Emily is a Java Champion and has been working on MicroProfile since 2016. She also leads the specifications of MicroProfile Config, Fault Tolerance and Service Mesh. She works for IBM as Liberty Architect for MicroProfile and CDI and is heavily involved in Java EE implementation in Liberty releases.

Arjan Tijms - @arjan_tijms

Arjan is a Jakarta EE committer and member of the Jakarta EE Steering Committee.

MicroProfile - @MicroProfileIO

MicroProfile is a baseline platform definition that optimizes Enterprise Java for a microservices architecture and delivers application portability across multiple MicroProfile runtimes. The initially planned baseline is JAX-RS + CDI + JSON-P, with the intent of the community having an active role in the MicroProfile definition and roadmap.

Sebastian Daschner - @DaschnerS

Sebastian has been working with Java enterprise software development for many years. Besides his work for clients, he set a high priority in educating developers in conference presentations, video courses, and training. He believes that teaching others not only greatly improves their situation but also educates yourself.

David Heffelfinger - @ensode

David R. Heffelfinger is an independent consultant based in the greater Washington DC area. He has authored several books on Java EE and related technologies. Heffelfinger has been architecting, designing, and developing software professionally since 1995. He has been using Java as his primary programming language since 1996. He has worked on many large-scale projects for several clients, including the US Department of Homeland Security, Freddie Mac, Fannie Mae, and the US Department of Defense. He has a master's degree in software engineering from Southern Methodist University, Dallas, Texas. Heffelfinger is a frequent speaker at Java conferences such as Oracle Code One (forme JavaOne).

John Clingan - @jclingan

John is Product Manager at Red Hat and an ex Java EE PM. He is also a MicroProfile co-founder.

Josh Juneau - @javajuneau

Josh Juneau works as an application developer, system analyst, and database administrator. He is active in many fields of application development but primarily focuses on Jakarta EE. Juneau is a technical writer for Oracle Technology Network, Java Magazine, and Apress. He is a member of the NetBeans Dream Team, the JCP, and a part of the JSR 372 Expert Group. He enjoys working with the Java community—he is the director of meetings for the Chicago Java User Group.

Tanja Obradovic - @TanjaEclipse

Tanja is the Jakarta EE Program Manager at Eclipse Foundation.

An airhacks.fm podcast conversation with Elder Moraes (@elderjava) about Java EE at JavaONE, why Java EE at all, enjoying boring stuff, Java EE for pet projects, thinking freely about business problems, no distractions, servlets and JSPs, Java as career choice, Jakarta EE opinions, Oracle's Java EE stewardship, Java EE 8 being late, Jakarta EE should remain boring, Jakarta EE and profiles, an idea for a Jakarta EE profile creation process, Eclipse Foundation and agility, the pace of MicroProfile, thoughts on Cloud Native, Java EE in Cloud Native environments, Sebastian Daschner and successful Java EE careers, Java EE impact on startups, ES 6, TypeScript, thoughts on serverless, future of Jakarta EE, JVM overhead and microservices, GraalVM and Nashorn, JavaONE vs Oracle Code, Java EE 8 recipes in the Java EE 8 Cookbook.

Checkout: eldermoraes.com, GitHub and @elderjava.

Subscribe to airhacks.fm podcast via: RSS iTunes

In this section, you're going to take a look at the following things:

• How to develop, build, and run your first Java-EE-8-powered microservices
• Required Java EE 8 dependencies for basic web-service development
• Basic components of any JAX-RS-based web service
• Deployment of a thin WAR artifact using Payara Server 5

Time to get started and dive into the code. The following is a prepared IDE and a raw skeleton Maven project. What you see here is a very basic POM file:

There's one thing missing though; first, you need to define the required dependency for the Java EE 8 API:

<dependency>
  <groupId>javax</groupId>
  <artifactId>javaee-api</artifactId>
  <version>8.0</version>
  <scope>provided</scope>
</dependency>

Specify version as 8.0. You must also define the proper scope for this, which, in this case, is provided, because the Java EE 8 API will later be provided by the application server. Next, add a beans.xml descriptor to the WEB-INF directory of the web application:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                      http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       bean-discovery-mode="all">
</beans>

Next, you need to bootstrap your JAX-RS application. Create a class called JAXRSConfiguration. The name really doesn't matter. What's important is that this class extends from the Application base class. Bear in mind the javax.ws.rs.core package while selecting Application. It's also important that you specify the @ApplicationPath annotation. This will be the base path to access the REST API:

package com.packtpub.javaee8;

//skipping imports to save space

/**
 * Configures a JAX-RS endpoint.
 */
@ApplicationPath("api")
public class JAXRSConfiguration extends Application {
}

Once you've bootstrapped JAX-RS, what's missing is a proper REST resource. Create a class called HelloWorldResouce. You’ve used the @Path annotation, which will be the path this resource will be accessible under. Call that "hello". Next up, create a method that will produce the proper response once called: helloWorld. Use the proper Response here; annotate this using the @GET annotation, as you’ll need to issue GET requests later on, and say that it produces MediaType.APPLICATION_JSON. Then return Response.ok, where ok is HTTP status 200 of a response when you call the build. So, what should be used as the response? Use Map<String, String> as the response and return singletonMap with the message key and the Hello World value:

package com.packtpub.javaee8;

//skipping imports to save space
/**
* The REST resource implementation class.
*/
@Path("hello")
public class HelloWorldResource {
   @GET
   @Produces(MediaType.APPLICATION_JSON)
   public Response helloWorld() {
      Map<String, String> response = singletonMap("message", 
                     "Building Web Services with Java EE 8.");
      return Response.ok(response).build();
   }
}

You should already have a basic working microservice. Now deploy this onto our Payara Server 5 and run it. You’re going to deploy the WAR file that’s been built; you can see that it's already been deployed and the deployment took 5.1 milliseconds.

Check your browser. You should see the "Hello World." message, as shown in the following screenshot:

Now modify the value here to "Building Web Services with Java EE 8". Deploy this once more and update your artifact. The new version has been deployed. Go back to your browser to check whether you have the proper response message:

That's all for this section; in the next section, you’ll see how to containerize a Java EE 8 microservice.

Containerizing Java EE 8 microservices

In this section, you're going to take a look at how to containerize and run Java EE 8 microservices using Docker. You'll learn how to write a basic Dockerfile and see how to build and run the Docker image using Payara Server full and Payara Server micro edition. Open the IDE to the microservice project from the previous section. All that's missing here is Dockerfile, so create one.

You must be wondering about which base image you should use. You have two basic options when using Payara—you can either use the server-full image or the Payara micro edition. For the purposes of this tutorial, use the full version of Payara first. Dockerfile will be as follows:

FROM payara/server-full:5-SNAPSHOT
COPY target/hello-javaee8.war $DEPLOY_DIR

In the preceding Dockerfile, you’ve mentioned that you're using payara/server-full. You need to use its correct version, which, in this case, is version 5-SNAPSHOT. Then, you can copy the hello-javaee8.war file of your microservice into the correct location of the produced image. You need to issue a COPY command from target/hello-javaee8.war and then copy this into the deployment directory. To check whether it works, open a console, keeping in mind that you're in the right directory. Check whether everything is packaged nicely by calling mvn package, just to make sure the WAR file is in the correct state. If it is, you'll see things running while compiling, an absence of tests, and an updated WAR file:

Build Docker using -t, which specifies the tag you want to use, by calling hello-javaee8 and giving it version number 1.0:

>docker build -t hello-javaee8:1.0 .

Use the following command to see whether your server starts up:

>docker run -it -p 8080:8080 hello-javaee8:1.0

You’ve mapped port 8080 from the container onto your Docker host. You'll see that the Payara Server is starting up in the console (which would take only a couple of seconds), after which the application will be deployed. To check whether you can reach the web service, hit the IP address as shown in the following screenshot:

Now it’s time to see how to use the Payara micro edition. Stop the service you just created and delete the contents of Dockerfile. First, you need to change FROM by use a different base tag for this image (payara/micro:5-SNAPSHOT). Then, copy the hello-javaee8.war file into the proper location for this base image. Next, copy the WAR file in the target directory and call it to /opt/payara/deployments. This is the default deployments directory for the micro edition base container. The Dockerfile should look as follows:

FROM payara/micro:5-SNAPSHOT
COPY target/hello-javaee8.war /opt/payara/deployments

Switch back to the console and issue the Docker build command again:

>docker build -t hello-javaee8:1.0 .

Fire up the container again:

>docker run -it -p 8080:8080 hello-javaee8:1.0

You can see that the output in the console changes, as you're using the Payara micro runtime this time. This takes a couple of seconds to spin up the web service. You can see that the REST Endpoints are available. To check again, go to the management console; you can see that you have a running container. Try calling the web service from the browser, as shown in the following screenshot:

As you can see, everything's working just fine and you have a running dockerized version of the service.

You’ve learned the basics of working with Java EE 8 microservices. To learn more about RESTful web services and Java EE 8, you can explore Building RESTful Microservices with Java EE 8. It’s a comprehensive guide that shows you how to use the APIs provided by Java EE to create RESTful web services. The book goes in depth to explain the usage of different JAX-RS APIs, while also delving into the structure of web services and data sharing between applications. The book is a must-read for Java developers keen on learning how to implement web services using the latest Java EE 8 APIs.

Learn how to connect external services and configure orchestrated applications in this tutorial by Sebastian Daschner, the author of Architecting Modern Java EE Applications.

The orchestration framework orchestrates and integrates enterprise applications in clustered environments. It takes a lot of work off the used application technology. Container orchestration also greatly simplifies the configuration of orchestrated applications and connection to external services.

Connecting external services

Client controls require URLs to connect against in order to integrate external services. The URLs traditionally have been configured in files, which potentially differed in various environments. In an orchestrated environment, the application can resolve external services using a logical name via DNS. The following code snippet shows how to connect against the cloud processor application:

@ApplicationScoped
public class HelloCloudProcessor {

   private Client client;
   private WebTarget target;

   @PostConstruct
   private void initClient() {
       client = ClientBuilder...
       target = client.target("http://cloud-processor:8080/processor/resources/hello");
   }

   public String processGreeting() {
       ...
   }
}

The same holds true for other URLs (for example datasource definitions). The application server configuration can simply point to the name of the database service and use it to resolve the corresponding instance at runtime.

Configuring orchestrated applications

Resolving services by logical names already eliminates a lot of configuration in the application. Since the same container image is being used in all environments, a potentially different configuration needs to be inserted from the orchestration environment. As shown in the previous example, Kubernetes config maps tackle this situation. The hello-cloud application expects that at runtime a properties file will reside under /opt/config/application.properties. The project code will hence access this location. The following demonstrates the integration of the properties file using a CDI producer:

public class HelloGreeter {

   @Inject
   @Config("hello.greeting")
   String greeting;

   @Inject
   @Config("hello.name")
   String greetingName;

   public String processGreeting() {
       return greeting + ", " + greetingName;
   }
}

The CDI producer is defined similarly to the configuration example shown previously:

@ApplicationScoped
public class ConfigurationExposer {

   private final Properties properties = new Properties();

   @PostConstruct
   private void initProperties() {
       try (InputStream inputStream =
               new FileInputStream("/opt/config/application.properties")) {
           properties.load(inputStream);
       } catch (IOException e) {
           throw new IllegalStateException("Could not init configuration", e);
       }
   }

   @Produces
   @Config("")
   public String exposeConfig(InjectionPoint injectionPoint) {
       Config config = injectionPoint.getAnnotated().getAnnotation(Config.class);
       if (config != null)
           return properties.getProperty(config.value());
       return null;
   }
}

The application loads the contents of the properties file into the properties map and produces the configured values using CDI. All managed beans can inject these values, which emerge from the Kubernetes config map.

In order to realize secret configuration values, Kubernetes includes the concept of secrets. A common practice is to make the contents of the secrets accessible in containers using environment variables.

Java applications use the System.getenv() method to access environment variables. This functionality is used for both secrets and config map values, respectively.

The demonstrated approaches and examples enable an enterprise application to be deployed, managed, and configured in a container orchestration cluster. They are sufficient for a majority of use cases.

You can now connect external services and configure orchestrated applications in Jakarta EE. If you found this tutorial helpful, you can explore Architecting Modern Java EE Applications, an end-to-end guide to designing and developing modern, business-oriented applications using Java EE 8. So if you’re a Java EE developer keen on architecting enterprise-grade applications, this book is a must-read!