| Re: [eclipse-dev] eclipse sdk v5 ❤ |
I will respond to comments made in multiple E-Mails (as I didn't really think responding to them was worth it before).
TL;DR: I think startup times are relevant for some people/RCP
products and may be worth improving but I think it would be better
to discuss concrete improvements on GitHub (in
issues/discussions/PRs for specific changes).
From Stephen:
Let me add one remark regarding performance: I don't know why people get so excited about Eclipse startup time. How often do people start Eclipse.
If switching workspaces is included (which I'd argue shares a lot with startup time as much of the startup time is about that even if it might not need to do class-loading related things so that wouldn't apply), I'd say that happens pretty regularly (maybe up to every 1-2 hours, typically like 3 times per day; at work, I'm using 3 workspaces consisting of around (estimated) 3-7 working sets each) and there are days where I might start Eclipse-based applications 10 times in one day (needing to do that more often is somewhat rare but happens, especially when I'm debugging native-image problems and stopping Eclipse and many other things to get more memory for a faster build). That is about Java development and general usage of Eclipse, not including starting Eclipse from Eclipse. That being said, there are Eclipse-based (RCP) applications where startup time matters more important like Vector's product taking more than one minute to start up (I don't work on those but I remember Heiko mentioning that startup times are relevant for them as a company building a complex RCP product).
Improvements to startup time could also manifest in other places like CI/test times (in some cases) and maybe some batch tasks using Eclipse installations (e.g. using -nosplash -application xyz argument to run something without a GUI) but I have no idea how much we could get with that. Because of these reasons, I think looking at startup time can be worth it, even if it doesn't result in much of an improvement for most users.
---
From Gireesh:
If you think you have a reasonable approach at improving it (even if it requires a "major overhaul", whatever that entails), feel free to suggest that (e.g. as an issue, discussion or as a (PoC) PR) in the relevant repository (I think these formats make more sense as they are more focused and you are more likely to get actionable advice and there's a higher chance of it being integrated reasonably fast). I think anyone who can demonstrate performance improvements in these areas is welcome to submit them as long as they don't case any regressions. I think these are still possible for a 4.x release (I wouldn't want a 5.x release just for performance) but if it helps you prototyping things, I guess it is also possible to build a PoC with major changes and breaking compatibility and then find a reasonable solution that may work without any 5.x or or regressions."builds taking minutes, incremental builds not really incremental": thanks for this Stephan, i think this is exactly what Daniel was looking for: substantial and recurring pain points.
Daniel: what do you think, addressing this issue (minutes to build) fall under v4.x, or does it warrant a major overhaul? in which case probably we have the first candidate for the future draft?
but i suspect slow builds and slow startups may be sharing a common genesis - a design weakness in the OSGi classloading model that obscures real dependencies in both casesWhile I don't have any reason to think so (I don't know why already linked classes from OSGi would be an issue here), feel free to use a profiler and show us if that is actually the case.
--
I don't think anything needs to be done about these things from "whoever feels for eclipse" as a general group. If someone wants to improve something, they can but I think it's more useful to discuss specific improvements (and any person willing to work on these enhancements can do that). However, I'm not really interested in arguing about that (which is also why I didn't respond to this before).thank you Daniel! that is three "yes"s with caveats! and that is enough common ground to build on!
> I don't know who "us" is.
"us" is whoever feels for eclipse. whoever shows up to a mailing list thread even when there were differences. and you, Daniel, have been one of the most engaged and thoughtful voices in this thread, pushing back where i was imprecise and finding alignment wherever it existed. and similar minded folks across this project. that is "us" for me!
pushing back where i was imprecise and finding alignmentThe main point I am pushing back against is that I don't think there is a need for a v5 (see also Mark Goodchild's E-Mail).
"builds taking minutes, incremental builds not really incremental": thanks for this Stephan, i think this is exactly what Daniel was looking for: substantial and recurring pain points.
Daniel: what do you think, addressing this issue (minutes to build) fall under v4.x, or does it warrant a major overhaul? in which case probably we have the first candidate for the future draft?
on the bike shed: i work in PDE, debugging plugin life cycle issues that require spinning child eclipse in release and debug modes a hundred times an hour, and those 5 seconds accumulate into intolerable frustration. your pain is builds. mine is startups. both are recurring and real pains. neither of us is bike shedding.
i am not 100% sure, but i suspect slow builds and slow startups may be sharing a common genesis - a design weakness in the OSGi classloading model that obscures real dependencies in both cases, loading more plugins than needed. at startup and at build time.
if this is true, we have been disagreeing on the manifestation while suffering from the same root cause, without knowing it. and even if it is not, no harm done; two different pain points - one big deal for someone, another one big deal for someone else.
"one of the last IDEs powered by human intelligence": looks like a resignation or making peace with an ending? 😊 maybe AI will eat all of this eventually and eclipse will become a museum piece. but i would rather find that out after we tried, not before. because if eclipse fades, this question may come up at the post mortem: what did we do to evolve, adapt and survive?
Thanks,Gireesh Punathil
From: eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on behalf of Stephan Herrmann via eclipse-dev <eclipse-dev@xxxxxxxxxxx>
Date: Wednesday, 3 June 2026 at 4:43 AM
To: General development mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>
Cc: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
Subject: [EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤
_______________________________________________ eclipse-dev mailing list eclipse-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev