Launch script fails on macOS

[tmmvn]

On macOS 12.4, the default Python version is 3.8, but the launch script uses a feature (argparse.BooleanOptionalAction) available only from Python 3.9 upwards. This means that to be able to utilize the language server for coding with Java on a Mac, you need to jump through hoops to upgrade Python (especially true if you don't actually work with Python).

However, the launch script could be modified to pre 3.9 syntax. So around line 68 the script could go something like:

parser.add_argument('--validate-java-version', action='store_true')
parser.add_argument('--no-validate-java-version', dest='validate-java-version', action='store_false')
parser.set_defaults(feature=True)

Since this would require the inverse flag, something like a custom method that parses the arg value to true or false might be a better alternative.

[rgrunber]

@schrieveslaach , seem reasonable ? I'd be happy to merge a PR if it preserves the same behaviour and makes support a bit easier on macOS.

[schrieveslaach]

@codemeddler, are you aware of the homebrew formula jdtls? This ensures that the correct Python version will be used.

Other than that it would be fine for me to change the script if it provides the same behavior as before.

[tmmvn]

@schrieveslaach I prefer macports over homebrew, but whatever way you install the additional dependency is beyond the point.

However, the new Ventura update ships with Python 3.9 by default, so I am okay with closing this ticket. The issue doesn't seem to be a common complaint and it is no longer relevant with the latest macOS defaults.

[kqvanity]

@tmmvn Can you open a pull request with that suggested fix. I'm having the same issue with python 3.8.

[tmmvn]

@tmmvn Can you open a pull request with that suggested fix. I'm having the same issue with python 3.8.

@z0xyz Not any time soon. It requires a decent amount of bureaucracy in the form of the Eclipse Foundation contribution agreement signings and whatnots, which I'm currently not interested in going through.

I made a local fork and added a fix there. Feel free to do the same, or if you already have signed the agreement, feel free to PR the fix.

So, inside org.eclipse.jdt.ls.product/scripts/jdtls.py, change:

parser.add_argument ("--validate-java-version", default=True, action=argparse. BooleanOptionalAction)

To:

parser.add_argument ('--validate-java-version', action='store_true')
parser.add_argument ('--no-validate-java-version', dest='validate-java-version', action='store_false')
parser.set defaults (feature=True)

There might be a more elegant way to fix it as per earlier discussion, but that change at least allows using the LSP server with an older Python version.

[kqvanity]

I made a local fork and added a fix there. Feel free to do the same, or if you already have signed the agreement, feel free to PR the fix.

Unfortunately I can't, as I'm relying on another nvim plugin that automatically grabs the plugin from the original repo.

@rgrunber said I'd be happy to merge a PR if it preserves the same behaviour and makes support a bit easier on macOS. Is that still viable without going thought the contribution agreement signings? All in all, I think couple of lines don't need a separate pull request, and just consideration of such an amendment!

[tmmvn]

@z0xyz At least it says so in the contributing readme:

In order to submit contributions for review, please make sure you have signed the Eclipse Contributor Agreement (ECA) with your account.

I think the PR is the right way to go though if the Eclipse team doesn't want to investigate fixing it, as the script changes of mine introduce a slight difference in behavior: Instead of being --validate-java-version=false and --validate-java-version=true, the flags become --validate-java-version and --no-validate-java-version. These then map to the --validate-java-version flag as either true or false, which allows rest of the code to work as is.

The difference didn't bother me, but might be an issue in the full scheme of things; The change allows the language server to run with older Python versions, but there's likely a better fix to add backwards support without breaking the flags.

As such, it might need more thinking, which would likely work better within a PR. Or for someone from the Eclipse team to just fix it (don't know who made the script originally).