Remove unused NLS message keys - #2860
Open
vogella wants to merge 2 commits into
Open
Conversation
An NLS class declares public static String fields that NLS.initializeMessages fills reflectively from a .properties file. The compiler cannot flag one that nothing reads: the field is public and the framework, not the code, writes it. Over the years 186 such keys across 21 message bundles lost their last caller and stayed behind. Each key is removed on both sides, field and properties entry, because NLS.initializeMessages logs a warning for an entry without a field and for a field without an entry. All 20 affected bundles compile, which is the actual check: a key that was still read would no longer resolve.
Contributor
|
This pull request changes some projects for the first time in this development cycle. An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch. Git patchFurther information are available in Common Build Issues - Missing version increments. |
Contributor
vogella
marked this pull request as ready for review
August 10, 2026 08:38
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An NLS class declares
public static Stringfields thatNLS.initializeMessagesfills reflectively from a.propertiesfile. The compiler cannot flag one that nothing reads, because the field is public and the framework rather than the code writes it, so dead keys accumulate invisibly. This removes 186 of them across 21 message bundles, roughly 370 lines.Each key goes on both sides, the field and the properties entry, since
NLS.initializeMessageslogs a warning for an entry without a field and for a field without an entry. I verified that all 21 class/properties pairs remain symmetric afterwards, and all 20 affected bundles compile, which is the real check: a key still being read would no longer resolve.Keys with a namesake elsewhere were checked individually rather than by name.
plugin_instantiateClassErrorandplugin_loadClassErrorare referenced downstream, but from Equinox'sRegistryMessages, not from theorg.eclipse.core.internal.runtime.Messagescopies removed here; likewiseTestRunSession_unrootedTestsandresources_errorVisitingexist as separate copies in jdt.ui and pde.