OpenJDK

Debugging GraalVM-native images using gdb

Debugging GraalVM-native images using gdb

andrewdinn
By Andrew Dinn

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”

Share
The road to Quarkus GA: Completing the first supported Kubernetes-native Java stack

The road to Quarkus GA: Completing the first supported Kubernetes-native Java stack

nmcl2001
By Mark Little

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”

Share
Ramp up on Quarkus: A Kubernetes-native Java framework

Ramp up on Quarkus: A Kubernetes-native Java framework

sahsingh
By Saharsh Singh

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

Share
Quarkus: Why compile to native?

Quarkus: Why compile to native?

nmcl2001
By Mark Little

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?”

Share
Set up JDK Mission Control with Red Hat Build of OpenJDK

Set up JDK Mission Control with Red Hat Build of OpenJDK

sshaaf
By Syed M Shaaf

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”

Share
Creating and deploying a Java 8 runtime container image

Creating and deploying a Java 8 runtime container image

sshaaf
By Syed M Shaaf

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:

  • Build an image with Docker as well as Buildah.
  • We will run that image with Docker as well as Podman on localhost.
  • We will push our image to Quay.
  • Finally, we will run our app by importing a stream into OpenShift.

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”

Share
Using Red Hat Application Migration Toolkit to see the impact of migrating to OpenJDK

Using Red Hat Application Migration Toolkit to see the impact of migrating to OpenJDK

sshaaf
By Syed M Shaaf

Migrating from one software solution to another is a reality that all good software developers need to plan for. Having a plan helps to drive innovation at a continuous pace, whether you are developing software for in-house use or you are acquiring software from a vendor. In either case, never anticipating or planning for migration endangers the entire innovation value proposition. And in today’s ever-changing world of software, everyone who wants to benefit from the success of the cloud has to ensure that cloud innovation is continuous. Therefore, maintaining a stack that is changing along with technological advancements is a necessity.

In this article, we will take a look at the impact of moving to OpenJDK and the results will aid in drawing further conclusions and in planning. It’s quite common to be using a proprietary version of JDK, and this article addresses how to use Red Hat Application Migration Toolkit to analyze your codebase to understand the impact of migrating to OpenJDK.

Continue reading “Using Red Hat Application Migration Toolkit to see the impact of migrating to OpenJDK”

Share
Migrating from Oracle JDK to OpenJDK on Red Hat Enterprise Linux: What you need to know

Migrating from Oracle JDK to OpenJDK on Red Hat Enterprise Linux: What you need to know

lufimtse
By Leo Ufimtsev

Oracle has announced that the Oracle JDK 8 builds released after Jan 2019 cease to be free for commercial use. GPL + Classpath Exception licensed (free for any use, subject to that license) are current made available by Oracle through http://jdk.java.net/11/. (See also Oracle’s blog entry & licensing).
An alternative is to use OpenJDK and effort is underway to make them fully interchangeable. A number of companies who are currently using Oracle JDK in production are making the decision to switch to OpenJDK or have already done so.

Andrew Haley (Red Hat’s Java Platform Lead Engineer) recently wrote a great article on the direction of OpenJDK.

In this article, I’ll discuss: the technical and support implications of the migration, what developers and operations teams need to know, and solutions to potential challenges.

I’ll go over the Red Hat support model and technical details of how to install, update, and run different OpenJDK versions on Red Hat Enterprise Linux (RHEL) 6 and 7 systems. I’ll also discuss the operations of Java applications (such as Red Hat JBoss Enterprise Application Platform (JBoss EAP) and other servers) on top of OpenJDK.

While this article is about OpenJDK on RHEL, I should also point out that OpenJDK for Windows can also be downloaded from developers.redhat.com. This lets you use the same JDK for Linux and Windows.

Continue reading “Migrating from Oracle JDK to OpenJDK on Red Hat Enterprise Linux: What you need to know”

Share
The future of Java and OpenJDK updates without Oracle support

The future of Java and OpenJDK updates without Oracle support

aphredhat
By Andrew Haley

Oracle recently announced that it would no longer supply free (as in beer) binary downloads for JDK releases after a six-month period, and neither would Oracle engineers write patches for OpenJDK bugs after that period. This has caused a great deal of concern among some Java users.

From my point of view, this is little more than business as usual. Several years ago, the OpenJDK 6 updates (jdk6u) project was relinquished by Oracle and I assumed leadership, and then the same happened with OpenJDK 7. Subsequently, Andrew Brygin of Azul took over the leadership of OpenJDK 6. The OpenJDK Vulnerability Group, with members from many organizations, collaborates on critical security issues. With the help of the wider OpenJDK community and my team at Red Hat, we have continued to provide updates for critical bugs and security vulnerabilities at regular intervals. I can see no reason why this process should not work in the same way for OpenJDK 8 and the next long-term support release, OpenJDK 11.

Continue reading “The future of Java and OpenJDK updates without Oracle support”

Share