What Is Payara Platform Enterprise? 

In prior versions of Jakarta EE, the use of UUID as entity ID or database primary key type was a vendor specific feature. So even though you could use it, you had to rely on vendor specific constructs to get the mapping right. With the release of Jakarta EE 10 however, the Jakarta Persistence specification now provides native support for using UUID as entity ID type.

The jakarta.persistence.GenerationType now has a UUID option that indicates to the persistence provider to generate and assign RFC 4122 UUID to the annotated field. The HelloEntity below shows how to use this new feature.

Jakarta EE 10 was released in September of 2022 as the first major release of the venerable Enterprise Java development platform since it was moved to the Eclipse Foundation. As a major release, it did come with a slew of updates to almost all the major specifications, including Jakarta REST. In this blog post, we take a look at how to get started developing RESTful web services on the Jakarta EE Platform using the Jakarta REST API.

Oftentimes in web applications, there is the need to intercept a request from the client to resource methods. Sometimes this interception must take place even before the request is matched to a resource method. For such needs, Jakarta REST provides the jakarta.ws.rs.container.ContainerRequestFilter interface. This interface is a Jakarta REST extension that can be used to intercept requests to resource methods. 

An implementation of this interface can decide if requests should be intercepted before they’re matched to resource methods through the @PreMatching annotation. A pre-matched request filter will be invoked by the container before the request is matched to its intended resource method. 

For this blog post, let us look at two use cases for request filters. One is a situation where for security reasons, certain HTTP methods are not allowed. For example an organisation can have a security rule in its firewall that disallows HTTP PUT methods. In this case, either all methods have to be POST or request filters can be used to workaround the restriction. 

The second situation is for the custom implementation of authentication. Of course you absolutely should NOT hand-roll your own security setup unless you know in detail exactly what you are doing. You are better off using tried and tested security frameworks and services out there. But for this blog post, assuming we need to implement custom security, we can use a pre matching request filter. The following code snippet below shows a ContainerRequestFilter implementation that implements the two scenarios above.

Java generics is a great feature that allows you to have compile time checks for generics. However, due to historical reasons of backward compatibility, type information for generics is erased at runtime. A lot of the time this shouldn’t be of much concern. But there are a few cases where type information is needed at runtime for some kind of decision. 

One such situation is in Jakarta REST when the jakarta.ws.rs.core.Response object is used to return a generic collection of a specific type. For example the code below shows the creation and return of a Response object that has a list of HelloEntity as the return payload to the client. 

All non-trivial enterprise applications have some sort of constraints on the data the application processes. These constraints could range from the simplest to the most complex custom built types. The default validation API on theJakarta EEPlatform, Jakarta Bean Validation has excellent out of the box support for constraining bean fields. Then with its @Valid annotation, you can trigger automatic validation of constrained objects in certain points of an application. 

It's a new month, and this February the Payara Fish Pond is bristling with new releases for both Payara Platform Community and Enterprise editions. Payara Platform Community 6.2023.2 is out with 3 improvements and 5 bug fixes. Payara Platform Enterprise 5.48.1 contains 2 improvements and 5 bug fixes.

The Jakarta EE Platform has come a long way since its debut as J2EE back the days of Sun Microsystems. Over the years, it has had its fair share of challenges. A natural consequence of this is that some notions about the platform arising from some of the past challenges that may have been true about past iterations have stuck. This blog post aims to dispel some of these deeply rooted misconceptions about the Jakarta EE Platform, especially after the last major release.

Jakarta EE 10 shipped with the fourth major release of its component based web framework Jakarta Faces. Hitherto known as Jakarta Server Faces, and Java Server Faces before that, Jakarta Faces, or just Faces,version 4.0is the first major version with API change since version 2.3 in Java EE 8. Among the major changes in this version are:

This post is inspired by Gunnar Morling'sposton a similar theme for the Java SE Platform. It is an opinionated guide to getting started developing applications on the Jakarta EE Platform. As an opinionated post, there may be some recommendations that you disagree with. That is natural. The post is directed at people just getting started and feel overwhelmed by all the options out there for getting started with enterprise Java. The post is broken down into the following sections;