graalvm

In this blog post, I show you how to build stackoverflow-cli - a command-line application that allows you to search Stack Overflow questions directly from the terminal window. I use Java 11+, Micronaut, Picocli, and GraalVM’s native-image.

GR8Conf EU 2019 starts precisely in 13 days (on May 27th). Each year Copenhagen becomes a heart of Groovy vibrant community for 3 days. The conference offers both talks and workshops, focused on Groovy related topics such as upcoming Groovy 3 release, building DSLs, using Micronaut in the cloud-native environment, or testing applications with Spock and Geb, to name a few. And that’s not even a quarter of great stuff you can expect from it. This year you can also attend one of my three talks I’m going to deliver.

In this short blog post, I would like to show you how to set a heap size of the application executed from the native image generated with GraalVM. We will also take a quick look at the effects caused the maximum heap size change.

I love SDKMAN!. It made using multiple different Java distributions in a single operating system much more comfortable. You can install Java across different versions (from 6 to 13.EA) and different vendors (OpenJDK, Oracle, Zulu, Corretto or GraalVM CE to name a few). Switching between those versions is as simple as executing a single sdk use java {version} command and you are ready to use whatever Java you want. However, not all Java versions are available by default, but luckily, SDKMAN! has a simple solution to this problem.

The journey inside the exciting world of GraalVM continues. Today I would like to share with you results of running Ratpack on GraalVM experiment. You are going to learn how to build a native binary of a simple "Hello, World!" Ratpack application. In the end we are going to run some benchmarks to see if running GraalVM executable produces better results than running JAR on a regular Oracle JDK.

We have learned how to create GraalVM native image from standalone Groovy script in the previous blog post. Today we continue the experiments, and this time we are going to create a Docker image to see what are the benefits and drawbacks of this solution.

The Apache Groovy programming language has extraordinary scripting capabilities. When you combine it with the Grape dependency management system, it turns out that the sky is the limit. In one of the previous blog posts, I explained how you can start compiling Groovy code to the native binary files, using GraalVM’s native-image compiler. This time I tried to do the same with the Groovy script that uses Grape to provide an external library to the classpath. I thought it won’t be possible, but luckily - I was wrong.

GraalVM became one of the most popular topics in the JVM ecosystem. It promises the highest possible speed of running JVM-based programs (when compiled to native images), hand in hand with the smaller memory footprint. It sounds interesting enough to give it a try. And today we are going to play around a little bit with running simple Groovy program after compiling to a standalone native image.