coc-java
coc-java copied to clipboard
Version of Eclipse jdt.ls
Is there a way to configure which version of the Eclipse jdt.ls will be downloaded? From what I noticed in the statusline it always goes for the latest snapshot (http://download.eclipse.org/jdtls/snapshots). Would be great if I can configure it to download only the released versions (http://download.eclipse.org/jdtls/milestones)
It may not be as convenient as changing the automatic download url, but you can use the java.jdt.ls.home config option to point to a different version in the mean time.
Hmm... It's seems that this is causing problems. The latest snapshot doesn't work:
[coc.nvim]: Uncaught exception: Header must provide a Content-Length property.
Manually compiled v0.66.0 and it's ok now. Can we at least switch to the release channel?
FWIW, I'm not seeing the same issue with the latest jdt.ls snapshot (0.67.0-202012040244). It could be project specific though?
@dansomething I was using the same snapshot of jdt.ls with OpenJDK 11.0.9 under macOS and I had this issue with two projects. Those two projects have got similar dependencies though so it might still be project-specific.
Btw there didn't seem to be anything relevant in server logs (and trace logs didn't have headers in them).
eclipse.buildId=unknown
java.version=11.0.9
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_AU
Command-line arguments: -data /Users/fzhang/.config/coc/extensions/coc-java-data/jdt_ws_abcf06a6453c19d21997fa5abfcea01a
!ENTRY org.eclipse.core.resources 2 10035 2020-12-08 09:10:40.508
!MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes.
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:48.984
!MESSAGE class org.eclipse.jdt.ls.core.internal.JavaLanguageServerPlugin is started
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:49.217
!MESSAGE Main thread is waiting
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:49.311
!MESSAGE >> initialize
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:49.318
!MESSAGE Initializing Java Language Server 0.67.0.202012040244
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:49.357
!MESSAGE Static Commands: []
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:49.358
!MESSAGE Non-Static Commands: [vscode.java.checkProjectSettings, vscode.java.isOnClasspath, vscode.java.fetchUsageData, vscode.java.validateLaunchConfig, vscode.java.resolveClassFilters, vscode.java.resolveMainMethod, vscode.java.resolveClasspath, vscode.java.resolveBuildFiles, vscode.java.resolveMainClass, vscode.java.updateDebugSettings, vscode.java.resolveSourceUri, vscode.java.fetchPlatformSettings, vscode.java.buildWorkspace, vscode.java.startDebugSession, vscode.java.inferLaunchCommandLength, vscode.java.resolveElementAtSelection, vscode.java.resolveJavaExecutable]
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:49.360
!MESSAGE Static Commands: []
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:49.362
!MESSAGE Non-Static Commands: [java.edit.organizeImports, java.project.refreshDiagnostics, java.project.import, java.project.removeFromSourcePath, java.project.listSourcePaths, java.project.provideSemanticTokens, java.project.resolveStackTraceLocation, java.project.getAll, java.project.isTestFile, java.project.getClasspaths, java.project.getSemanticTokensLegend, java.project.getSettings, java.project.updateSourceAttachment, java.project.resolveSourceAttachment, java.project.addToSourcePath]
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:51.357
!MESSAGE Importing Maven project(s)
!ENTRY org.eclipse.jdt.ls.core 1 0 2020-12-08 09:10:52.210
!MESSAGE Workspace initialized in 2074ms
I'm using the save version of Java on macOS.
$ java -version
openjdk version "11.0.9" 2020-10-20
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9+11)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.9+11, mixed mode)
Have you tried a plain "Hello World" Maven or Gradle project to see if that works for you?
@dansomething I tried it on my playground project and got the same error.
I pulled your playground project and that worked fine with just a couple of minor tweaks. Though they don't seem to be related to your issue here.
- The
.mvn/wrapper/maven-wrapper.propertiesfile was missing - I had to add Lombok to the vmargs in my
coc-settings.jsonfile."java.jdt.ls.vmargs": "-javaagent:/path/to/lombok.jar"
It certainly seems like it could be an issue somewhere in your setup, but it's hard to say for sure where.
@dansomething What about coc and vim? I'm using NeoVim 0.4.4 with neoclide/coc.nvim@f565111. If yours are still the same I'll try minimal vimrc later.
Edit: Just noticed that I've already got a minimal vimrc (and I disabled all coc extensions except for coc-java). Tested and got same error.
set runtimepath^=~/.vim runtimepath+=~/.vim/after
let &packpath = &runtimepath
" vim-plug
call plug#begin()
Plug 'neoclide/coc.nvim', {'branch': 'release'}
call plug#end()
let g:fzf_layout = { 'window': { 'width': 0.8, 'height': 0.7 } }
let g:fzf_preview_window = 'down:65%:wrap'
" ==== Start Coc Configurations ====
" Some servers have issues with backup files, see #649
set nobackup
set nowritebackup
" Better display for messages
set cmdheight=2
" You will have bad experience for diagnostic messages when it's default 4000.
set updatetime=300
" Don't give |ins-completion-menu| messages.
set shortmess+=c
" Always show the signcolumn, otherwise it would shift the text each time
" diagnostics appear/become resolved.
if has("patch-8.1.1564")
" Recently vim can merge signcolumn and number column into one
set signcolumn=number
else
set signcolumn=yes
endi
" Single column signs
let g:coc_status_error_sign = "\U2717 "
let g:coc_status_warning_sign = "\U26A0 "
" Remap keys for gotos
nmap <silent> gd <Plug>(coc-definition)
nmap <silent> gy <Plug>(coc-type-definition)
nmap <silent> gi <Plug>(coc-implementation)
nmap <silent> gr <Plug>(coc-references)
" ==== End Coc Configurations ====
" vim: set tabstop=4 softtabstop=0 expandtab shiftwidth=2 smarttab:
I used Vim and Neovim installed via Hombrew on the latest coc.nvim release branch. Here's the relevant output from :CocInfo
vim version: NVIM v0.4.4
node version: v15.3.0
coc.nvim version: 0.0.79-8b967b0bbd
vim version: VIM - Vi IMproved 8.2 8021719
node version: v15.3.0
coc.nvim version: 0.0.79-8b967b0bbd
@dansomething We're using the same versions then... I'll look into it when I've got time.
@dansomething I think I've found the file that's causing the problem but I'm not sure about the root reason.
Here's what I did
- Back up the old
coc-java-datacd ~/.config/coc/extensions mv coc-java-data coc-java-data.bak - Open a Java project, so that
coc-javacan re-download the server snapshot - Compare the files
cd ~/.config/coc/extensions/coc-java-data/server sha1sum **/** | tee /tmp/java.new.sha1sums cd ~/.config/coc/extensions/coc-java-data.bak/server sha1sum **/** | tee /tmp/java.old.sha1sums cd /tmp cat java.new.sha1sums | while read -r line; do HASH="$(cut -d ' ' -f 1 <<< "$line")" if [[ -z "$(rg "$HASH" java.old.sha1sums)" ]]; then printf '%s not found\n' "$HASH" fi done2c77592a3a0f6e1ab21ab7d2e5b401c0a8dd7789 not found - The mismatch was
server/config_mac/org.eclipse.osgi/framework.info.1, so I:cd ~/.config/coc/extensions mv coc-java-data coc-java-data.new mv coc-java-data.bak coc-java-data cd coc-java-data/server/config_mac/org.eclipse.osgi cp ~/.config/coc/extensions/coc-java-data.new/server/config_mac/org.eclipse.osgi/framework.info.1 ./framework.info.63 # this is the existing file in the original copy of the folder
And now the issue is gone! I haven't got time to scrutinise this file. Is this something that concerns coc-java?
framework.info is created by the OSGi framework when the language server loads. I don't know enough about OSGi to explain why it would fail to be created. I don't see a connection between this and coc-java unless the server download got corrupted somehow?
@dansomething I believe the server files are correct, since they all checked out with the new ones.
It's just somehow not refreshed after server update. I quickly searched jdt.ls issues without getting any hits. If this happens to other users it may worth the effort for coc-java to delete this file after server updates (?)
The whole server directory could be replaced during an update. Nothing in it is project-specific.
Should be fixed on recent version of coc-java, try upgrade coc.nvim to latest release and coc-java to version 1.14.0.
No download supported from [email protected]