Error: /usr/lib/jvm/java-11-openjdk/bin/java exited with code: 13 about coc-java HOT 13 CLOSED

@oldsouless I had the same issue. :CocCommand java.clean.workspace was not working either.
What I had to do was to manually remove $HOME/.config/coc/extensions/coc-java-data and restart nvim. Then I had to wait for the download to complete (it can take several minutes but a message should appear).

Do not close nvim before the message comes in or you will get the 13 error code back.
It would be nice if the incomplete download was canceled/clear out when exiting nvim?

from coc-java.

Looks like it doesn't work with openjdk or your jdk version too old.

from coc-java.

@chemzqm I think that I've narrowed down the problem.

I got it working for NeoVim simply by running CocCommand java.clean.workspace and CocRestart (i.e. coc.nvim printed out JDT Language Server started without any errors).

However, whenever I open gVim outside the project directory, cd to the project and open the same Java file I get the error message below.

If I then run CocRestart I get the message JDT Language Server started, without errors. After closing gVim I can redo the same procedure again (with the errors below).

## versions

vim version: VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 15 2019 00:11:27)
node version: v11.7.0
coc.nvim version: 0.0.65
term: dumb
platform: linux

## Error messages

## Output channel: prettier

## Output channel: highlight
[Info  - 10:59:58] Highlight server running in node v11.7.0

## Output channel: java
[Error  - 11:00:10] 27 Apr 2019, 11:00:10 Initialization failed
Failed to scan /2048/2048
org.eclipse.core.runtime.CoreException: Failed to scan /2048/2048
    at org.eclipse.jdt.ls.core.internal.managers.BasicFileDetector.scan(BasicFileDetector.java:134)
    at org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporter.applies(GradleProjectImporter.java:69)
    at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.getImporter(ProjectsManager.java:341)
    at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.importProjects(ProjectsManager.java:144)
    at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.initializeProjects(ProjectsManager.java:136)
    at org.eclipse.jdt.ls.core.internal.handlers.InitHandler$1.runInWorkspace(InitHandler.java:245)
    at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:42)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.nio.file.NoSuchFileException: /2048/2048
    at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
    at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
    at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:145)
    at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
    at java.base/java.nio.file.Files.readAttributes(Files.java:1763)
    at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:225)
    at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
    at java.base/java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:322)
    at java.base/java.nio.file.Files.walkFileTree(Files.java:2716)
    at org.eclipse.jdt.ls.core.internal.managers.BasicFileDetector.scanDir(BasicFileDetector.java:168)
    at org.eclipse.jdt.ls.core.internal.managers.BasicFileDetector.scan(BasicFileDetector.java:132)
    ... 7 more

from coc-java.

@Melkster did you eventually resolve this? I'm having the same issue with the only difference being that the server returns code 13 regardless of how I open the file or where the current working directory is or after using any CocCommands. Here is my log:

`!SESSION 2019-04-29 10:51:10.131 -----------------------------------------------
eclipse.buildId=unknown
java.version=12.0.1
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Command-line arguments: -data ${HOME}/.config/coc/extensions/coc-java-data/jdt_ws_7885b3803f8a351b1b22bf1f7e9bd96f

!ENTRY org.eclipse.osgi 4 0 2019-04-29 10:51:11.029
!MESSAGE Application error
!STACK 1
java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:81)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:661)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:597)
at org.eclipse.equinox.launcher.Main.run(Main.java:1476)
at org.eclipse.equinox.launcher.Main.main(Main.java:1449)`

Tried with the latest open-jdk from homebrew as we as the official Java SE from Oracle. @chemzqm Note that earlier versions of coc-java/coc.nvim worked fine although I can't seem to pinpoint the branch that breaks.

from coc-java.

Could be wrong workspace folder, start you vim in project root.

from coc-java.

@oldsouless No I still have the same problem 🙁

I noticed today that coc.nvim occasionally throws an error while editing Java files in NeoVim as well, even though it started successfully (I don't remember the specific error message however).

from coc-java.

@chemzqm Yeah I don't get the error when I start gVim or NeoVim in the project directory, so that might be it.

Maybe I it's already in there, but if not I suggest that this should be mentioned in the documentation 😃

It would be nice however if coc.nvim at least allowed me to open Vim outside the project root and then :cd to the project root before I open a Java file, which currently seems to break coc.nvim. I personally often launch gVim through the "dock" in my DE like a regular desktop application, and then :cd from there to wherever my project is.

from coc-java.

I'm getting the same error on latest version

coc-java 1.4.3
coc.nvim v0.0.73
java -version
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment (build 11.0.3+7-Ubuntu-1ubuntu218.04.1)
OpenJDK 64-Bit Server VM (build 11.0.3+7-Ubuntu-1ubuntu218.04.1, mixed mode, sharing)

I had to do a bit of trickery (replacing java with a script to log the argument tee the output):

 ~  cat /usr/bin/java
#!/bin/bash
echo $@ >~/tmp/java.log
/usr/lib/jvm/java-11-openjdk-amd64/bin/javabin $@ | tee &>> ~/tmp/java.log

and the log shows:

--add-modules=ALL-SYSTEM --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED -Declipse.application=org.eclipse.jdt.ls.core.id1 -Dosgi.bundles.defaultStartLevel=4 -Declipse.product=org.eclipse.jdt.ls.core.product -Dfile.encoding= -noverify -Xmx1G -XX:+UseG1GC -XX:+UseStringDeduplication -jar /home/jackieli/.config/coc/extensions/coc-java-data/server/plugins/org.eclipse.equinox.launcher_1.5.300.v20190213-1655.jar -configuration /home/jackieli/.config/coc/extensions/coc-java-data/server/config_linux -data /home/jackieli/.config/coc/extensions/coc-java-data/jdt_ws_65b8ef9878eadc4f2dfc1cfd936295f0
Error occurred during initialization of VM
java.nio.charset.IllegalCharsetNameException:
        at java.nio.charset.Charset.checkName(java.base/Charset.java:296)
        at java.nio.charset.Charset.lookup2(java.base/Charset.java:482)
        at java.nio.charset.Charset.lookup(java.base/Charset.java:462)
        at java.nio.charset.Charset.defaultCharset(java.base/Charset.java:608)
        at sun.nio.cs.StreamEncoder.forOutputStreamWriter(java.base/StreamEncoder.java:56)
        at java.io.OutputStreamWriter.<init>(java.base/OutputStreamWriter.java:110)
        at java.io.PrintStream.<init>(java.base/PrintStream.java:110)
        at java.io.PrintStream.<init>(java.base/PrintStream.java:148)
        at java.lang.System.newPrintStream(java.base/System.java:1892)
        at java.lang.System.initPhase1(java.base/System.java:1968)

from coc-java.

workaround is to add

  "java.jdt.ls.vmargs": "-Dfile.encoding=UTF-8",

in coc config

The error is at

need to check if config.encoding is not empty

from coc-java.

@oldsouless I had the same issue. :CocCommand java.clean.workspace was not working either.
What I had to do was to manually remove $HOME/.config/coc/extensions/coc-java-data and restart nvim. Then I had to wait for the download to complete (it can take several minutes but a message should appear).

Do not close nvim before the message comes in or you will get the 13 error code back.
It would be nice if the incomplete download was canceled/clear out when exiting nvim?

I had the same issue, probably because I had no proxy configured before opening java files for the first time.

Thanks.

from coc-java.

@oldsouless I had the same issue. :CocCommand java.clean.workspace was not working either.
What I had to do was to manually remove $HOME/.config/coc/extensions/coc-java-data and restart nvim. Then I had to wait for the download to complete (it can take several minutes but a message should appear).

Do not close nvim before the message comes in or you will get the 13 error code back.
It would be nice if the incomplete download was canceled/clear out when exiting nvim?

I had exactly the same issue and this helped. Thanks a lot! Probably the issue should be re-opened to start a pull request to clean up the folder in case the download is canceled..?

from coc-java.

There is java.updateLanguageServer CocCommand for download latest jdt.ls.

from coc-java.

I also encountered this issue (the error code 13), but with an older JDK which is also related to #106 . The solution was obvious (upgrading my jdk or downgrading the jdt.ls) in this case so this is just a heads up.

from coc-java.