When OpenJDK‘s Java virtual machine (JVM) runs a Java application, it loads a dozen or so classes before it starts the main class. It runs a method several hundred times before it invokes the optimizing compiler on that method. This preparation is a critical component of Java’s “write once, run anywhere” power, but it comes at the cost of long startup times.
Continue reading Checkpointing Java from outside of Java
As a developer, you have probably experimented with Kubernetes. It’s also possible that you are already running several Java applications on a Kubernetes platform, maybe Red Hat OpenShift. These initial containerized applications were greenfield projects, where you enjoyed the benefits of a platform providing templated deployments, easy rollbacks, resource availability, security by default, and a manageable way to publish your services.
Now, you might be thinking, “How can I enjoy all of these benefits in my existing Java applications?” Most Java applications in production today are running on virtual machines (VMs), likely on an application platform that is not container friendly. So, how can you migrate them from the current platform to containers on Kubernetes?
It isn’t an easy task, but this is a problem that we have been working hard on for years. Red Hat’s Migration Toolkit for Applications (MTA) 5.0 is the latest resulting iteration: An assembly of tools that you can use to analyze existing applications and discover what is required to modernize them. Read on to learn MTA 5.0’s features and migration paths.
Continue reading “Migrate your Java apps to containers with Migration Toolkit for Applications 5.0”
The OpenJDK 8u 262 release includes several security-related patches and a new addition, JDK Flight Recorder (JFR). This article introduces OpenJDK developers to using JDK Flight Recorder with JDK Mission Control and related utilities. I will also briefly introduce you to Project Hamburg, also known as Container JFR.
Continue reading Get started with JDK Flight Recorder in OpenJDK 8u
The GraalVM project includes, amongst other capabilities, a component called GraalVM Native Image. GraalVM Native Image supports the delivery of Java applications as shrink-wrapped, self-contained, standalone executables, commonly referred to as Java-native images. Native images often have a smaller footprint and faster startup time compared to running the same application in the traditional way on the JVM. This is often a win for short-running applications or small, container-based services. The trade-off is usually lower peak performance for long-running programs, and higher garbage collection overheads and latencies for programs with large amounts of resident data.
We are especially interested in GraalVM-native images as an alternative back-end delivery option for applications based on Quarkus. The Java team has worked hard to ensure that Quarkus is well integrated with GraalVM Native Images. In the process, they have found that one important usability issue is the ability to debug the delivered native image.
Continue reading “Debugging GraalVM-native images using gdb”
I’ve had many proud moments in my role here at Red Hat over the years. Examples include when we released the first version of WildFly, when we acquired the Camel team, when we worked with other vendors to create Eclipse MicroProfile, the great work the Strimzi team did to get into the Cloud Native Computing Foundation, our entire Red Hat Managed Integration effort, Kogito, and the list goes on. I feel like I add to this list of examples on an almost weekly basis.
Well, I can now update this list with the first product release of Quarkus, formally called the Red Hat build of Quarkus. (You can also find more support options on the Quarkus project site.) It should come as no surprise that Quarkus is on this list. I suppose what might surprise some people is that Quarkus is only just a product now. Given all of the activities since we officially launched the Quarkus project in 2019, you could be forgiven for thinking it was already a product.
Continue reading “The road to Quarkus GA: Completing the first supported Kubernetes-native Java stack”
Java has been in a bit of an awkward spot since containers took off a few years ago. In the world of Kubernetes, microservices, and serverless, it has been getting harder and harder to ignore that Java applications are, by today’s standards, bloated. Well, until now. In this article, I explore the basics of Quarkus, a Kubernetes-native Java framework built to specifically address Java’s bloatedness problem.
Continue reading Ramp up on Quarkus: A Kubernetes-native Java framework
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”
Quarkus is Kubernetes native, and to accomplish that we’ve spent a lot of time working across a number of different areas, such as the Java Virtual Machine (JVM) and various framework optimizations. And, there’s much more work still to be done. One area that has piqued the interest of the developer community is Quarkus’s comprehensive and seamless approach to generating an operating system specific (aka native) executable from your Java code, as you do with languages like C and C++, which we believe will typically be used at the end of the build-test-deploy cycle.
Although the native compilation is important, as we’ll discuss later, Quarkus works really well with vanilla OpenJDK Hotspot, thanks to the significant performance improvements we’ve made to the entire stack. The native executable aspect Quarkus offers is optional and, if you don’t want it or your applications don’t need it, then you can ignore it. In fact, even when you are using native images, Quarkus still relies heavily on OpenJDK. The well-received dev mode is able to deliver near-instantaneous change-test cycles all due to Hotspot’s rich dynamic code execution capabilities. Additionally, GraalVM internally uses OpenJDK’s class library and HotSpot to produce a native image.
Still, there’s the question: Why have native compilation at all if the other optimizations are so good? That’s the question we’ll look at more closely here.
Continue reading “Quarkus: Why compile to native?”
JDK Mission Control is now the newest member of the Red Hat Software Collections (RHSCL). JDK Mission Control is a powerful profiler for HotSpot Java virtual machines (JVMs) and has an advanced set of tools that enable efficient and detailed analysis of the extensive data collected by JDK Flight Recorder. The toolchain enables developers and administrators to collect and analyze data from Java applications running locally or deployed in production environments using OpenJDK 11.
In this article, I will go through a primary example of setting up JDK Mission Control. For Linux, JDK Mission Control is part of the RHSCL and, for Windows, it is available as part of the OpenJDK zip distribution on the Red Hat Customer Portal. For Linux, these instructions assume that Red Hat Build of OpenJDK 11 is already installed. I will show how to set up the system to install software from RHSCL, which provides the latest development technologies for Red Hat Enterprise Linux. Then, I will install the JDK Mission Control and run a simple sample application. The whole tutorial should take fewer than 10 minutes to complete.
Continue reading “Set up JDK Mission Control with Red Hat Build of OpenJDK”
A Java runtime environment should be able to run compiled source code, whereas a development kit, for example, OpenJDK, would include all the libraries/binaries to compile and run the source code. Essentially the latter is a superset of the runtime environment. More details on OpenJDK support and lifecycle can be found here.
Red Hat ships and supports container images with OpenJDK for both Java 8 and 11. More details are here. If you are using Red Hat Middleware, the s2i images shipped are also useful to deploy, for example, on Red Hat Openshift Container Platform.
Note that Red Hat only provides OpenJDK-based Java 8 and 11 images. With that said, there will certainly be situations where developers would like to create their own Java runtime images. For example, there could be reasons such as minimizing storage to run a runtime image. On the other hand, a lot of manual work around libraries such as Jolokio or Hawkular and even security parameters would need to be set up as well. If you’d prefer not to get into those details, I would recommend using the container images for OpenJDK shipped by Red Hat.
In this article we will:
This article was written for both OpenShift 3.11 and 4.0 beta. Let’s jump right into it.
Continue reading “Creating and deploying a Java 8 runtime container image”
