Simplify Java launchers and standardize memory options across Java programs

[gouttegd]

Java programs bundled in the ODK come with their own launcher script (which we get directly from upstream).

In most cases these scripts are much more complicated than what is needed in the context in the ODK. They are intended to cope with many possible variations across operating systems, including for example the possibility that the script is called on a Windows machine within a Cygwin environment – something that can never remotely happen in the context of the ODK.

Within the ODK, where we know exactly (1) that we are running on a GNU/Linux machine (which may be virtual, but what do we care), (2) where the java executable is on that machine, (3) where the Jar archives are, and (4) where the launcher script is, a launching script does not need to be anything more complicated than

#!/bin/sh
exec java $ODK_JAVA_OPTIONS -cp /tools/mytool/{mylib1.jar,mylib2.jar,mylib3.jar} org.example.mytool.MainClass "$@"

for a Java program provided as a set of Jar archives, or

#!/bin/sh
exec java $ODK_JAVA_OPTIONS -jar /tools/mytool.jar "$@"

for a Java program provided as a single Jar archive with a self-declared entry point.

Another problem with the upstream launchers is that they all expect different environment variables to pass options to the Java virtual machine (ROBOT_JAVA_ARGS, OWLTOOLS_MEMORY, etc.).

We should get rid of all the upstream launchers and replace them with simple ODK-specific launchers that (1) do just what is needed in the context of the ODK and (2) expect $ODK_JAVA_OPTIONS to pass options to the JVM.

[gouttegd]

In the particular case of OWLTools’s ontology-release-runner tool, there is one more thing to simplify:

We currently download both owltools (the main OWLtools Jar archive, which is a self-executable Jar), and owltools-oort-all.jar (a Jar that declares owltools.ontologyrelease.OboOntologyReleaseRunner as the entry point, but that otherwise contains the same Java classes than the “main” OWLTools Jar archive).

We don’t need to have two different archives that differ just by their entry point. We can have just the main archive, with a launching script for the ontology-release-runner that ignores the self-declared entry point and explicitly invokes owltools.ontologyrelease.OboOntologyReleaseRunner:

#!/bin/sh
exec java $ODK_JAVA_OPTIONS -cp /tools/owltools owltools.ontologyrelease.OboOntologyReleaseRunner "$@"