Posts tagged Java EE

Easily Manage Different Java Versions on Your Machine with SDKMan!

So, you're a Java developer, or maybe you're aspiring to be one. Either way, you've probably faced the challenge of managing multiple versions of Java on your machine. One project requires Java 8, but another needs Java 11, yet another requires Java 17. The open-source library you're keen on contributing to needs yet another version. What do you do? You start juggling environment variables, and before you know it, your system is a tangled mess of configurations. Not fun, right?

And let's not even get started on the difference between JRE and JDK. It's easy for beginners to get confused about the distinction between the two. The JRE (Java Runtime Environment) is sufficient if you just want to run Java applications, but if you're going to be developing them, you'll need the JDK (Java Development Kit). The JDK includes everything the JRE has, plus additional tools and utilities for developers like the Java compiler, or javac.

Tired of all this complexity? Let me introduce you to SDKMan!, a version manager that streamlines the process, making it a breeze to manage multiple Java versions on your machine. Not just Java, SDKMan! can be used to manage a lot more kits and tools such as Maven. In this blog post however, we see how to use SDKMan! to effortlessly manage different versions of Java on the same machine. 

Exploring the JSON-P API: Simplifying JSON Processing In Jakarta EE 10

JSON (JavaScript Object Notation) has become the de facto standard for data interchange in modern web applications. Its simplicity, readability, and compatibility have made it a popular choice for representing structured data. The JSON-P (JSON Processing) API provides a powerful and convenient way to parse, generate, transform, and query JSON data on the Jakarta EE Platform.  In this blog post, we will explore the fundamentals of the JSON-P API, its core functionalities, and how it empowers you to work with JSON effortlessly in your Jakarta EE applications. 

Getting Started With Apache Camel On Jakarta EE 10

Apache Camel is an open source enterprise integration framework that helps you connect different systems and applications together with as little effort as possible. It provides a simple and powerful way to define and implement message-based routing and mediation rules. It is an implementation of the patterns described in the book Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf.

In simple terms, Apache Camel acts as a "translator" or "bridge" between different systems. It allows you to easily route, transform, and process messages as they move from one system to another. It supports a wide range of communication protocols and data formats (JSON, XML, YAML, etc.), making it easier to integrate different technologies and applications.

How To Consume and Return Data In YAML In Jakarta REST

YAML is a simple, human-friendly data serialization language for all programming languages. It is the main format for working with Docker. As a language agnostic format, there are many bindings for all the major programming languages. You can easily consume and return data in the YAML format in your Jakarta REST application using message body readers and writers.

Intercepting REST Requests With Jakarta REST Request Filters

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.

Returning Beautiful Validation Error Messages In Jakarta REST With Exception Mappers

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. 

🔥NoSQL Persistence on The Jakarta EE Platform With Google Firestore🔥

SQL isn't your only option! 
 
Document NoSQL databases store data as document objects, much like JSON objects. Google Firestore is a document database, a NoSQL database offering from Google’s Firebase service. You store your data in documents that are collected into collections.

This guide will introduce you to incorporating Firestore NoSQL database into your Jakarta EE application.

5 Jakarta EE (Formerly Java EE) Myths That Need To Die

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.