What to do about some 19318 warnings in Eclipse?

[gnl42]

Eclipse is currently showing (for me) 19318 warnings for Mylyn:
Of those, the major offenders are:

• 'Non-externalized string': 15478
• 'Discouraged access': 2315
• 'deprecated': 839

Any thoughts on how clean up the code?
@merks @BeckerFrank @akurtakov @ruspl-afed

[ruspl-afed]

I'm not sure what do you mean by "how". By fixing them all, of cause.

• 'Non-externalized string'

We can suppress them for test classes, all the rest needs individual review, followed either by i18n or //NON-NLS

• 'Discouraged access':

We can suppress them for test classes and may be specify x-friends inside one subsystem. But all the rest should be reviewed.
And I will veto blind promotion to API for packages, even if they looks like API and were used for years as an API. Because at this level of project resources, we will not be able to support old-fashion signatures promoted to the API.

'deprecated'

We need to review and rework them individually

[merks]

FYI, @SuppressWarnings("nls") works on larger scopes where appropriate, i.e., in a method or class where externalization does not and will never make sense.

[ruspl-afed]

Yes, I know, missed this in my comment for some reason. Thank you for this useful addition.

[gnl42]

"how" as in how to tackle the problem given the numbers

[merks]

Work very hard and very long. 😱

Note that access rules can also be used to fix access warnings:

For those you can fix many things quickly with small changes.

There are quick fixes for the NLS things, including the externalization wizard, but I'd start by identifying those places, e.g., tests where it just isn't needed.

I think no matter way, it's a lot of work...

[ruspl-afed]

Yes, a lot of work, but even after first approach to "commons" component I have 18096 warnings left. So, not so hopeless.

[ruspl-afed]

After completing the first round we have <7k (instead of >19k in the beginning) and there are still items relatively easy to resolve.
Thanks @gnl42 for your outstanding contribution to this activity!
Let's continue after 4.2.0

[gnl42]

Re 'Discouraged access':
@ruspl-afed @merks How about for now we changed the notification level from Waring to Info for all projects.
That way they won't clutter up the things we can fix, but they are still reported

[ruspl-afed]

Discouraged access is not different from other kinds of warnings and indicates that we need to pay attention on it. And we can apply bulk solution in 2 base cases:

1. we are in test bundle and access non-API signatures from bundle-under-test:
   => suppress them (actually this is weak solution since it may affect other usages)
2. we access non-API signatures from the same subsystem, i.e. x.y.z.ui calls x.y.z.internal.core:
   => declare x-friend x.y.z.internal.core package for x.y.z.ui

Other cases require individual review and may be even individual tickets, because they indicates "lack of API", or "leak of API" or other things to be considered, that may lead to [breaking] API change(s).

[gnl42]

I'm just suggesting that we set the level to Info temporarily so that the Warnings don't hide the items we can fix more easily

[ruspl-afed]

Eclipse Problem view has an excellent filtering capabilities to let one focus on issues of particular origin

[gnl42]

Down to 2638 (1749 'Discouraged access')