A couple of years ago, I developed a small Kotlin GUI to help me rename my files in batch. I actually created it with different JVM frameworks to compare their relative merits. In any case, I didn’t use it up until last week. And then, I was surprised to see that it didn’t work to rename a network volume, although it had in the past. In this brief post, I aim to describe the issue and its solution. The problem When launching the UberJAR, I couldn’t see the network volumes.

When your application goes beyond a dozen of lines of code, you should probably split the code into multiple classes. At this point, the question is how to distribute them. In Java, the classical format is the Java ARchive, better known as the JAR. But real-world applications probably depend on other JARs. This post aims to describe ways to create self-contained executable JARs, also known as uber-JARs or fat JARs. What is an executable JAR? A JAR is just a collection of class files.

Some time ago, RAM and disk space were scarce resources. At that time, the widespread strategy was to host different applications onto the same platform. That was the golden age of the application server. I wrote in an earlier post that the current tendency toward cheaper resources will make it obsolete, in the short or long term. However, a technology trend might bring it back in favor.

This is the 3rd post in the JVM Security focus series. Last week, I wrote about the JVM policy file that explicitly lists allowed sensitive API calls when running the JVM in sandboxed mode. This week, I’d like to improve the security by signing the JAR.