> To be fair, that’s just what the ResourcesPlugin does at the moment:
Private mutable static fields are not the same as a public mutable static fields - especially without any synchronization means when the entire story appears to be about concurrent bundle activation. And better locality is something that I'm not sure about when the only supposed client of an API is no longer the owner of the API. Anyhow, nitpicking aside. Personally I see a lot of value in backwards compatibility at Eclipse. Amongst others, the ResourcesPlugin is a very central API and its offered accessors to the workspace and friends are probably used by hundreds and thousands of plugins that are not under our control. Before moving code left and right, I would be really curious how a fully backwards compatible solution may look like. What concerns me a little are the other exercises in that direction that did already land. I often read on bugzillas that class loading is dominating the entire activation and if a class is not loaded in context of plugin A, it will simply trigger the load in the context of a plugin B and there is no real gain in the total startup. After all, the code that is supposed to be executed must be loaded before it can run and before the workbench can appear. Even if I will be perceived as the party pooper: Another concern of mine (there is always another concern...): Is this level of complexity that is inherent to any multi threaded solution for bundle activation and class loading worth the few milliseconds that can be shaved. Especially in the light of > hard-coded references to ResourcesPlugin that are likely to be affected which we need to resolve and therefore at the risk of breaking plugins that used to run perfectly fine for years? All this really makes me wonder if the imposed risk and effort (in coding, reviewing, testing etc) is in a healthy relation to the outcome. But in the end, I'm not a committer on the platform and only a consumer that tries to maintain a complex framework across various versions of Eclipse in a backward- and forward-compatible way. In the end I can only voice my opinion and try to understand the solution such that I know how to best use it such that the code is still fine with Eclipse 4.8, 4.20, and all versions inbetween. Best Sebastian On Tue, Mar 23, 2021 at 5:55 PM Alex Blewitt <[email protected]> wrote: > On 23 Mar 2021, at 10:58, Sebastian Zarnekow <[email protected]> > wrote: > > Hi Alex, > > given the long explanation for the issue and the impact such a change > might have on downstream consumers along with the scray feeling that I have > about code like > > public class Workspace .. { > /** > * Used by ResourcesPlugin to identify the workspace, not for other uses. > */ > public static IWorkspace singleton; > .. > } > > > To be fair, that’s just what the ResourcesPlugin does at the moment: > > > https://github.com/eclipse/eclipse.platform.resources/blob/7fc856229a1e26eae354adf70d11b39d6727c20e/bundles/org.eclipse.core.resources/src/org/eclipse/core/resources/ResourcesPlugin.java#L350-L356 > > It was a refactoring that essentially moved it from > ResourcesPlugin.workspace to Workspace.workspace for better locality. This > is where it initialises the static singleton at the moment: > > > https://github.com/eclipse/eclipse.platform.resources/blob/7fc856229a1e26eae354adf70d11b39d6727c20e/bundles/org.eclipse.core.resources/src/org/eclipse/core/resources/ResourcesPlugin.java#L464 > > Alex > _______________________________________________ > platform-dev mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
