Community

5 Red Hat Summit sessions developers won’t want to miss

5 Red Hat Summit sessions developers won’t want to miss

Oh sure, like countless thousands of others you’re planning on attending Red Hat Summit in Boston this year. But you’re a little anxious that you might miss the best sessions at the show. In no particular order, here are five sessions (actually five sessions and a workshop) that will enrich your life, expand your horizons, and give you the knowledge you need to lead your team forward. Be sure to check them out.

Continue reading “5 Red Hat Summit sessions developers won’t want to miss”

Share
Migrating Java applications to Quarkus: Lessons learned

Migrating Java applications to Quarkus: Lessons learned

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”

Share
Report from the February 2019 ISO C++ meeting (Core Language working group)

Report from the February 2019 ISO C++ meeting (Core Language working group)

The February 2019 ISO C++ meeting was held in Kailua-Kona, Hawaii. As usual, Red Hat sent three developers to the meeting: I attended in the Core Language working group, Jonathan Wakely in Library, and Thomas Rodgers in SG1 (parallelism and concurrency). The meeting went smoothly, although there was significant uncertainty at the beginning where we would end up. In the end, Modules and Coroutines were accepted into the C++20 draft, so now we have our work cut out for us nailing down the remaining loose corners. Here ar highlights from the meeting.

Continue reading “Report from the February 2019 ISO C++ meeting (Core Language working group)”

Share
From zero to Quarkus and Knative: The easy way

From zero to Quarkus and Knative: The easy way

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”

Share
Quarkus: Why compile to native?

Quarkus: Why compile to native?

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
A platform interface for the GNU C Library

A platform interface for the GNU C Library

Application developers continue to need newer versions of libraries, including core runtimes like GNU C Library (glibc), for their applications. In this article, I’ll look at some issues related to upgrading glibc in an operating system (OS) distribution, and I also encourage you to read Florian Weimer’s excellent blog post on the topic.

The problem

Deciding between a library rebase or continued backporting of commits involves a complex set of risks and rewards. For some customers and users, it is important not to rebase the library (ensuring the lowest risk of impact by change); but for others, the rebase brings valuable bug fixes (lowest risk of impact from known issues). In other cases, the newer library may perform better, even if the interfaces haven’t changed, because it can take advantage of newer hardware or a newer Linux kernel (performance advantage to first mover).

There is no way to simultaneously satisfy all the requirements of slow-moving versus fast-moving development. The recent work in Fedora Modularity is aimed at solving the root of this problem, but there is a limit to this work. The further down the stack you go, the harder the problem becomes. The potential for breakage further up the stack increases. You can’t always arbitrarily change a component’s installed version without consequences, either at build time or at runtime.

Continue reading “A platform interface for the GNU C Library”

Share
An introduction to Linux virtual interfaces: Tunnels

An introduction to Linux virtual interfaces: Tunnels

Linux has supported many kinds of tunnels, but new users may be confused by their differences and unsure which one is best suited for a given use case. In this article, I will give a brief introduction for commonly used tunnel interfaces in the Linux kernel. There is no code analysis, only a brief introduction to the interfaces and their usage on Linux. Anyone with a network background might be interested in this information. A list of tunnel interfaces, as well as help on specific tunnel configuration, can be obtained by issuing the iproute2 command ip link help.

Continue reading “An introduction to Linux virtual interfaces: Tunnels”

Share
Rust All Hands 2019: Array iterators, Rayon, and more

Rust All Hands 2019: Array iterators, Rayon, and more

A few weeks ago, I had the pleasure of attending the second annual Rust All Hands meeting, hosted by Mozilla at their Berlin office. The attendees were a mix of volunteers and corporate employees covering the full range of Rust development, including the compiler, language, libraries, docs, tools, operations, and community. Although I’m sure there will be an official summary of the meeting (like last year’s), in this article, I’ll cover a few things I was directly involved in. First, I’ll look at a feature many developers have wanted for a long time…

Continue reading “Rust All Hands 2019: Array iterators, Rayon, and more”

Share
Getting started with the updated VS Code Yeoman extension for Camel projects

Getting started with the updated VS Code Yeoman extension for Camel projects

The Visual Studio (VS) Code IDE is one of the most-used platforms for JavaScript, C#, and Python developers and is quickly becoming one of the top three tooling environments at Red Hat. VS Code is highly customizable and offers a healthy and growing marketplace for extensions of all types and technologies, including an extension for Yeoman. In this article, I’ll explain how to get started using the updated extension that works with latest versions of VS Code.

Continue reading “Getting started with the updated VS Code Yeoman extension for Camel projects”

Share
Quarkus 0.12.0 released

Quarkus 0.12.0 released

Quarkus, a next-generation Kubernetes native Java framework, was announced in early March, and now Quarkus 0.12.0 has been released and is available from the Maven repository. The quickstarts, guides, and website also have been updated, and 213 issues and PRs are included in this release. That’s quite a few updates, but in particular check out the new metrics, health check, and Kafka guides. Also, this release requires GraalVM 1.0.0-RC13 for Building a Native Executable.

Continue reading “Quarkus 0.12.0 released”

Share