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.