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”
In 2018, Oracle announced that it would only provide free public updates and auto-updates of Java SE 8 for commercial users until the end of January 2019. Java 8 is a very important platform, used by millions of programmers, so this was a big deal. The Java community needed to fill the gap.
Continue reading “OpenJDK 8 and 11: Still in safe hands”
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”
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”
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”
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”
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”
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”
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”
JBoss Tools 4.11.0 and Red Hat CodeReady Studio 12.11 for Eclipse 2019-03 are here and are waiting for you. In this article, I’ll cover the highlights of the new releases and show how to get started.
Continue reading “Announcing Red Hat CodeReady Studio 12.11.0.GA and JBoss Tools 4.11.0.Final for Eclipse 2019-03”