Fix javalsp command callback.

[hsanson]

The command used to invoke the language server is missing some options
to include additional java modules. Without these modules the server
was not working properly.

The correct command can be found in a launcher script on the same
directory the java executable for the language server is found.

This commit changes the docs to prefer the launcher script over the java
executable. For backward compatibility it also fixes the command
invocation in case the java executable is configured.

[w0rp]

I think launcher is probably an executable name that's too generic and might cause other programs to be run. Is there a set of locations where the launcher script is likely to be installed, say in your HOME directory? It might be a better idea to look for the language server script in those directories first, and fall back on launching the language server with java if the script cannot be found.

[hsanson]

@w0rp I thought about this for a while and cannot really find a way to prevent getting the wrong binary . The only solution I can see is to force users to explicitly set a value for g:ale_java_javalsp_executable.

When installing the java-language-server manually there is no pre-defined location so it can be anywhere on the users home dir and when installing it via VSCode plugin there is no binary at all. Not sure how vscode invokes the language server.

Falling back to java is not good either. it must be the java binary generated when compiling the language server. It cannot be the system installed java. Therefore, this also must be explicitly set to the absolute path of the language server provided binaries.

[w0rp]

This should be fine.

[w0rp]

Cheers! 🍻