interestingly, what you just described answers your own question: java did a
remarkable job managing the complexity of module systems, deprecation cycles,
compatibility flags and unsafe replacements: all under a major version
umbrella that gave the ecosystem a clear signal and a clear timeline.
are you suggesting java should have done all of that through v8.x releases? or
were v9, v11, v17, v21 the right approach? java's transitions being less
painful than feared is not an argument against following that model, instead
it is the strongest possible argument to follow it.
i have been observing a pattern: your responses keep picking individual items
to argue against a major version while stepping around the central question.
so let me ask it directly:
1. do you agree eclipse has a competitive problem?
2. do you agree something has to be done about it?
3. do you agree that something should come from us?
if your answer is no to any of those, i would like to understand that position
better. because without agreeing at those premises, we will keep going in
circles debating lazy activation policies and aot cache flags, never to converge.
Thanks,
Gireesh Punathil
*
*
*From: *eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on behalf of Daniel
Schmid via eclipse-dev <eclipse-dev@xxxxxxxxxxx>
*Date: *Saturday, 30 May 2026 at 8:05 PM
*To: *eclipse-dev@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
*Cc: *Daniel Schmid <daniel@xxxxxxxxxxxx>
*Subject: *[EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!
95Fac3zzUu9Rf9bYr8RAEtKnYChdr97kFcmxfqDRpKM6LQruOw-
SnQQ8ueIjO3DBoqONVul7cvUrv-3sUObcYmUO9GrXFUA6hnxD$>
believe me, thousands of tools, frameworks and platforms have gone through
exactly this: Java, Spring, Hibernate, Angular, React, Django,
Rails, .NET... you name it. and all of them shipped major versions that
broke things and scared their ecosystems. companies kept saying "we can't
migrate right now." something broke and someone fixed it and the platform
came out stronger. it is the normal lifecycle of healthy software.
Looking at the first three since these are in the Java ecosystem:
Java
Despite that sentiment, there wasn't really a single version with many
breaking changes. If you are talking about JDK 9, that included many internal
changes and the module system but it was generally compatible and the
restrictions related to modules and integrity by default came in a compatible
way where permanent CLI options are used to declare what should be allowed
(there's also the deprecation of the memory-access methods of Unsafe which is
supposed to be permanent but it's just something that's being replaced). None
of that is really comparable to your "v5" approach. If you are thinking about
the one thing where people seemed to consider breaking changes the most
(everything related to project Valhalla), even that is pretty non-invasive to
how people use it in my opinion.
Spring
Assuming you are talking about Spring 6/Spring Boot 3, the most "annoying"
part of the migration was the javax-->jakarta namespace change which was
external and outside of Spring's control (it was Oracle not liking Jakarta EE
making changes to things in the javax namespace). While there were other
changes, I'd argue that these are normal changes of a major version. If you
are talking about Spring 7/Spring Boot 4, that one isn't /that/ big of a
breaking change in my opinion.
Hibernate
This was the same as with Spring: The biggest breaking change was forced by
the javax-->jakarta namespace change.
Note of these changed the core programming model or fundamental design
principles or similar (maybe you could argue for that with Spring 7/Spring
Boot 4 as they split the codebase into smaller (non-JPMS) "modules" but even
that comparison is lacking).
To me, it seems like what you are suggesting is more similar to the Python 2
--> Python 3 change which was just a pain for everyone why the people working
on Python later said that there would never be a Python 4 (at least not with
one thing fundamentally changing the C interop or something like this IIRC)
and changes would rather be incremental.
These projects make new versions in the same way there are new Eclipse
versions like 4.40.
but they may be also scared off by the perception that Eclipse is not
moving forward
Would a v5 that isn't finished within 5 years help with that?
On 30/05/2026 13:17, GIREESH PUNATHIL wrote:
Daniel, thank you, genuinely!
your concerns are about why change is needed, and about whether change is
safe. thats fair, and shows the care for the ecosystem.
believe me, thousands of tools, frameworks and platforms have gone through
exactly this: Java, Spring, Hibernate, Angular, React, Django,
Rails, .NET... you name it. and all of them shipped major versions that
broke things and scared their ecosystems. companies kept saying "we can't
migrate right now." something broke and someone fixed it and the platform
came out stronger. it is the normal lifecycle of healthy software.
and i say this from what i see. my day job is migration. i live in the
middle of this friction every day. i can see that "companies will be
scared off by v5", but they may be also scared off by the perception that
Eclipse is not moving forward.
on not knowing the exact list of changes for v5: you are right, and i will
own that. i like the change set emerging from the community, not dictated
by one person. and this gets in to the depth of OSS culture:
from
"bring a PR and we will discuss it" (sounds open but is actually hard for
people without knowledge about many repos with hundreds of bundles and
their relations and inter dependencies and the overarching architecture
and the prevailing tradeoffs)
to
"this is what Eclipse looks like today, this is why it feels slow and
heavy, this is why users drift away, this is what we need to fix that
(call it something else than v5 if that word scares folks) this is what
the tradeoffs are, and this is the way forward. commits welcome."
a shift from gatekeeping to beckoning. a shift from mailing list
discussion into a contributor pipeline.
WDYT?
and thank you for the devcall. i always had the invite, but missed every
time. will try to join next one.
Thanks,
Gireesh Punathil
*From: *eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on behalf of Daniel
Schmid via eclipse-dev <eclipse-dev@xxxxxxxxxxx>
*Date: *Friday, 29 May 2026 at 9:39 PM
*To: *eclipse-dev@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
*Cc: *Daniel Schmid <daniel@xxxxxxxxxxxx>
*Subject: *[EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/
AdhS1Rd-!
95Fb0nyS2CU7tbbYjiWAcl2mNC2wBkjI3s4bxI_DDGe7jk33shuAmt69K3L33SH98-5LZ1t2uMgTfggKey2ytquIDcgSda1j9Oga$>
on resources: i agree on the constraints, but gently disagree on the
inference. a v5 commitment is not a demand for more volunteer hours
from existing contributors, but a clear message to companies that
investment here has a direction and a destination. setting a clear
vision and roadmap can help drive more contributors.
How would you get contributors interested in doing that work that wouldn't
be possible without a "v5 commitment"? Also note that I think that most
companies earning money from Eclipse (and the RCP applications they are
building) would be scared off by hearing about a v5. Not getting enough
resources "despite" being a rewrite/big new thing is pretty much the main
problem Initiative 31 is facing so I don't see why this would be different.
on per-change compatibility windows: here our difference is very tiny!
you describe multiple changes with individual migration windows moving
at different speeds. the issue with that is, in the absence of
overarching commitment to remove those, the layers can become
permanent, and Eclipse 4 is the evidence. the e4 compatibility layer
had no coordinated sunset, so it is still there.
Many products would probably never migrate, this isn't really an option in
my opinion.
on AI: my AI argument is about Eclipse's survival and relevance, not
about forcing personal preferences or changing any individual's workflow.
I still have no idea why a rewrite would be necessary or even help with
integrating AI when everything necessary is there. And AI shouldn't be the
reason for a rewrite breaking compatibility anywhere else. Anything done
"for AI" shouldn't negatively impact anyone who doesn't want it. (I'm also
tired of the "AI is necessary to survive" argument, you don't need to
repeat it to me.)
the changes need to happen
If you are talking about agreeing on specific changes that need to happen,
I don't see that. While there are some things I'd like to see (including
work on CDS which doesn't require anything impacting compatibility for
example), I don't think there are that many changes relevant here that I
think need to happen. As you mentioned wanting to set a "clear vision and
roadmap", I don't think you even know the changes that "need to happen"
which I'd argue is a prerequisite to agreeing on these changes with anyone.
changes need clear migration paths
migration need explicit expiry
I'm not so sure about this. While I don't have an issue with migration
paths, there are many reasons why plans like that need to change. If
people didn't finish getting rid of a deprecated feature, that might be an
argument for keeping it (at least for some time) and people can still get
the advantages of the new feature while the old version is still around.
While it can be helpful to define a plan for when something should be
removed, that would rather be a "minimum" time.
rcp as a class I citizen.
I guess that is something I personally agree with (despite not working on
any RCP applications).
To be honest, I also don't like the idea of a compatibility "layer", I
prefer having building on top of existing things (e.g. capability to use
JPMS modules within OSGi and e.g. generating module descriptors at
compile-time (tycho) and using the existing approach where necessary)
without really deprecating the "old" approach.
As I previously mentioned with regard to scaring people with a v5, I would
strongly recommend not calling it v5. I don't think people want that.
That being said, please note that I'm not a committer on any Eclipse
project, I am not involved in decisions. I am just saying my personal
opinions (which may or may not help you with improving your proposal).
However, in addition to the mailing lists, I think you might be interested
in the devcall every two weeks: https://github.com/eclipse-platform/
eclipse.platform.releng.aggregator/wiki/Eclipse-IDE-%E2%80%90-Developers-
Community-Call. There, some people working on Eclipse including some
people working on RCP apps meet and you might be able to gather other
opinions on that topic. You can find an invite in the calendar linked on
the top of that page. However, I would still recommend providing concrete
evidence on why you think it's necessary to break compatibility in a
significant way (at least I'm not convinced of that at all).
On 29/05/2026 17:37, GIREESH PUNATHIL wrote:
Daniel: great! thankful to see you acknowledging i) competitive gap
exists ii) lazy activation could eventually become default and iii)
need of compatibility window. i think we are converging on many aspects!
on resources: i agree on the constraints, but gently disagree on the
inference. a v5 commitment is not a demand for more volunteer hours
from existing contributors, but a clear message to companies that
investment here has a direction and a destination. setting a clear
vision and roadmap can help drive more contributors.
on per-change compatibility windows: here our difference is very tiny!
you describe multiple changes with individual migration windows moving
at different speeds. the issue with that is, in the absence of
overarching commitment to remove those, the layers can become
permanent, and Eclipse 4 is the evidence. the e4 compatibility layer
had no coordinated sunset, so it is still there.
on RCP: agree 100%. any v5 process should consider RCP as the
exemplary use case when defining migration paths, deprecations, sunset
and timelines. if a v5 migration path works for RCP, it works for
everyone.
on AI: my AI argument is about Eclipse's survival and relevance, not
about forcing personal preferences or changing any individual's workflow.
in summary, i think we agree on most parts:
- the changes need to happen
- changes need clear migration paths
- migration need explicit expiry
- rcp as a class I citizen.
where we may differ is whether the compatibility layer needs a
coordinated migration path and expiry. to me, that definition is what
a v5 draft could contain.
WDYT?
Thanks,
Gireesh Punathil
*From: *eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on behalf of
Daniel Schmid via eclipse-dev <eclipse-dev@xxxxxxxxxxx>
*Date: *Thursday, 28 May 2026 at 8:43 PM
*To: *eclipse-dev@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
*Cc: *Daniel Schmid <daniel@xxxxxxxxxxxx>
*Subject: *[EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/
AdhS1Rd-!95FbcrbSsmWxlTbTDoQg8korHDR4AEaJch9B-
u6x08NgZ546baRyFzRiWquTqXgMvsp3GJRuDD1oS5fb_W4KUgwTNxr-HUUtC1x2$>
> while each of these is technically valid, they all are proposals to
optimize within the current architecture, not helping evolution based
on changing technologies, programming practices and expectations.
That is the point I'm making. There are a lot of opportunities for
improvement within the current architecture (and some with possibly
major non-breaking changes). With people not having enough time/
resources to improve performance within the "current architecture", I
don't have any reason to think why people would be willing to take on
the even bigger effort of making major changes to how everything
works. For example, you could take a look at Initiative 31 (https://
github.com/swt-initiative31/documents/blob/main/report/
overall_report.md) which was about changing SWT to use a single (more
modern) stack across operating systems. It concluded that it would be
possible (some things are even being integrated - without
significantly breaking compatibility) but it would be too much work
without companies willing to invest the necessary amount of resources.
> lazy activation? add a system property
That system property would be a compatibility layer that could
eventually default to lazy activation (but using eager activation at
first).
> here is my take: the traditional IDE shell (the menus, the views,
perspectives, the edit-compile-debug loop) is under genuine pressure
from AI tools. they are already replacing significant parts of the
classical developer workflow and making many of these views and
actions redundant.
While this may be applicable to many people, there are also a lot of
people that don't want to use AI tools. Any change made should not
negatively affect that workflow (in my opinion).
Another thing you should consider is RCP applications which is one
thing where Eclipse is used a lot (and which contributes a lot to the
resources spent on developing the Eclipse IDE). With there being many
applications based on the Eclipse Platform, changes like that
(especially something like replacing the class loading approach with
JPMS modules) have a noticable (not to say disproportionate) affect on
these applications as well whereas forcing them to rewrite their
application to improve the standard IDE is not reasonable.
To sum it up, I think it's probably better to make smaller changes in
a compatible way (and deprecate and remove these compatibility
helpers/layers in the future) rather than creating a v5 where there
are a lot of changes at once (which also won't be completed within the
next few years). That would also allow moving faster with some parts
of that effort than with others. Instead of one compatibility window,
there can be a compatibility window for each change requiring it.
On 28/05/2026 13:49, GIREESH PUNATHIL via eclipse-dev wrote:
at this point i want to step back from individual topics, as i
think otherwise the top level point gets lost. every time a
structural concern is raised, the response has been a local fix:
startup too slow? some JDK flag gives us 20%
lazy activation? add a system property
lingering stale APIs? policy is in place
while each of these is technically valid, they all are proposals
to optimize within the current architecture, not helping evolution
based on changing technologies, programming practices and
expectations.
the competitive reality is that eclipse is losing ground[1]. it is
not an option or an opinion, instead reality. AI SDK integrations
ignored us. IMO, other IDEs didn't become popular through better
Java support but with better architectural choices from day one.
The 20% startup improvement from AOT is real and great, but that
20% of 5 seconds is still 4. VSCode starts in 2. that gap is
architectural and is not tunable.
my v5 proposal is not "rewrite everything and break the world.”.
it is a request for a draft:
- what the next major version should look like
- a formal statement about architectural directions. with reasons
and contexts
- a defined compatibility window for the old path [ example:
apple migrated from ppc (p) to inel (x) to arm (a). easily. each
time, a compatibility layer ran the old arch while the new one
matured. and each time, there was a hard deadline. and each time
the ecosystem moved because it had to! ]
Stephan asked the most relevant and honest question: "does anybody
still need us?" lets all try to answer that directly rather than
deflect it. here is my take: the traditional IDE shell (the menus,
the views, perspectives, the edit-compile-debug loop) is under
genuine pressure from AI tools. they are already replacing
significant parts of the classical developer workflow and making
many of these views and actions redundant.
[1] https://survey.stackoverflow.co/2025/technology#1-dev-id-es
Thanks,
Gireesh Punathil
*From: *Daniel Schmid <daniel@xxxxxxxxxxxx>
*Date: *Thursday, 28 May 2026 at 4:09 PM
*To: *GIREESH PUNATHIL <gpunathi@xxxxxxxxxx>; General development
mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>
*Subject: *[EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/
v1/AdhS1Rd-!
95FRODc4EuWxVXbTTi7KUid11Oohd588BbuUswA2ApJj9gbV_6ItYaQsyXWC7dz4lfEg2Yn4NdVuIXjsHS1VXRPqS1BKCvyATpop$>
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.
Thanks,
Gireesh Punathil
*From: *eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on
behalf of Daniel Schmid via eclipse-dev <eclipse-dev@xxxxxxxxxxx>
*Date: *Wednesday, 27 May 2026 at 10:39 PM
*To: *General development mailing list of the Eclipse project.
<eclipse-dev@xxxxxxxxxxx>
*Cc: *Daniel Schmid <daniel@xxxxxxxxxxxx>
*Subject: *[EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/
EWT/v1/AdhS1Rd-!95Fb8hbYEg9RX3bZhE4AEoyuXGmer7-Jq0ajBtY8CF-
E795bIXpYTws4fssJUUgNwvHHBDH_SUQtkCsuWeSznB8CS-0BUnkdjXmS$>
> 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?
Thanks,
Gireesh Punathil
*From: *eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on
behalf of Daniel Schmid via eclipse-dev <eclipse-
dev@xxxxxxxxxxx>
*Date: *Wednesday, 27 May 2026 at 8:41 PM
*To: *eclipse-dev@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
*Cc: *Daniel Schmid <daniel@xxxxxxxxxxxx>
*Subject: *[EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious <https://us-phishalarm-
ewt.proofpoint.com/EWT/v1/AdhS1Rd-!
95FRODy4MyW7lRbZrsTqUuB-ZjQpLgh9YCy5iSHuUu6LRPhOtk-
pmuWipfhmBcuMy31eKvIm64sxI_qxnQhH5KNRdZfQRwtURCsQ$>
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:
the previous discussion on the topic here: https://
www.eclipse.org/lists/eclipse-dev/msg12346.html (not
sure how to link these two)
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.
Thanks,
Gireesh Punathil
*
*
*From: *Александър Куртаков <akurtakov@xxxxxxxxx>
*Date: *Wednesday, 27 May 2026 at 2:00 PM
*To: *General development mailing list of the Eclipse
project. <eclipse-dev@xxxxxxxxxxx>
*Cc: *GIREESH PUNATHIL <gpunathi@xxxxxxxxxx>
*Subject: *[EXTERNAL] Re: [eclipse-dev] eclipse sdk v5 ❤️
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
Report Suspicious <https://us-phishalarm-
ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-
XFVHHk6su91vTm1jsvA8TYNUzLSLUApnQgk85u87o3ZfCToim5LSHMwBumsfdIMk2kBfl7JbeT0soUQkbkVUGbxaeBuvrawbPZEvr52Il89uY7LNEKFQKY6naQ$>
On Wed, May 27, 2026 at 10:34 AM GIREESH PUNATHIL via
eclipse-dev <eclipse-dev@xxxxxxxxxxx> wrote:
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:
* Old APIs can be removed incrementally with 2 years
deprecation period as per https://eclipse.dev/eclipse/
markdown/?file=eclipse-platform/eclipse.platform/
master/docs/Eclipse_API_Central_Deprecation_Policy.md
<https://urldefense.proofpoint.com/v2/url?
u=https-3A__eclipse.dev_eclipse_markdown_-3Ffile-3Declipse-2Dplatform_eclipse.platform_master_docs_Eclipse-5FAPI-5FCentral-5FDeprecation-5FPolicy.md&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=oIraoLjZ3gTnNfPqyRvrAgzzll7PPZoR5jIgunYzz5E&m=IqSEJJbxHuJLWFHSBWJ6u8ia2WTxxTwqwE5ey7gY780QmQKiA6ZBSY6q87oRGrQ7&s=0jOaaIQ1css1zKtQxUmtXRhfXbp1MprIozZG_sIr_oE&e=>
* Old APIs are getting deprecated - e.g. https://
download.eclipse.org/eclipse/downloads/drops4/
R-4.39-202602260420/apitools/deprecation/
apideprecation.html for 4.39 deprecations and the
javadoc clearly shows terminally deprecated APIs
https://help.eclipse.org/latest/index.jsp?
topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Fdeprecated-list.html&anchor=for-removal <https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Fdeprecated-list.html&anchor=for-removal>
* Old APIs are getting removed - e.g. https://
github.com/eclipse-platform/
eclipse.platform.releng.aggregator/blob/master/
eclipse.platform.common/bundles/
org.eclipse.platform.doc.isv/porting/removals.html
<https://urldefense.proofpoint.com/v2/url?
u=https-3A__github.com_eclipse-2Dplatform_eclipse.platform.releng.aggregator_blob_master_eclipse.platform.common_bundles_org.eclipse.platform.doc.isv_porting_removals.html&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=oIraoLjZ3gTnNfPqyRvrAgzzll7PPZoR5jIgunYzz5E&m=IqSEJJbxHuJLWFHSBWJ6u8ia2WTxxTwqwE5ey7gY780QmQKiA6ZBSY6q87oRGrQ7&s=VPBYsqKg1yo-Qid3cich5LlDaqZkXq8QcXIt03Y61y8&e=> , https://github.com/eclipse-platform/eclipse.platform.swt/pull/3127 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse-2Dplatform_eclipse.platform.swt_pull_3127&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=oIraoLjZ3gTnNfPqyRvrAgzzll7PPZoR5jIgunYzz5E&m=IqSEJJbxHuJLWFHSBWJ6u8ia2WTxxTwqwE5ey7gY780QmQKiA6ZBSY6q87oRGrQ7&s=n8pke79Sti5QBvqos9GX54QPzHpcA5oR_vE872_2kNI&e=>, .....
Are you actually looking for the "marketing" effect of
v5? I ask as so far I fail to spot any technical
reason for v5.
Thanks,
Gireesh Punathil
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://
www.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list eclipse-dev@xxxxxxxxxxx To
unsubscribe from this list, visit https://
www.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________ eclipse-dev
mailing list eclipse-dev@xxxxxxxxxxx To unsubscribe from this
list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev
