Java

Project Loom: Lightweight Java threads

Project Loom: Lightweight Java threads

Building responsiveness applications is a never-ending task. With the rise of powerful and multicore CPUs, more raw power is available for applications to consume. In Java, threads are used to make the application work on multiple tasks concurrently. A developer starts a Java thread in the program, and tasks are assigned to this thread to get processed. Threads can do a variety of tasks, such as read from a file, write to a database, take input from a user, and so on.

In this article, we’ll explain more about threads and introduce Project Loom, which supports high-throughput and lightweight concurrency in Java to help simplify writing scalable software.

Continue reading “Project Loom: Lightweight Java threads”

Share
Building and understanding reactive microservices using Eclipse Vert.x and distributed tracing

Building and understanding reactive microservices using Eclipse Vert.x and distributed tracing

I recently had the opportunity to speak at Red Hat Summit 2019. In my session, titled “Vert.x application development with Jaeger distributed tracing,” I discussed how scalable event-driven applications could be built with Eclipse Vert.x, a Java Virtual Machine toolkit for building reactive applications.

Thanks to many developer tools, creating these applications is no longer the most effort-consuming task in IT. Instead, we now have to understand how parts of our application function together to deliver a service, (across dev, test and production environments).  This can be difficult because, with distributed architectures, external monitoring only tells you the overall response time and the number of invocations, providing no insight into the individual operations. Additionally, log entries for a request are scattered across numerous logs. This article discusses the use of Eclipse Vert.x, distributed tracing, and Jaeger in the context of this problem.

Continue reading “Building and understanding reactive microservices using Eclipse Vert.x and distributed tracing”

Share
Migrating Java applications to Quarkus, Part 2: Before and after

Migrating Java applications to Quarkus, Part 2: Before and after

This article is a continuation of Migrating Java applications to Quarkus: Lessons learned, and here, I’ll make a comparison of performance metrics for building and running a Java app before and after Quarkus. My goal here is to demonstrate how awesome Quarkus is and maybe help you decide to use Quarkus to build your cool microservices.

Continue reading “Migrating Java applications to Quarkus, Part 2: Before and after”

Share
Optimizing Red Hat Fuse 7 Spring Boot container images

Optimizing Red Hat Fuse 7 Spring Boot container images

Working with Red Hat Fuse 7 on Spring Boot is straightforward. In my field experience, I have seen many development (a.k.a. integrator) teams moving to Fuse 7 on Spring Boot for their new integration platforms on Red Hat OpenShift Container Platform (well aligned with agile integration).

Lately, however, I have also seen some teams worried about the size of the final images and the deployment pipeline. In most cases, they had developed a set of common libraries or frameworks to extend or to homogenize the final integration projects. All the cases have the same result:

  • Several dependencies copied in each integration project
  • Always replacing the container images with the latest fat JAR (including the same dependencies) in each build pipeline

Spring Boot is usually packaged as “fat JARS” that contain all runtime dependencies. Although this is quite convenient, because you only need a JRE and a single JAR to run the application, in a container environment such as Red Hat OpenShift, you have to build a full container image to deploy your application.

Continue reading “Optimizing Red Hat Fuse 7 Spring Boot container images”

Share
Not all OpenJDK 12 builds include Shenandoah: Here’s why

Not all OpenJDK 12 builds include Shenandoah: Here’s why

OpenJDK 12 is now out, and it has new features. These are:

189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
230: Microbenchmark Suite
325: Switch Expressions (Preview)
334: JVM Constants API
340: One AArch64 Port, Not Two
341: Default CDS Archives
344: Abortable Mixed Collections for G1
346: Promptly Return Unused Committed Memory from G1

When I follow the link from the OpenJDK 12 project page to the open source builds page, I see the downloadable binaries. I download the Linux binary and install it, then see if the first item on the feature list, Shenandoah, works:

$ ./jdk-12/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -cp ~ Hello
Error occurred during initialization of VM
Option -XX:+UseShenandoahGC not supported

Oh! What is going on?

Continue reading “Not all OpenJDK 12 builds include Shenandoah: Here’s why”

Share
Migrating Java applications to Quarkus: Lessons learned

Migrating Java applications to Quarkus: Lessons learned

Migrating applications from a well-grounded framework to a completely new framework just a few days after its public release sounds crazy, right? Before doing so, I asked myself several questions, such as: Why should I do that? Is this new framework stable? What would be the gain? To me, the most important of these is: Why?

To help answer that question, I started thinking about my application’s performance—in this case, the bootstrap time—and asked myself whether I was happy with the actual time my application took to start up. The answer was no. And, nowadays, this is one of the most important metrics to be considered when working with microservices, mainly on a serverless architecture.

The goal of this article is to provide a point of reference for a basic migration of an existing Java EE application to Quarkus. For this reason, I’ll save a few lines of the article by not introducing Quarkus and focus mostly on the migration part. If you don’t know what Quarkus is, then I recommend reading this article and visiting the Quarkus homepage.

In this article, I’ll try to illustrate all the changes, or at least the most important changes, that I had to do on my existing application to make it run well with Quarkus.

Continue reading “Migrating Java applications to Quarkus: Lessons learned”

Share
From zero to Quarkus and Knative: The easy way

From zero to Quarkus and Knative: The easy way

You’ve probably already read about Quarkus, but you may not know that the superfast startup speed of Quarkus makes it the best candidate for working with Knative and serverless for your Function-as-a-Service (FaaS) projects.

Quarkus, also known as Supersonic, Subatomic Java, is a Kubernetes native Java stack tailored for GraalVM and OpenJDK HotSpot, crafted from the best-of-breed Java libraries and standards. Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads. You can learn more in this article series.

This article does not provide a full deep dive on Knative or Quarkus. Instead, I aim to give you a quick and easy way to start playing with both technologies so you can further explore on your own.

Continue reading “From zero to Quarkus and Knative: The easy way”

Share
10 things developers need to know about JShell

10 things developers need to know about JShell

JShell was introduced in JDK 9 as part of Java Enhancement Proposal (JEP) 222 under project Kulla. Many programming languages, such as JavaScript, Python, Ruby, etc., provide easy-to-use, command-line tools for their execution, but Java was still missing such a utility. So, JDK 9 introduced the Java shell (JShell) tool.

I discussed the basics of JShell (which is a Read-Evaluate-Print-Loop; REPL) in a previous article. In this article, I’ll cover advanced concepts in JShell that users should know for rapid development.

Continue reading “10 things developers need to know about JShell”

Share