Hi Alex, thanks for the clarification of the event admin suggestion. Sounds like the additional service property is currently the best approach.
> 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? We should definitely continue to improve the platform and improving performance is a key part of this. Thank you for working on this. Best regards, Lars On Tue, Mar 23, 2021 at 7:19 PM Mickael Istria <[email protected]> wrote: > > > > On Tue, Mar 23, 2021 at 6:37 PM Sebastian Zarnekow > <[email protected]> wrote: >> >> 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. > > > Platform has policies and technical validation that ensure that backwards > compatibility is enforced at API level: most APIs have tests that are > contract/spec tests of the behavior, and there are a lot of tools to ensure > API so linkage compatibility is not broken by inadvertence. Concretely, > ResourcePlugin.getWorkspace() will never be removed. > If there are some tricky case you foresee about the upcoming refactoring > which risk of breaking the current API contract, I suggest you capture them > in some test case to integrate in the Platform test bench. In the best case, > they'll be consensual and be merged to prevent this area from regressing in > future refactorings; in the worst case, it's not clear the behavior being > tested is a contract, but it brings the test brings the best possible > material for discussing it. > >> 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. > > > Workbench is not the only consumer of the bundles. Many applications do run > headless, repeatedly at build-time (API Tools for instance). So even if some > refactorings do not impact workbench load, they can positively impact other > use cases, that are also interesting. > >> 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. > > > I looked at a few reviews on the matter of workspace initialization, and my > impression is that it depends: in some cases, refactorings to use an OSGi > service do not increase complexity, they sometimes happen to better separate > concerns and thus improve maintainability/simplicity. But sometimes, it's > indeed slightly more complex. > I have the impression those are similar to any change and should be treated > individually like we do for all other changes, as there is not clear sign > that things get systematically simpler/harder, better/worse,... when using > services. > >> >> 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. > > > Platform usually try to capture new patterns in migration guide and > documentation. But for sure, if you want to still write code that targets > Eclipse 4.8, you won't be able to use newer APIs and patterns, eg your plugin > will keep calling ResourcePlugin.getWorkspace early in Activator and Eclipse > Workbench will not start faster when your plugin is installed. But as long as > you stick to 4.8 and verify you don't rely on APIs that don't get > deprecated/removed, it should work with 4.20 even if some refactorings about > internal Activator have been happening; 4.20 should not work worse than 4.8. > _______________________________________________ > platform-dev mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev -- Eclipse Platform project co-lead CEO vogella GmbH Haindaalwisch 17a, 22395 Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (040) 5247 6322, Email: [email protected], Web: http://www.vogella.com _______________________________________________ platform-dev mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
