Currently, I don't think there's a nice to way to set this since there's so many possible options, and I don't think we have a UI to go through all of them, but it should be possible to configure.

For example, in a Maven project, I ensured there was a .settings/org.eclipse.jdt.core.prefs file. This file has a key=value format and the various options can be found at https://github.com/eclipse/eclipse.jdt.core/blob/master/org.eclipse.jdt.core/model/org/eclipse/jdt/core/JavaCore.java#L270 (listing the key, possible values, and the default).

We do override some of these defaults in https://github.com/eclipse/eclipse.jdt.ls/blob/master/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/preferences/PreferenceManager.java#L124 .

So it is possible to customize these options. With that said, do you have a rough idea of which errors/warnings are particularly annoying ? Maybe we could consider changing their default state.

Hi @rgrunber ,
Thanks for the above note.
We do not have a list of which messages are targeted. Maybe it would be best to start with the ability to turn off WARNs, we can further refine if we get more feedback.

@fbricon , @testforstephen here's an example of a case where a global settings file would be beneficial. Also, some kind of location that lists the available options as opposed to having to reference the source javadoc.

I have a small draft of such a feature I can post soon. It works as follows. For every error/warning message that can actually be ignored, a code action is generated called "Ignore ${message}" . If performed, it will create/append a file under .settings/org.eclipse.jdt.core.prefs of the project with an entry to ignore that particular error/warning. A few things still to address :

• If an element has something like 3 warnings, that's 3 different code actions, and this dynamic behaviour could produce some ugly menu popups if the number grows. Maybe have an option like "Ignore all errors/warnings for element" when more than 3 errors/warnings ? If a user still wanted to only disable a particular one, they would still be able to remove the unwanted ones from the settings file. Entry names are pretty intuitive.
• Currently the options to ignore are saved to the project specific settings file, but we could potentially save to the global one. My preference is for the project file for now.
• Noticed some odd behaviour in appending/creating the project settings file, where occasionally the options aren't respect. This seems to point more to some issues we may have with responding to changes in the settings file.

If an element has something like 3 warnings, that's 3 different code actions, and this dynamic behaviour could produce some ugly menu popups if the number grows. Maybe have an option like "Ignore all errors/warnings for element" when more than 3 errors/warnings ? If a user still wanted to only disable a particular one, they would still be able to remove the unwanted ones from the settings file. Entry names are pretty intuitive.

The label is Ignore compiler problem(s) and it will ignore all compiler problems annotated on the current line.

Currently the options to ignore are saved to the project specific settings file, but we could potentially save to the global one. My preference is for the project file for now.

It now respects java.settings.url and will save the options there. If that setting is not defined / file doesn't exist, then the setting will be saved to the project metadata location (it applies the option for every Java project imported). A simple Java: Clean Java Language Server Workspace can be used to clear these out.

Noticed some odd behaviour in appending/creating the project settings file, where occasionally the options aren't respect. This seems to point more to some issues we may have with responding to changes in the settings file.

Found the problem. We're sending a regular string absolute path as a glob pattern for the watcher registration. This ends up calling VS Code's workspace.createFileSystemWatcher(..) which states :

* Providing a string as globPattern acts as convenience method for watching file events in
* all opened workspace folders. It cannot be used to add more folders for file watching, nor will
* it report any file events from folders that are not part of the opened workspace folders.

So we need to use https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#relativePattern to listen for files that may exist outside the workspace. I have a fix for this but I'll address it in a separate the same PR.