Project compiles with Eclipse; errors with JDTLS, using same data directory #3370
Comments
|
@aj-sarama Could you show your .classpath, .project files? Is there pom.xml, build.gradle or build.gradle.kts in your workspace? |
|
The project uses Ant as its build tool. There's a build.xml at the root of the project, although that file does not seem to specify which Java version to use. Could that be a problem? It's a multi-project workspace, so there are many .project and .classpath files. Here's a .classpath file for one of the projects: |
No, Java Ls doesn't check build.xml
Could you check the project/directory where you get |
|
Oh, many of my projects have this in their .classpath:
Also in their MANIFEST.MF:
So that may be why JDTLS is tripping up, although I don't understand why/how Eclipse is handling this case and JDTLS is not... |
|
Hi @snjeza I have updated every .classpath and MANIFEST.MF in my project to use JavaSE-11. I still get the error And this is the .project: Booting up the same project in Eclipse, then running Clean results in none of these errors that I get with JDTLS. |
|
@aj-sarama Could you attach your server log? - Enable Logging |
|
Also, are you able to share the projects at all or pared down version of them ? You mentioned " If you really do need PDE support, there is https://github.com/testforstephen/vscode-pde but the bundles that provide that support to the JDT-LS language server is embedded into the VS Code extension for it. |
|
Thanks for responding--yes, it is an Eclipse plugin project. So I would need PDE support for my project. Not particularly interested in using VSCode specifically. How difficult would it be to replicate the support provided by https://github.com/testforstephen/vscode-pde? |
|
@aj-sarama ok, good to know. Hearing I'm not sure if nvim-jdtls has a way to do this, but based on a quick look at the sources, you would need to invoke a command through the language server protocol. Specifically, the well-defined Update: This whole bundle is provided to JDT-LS through the (your absolute path would of course be a bit different) bundles setting list |
|
What a fantastic and helpful reply, thank you very much. I'm going to first see if my project works with VSCode + the PDE extension, and will follow your advice if it does. |
|
Working with VSCode and the PDE plugin now, I'm getting the same error and stack trace as the log I provided previously: I have my Now in that I have confirmed that I get the error immediately after right clicking my |
@aj-sarama You may want to take a look at redhat-developer/vscode-java#3926 (comment) |
|
It looks like VSCode was giving me a bunch of phantom errors after building my project, so I thought something was wrong. When it built, it reported ~250 errors. When I visited each file with errors, they magically disappeared from the diagnostics. I don't know how to diagnose whether that is a problem with VSCode/Java Extension/PDE Plugin or JDTLS. Or perhaps it's automatically resolving them somehow? |
@aj-sarama Could you attach some of these projects? |
|
It would help to know what some/most of those 250 errors were, or even a sample project where it happens. We do have a setting to control how we check/update errors/warnings on opened files but for the most part, files shouldn't have to be opened to get the state of errors/warnings to be accurate. Sometimes it might appear as if the build is complete because you can do things, but the language server begins responding to requests even while the build might be ongoing. You'd want to pay attention to the Java server status item in the toolbar at the bottom. In some instances it can temporarily signal "Ready" and jump to building. Screencast.From.2025-01-28.23-25-50.mp4There are a very small set of errors which can disappear (but aren't truly resolved) (eg. type name already defined, preview features enabled for incompatible version) mainly because certain errors can only be detected by a full build, and when a file is opened a less intensive error reporting is done which doesn't catch some. This is a bug in how we report certain errors in our the language server. |
|
The project is a very complicated monolith (~850 subprojects, ~13,000 source files), and although it is open source, it isn't so easy to get set up. So I'm not sure sharing the project here is the right approach. As for the errors, the vast majority of them are "the import ___ cannot be resolved", where once I visit the file with the error in question, it seems to immediately resolve the issue. Rebuilding the project seems to make them pop up again. By watching the compilation progress, it seems like one project temporarily fails to build, leading to its dependencies being unable to import it. Once that project eventually does build successfully, those projects that depend on it are left with that error until I explicitly open them. If it's a particular project setup issue, a screensharing situation may be more productive. In any case, please consider setting up either a sponsor page for JDTLS or your own GitHub sponsor pages. I am grateful that the both of you are giving me the time of day for my very specific issues. One thing I question about VSCode's JDTLS is that it is not asking me for a data directory, and it doesn't seem to be configurable anywhere. Given that Eclipse handles the project okay, I figured passing the same data directory to JDTLS would be helpful. I'm going to fork nvim-jdtls and add that workspace command for PDE support. Hopefully that combined with using a working Eclipse's data directory will make things behave. |
|
@aj-sarama you can upload your projects to github - Creating a new repository |
|
Unfortunately, I won't be able to do that, as they are sadly not fully open-source. I'll close the issue momentarily--I just wanted to ask, for my own PDE JDTLS setup, @rgrunber in your analysis of how the PDE VSCode plugin works, I noticed you did not include this request to resolve the launch arguments through the included PDE project. Is it necessary to do this with my own extension of nvim-jdtls? Edit: after further inspection, it looks like it's only necessary for launching the PDE application, which I probably will just do through Eclipse |
|
Exactly. PDE provides the ability to generate the target platform (set of all dependencies that could be used to build/test the application) but also the ability to launch the application from a valid The call at https://github.com/testforstephen/vscode-pde/blob/795f86673ba29f50f7c1f3e09c63d9d155577bfc/src/extension.ts#L120-L134 , programmatically configures this https://code.visualstudio.com/docs/java/java-debugging#_configuration-options , which is defined at https://github.com/microsoft/vscode-java-debug/blob/4d30fc1364a233570f9cdec1ee5522e3e6d49b1a/package.json#L369-L776 . Regarding your data directory question, vscode-java configures that on behalf of users. It's details like these that we attempt to hide from users as they complicate things. VS Code defines a storage location for each extension (eg. |
|
For those "phantom errors" that seem to resolve themselves when I open a file, is there a command I can send to JDTLS using my neovim client, essentially asking it to reload a specific file? Something other than textDocument/didOpen? Edit: right as the errors magically resolve themselves, JDTLS is sending a "Validating file" message to my client, and then stops reporting diagnostics like "Support for compiling Java 1.6..." |
|
"Validating file" is probably triggered by opening the file. Also, we dropped support for compiling projects that enforce a pre-1.8 around summer 2024. Recent Eclipse's releases (after summer 2024) should behave the same as the support was dropped there. See #3227 . It's updated on our README : https://github.com/eclipse-jdtls/eclipse.jdt.ls?tab=readme-ov-file#features . Just realized you mentioned this earlier on but couldn't understand how a BREE of JavaSE-1.6 could have caused any issues given we didn't support PDE at all by default. Maybe you have some .settings/ folder somewhere that contains "1.6" in the org.eclipse.jdt.core.prefs file ? It actually looks like this kind of error, |
|
Yes, a rebuild does retrigger those errors. Let me know what specific questions I can answer about the project where that error originates, as I unfortunately cannot send it as-is. Edit: your second paragraph confused me a little bit--are the errors legitimate and are being lost on open? |
@aj-sarama Could you show the project's .project and .classpath? |
|
Oh, for a couple of my projects I see that I have this entry in the classpath: That's obviously the problem here. Although, Eclipse doesn't seem to report this as an error for the same project setup. |
What version of Eclipse are you using? |
I first set up my multi-project workspace in Eclipse. Opening the same project using JDTLS gives errors that indicate there is something wrong with the JRE being used by JDTLS:
Compiling for Java version '1.6' is no longer supported. Minimal supported version is '1.8'My relevant Eclipse project settings are:
Preferences -> Java -> Installed JREs: JavaSE-11 (/path/to/jdk-11)
Preferences -> Java -> Compiler -> Compliance: 1.8 (required for my project)
These settings are reflected in my org.eclipse.jdt.core.prefs:
I pass the following settings via nvim-jdtls to the language server:
Using the same data directory as the Eclipse project that was set up without issues.
Again, I get errors that look like:
Compiling for Java version '1.6' is no longer supported. Minimal supported version is '1.8'Please advise how I can continue to debug my setup.
The text was updated successfully, but these errors were encountered: