Friends of OpenJDK Today

This is a followup on Part 1 of the blog post series we started earlier this month, analyzing the performance of modern JVMs on workloads that are relevant to the use case of real-time stream processing.

As a quick recap, in Part 1 we tested the basic functionality of Hazelcast Jet (sliding window aggregation) on two types of workload: lightweight with a focus on low latency, and heavyweight with a focus on the data pipeline keeping up with high throughput and large aggregation state. For the low latency benchmarks we chose the JDK 14 as the most recent stable version and three of its garbage collectors: Shenandoah, ZGC, and G1 GC.

Unless you are creating all your images, by drawing then inside the code with the Graphics2D commands, you will need an image library to load images as BufferedImages. You will also need an Image library if you wish to save the results.

ImageIO is part of Java, it is free and it supports a range of Image formats including GIF, JPEG, PNG, and TIF. Because it is expandable, there are additional libraries to extend it.

BufferedImage is one of the most useful Java abstractions. It hides all the complexity of different types of images whilst allowing access to the underlying data. Under the hood, a BufferedImage can be many types of image.

Java includes support to load and save images in various formats using ImageIO, and other libraries such as Apache Imaging and our JDeli library also offer this feature.

Next time we will talk more about ImageIO and other Image libraries.

There are lots of different ways of describing Color. As developers, we are most familiar with the RGB model, where every color is defined by mixing Red, Green and Blue together. In the print world, CMYK is very common, where colors or printed by literally mixing different amounts of Cyan, Magenta, Yellow and Key (black). You may also come across other ways of describing color such as DeviceN. There are also lots of different versions of RGB.

Next time we will talk more about BufferedImages.

Java makes images simple to use. You can work with a BufferedImage and just load or save this to any supported image file format. A BufferedImage includes lots of functionality which allows you to render and process the image, with all the complexity and implementation hidden by Java. A BufferedImage can even be used as a Graphics2D canvas which can be drawn on. Here is some example code.

While Java removes a lot of Image complexity, it is worth understanding in more detail how images work. In this series of articles, we will be diving deep into how BufferedImage provides this abstraction, how different types of images work and how you can access the low-level Image data.

A batch pipeline processes a finite amount of stored data. There are no running results, we need the output of the aggregate function applied to the entire dataset. This changes our performance requirements: the key factor in streaming, latency, doesn’t exist here since we are not processing data in real time. The only metric that matters is the total run time of the pipeline.

For this reason, we considered the Parallel GC as a relevant candidate. In the first testing round, on a single node, it actually delivered the best throughput (but only after GC tuning). However, it achieves that throughput at the expense of GC pause duration. In a cluster, whenever any node enters a GC pause, it stalls the whole data pipeline. Since individual nodes enter GC pauses at different times, the amount of time spent in GC goes up with every node you add to the cluster. We explored this effect by comparing single-node tests with tests in a three-node cluster.

The Java runtime has been evolving more rapidly in recent years and, after 15 years, we finally got a new default garbage collector: the G1. Two more GCs are on their way to production and are available as experimental features: Oracle’s ZGC and OpenJDK’s Shenandoah.

We at Hazelcast thought it was time to put all these new options to the test and find which choices work well with workloads typical for our distributed stream processing engine, Hazelcast Jet.

When I first started programming in Java and configuring my local environment, I came across mentions of JVM flags. I wanted to find out more about what options are available, what they do, and how to make use of them.

Since resources on this topic are scattered and hard to find, I put together this consolidated list of places where JVM command line arguments are described in the hopes that others don’t have to scour the internet as I did to find these useful morsels.

Well, another six months have passed, and we have another release of Java, this one pretty packed with exciting new features. It is, therefore, time for another blog post trying to list everything new in JDK 14.

In total, there are a very impressive 16 JDK Enhancement Proposals (JEPs) and 69 new API elements.

Let’s start with the more significant items that introduce changes to the Java language syntax.

The user’s perspective matters. There is a material difference between the importance and impact on Java deployments and the notion of what “priority” is for issues in the Java Bug System.

The issue notes and material circulated on OpenJDK lists tend to center, for good reason, on the needs and concerns of developers who build and maintain OpenJDK. In fact, an inverse relationship often exists. Some of the most important and impactful items in OpenJDK updates in recent years were categorized as lower priority in the Java bug system.

It’s exciting to have foojay as a place to provide information to everyday Java developers and to work collaboratively on evolving foojay content to provide commentaries on the latest Java developments.

We’re actively looking for highly skilled and knowledgeable Java developers to join us (we are even hiring for that purpose) and our aim is for foojay to increasingly become a place of sharing reference materials and discussion throughout the Java industry.