The Protocol That Unbundled the IDE

There is a thing people who used Eclipse remember, and it is not a feature. You open a project, and before you can type a character the application resolves several hundred bundles, activates the ones it cannot avoid, and then starts building a workspace. On a large codebase that is minutes, with a progress bar narrating it. That experience is the single most cited fact about the product, and it is universally filed as a defect.

The Stack Overflow Developer Survey 2023, fielded in May and published in June, asked which development environments people use. Reading the figures off the chart for that question rather than off the narrative around it, on 86,544 responses, Visual Studio Code sits at 73.71 percent and Eclipse at 9.9 percent. Take that for exactly what it is: one self-selected population, one multi-select question, measuring what people report opening rather than where work gets done. It still describes an argument that has stopped being had.

The usual explanation is that Eclipse was bloated and the newer editors were lean, which is true and explains nothing, because the same sentence was true in 2009 when Eclipse was winning. Weight is not something a product acquires through carelessness. It is the invoice for a property somebody chose on purpose, and in this case the property is the entire reason anyone built on it.

So the claim, stated plainly. Eclipse is heavy because of the thing that made it powerful: everything in it including the IDE is a bundle, anything a third party writes can extend the tool as deeply as its authors did, and the semantic model of your code is meant to be complete and current at every keystroke. Those three decisions produced refactoring that was years ahead of everything else, and they produced the progress bar. You never got to buy one of them separately.

Everything is a bundle, including the application. Eclipse 3.0 replaced the original plug-in runtime with OSGi in 2004, implemented as the Equinox project. After that the editor, the Java tooling, the version control integration and the platform itself were all the same kind of object: a jar with a manifest declaring what it exports, what it imports, and at which version ranges. There is no privileged core with plugins attached to the outside. There is a bundle graph, and the IDE is a region of it.

Resolution has to finish before anything runs. Several hundred bundles declaring version ranges against each other means something has to compute a consistent wiring: which exporter satisfies which import, at which version, with no conflicts anywhere in the graph. That is a constraint problem. It is solved at startup, it has to succeed completely before the first window can appear, and the user-facing name for that work is a splash screen.

The bill for extensibility is not paid where it is incurred. The plugin author gets the reach, and the reach is worth a great deal to them. The resolution work, the resident memory, the startup time and the risk that one contribution makes the entire window stop responding land on every user of the application, including the large majority who installed nothing extra and use four of its capabilities.

So, the sentence the rest of this rests on. An extensible platform accumulates the cost of its own extensibility, and it collects that cost at startup, from every user, for the benefit of the few who extend it. None of that is a mistake or an oversight. It is a price list, and Eclipse published it honestly for twenty years.

The workspace is a model, not a directory. Eclipse does not treat your project as files to be opened on demand. It maintains a model: the source parsed, the type hierarchy resolved, references indexed, the whole of it kept current as you type. The metadata folder people delete when things go strange is where that model lives. Opening a project is not opening files, it is materializing a model, which is exactly why it is an event rather than an action.

That is why the refactoring was so good so early. Rename, extract method, change method signature, pull members up, each propagated across every reference with a preview of what would change. Eclipse had that in the early 2000s, when the alternative in most languages was find and replace followed by hope. None of it is possible without a complete index, because a rename that silently misses one reference is worse than no rename at all.

Completeness and startup are the same number. A model that can answer any question about a project has to have read the project. Incremental builders keep it current cheaply once it exists, but it has to exist first, and the initial build of a large workspace is the admission fee for every question you will ask afterward. Eclipse chose to pay it up front and in public. The alternative is to answer fewer questions and open faster, which is a real choice and not self-evidently the worse one.

For roughly a decade an unreasonable share of commercial developer tooling was not a product at all but an Eclipse distribution with a vendor's name on the splash screen. Chip companies handed you a customized Eclipse and called it their development environment. Enterprise software vendors built their studios on it. Web tooling, C and C++ tooling, tooling for languages whose own communities had no interest in writing an editor, and Android's official tooling before it had a dedicated environment: all of it arrived as bundles.

The reason all of that happened is worth naming precisely, because it is the moat. Deep integration was scarce. If you wanted a tool that understood a language, could drive a debugger, could contribute to the build and looked like the rest of the environment, you had to be inside the process, and being inside the process meant being a bundle. Eclipse owned the only affordable route to being deeply integrated, and gave it away, which is how an ecosystem happens.

The problem it names is a multiplication. Supporting N languages across M editors means M times N integrations, each written against a different extension model, each maintained by whoever cared enough that year. That is why language support used to cluster: a language got excellent tooling in one environment and nothing anywhere else, and the environment where it got excellent tooling was whichever one had the most patient plugin authors.

The announcement was not one vendor. Microsoft announced a collaboration with Red Hat and Codenvy to standardize the specification, and that detail matters more than it looks. A wire format published by one editor vendor is a feature of that editor. A specification with a Java tooling vendor and a hosted development environment vendor attached is something other people can adopt without adopting your product, which is the entire difference between an interface and a lock.

The server is a separate process, which is the real change. Language intelligence moved out of the editor's address space. It can be written in whichever language its authors prefer, it can be slow, it can leak, it can crash, and the editor stays up and restarts it. Every failure that would have degraded a monolithic platform becomes a subprocess that went away and came back. That isolation is not an optimization. It is the thing being sold.

The multiplication becomes M plus N, and the incentive moves with it. Once the protocol exists, the group best placed to write language intelligence is the group that already maintains the compiler, and they write one server instead of one plugin per editor. That is why serious languages now ship an official language server as part of the project. Tooling stopped being a favor an editor community did for a language and became something the language is expected to provide for itself.

A language server answers questions about what you have open, and for most work that is the whole job. It is not an index that knows every reference in a very large repository. The gap is invisible until you need a whole-program answer: every implementation of an interface including the ones reached indirectly, a module boundary restructured across dozens of packages, a signature change propagated everywhere it lands, code generated against a model of the entire codebase. Those need something that has read all of it and kept it current.

The strongest version of this complicates my own story, so I will make it properly. Where a language server does have a complete index, it usually got one by wrapping a heavyweight platform. The main Java language server is Eclipse's own tooling running headless behind the protocol. Several of the best servers for other languages are, functionally, an entire compiler front end resident in memory doing exactly what the workspace model did. The protocol did not make the index cheap. It moved the index into another process and let you keep a light editor in front of it.

The specification's own history shows the direction of travel and puts dates on it. Type hierarchy, which is asking what extends this and what implements it across a project, entered the protocol in version 3.17, published in 2022, alongside inline values and inlay hints. Eclipse shipped a type hierarchy view around two decades earlier. That is not an argument that the protocol is behind. It is a measurement of how much of a heavyweight IDE's capability turns out to be whole-program questions, and how long those take to standardize across editors that do not even agree on what a project is.

What makes the loss hard to argue about is its shape. Nobody is shown an error saying this refactoring is unavailable. They are shown an editor where the rename is simply not offered, so they do it by hand across the files they can think of, and over time they stop attempting the restructurings that would need a confidence they no longer have. It shows up as work not attempted, which is the one category no tool can measure and no survey knows how to ask about.

So here is the ground this takes from me. I have spent the piece describing Eclipse's weight as the honest price of a capability, and I have to accept that for a large statically typed codebase under continuous restructuring the heavyweight environment still wins outright, that the protocol has not closed that gap, and that a great many teams gave the capability up without ever deciding to. What I would not concede is the direction. A boundary you can improve behind is worth more than a platform you cannot leave, even during the years when the thing behind the boundary is worse.

Look for the seam a protocol could run along. The competitor that wins usually does not build a better platform, because building a better platform means paying the same bill with less experience. It finds a boundary inside the existing platform, writes it down, and lets everyone implement both sides independently. Language intelligence was such a boundary and it had been sitting in plain sight since the first integrated environment.

I should be careful about how tidy this is. Eclipse's decline has causes with nothing to do with architecture: a governance model that made the default distribution a committee product, an interface that aged in public while the alternatives were being redrawn, and the ordinary fact that a generation arrived after the question had already been settled by whatever their first employer had installed. Architecture is the explanation I find most interesting, and that is not the same as it being the largest term.

What stays is the shape. A platform's power and its weight are one property measured from two sides, and whoever eventually unbundles it does not need to be better at building platforms. They need to find the single line inside yours that can be written down as a message, publish it so anyone can implement either end, and then wait. Eclipse spent twenty years making it possible for anybody to reach into the IDE. Somebody drew a line through the middle of it and reached in from outside.