OpenJDK

Installing Red Hat’s migration toolkit for applications on your laptop

Installing Red Hat’s migration toolkit for applications on your laptop

miguel
By Miguel Pérez Colino

If you are a developer considering modernizing your Java applications by containerizing or migrating them to a more modern application server, then you are likely aware of Red Hat’s migration toolkit for applications. This article helps you get started with migration toolkit for applications by installing it directly on your laptop. For more about the toolkit, see:

Note: Red Hat’s migration toolkit for applications (formerly Red Hat Application Migration Toolkit) is based on the upstream, open source Windup project. Check out the code and see how it works!

Continue reading “Installing Red Hat’s migration toolkit for applications on your laptop”

Share
Checkpointing Java from outside of Java

Checkpointing Java from outside of Java

chfredhat-com
By Christine Flood

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

Share
Migrate your Java apps to containers with Migration Toolkit for Applications 5.0

Migrate your Java apps to containers with Migration Toolkit for Applications 5.0

miguel
By Miguel Pérez Colino

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”

Share
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