Summary

In #724, we replaced profiler.sh script with a binary launcher asprof.
Now we take a step further and replace converter.jar with a binary executable jfrconv.

Motivation

1. Simpler command

A command to run converter currently looks as follows:

java -cp /path/to/converter.jar jfr2flame [options] input.jfr output.html

It's too long to type and easy to make a mistake (-cp or -jar? where to put options?)

Proposed command is much shorter:

jfrconv [options] input.jfr output.html

2. Standard deployment

There is no standard location for .jar files.
Binary executable can be put in /usr/bin and run like other utilities.

3. Packaging

It will be easier to prepare packages in deb and rpm formats for commonly used OS distributions.
Contents will be organized as follows:

bin/
    asprof
    jfrconv
lib/
    libasyncProfiler.so

Non-goals

There is no intention to rewrite converter in other languages or make it run without a JVM.
JAR files (including profiler API) will not be bundled in OS-specific packages. They will be available for download from GitHub and Maven Central.

How it will work

The converter code with required resources will be built into a .jar file which will be then embedded in a binary launcher.
The launcher will automatically search for a suitable JRE in the following locations:

• JAVA_HOME environment variable;
• PATH;
• /etc/alternatives/java;
• commonly used directory: /usr/lib/jvm on Linux or /Library/Java/JavaVirtualMachines on macOS.

Converter classes will be loaded directly from the binary; no unpacking to a temporary folder will happen.

Users will not have to specify the convert class such as jfr2flame, jfr2pproto, etc.
The input format will be detected automatically, and the output format will be chosen by the file extension.

jfrconv will optionally accept JVM arguments starting with -X, -XX, -D. Other JVM arguments can be passed with -J prepended. Example: jfrconv -Xmx4g -Xlog:gc input.jfr output.html