Re: [platform-dev] Workspace location, properties and declarative services
On Wed, Mar 24, 2021 at 12:28 PM Lars Vogel wrote: > 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. > I should make it clear that declaring platform 'done' means effectively killing eclipse platform because: * --illegal-access deprecation with Java 16 means some work will have to happen on p2/equinox and quite likely on extension points as reflections is just not what it used to be * split-packages are causing issues https://bugs.eclipse.org/bugs/show_bug.cgi?id=360659#c8 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=570189 for more details * dependencies - what do we do all the CVEs coming only to latest versions - Jetty is covered (for now!) but there is still xmlgraphics-commons with open CVE-2020-11988. Batik, lucene and etc. versions we ship are most likely not going to receive security fixes anymore and every such update has implications on our codebase. * not going to even mention getting more and more disconnected to new UI workflow, view and etc. which make it even more Last but not least - people working on this are not many so I'm facing decision like either fix 2 security/runtime/whatever issues in a way working on last versions and thus bumping our min requirements and support only latest or fix only one and have my product being vetoed by security and/or qa teams. I wouldn't even say there is even a dilemma for me here. Heck, if at end of this year there are things working with Java 17 only - so be it! Preserving backward compatibility is always an option and can be done better and/or less intrusive but it's an extremely expensive one which requires significantly higher investment from companies interested in preserving the compatibility. After all we do our best to keep things working as much as we can with available resources with the clear goal to make things easier to maintain for the future and if it comes at the price of inconvenience for people depending on extra compatibility efforts - consider participating in the maintenance! > Best regards, Lars > > On Tue, Mar 23, 2021 at 7:19 PM Mickael Istria wrote: > > > > > > > > On Tue, Mar 23, 2021 at 6:37 PM Sebastian Zarnekow < > sebastian.zarne...@gmail.com> 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
Re: [platform-dev] Workspace location, properties and declarative services
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 wrote: > > > > On Tue, Mar 23, 2021 at 6:37 PM Sebastian Zarnekow > 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 > platform-dev@eclipse.org > 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:
