nextflow installation script yields "Could not parse version" error, OpenJDK 11.0.14.1 from MacPorts

[ernstki]

Bug report

Hi everyone, hope you're well. I ran into a problem similar to what's described in #953 (for OpenJDK 10 in that case). As before, the nextflow installation script—or, I assume, some Java bit that's called from the installation script—yields the error

Could not parse version: 11.0.14.1 while processing attribute Min-Java-Version: 1.8.0 

in spite of my installed java meeting the requirements stated in the "Getting started" section of the Nextflow home page.

Expected behavior and actual behavior

Expected: nextflow installation script would work with an installed java, version 11.x, from MacPorts' openjdk11 package.

Actual: running the installation script yields an error about being unable to parse the (Java) version.

Steps to reproduce the problem

1. download nextflow script from the releases page
2. run the script with Bash

Program output

$ port echo installed | grep -iE '(java|jdk|jre)'
openjdk11                      @11.0.14.1_4+release+server

$ java -version
openjdk version "11.0.14.1" 2022-02-08
OpenJDK Runtime Environment (build 11.0.14.1+0)
OpenJDK 64-Bit Server VM (build 11.0.14.1+0, mixed mode)

$ bash nextflow
CAPSULE EXCEPTION: Could not parse version: 11.0.14.1 while processing attribute Min-Java-Version: 1.8.0 (for stack trace, run with -Dcapsule.log=verbose)
USAGE: java <options> -jar ../.nextflow/framework/22.10.3/nextflow-22.10.3-one.jar
⋮

Environment

• Nextflow version: n/a (using latest release script from 22.10.3
• Java version: 11.0.14.1
• Operating system: macOS 10.15.7 (Catalina)
• Bash version: GNU bash, Version 5.1.12(1)-release (x86_64-apple-darwin19.6.0)

Additional context

Running bash nextflow -Dcapsule.log=verbose does not yield any more useful information, as far as I can tell, but I will include its output if you deem it necessary.

Initially, I had a problem with the installation script due to an old JAVA_HOME defined in my login scripts, pointing to a JRE that was no longer available (1.8.something). I quickly resolved this, though, started a fresh shell, and did an rm -rf ~/.nextflow to be sure that no evidence remained of previous attempts. I currently do not have any JAVA_HOME defined in my shell environment, verified with echo $JAVA_HOME.

Oddly, I was unable to reproduce this in a CentOS 7 Docker container having java-11-openjdk-11.0.17.0.8-2.el7_9.x86_64 installed from the official repositories. (It was necessary to install which in the container in order for the nextflow script to work properly, which is perhaps a separate bug report.)

Thanks for taking a look.

[manulera]

Same problem here.

[manulera]

My settings in MacOS:

java version "18.0.1.1" 2022-04-22
Java(TM) SE Runtime Environment (build 18.0.1.1+2-6)
Java HotSpot(TM) 64-Bit Server VM (build 18.0.1.1+2-6, mixed mode, sharing)

[manulera]

I found a solution in #2856. Setting the variable JAVA_HOME in the bash profile did it for me. Here the instructions for different MacOS versions:

https://mkyong.com/java/how-to-set-java_home-environment-variable-on-mac-os-x/#java-home-and-macos-11-big-sur

@ernstki I guess it's too late, but if you try this and it works for you, feel free to close the issue.

[mhebrard]

Same problem on my macOS today when trying to update nextflow

> java -version
openjdk version "18.0.2.1" 2022-08-18
OpenJDK Runtime Environment Homebrew (build 18.0.2.1+0)
OpenJDK 64-Bit Server VM Homebrew (build 18.0.2.1+0, mixed mode, sharing)

> sudo nextflow self-update   
CAPSULE EXCEPTION: Could not parse version: 18.0.2.1 while processing attribute Min-Java-Version: 1.8.0 (for stack trace, run with -Dcapsule.log=verbose)
USAGE: java <options> -jar ../../../../../.nextflow/framework/23.04.2/nextflow-23.04.2-one.jar

From what I gather it is a known issue whis all the version of java that return more that 3 sections ( i.e. "1.2.3.*" )
Work around is install a version of java that luckily retrun only 3 sections...
It would be nice thought to get Nextflow dev team to extend java version format handling to be robust of "more that 3 sections"

Best

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ernstki]

@mhebrard I'll try to have a look when I have access to my Mac again. Patching a regular expression somewhere to check for (\d+)(\.\d+)+ instead of (\d+)\.(\d+)\.(\d+) is probably within my abilities, even though I'm not a "Java programmer."

[pditommaso]

Solved via #2951

[ernstki]

Thanks for your efforts, @pditommaso!

[pditommaso]

@ernstki you are welcome!