eclipse.jdt.ls
eclipse.jdt.ls copied to clipboard
Fix deleting invisible projects when updating workspace folders.
I noticed that when I removed a workspace folder through workspace/didChangeWorkspaceFolders, it wasn't being cleaned up. It seems like the workspace folders are being registered as invisible projects, but when it comes time to clean them up, invisible projects aren't handled properly.
Can one of the admins verify this patch?
Cómo eliminar la rama de flujos de trabajo es un dominio
This doesn't seem to clean up the workspace folder either from what I can tell.
Can you describe what you noticed that wasn't being cleaned up ? Do you mean that the files from the removed workspace folder are still accessible ? It definitely looks like the removed folder doesn't match correctly with the invisible project.
Sorry, I think I was a little overeager with this PR.
I will be opening and closing hundreds of workspace folders, so I need to make sure that the RAM used when opening those folders is reclaimed once the folder is closed. I haven't experienced any memory leakage yet, but a few signs point toward workspace folders remaining on the system even after being closed:
ProjectsManager.getWorkspaceRoot().getProjects()shows workspace folders that have already been removed- Normally, when you open/close files, those files are added/removed in
JavaCore.getWorkingCopies(null). But files from removed workspaces still appear in that list. - I see removed workspace folders inside
JavaModelManager.getJavaModelManager().containers - etc.
Please let me know if these behaviors are normal or cause for alarm. I'm not familiar with this codebase, so maybe it is silly of me to expect all traces of workspace folders to be removed.
Just to confirm, which client are you using with JDT-LS ? Is it VS Code (ie. vscode-java extension), NeoVim, etc. ? In VS Code you're right that when closing a workspace folder the info is still available, and that seems like a bug. However there's a small distinction :
- If you're adding folders (eg. hundreds) to an existing workspace, then yes, removing some might not properly remove some things. I've noticed this as well, and think it's worth trying to fix
- If you're simply closing the entire workspace and re-opening another one, there should be no issue, because the language server actually shuts down and starts back up when a new folder is present (for Maven/Gradle/Eclipse projects) or a file is opened (Invisible project).
I have a custom setup where multiple clients share the same underlying server. When they connect/disconnect, I open/close a workspace folder for them, and the language server isn't restarted in between.
Oops... I just realized that what I thought were left-over projects were actually entries inside the workspace data folder that I wasn't cleaning up properly. My apologies...
There is still the issue of files staying open after their workspace folder has been removed, but since open files are controlled by the client, I guess we can't assume that those files are closed until we receive textDocument/didClose.