How to stop passing a specific flag to jlink? (--strip-native-commands specifically)

[thagikura]

How can I stop passing a specific flag to jlink (specifically avoid passing --strip-native-commands)

My app needs to bundle java executables because my app needs to launch another java process from my app.
So I want to bundle the java executables from jdk by not passing --strip-native-commands flag to jlink.

It looks like I'm able to add a flag to jlink by https://conveyor.hydraulic.dev/12.0/configs/jvm/#appjvmjlink-flags, but is it possible to stop passing a specific flag?

After the conveyor make app command and looking at the log file at ~/Library/Logs/Hydraulic/Conveyor/log.latest.txt, following options are passed.

   $ jlink '--strip-native-commands' '--no-man-pages' '--no-header-files' '--compress=1' '--add-modules' 'ALL-MODULE-PATH' '--limit-modules' 'jdk.crypto.ec,jdk.accessibility,java.base,     java.compiler,java.datatransfer,java.desktop,java.logging,java.management,java.naming,java.net.http,java.prefs,java.rmi,java.scripting,java.security.jgss,java.sql,java.xml,jdk.compiler,   jdk.httpserver,jdk.unsupported,jdk.compiler,jdk.unsupported,hydraulic.conveyor.launcher,dev.hydraulic.conveyor.control' '--ignore-signing-information' '--order-resources' '**/module-info. class,@classlist,/java.base/java/lang/**'

[mikehearn]

Unfortunately that's not possible in current versions of Conveyor, the list of base flags is hard coded.

What you could do is just change your main() method to forward to the right entry point based on flag or env var, optionally using a classloader if the sub-program conflicts with the classes of the main program.

[ennerf]

I have a similar use case where I need to launch various secondary apps from my main application (e.g. I need to decouple the GC of a real-time UI from an offline file viewer). I solved it by adding additional launchers to Conveyor and launching them with the process API:

extra executable:

app.jvm.cli.myOtherApp {
  main-class=some.other.App
  console = false;
}

Finding the directory of the executable:

    /**
     * @return path to directory with executables or empty if not inside conveyor
     */
    public static Optional<Path> getBinDirectory() {
        return Optional.ofNullable(System.getProperty("app.dir"))
                .map(Paths::get)
                .map(Path::toAbsolutePath)
                .map(p -> p.resolve(getRelativeBinPath()))
                .map(Path::normalize);
    }

    private static String getRelativeBinPath() {
        if (OS.isWindows()) {
            return "../bin/";
        } else if (OS.isMac()) {
            return "../MacOS/";
        } else if (OS.isUnix()) {
            return "../../bin/";
        } else {
            throw new UnsupportedOperationException("unknown OS: " + System.getProperty("os.name"));
        }
    }

That approach is also safer because users could use java.exe to launch arbitrary Java applications using the signatures of your company.

[thagikura]

Thanks both!

Although it's unfortunate that Conveyor doesn't support modifying the default flags passed to jlink, I'll see if @ennerf 's suggestion works with my use case.

My use case is to run a gradle process with JAVA_HOME set to the directory where java executable is located. Thus, it might be a different use case, though.

[mikehearn]

Bear in mind that Conveyor will attempt to shrink the bundled Java, and it also does various other things designed for desktop app distribution in the code signing context. It sounds like what you're after is really just downloading a full blown JDK and then be able to point Gradle at it.

[thagikura]

It sounds like what you're after is really just downloading a full blown JDK

Yes, that's true, but I believe it's a legit use case for apps like IDEs given that jlink has an option to toggle if the executables are included in the bundle (--strip-native-commands).

And the impact of the app size seems to be negligible. When I compared the sizes of the apps between with/without stripNativeCommands flag to jlink using Compose Multiplatform plugin, the app size looked like:

• with executables : 263.9MB
• without executables: 263.8MB

Also JFYI there is a similar feature request to Compose Multiplatform at https://youtrack.jetbrains.com/issue/CMP-3946 (the previous comparison was made by using the same workaround in the link)

[mikehearn]

The issue is the CMP plugin isn't optimizing download size :) Try a small simple app in Conveyor and you'll find it's much smaller than 263MB because it identifies which modules you're using and removes the rest. You can disable that, though.

[thagikura]

The experiment in my previous post was not a starter project created from scratch.
So the total size of 260MB wasn't surprising. The point was the addition of the amount of size (about +0.1MB) was relatively negligible compared to the entire app size, even if the app was created from scratch from Conveyor (when I tried to start a project from scratch, the total app size was about 50MB with Conveyor).

Anyway, since including java executables in the bundle is one of our core functionalities, unfortunately it seems I need to figure out other way of distributing our app although the other parts were working greatly.

Thanks for your support!

[mikehearn]

Sorry it can't do what you need! For the IDE use case, it may be better to separately download the JDK from your app, as that way users are not tied to whatever Java version you're using to build your own IDE and can upgrade faster than you do. IntelliJ does it this way for example.