With the recent release of Red Hat Enterprise Linux 8.2, we also added the first Red Hat build of OpenJDK Universal Base Images. These General Availability (GA) images for OpenJDK 8 and OpenJDK 11 set a new baseline for anyone who wants to develop Java applications that run inside containers in a secure, stable, and tested manner.
In this article, we introduce the new OpenJDK Universal Base Images and explain their benefits for Java developers. Before we do that, let’s quickly review what we know about UBIs in general.
About Universal Base Images
Red Hat Universal Base Images (UBIs) are:
OCI-compliant container base operating system images with complementary runtime languages and packages that are freely redistributable. Like previous base images, they are built from portions of Red Hat Enterprise Linux (RHEL). UBI images can be obtained from the Red Hat container catalog and be built and deployed anywhere.
In other words, UBIs help application developers reach the secure, stable, and portable world of containers. These images are accessible using well-known tools like Podman/Buildah and Docker. Red Hat Universal Base Images also allow users to build and distribute their own applications on top of enterprise-quality bits that are supportable on Red Hat OpenShift and Red Hat Enterprise Linux.
Continue reading “Introducing the Red Hat build of the OpenJDK Universal Base Images—now in Red Hat Enterprise Linux 8.2”
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”
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”
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”