Re: [platform-dev] Workspace location, properties and declarative servic

[Alex Blewitt <alex.blewitt@xxxxxxxxx>]

> On 23 Mar 2021, at 17:37, Sebastian Zarnekow <sebastian.zarnekow@xxxxxxxxx> wrote:
> 
> > 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.

The problem is that there’s ResourcesPlugin and Workspace, in different packages, and the current implementation is that the former instantiates the latter and keeps a global reference to it on the assumption that there will be only one. If you move this out and defer the construction to DS (as this patch does) then the ResourcesPlugin will have access to the state on the Workspace only through public accessors, but it would be counterproductive to add the public API on ResourcesPlugin to let the instantiation of the Workspace have modification rights.

One trivial way of fixing this would be to have the Workspace store it in a private field, with a public accessor, that the ResourcesPlugin to use. At least that would be no worse than today.

> Anyhow, nitpicking aside.

Nitpicking can sometimes be a force for good and to improve code, so I thank you for it.

> 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.

Total number of classes certainly matters. But the problem is I’m typing this on a 16-virtual core laptop, and Eclipse is using at best 2 threads (main and DS) to bring it up. Even with SSDs there’s non-trivial latency in looking up a class. Much of those threads are spent on IO which means there’s free compute going unused, both on the cores that are waiting for IO responses and those which aren’t being exercised.

We can’t unlock the bundle activators; they’re designed to be blocking until such time as everything happens. We can (theoretically) start multiple DS components in parallel. Currently the Activators are the synchronisation point.

> 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?

Not necessarily; the getWorkspace works as it did before. It may need to block while waiting for the resource to appear (with a timeout?) to emulate past behaviour.

> 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.

I think Eclipse is both blessed and cursed by the longevity of the platform. I know that many plugins attempt to preserve backward compatibility for many releases. Sometimes, however, I think they take it too far. 4.8 didn’t support Java 11 for example, and many plugins are using that as a minimum, which realistically means that 4.9 is the lowest sensible cut off for support.

But with the update in release speed, and particularly moving forward to a dated release schedule, you’re suggesting that (effectively) 2018-09 is still being used actively and wanting to update to newer features for complex frameworks but not the platform itself?

I guess the question we have to answer is: do we think the platform is ‘done’ and we don’t want to work on improving it? If so, what’s the future state of the platform?

I don’t think Eclipse can go through an E4 type transition again, nor should we want to. But we can either incrementally work on improvements or leave it as is.

Alex