Access services via IWorkbench

[ruspl-afed]

We may avoid additional service trackers that nobody closes and access services via IWorkbench for this UI bundle

[github-actions]

Test Results

 1 947 files  ±0   1 947 suites  ±0   1h 27m 35s ⏱️ + 1m 9s
 4 718 tests ±0   4 694 ✅ ±0   24 💤 ±0  0 ❌ ±0 
14 154 runs  ±0  13 987 ✅ ±0  167 💤 ±0  0 ❌ ±0 

Results for commit 8b89a9d. ± Comparison against base commit b47f9cd.

[laeubi]

I would not tie this to PlatformUI as it would mean it can not be used in a plain RCP application without legacy mode.

As all services are automatically freed when a bundle shuts down one not necessarily needs to dispose a service tracker, but it would better be not a static field but an instance field to account for possible restarts of the bundle what Eclipse actually do not support well anyways, but this does not mean we must not try to do it better.

[ruspl-afed]

as it would mean it can not be used in a plain RCP application without legacy mode

Very comforting to know that E4 is still an option. May be we can discuss the E4 plans separately.

I'm closing this one because you have a better offer @laeubi

[laeubi]

@ruspl-afed I know platform is late (if not lazy ...) in migrating to E4, but I try to be E3/E4 agnostic where possible. Still there are references to PlatformUI in this bundle(s) but we should at laest try not to make it more worse.

[ruspl-afed]

but I try to be E3/E4 agnostic where possible

this is great to read, now I know where to appeal in the case of counter-E4 changes/comments

but we should at laest try not to make it more worse

absolutely, I will be even more careful with PlatformUI/Platform usage

[merks]

Yes, it's sometime frustrating with the Eclipse Installer to find that things depend on the workbench when there isn't really strictly a need for the workbench itself, e.g, org.eclipse.ui.IWorkbench.getDisplay() seems so innocent.

[ruspl-afed]

to find that things depend on the workbench when there isn't really strictly a need for the workbench itself

So now I know who else can support the changes for independence from E3 IWorkbench.
BTW, never thought it may be you @merks because EMF UI is extra conservative.

[laeubi]

See also

• Convert "Terminal View" to only using E4 API #2042

[mickaelistria]

I know platform is late (if not lazy ...) in migrating to E4

I don't think it's a matter or being late or lazy; but it's more a matter of using E4 not being the priority of many.
(some history, hear grandpa 👴📖 )
That has been since day 0 the issue with E4: it's a bunch of small nice things, but the added-value has never been compelling enough to be worth the migration effort. And even at the early time when Platform development was docused on development and adoptiong of E4, the result was rather negative: the usability and stability got worse, and the IDE didn't offer any sensible added-value to users for several releases in a row. It took place about the same time as the quality and marketing rise of IntelliJ. Both at the same time have caused millions of users to move away from Eclipse IDE in favor of IDEA. Many of the people who already around back then are still slightly "traumatized" by it and the enthusiasm in E4 has faded very fast for many people. Many still believe that if the energy of developing/adopting/promoting E4 were spent on usability and new features; Eclipse could still be the main Java IDE
(📕 end of story, you may go to bed now, but should probably read the next paragraph before)

But that said, I think there is a general agreement that E4 APIs are usually much better and to be preferred when it comes to new code or refactorings. It's just a matter of getting people interested in adopting them in existing code when there is no sensible added-value for maintainers or users...

[laeubi]

The problem is if you do it like in E3 then there is of course no added value. If you once got to the point where you are actually using E4 you don't want get back (and gets really frustrated maybe when forced to use "E3 way".

This is actually a very good example actually, so much efforts to avoid the static singleton access where in E4 I would simply have done:

@Inject
ITerminalService terminalService;

So maybe a bit like Junit3 > Junit 4/5, of course it has worked before and if you are used to it it seems completely bogus to convert, but on the long run it gives you more freedom and less boilerplate.

Of course this sometimes need to enable new things, but we have made great progress here in the past years already so thing are even much nicer now.

And about "major IDE" ... who really cares? If we would get a penny for each download maybe, but honestly I really sick of these "This is crap and because of that I use InteliJ" ... if it is that great we probably should simply stop wasting time with an own IDE.

[mickaelistria]

if it is that great we probably should simply stop wasting time with an own IDE.

It's what some organizations have been steadily doing for about a decade.
Fortunately, OSS works like a charm and Eclipse Platform is a great piece of technology that can always attract new people, so some other people happily have come as regularly and fill the gap, and even better as diversity has increased. So overall, it could be that losing users and historical organizations losing their influence was actually a win for the ecosystem sustainability and to reinforce the OSS values and benefits.