Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: /usr/lib/jvm/java-11-openjdk/bin/java exited with code: 13 #20

Closed
Melkster opened this issue Apr 26, 2019 · 10 comments
Closed

Error: /usr/lib/jvm/java-11-openjdk/bin/java exited with code: 13 #20

Melkster opened this issue Apr 26, 2019 · 10 comments
Labels

Comments

@Melkster
Copy link

@Melkster Melkster commented Apr 26, 2019

After opening a file in a small project I get the following errors:

## versions

vim version: NVIM v0.3.4
node version: v11.7.0
coc.nvim version: 0.0.65
term: xterm-256color
platform: linux

## Error messages

## Output channel: prettier

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

## Output channel: java
[Info  - 00:56:12] Connection to server got closed. Server will restart.
[Error  - 00:56:12] /usr/lib/jvm/java-11-openjdk/bin/java exited with code: 13
[Info  - 00:56:14] Connection to server got closed. Server will restart.
[Error  - 00:56:14] /usr/lib/jvm/java-11-openjdk/bin/java exited with code: 13

The odd thing is that if I create a testfile Test.java in its own directory and open it, JDT Language Server starts just fine.

@chemzqm chemzqm added the help wanted label Apr 26, 2019
@chemzqm

This comment has been minimized.

Copy link
Member

@chemzqm chemzqm commented Apr 26, 2019

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

@Melkster

This comment has been minimized.

Copy link
Author

@Melkster Melkster commented Apr 27, 2019

@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
@oldsouless

This comment has been minimized.

Copy link

@oldsouless oldsouless commented Apr 29, 2019

@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.

@chemzqm

This comment has been minimized.

Copy link
Member

@chemzqm chemzqm commented Apr 29, 2019

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

@Melkster

This comment has been minimized.

Copy link
Author

@Melkster Melkster commented Apr 29, 2019

@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).

@Melkster

This comment has been minimized.

Copy link
Author

@Melkster Melkster commented Apr 29, 2019

@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.

@chemzqm chemzqm closed this in b0038b1 Apr 29, 2019
@noboruma

This comment has been minimized.

Copy link

@noboruma noboruma commented May 16, 2019

@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?

@jackielii

This comment has been minimized.

Copy link
Contributor

@jackielii jackielii commented Jul 17, 2019

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)

@jackielii

This comment has been minimized.

Copy link
Contributor

@jackielii jackielii commented Jul 17, 2019

workaround is to add

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

in coc config

The error is at

params.push(encodingKey + config.encoding)

need to check if config.encoding is not empty

jackielii added a commit to jackielii/coc-java that referenced this issue Jul 17, 2019
Check if config.encoding is specified, if not, `-Dfile.encoding=` won't be added to the vm args, otherwise jvm will fail to start with `java.nio.charset.IllegalCharsetNameException`
chemzqm added a commit that referenced this issue Jul 17, 2019
A fix for #20
@JSamir

This comment has been minimized.

Copy link

@JSamir JSamir commented Aug 1, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.