Launcher fails with Java 10 or later

[ODiogoSilva]

Bug report

Installing nextflow via conda on a fresh environment will install nextflow 18.10.1 and openjdk 10.0.2. However, executing nextflow with these versions yields the following:

$ nextflow -version 
CAPSULE EXCEPTION: Could not parse version line: openjdk version "10.0.2" 2018-07-17 (for stack trace, run with -Dcapsule.log=verbose)
USAGE: java <options> -jar ../miniconda3/envs/myenv/share/nextflow/framework/18.10.1/nextflow-18.10.1-one.jar

Actions:
  capsule.version - Prints the capsule and application versions.
  capsule.modes - Prints all available capsule modes.
  capsule.jvms - Prints a list of all JVM installations found.
  capsule.help - Prints this help message.
  capsule.tree - Prints the capsule's dependency tree.
  capsule.resolve - Downloads all un-cached dependencies.

Options:
  capsule.mode=<value> - Picks the capsule mode to run.
  capsule.reset - Resets the capsule cache before launching. The capsule to be re-extracted (if applicable), and other possibly cached files will be recreated.
  capsule.log=<value> (default: quiet) - Picks a log level. Must be one of none, quiet, verbose, or debug.
  capsule.java.home=<value> - Sets the location of the Java home (JVM installation directory) to use; If 'current' forces the use of the JVM that launched the capsule.
  capsule.java.cmd=<value> - Sets the path to the Java executable to use.
  capsule.jvm.args=<value> - Sets additional JVM arguments to use when running the application.
  capsule.local=<value> - Sets the path of the local Maven repository to use.
Unable to initialize nextflow environment

Is nextflow supposed to support java 10?

Environment

• Nextflow version: 18.10.1
• Java version: openjdk 10.0.2
• Operating system: archlinux

Additional context

(Add any other context about the problem here)

[jenzopr]

Confirmed. An easy solution would be to pin openjdk to <10 in bioconda.

[pditommaso]

That's weird we have integration tests for JDK 8 up to 11. What's the version string returned by your JDK?

$ java --version

[jenzopr]

For us, it returns

openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment Zulu10.3+5 (build 10.0.2+13)
OpenJDK 64-Bit Server VM Zulu10.3+5 (build 10.0.2+13, mixed mode)

Best,
Jens

[pditommaso]

This is mine

java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+46)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)

and

java version "11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)

Apparently the Zulu distribution deviate from OpenJdk adding the minor version in that string causing this problem.

[jenzopr]

IMHO, it would definitely add to nextflows popularity if java versions delivered by large and state of the art software management tools (e.g. conda, in this case java comes from the conda-forge channel) would be seamlessly supported by nextflow. I guess there are numerous parsers for version numbers available in groovy (e.g. org.codehaus.groovy.grails.plugins.VersionComparator)?

[pditommaso]

The problem is not NF but Capsule package manager that seems to not recognise the version.

[pditommaso]

The Java spec for version number just for ref.

[pditommaso]

Actually this code.

[jenzopr]

Sorry, my bad about blaming nf then 😉
Is it worthwhile to file an issue upstream then? Unfortunately, I'm not fluent in groovy, so I can't contribute a minimal example..

[jenzopr]

I checked the regex pattern, it recognizes also minor versions..?

[pditommaso]

I've isolate the code

import java.io.IOException;
import java.util.Scanner;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

/**
 * @author Paolo Di Tommaso <paolo.ditommaso@gmail.com>
 */
public class Ver {

    public static void main(String... args) throws IOException {
        getActualJavaVersion();
    }

    private static final Pattern PAT_JAVA_VERSION_LINE = Pattern.compile(".*?\"(.+?)\"");

    private static void getActualJavaVersion() throws IOException  {
        System.out.println("Version property: " + System.getProperty("java.version"));
                
        Process process = new ProcessBuilder("java", "-version").redirectErrorStream(true).start();
        Scanner s = new Scanner(process.getInputStream()).useDelimiter("\n");
        String versionLine = s.hasNext() ? s.next() : "";
        System.out.println("Version string: " + versionLine);

        final Matcher m = PAT_JAVA_VERSION_LINE.matcher(versionLine);
        if (!m.matches()) {
            System.err.println("** Could not parse version line: " + versionLine);
        }
        else {
            final String version = m.group(1);
            System.out.println("Version detected: " + version);
        }
    }
}

It works for Java 8 and 9 and fails with 10 .. not sure to understand how test can pass on travis ? 😕

If you want to try it, save the above snippet, then use javac Ver.java && java -cp . Ver.

[jenzopr]

Thanks a lot! I can look into it and eventually propose a fix upstream.

[pditommaso]

Ok, looking better at this the regex .*?\"(.+?)\" fails because it assumes there's nothing else after the number, instead since java 10, it prints the build date java version "10" 2018-03-20.

However this does not explain why tests with OpenJDK are fine. I think this happens because before checking java -version, Capsule tries to infer the version number from the installation path:

https://github.com/puniverse/capsule/blob/master/capsule/src/main/java/Capsule.java#L4165-L4170

and

https://github.com/puniverse/capsule/blob/master/capsule/src/main/java/Capsule.java#L4189-L4216

I guess Azul is not recognised by the latter. Could you please check how is the installation path of your Azul JVM ?

[pditommaso]

Ahah, it looks conda mess up the Java install path, therefore it tries to use the java -version string, causing that issue.

$ which java
/Users/pditommaso/miniconda2/envs/nf-test/bin/java