Topic navigation

Blog Articles

Products

Find out how to configure the CodeReady workspace for debugging, set up breakpoints, and debug the application using the integrated browser-based IDE in the workspace. The steps explained in this video are also available in the tutorial here.

Although containers and Kubernetes and microservices seem to come up in every conversation, there’s a big chasm between talking about, demonstrating, and actually using a technology in production. Anyone can discuss containers, many people can demo them, but far fewer are successfully using containers and Kubernetes in a microservices architecture.

Why? There are likely many reasons, but a simple one may be that developers don’t know where to start.

Consider this series of articles your starting point. Relax, read on, and get ready to enter the exciting world of containers, Kubernetes, and microservices.

In this CodeReady Workspaces video, learn how to create a new workspace using the code generated from the launcher, and how to make the application run locally. Also find out how to build and deploy an application locally within the workspace, how to edit and test the code, and how to commit code changes to a remote git repository. The steps described in this video are also available in the tutorial on GitHub.

The concept of RPM packaging can be overwhelming for first-timers because of the impression a steep learning curve is involved. In this article, I will demonstrate that building an RPM with minimal knowledge and experience is possible. Note that this article is meant as a starting point, not a complete guide to RPM packaging.

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”

Have you tried the Red Hat Enterprise Linux 8 (RHEL8) Beta yet? Read on to learn how to stand up a LAMP stack on top of RHEL8 Beta quickly, and play around with new features built into the operating system.

A LAMP stack is made up out of four main components, and some glue. The first main component in a LAMP stack is Linux. In my example, I’m using Red Hat Enterprise Linux 8 Beta for that, which gives me a secure operating system, a modern programming environment, and user-friendly set of tools to control it.

In part 1, I shed light on trade-offs involved in the GCC implementation choices for various types of front-end warnings, such as preprocessor warnings, lexical warnings, type-safety warnings, and other warnings.

As useful as front-end warnings are, those based on the flow of control or data through the program have rather inconvenient limitations. To overcome them, flow-based warnings have increasingly been implemented in what GCC calls the “middle end.” Middle-end warnings are the focus of this article.

Most of us appreciate when our compiler lets us know we made a mistake. Finding coding errors early lets us correct them before they embarrass us in a code review or, worse, turn into bugs that impact our customers. Besides the compulsory errors, many projects enable additional diagnostics by using the -Wall and -Wextra command-line options. For this reason, some projects even turn them into errors via -Werror as their first line of defense. But not every instance of a warning necessarily means the code is buggy. Conversely, the absence of warnings for a piece of code is no guarantee that there are no bugs lurking in it.

In this article, I would like to shed more light on trade-offs involved in the GCC implementation choices. Besides illuminating underlying issues for GCC contributors interested in implementing new warnings or improving existing ones, I hope it will help calibrate expectations for GCC users about what kinds of problems can be expected to be detected and with what efficacy. Having a better understanding of the challenges should also reduce the frustration the limitations of the available solutions can sometimes cause. (See part 2 to learn more about middle-end warnings.)

The article isn’t specific to any GCC version, but some command-line options it refers to are more recent than others. Most are in GCC 4 that ships with Red Hat Enterprise Linux (RHEL), but some are as recent as GCC 7. The output of the compiler shown in the examples may vary between GCC versions. See How to install GCC 8 on RHEL if you’d like to use the latest GCC.