[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] eclipse sdk v5 ❤
|
From what I recall, the "expected" startup improvement with these
things for most applications wouldn't be much more than 20% so I'm
not sure how much that would actually improve in that area. Also,
my point was that there may be a possibility to get some of that
improvement by supporting externally loaded classes in some way.
If you think about improving startup time using lazy activation,
you could try asking Heiko Klare (who participated in that
aforementioned discussion) how changing the activation policy to
lazy (or eager) would affect their startup time since they are
interested in better startup time. If you really want lazy bundle
activation by default, I think the way to go would be creating a
system property or similar that affects the default (and if some
plugin explicitly specifies the bundle activation policy, I guess
that should still be respected).
However, I don't see any reason why breaking changes in a "v5"
would motivate people to do performance work.
On 28/05/2026 06:58, GIREESH PUNATHIL
wrote:
thank you Daniel for the link - impressive work and impressive
numbers! but pls note that the 20% startup improvement with JDK
assistance will further benefit if assisted by eclipse' own
re-architecture: probably in order of multiples. for example VS
code has extension lazy loading by default, enforced at the
platform. any extension needs to request explicitly to get
activated, or else it simply is not loaded. so you are not
loading most of the IDE until its actually needed.
i too haven't heard any one talking about moving away from OSGi.
and i agree, moving away from OSGi isn't practical too. but OSGi
with lazy load enforced at the platform is is different from the
current OSGi. lazy activation existed since long ago. The fact
that it hasn't solved Eclipse's startup performance problem in
~20 years is an evidence on the architectural improvement
opportunity. in summary, bold experiments would not happen
without bold thoughts, and major enhancements (such as fast
bootstrap) will not happen without major architectural shifts
either.
This Message Is From an External Sender
This message came from outside your organization.
> OSGi
classloading is slow due to one loader per plugin, among other
reasons. JPMS is light weight and can load classes faster. can
v4.x accommodate / entertain this change? even as an
experiment?
I am
not sure whether anyone would be willing to move away from
OSGi in any capacity. If there is a possibility to change
equinox to use module layers with one class loader for some of
the bundles (if there are no split packages or other things,
possibly with tycho automatically creating a module descriptor
for bundles where this is possible), I guess that could be
worth an experiment but it would be quite a bit of effort
(though probably nothing in comparison to rewriting all
bundles). Since you mentioned startup time here, you might
want to take a look at this discussion I created which is
about using JDK features for better startup time:
https://github.com/eclipse-platform/eclipse.platform/discussions/2060 However,
I think that parts of that may work better with a somewhat
stable classpath and it might be useful to get in touch with
the JDK team to find a solution where Eclipse/OSGi can tell
the JDK about that in some way (e.g. where these classes come
from, possibly one archive per class loader).
I
don't think getting rid of OSGi is reasonable even for a v5 if
that requires all plugins to change without there being a
compatibility layer of some sort.
> -
plugin registry loading is heavyweight and slow because all
the installed plugins are loaded up front. can we do lazy
activation in v4.x?
I am
not sure but I thought that at least some plugins are loaded
lazily? See also
https://stackoverflow.com/a/17592449/10871900. I guess
what might be needed here is making sure that it is actually
used where it is possible?
On 27/05/2026 18:01, GIREESH
PUNATHIL wrote:
Thank you Daniel! a couple of examples:
- OSGi classloading is slow due to one loader per plugin,
among other reasons. JPMS is light weight and can load
classes faster. can v4.x accommodate / entertain this
change? even as an experiment?
- plugin registry loading is heavyweight and slow because
all the installed plugins are loaded up front. can we do
lazy activation in v4.x?
there are many ways through which we could make eclipse
light weight, above are just few examples.
when you say lightweight is a "matter of willingness", pls
remember none of the v4.x releases were willing to do this,
and we kept on losing ground. and "we could do this in v4.x
itself but havent" has become indistinguishable from "we
won't." a major version on the other hand creates the
forcing function and opens up opportunities to experiment.
why do you think eclipse agent project is slow moving? IMO
it is due to the complexity of the code base. a light weight
IDE would make AI integration seamless.
but from the fact that eclipse agent project is slow, do you
allude that eclipse users do not want AI SDK? and from a lot
of people don't was AI assistance in SDK, so does the
majority of the user base?
This Message Is From an External Sender
This message came from outside your organization.
Hi,
> *
an IDE that is lightweight and fast. why this is needed?
because all the competing IDEs are light and fast. are
they more attractive because they are light and fast? yes.
This requires breaking changes with a major version.
Can
you elaborate what "breaking changes" would be needed for
this? It is already possible to remove plugins from the
default packages (e.g. Mylyn) to make parts of it faster
and make some changes to the default perspectives for a
more "lightweight" experience (that is just a matter of
willingness). When it comes to performance, there are
probably a lot of optimizations that could be done without
breaking compatibility (which haven't been done yet).
Furthermore (on the "lightweight" side), it may also be
possible to refactor some things into different OSGi
bundles if most users don't need a part of the
functionality and keep the existing bundle with the
extracted bundles as dependencies to preserve
compatibility.
> *
an IDE that AI assistants can easily integrate into. major
LLM SDKs build first class integrations for other IDEs. AI
assisted development is the new baseline and when we don't
have a credible AI story. developers switch IDEs and do
not return. and we can't do modern AI integration cleanly
onto a 20 year old plugin architecture. This requires
breaking changes with a major version.
I
think the Eclipse Agents (https://github.com/eclipse-agents/eclipse-agents/)
proposal/project already does that but there isn't
sufficient interest to actually put it forward. I don't
see any reason why any of this would require any breaking
changes.
What
exactly are the APIs you need to make breaking changes for
and how "breaking" are they? How would you get most of the
existing plugins working with v5 (including ones that may
not be maintained)? Could you point out what deprecated
APIs (or design decisions) are actually causing the issues
you mentioned? From what I can see, both of the issues are
things that could be addressed without major breaking
changes but I don't feel like having a v5 in sight will
make people more willing to implement these things. I
think the main problem is not being bound by staying on v4
but by the development capacity for improvements. And if
minor removals are needed, these are probably still
possible.
That
being said, there are a lot of people who don't want AI
assistents at all on their systems. Building the tools
they use around AI assistents would likely cause
annoyances for those people.
Yours,
Daniel
On 27/05/2026 15:37, GIREESH
PUNATHIL via eclipse-dev wrote:
thanks Aleks for the links. the incremental API removal
policy looks good. i did some random search and found
APIs that are 15+ years old living with deprecated tag.
if the policy is working smoothly, why are some of those
APIs still present? i guess the answer is API removal is
hard when they are fused into the core design of the
IDE.
and that was just one item from the list of concerns
(breaking changes accumulating over time, exponentially
harder for future migrations, introduction of awkward
workarounds...) i raised.
to me, what are the compelling case for v5? what are
things that cannot be developed without breaking v4?
* an IDE that is lightweight and fast. why this is
needed? because all the competing IDEs are light and
fast. are they more attractive because they are light
and fast? yes. This requires breaking changes with a
major version.
* an IDE that AI assistants can easily integrate into.
major LLM SDKs build first class integrations for other
IDEs. AI assisted development is the new baseline and
when we don't have a credible AI story. developers
switch IDEs and do not return. and we can't do modern AI
integration cleanly onto a 20 year old plugin
architecture. This requires breaking changes with a
major version.
This Message Is From an Untrusted Sender
You have not previously corresponded with this
sender.
i want to resume this discussion , but i lost the
old mail thread (more than an year old), hope the
title will help sync with the thread in the email
discussion archive.
what do people think about moving to v5?
i strongly support this.
What would be the driving new
feature/api/design for v5? If such a development is
happening yet - it would better be shared with the
community so more context could be put in the
discussion. At least I'm not aware of anything like
that.
if backward incompatibility and ecosystem breakage
is a concern, the one time manual efforts for
migration is now drastically reduced with several AI
tools available.
on the other hand, if we don't move, breaking
changes accumulate over time, making it
exponentially harder for future migrations, while
code gets filled with awkward workarounds, old APIs
still linger while better designs are possible....
That's totally not the case:
Are you actually looking
for the "marketing" effect of v5? I ask as so far I
fail to spot any technical reason for v5.
