[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] eclipse sdk v5 ❤
|
> 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.
