What's the alternative of a Java 10 secondary launcher on Mac OSX?

Question

I'm using Maven to build a JavaFx project on Windows and Mac. I'm using Maven-ant-plugin to build my package and my build.xml contains several fx:secondaryLauncher blocks.Secondary launchers enable you to create additional executables inside your app directory that will launch classes other than your main class.

Here is a sample from the official documentation:

<fx:info title="Test Suite"/>

<fx:secondaryLauncher
    mainClass="samples.TestSuite"
    name="Suite Applications"/>
    shortcut="true"/>

<fx:secondaryLauncher name="Editor">
    <fx:bundleArgument arg="icon" value="../resources/editor.ico"/>
</fx:secondaryLauncher>

<fx:secondaryLauncher name="Spreadsheet">
    <fx:bundleArgument arg="icon" value="../resources/spreadsheet.ico"/>
</fx:secondaryLauncher>

When I switched from Java 8 to Java 10 - the package that maven creates via the maven-ant-plugin stopped creating the secondary launchers on Mac OSX. The fx:secondaryLauncher blocks seem to be ignored by the packager.

The Windows package DOES contain the secondary launchers and after researching a bit I found out that since Java 9 was released - "Multiple entry points are supported only for Windows and Linux applications" (full documentation here : https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG1000 ).

Does anyone have an idea about a good alternative to secondary launchers ? I would prefer to minimize the differences between Windows and Mac OSX build process (although it might not be able to this time ;-) ) Thanks!

Answer 1

After researching several possible solutions it looks like the following solution is the best one :

1. specify a "strip-native-commands" attribute with the value "false" in the fx:runtime block of hte fx:deploy xml block. this means that your application package will include the main java executables in your self-contained inatallation package.
2. Instead of invoking the secondary launcher executables which no longer exist - activate the classes that the executables invoked directly (eg running java -cp .

this has several benefits :

1. Minimal changes to the code/pom/build.xml .
2. No dependency on a user-installed JRE because you use the JRE installed as part of your application installation.