scalameta / metals-languageclient Goto Github PK

Whenever a JDK_JAVA_OPTIONS or JAVA_TOOL_OPTIONS environment variable is defined, Metals fails to start. Even if the content is something as innocent as -XX:+PrintCommandLineFlags. The log looks like this.

Java home: /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64
Metals version: 0.9.5
[Error - 5:01:04 PM] Connection to server is erroring. Shutting down server.
[Error - 5:01:04 PM] Connection to server is erroring. Shutting down server.
[Error - 5:01:04 PM] Connection to server is erroring. Shutting down server.
[Error - 5:01:04 PM] Connection to server is erroring. Shutting down server.
NOTE: Picked up JDK_JAVA_OPTIONS: -XX:+PrintCommandLineFlags
Error: -classpath requires class path specification

(Exception is, if the variable is defined as an empty string or a white space, like " ", then Metals works normally as well.)

Metals should work well, even in the presence of these (officially supported 1, 2) environment variables.

On Ubuntu 20.04.

Ubuntu 19
OpenJDK 11
VSCode 1.43.0
Metals 0.8.1

When I open a project, which has .jvmopts with any of commented settings with #
Metals fails immediately with the following message:

Failed to download Metals, make sure you have an internet connection and the Java Home '/usr/lib/jvm/java-11-openjdk-amd64' is valid. You can configure the Java Home in the settings

If I remove it, it works. My .jvmsettings file is:

-XX:+CMSClassUnloadingEnabled
-Xmx2G
-Xms2G
-XX:MaxMetaspaceSize=1g
-Xss8m 

#-XX:+UseNUMA 
#-XX:+UnlockExperimentalVMOptions 
#-XX:+UseZGC

Describe the bug

When Starting VSCode, I get

Java home: /nix/store/rjgb7sb2wrhl98gqda31h1iaa7v6nm9y-openjdk-11.0.12+7/lib/openjdk
Metals version: 0.10.8
Unrecognized option: --add-exports java.base/sun.nio.ch=ALL-UNNAMED
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Downloading Metals failed with the following:
Process exited with code 1

To Reproduce

• Create a simple Scala project
• Write to .jvmopts

  --add-exports java.base/sun.nio.ch=ALL-UNNAMED
  

Expected behavior

Language server should not crash. Indeed, sbt works fine from console for instance.

Installation:

• Operating system: Linux
• Editor: Visual Studio Code
• Metals version: v0.10.8

Additional context

I am providing OpenJDK and sbt from Nix.
I've tried providing metals from Nix as well, but it did not fix my issue.

The fetchMetals function uses child_process.spawn* to start a JVM to call coursier to fetch Metals. When we're behind a proxy, the .jvmopts allow us to set the http.proxyHost=my_proxy_host which is passed to the JVM and should be respected.

This works well when when my_proxy_host is an IPv4 host. If it's IPv6, things break: coursier isn't able to connect to the proxy.

Why this happens: Due to a very obscure bug in the JVM. To quote the description

A DESCRIPTION OF THE PROBLEM :
When a unix domain socket is bound to fd 0 of a JVM instance all IPv6 functionality is disabled. This for example occurs when the JVM is spawned by Node.js (see https://stackoverflow.com/questions/34108124/ip-addresses-of-network-interfaces-in-a-java-process-spawned-by-nodejs).

So if your proxy is IPv6 only, this functionality doesn't work. And since this is the first step in setting up Metals, nothing else work.

How to fix it: The fix is simple -- we need to pass {stdio: ["ignore"]} as an option to the child_process.spawn which fixes this issue. Since we don't interact with the stdin of the JVM and it's a short lived process, I think this is a reasonable change to add.

Repro:

1. Setup an HTTP IPv6 proxy. Let's call it my_proxy_host
2. Either in the server properties on VSCode or in the .jvmopts add the following lines:

   -Djava.net.preferIPv4Stack=false
   -Djava.net.preferIPv6Addresses=true
   -Dhttp.proxyHost=my_proxy_host
   -Dhttp.proxyPort=8080
   

3. Now simply try starting VSCode after clearing your coursier cache.
4. Observed Behavior: VSCode extension fails to Download metals.
   5 Expected Behavior: VSCode extension should respect the proxy and download Metals.

Smaller Repro step:

1. Create the following program into a JAR file: https://gist.github.com/siddhant3s/3f843dd5f3f2fd30788dfb97e901397e and save it into /tmp/javaget.jar
2. Copy this small NodeJS script https://gist.github.com/siddhant3s/7cf5828231f60664e25011796fb70733 and save it to /tmp/node2java.js
3. Run this script node /tmp/node2java.js.

You will see that the first call will not succeed while the second call will succeed.

Fix

It's a simple one line fix which I have already tried and it succeed. The bug report also mentions the same fix.

Describe the feature

Allow user to dismiss "out of date" message for some time.

Currently the message:

You are running an out-of-date version of Metals. The latest version is 0.9.3, but you have configured a custom server version 0.7.5

is displayed every time I open neovim.
I use this version to be compatible with an old scala version.

Describe the bug

Cannot use metals with openjdk11 when editing .scala file

To Reproduce

Steps to reproduce the behavior:

1. Install openjdk11
2. nvim main.scala when main.scala is absent

Expected behavior

Metals should work

Actual behaviour

Error message fires:
Unable to find a Java 8 or Java 11 installation on this computer. To fix this problem, update the 'Java Home' setting to point to a Java 8 or Java 11 home directory:

Metals does not work

Installation:

• Operating system: Linux
• Vim or nvim version: NVIM v0.4.3
• coc-metals extension version: 0.5.3
• Metals version: 0.8.0

Search terms
java not found, openjdk 11

• typecheck PRs
• enable dependabot
• enforce prettier
• publish on tags

Hello Metals team:

First off, thanks for all the great work on Metals, not only have I been a user myself (via VSCode) but have also used some of the internals to inform my own language server for a mission scripting language I've been working on for a while (not yet open source).

In my vscode extension impl, I've recently switched to using https://github.com/Jabba-Team/jabba for the underlying java downloading functionality and it has worked very well so far. In particular, it's great to know one is using a maintained tool (shyiko/jabba#845).

I did some searching and it seems this has not been mentioned in this repo so I thought I'd enter this ticket in case it motivates some consideration. Of course, feel free to close as you deem appropriate.