Get rid of deprecated org.eclipse.core.runtime.Preferences in platform code

[laeubi]

org.eclipse.core.runtime.Preferences is deprecated since 2014, but there are still as of today 46 matches.

It would be good to get the reference count down her and seems a good first issue for contributors that want to get in touch with eclipse code or anyone interested in cleaning up things.

As there was a quite large attempt to "move" code to Java 17 it seems to have issues for deprecated references is even worth more.

[alex2145]

If I understood correctly, you want to remove some references to the deprecated class org.eclipse.core.runtime.Preferences from the runtime module.

This will break all the plugins that use deprecated methods like Plugin.getPluginPreferences().

[laeubi]

If we remove/replace the reference how could it break things?

[alex2145]

For example, if we remove the method Plugin.getPluginPreferences() then all plugins that still use it will not compile anymore.

I don't see why we should replace those references, preferences are now stored according to scopes in the org.eclipse.core.runtime.preferences.IPreferencesService part of equinox and plugins should use InstanceScope.INSTANCE.getNode(yourPluginId) to set preferences and DefaultScope.INSTANCE.getNode(yourPluginId) to set default preferences.

It's my first time looking at this project, I might be misunderstaning. Can you provide an example reference and what you would replace it with?

[laeubi]

For example, if we remove the method Plugin.getPluginPreferences() then all plugins that still use it will not compile anymore.

The method has to stay, but we should remove any call to this method in platform code.

I don't see why we should replace those references, preferences are now stored according to scopes in the org.eclipse.core.runtime.preferences.IPreferencesService part of equinox and plugins should use InstanceScope.INSTANCE.getNode(yourPluginId) to set preferences and DefaultScope.INSTANCE.getNode(yourPluginId) to set default preferences.

Because the class is deprecated, that means we do not recommend to use it anymore. So it would be good to replace all usages of that class with the now recommended approach

https://github.com/eclipse-platform/eclipse.platform/blob/1809821c284452c8ee496dd133f2c4b3a2996a7b/runtime/bundles/org.eclipse.core.runtime/src/org/eclipse/core/runtime/Preferences.java#L90-L93

[lathapatil]

This class is used in other eclipse repositories as well like in eclipse platform ui, eclipse platform text , eclipse jdt . How will this be handled ? can a single contributor work on fixing all of these ?

[akurtakov]

So this is about Eclipse Platform project to stop using deprecated APIs itself. No one said anything about removing these APIs so other projects can continue using them. It would shift responisibility for fixing issues if/when they arise in usage of these APIs to whoever still uses them.

[laeubi]

can a single contributor work on fixing all of these ?

Sure why not, its just a matter of time/motivation, but for sure one can simply choose one place where the deprecated class is used and replace with newer construct, so it could be iteratively done by many developers.

The goal would be that searching for references inside the eclipse-sdk will only show the class itself and public API methods that should be deprecated as well.

Once this is done, we might even mark them for removal so they can be deleted some time in the future.

[alex2145]

I get it now, I didn't know that org.eclipse.core.runtime.Preferences was used by other modules in the project (I had imported only the runtime module and I could only find references in deprecated methods).

I imported the whole project and found more references.

[laeubi]

You can setup a full IDE for eclipse here: https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md#create-an-eclipse-development-environment

[lathapatil]

how do we do testing for the fix we are providing for this issue ? are there any automated tests available or we should do any manual testing before code commit?

[jukzi]

Generally there are a lot of automated tests running before an commit is accepted and also even more tests in the day after. However it's also good to test the code before creating a PR. In the call hierarchy of the code you may eventually find a testcase that can be manually run on your local computer. Sometimes helps to debug it. If you don't find a testcase it is very appreciated to add a junit test that both validates old and new behaviour.

[lathapatil]

Is there any reason why RefreshManager.java is not fixed for this issue and the issue is already closed?

could anyone let me know the reason before creating a PR for the same

[jukzi]

that was autoclosed by related PR.

[vogella]

If we do not use it anymore in platform, please mark it for deletion (via the forRemoval=true attribute on the @Deprecated annotation, so that we have the option to delete it in 3 years.