Deutsche VersionEclipse E4: A Critique
At work, I’m developing on a large internal application based on the Eclipse Rich Client Platform, which is basically the foundations of the Eclipse IDE made available for everyone else, too. As platforms go, it’s alright, I guess, but it does have its share of weirdness. For example, why do I have to dispose [colors](http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fgraphics%2FColor.html) once I’m done with them!?[^1](#) But with a healthy amount of helper functions, it’s all manageable.
[^1](#): For compatibility with 8-bit indexed displays. Since this is nowhere near a target for our app, I generally don’t dispose colors.
We’ve recently finished porting the application from Eclipse 3.7 to the 4.x line (specifically 4.5, planning to upgrade to 4.6 once it’s out). This may seem a bit late, considering that the first official release of that line, Eclipse 4.2, came out four years ago. After working with the new code, though, I’m starting to think that maybe we’re still too early. Eclipse 4, or e4 for friends, features a massive rewrite of some of the core parts of the platform. And I think that it’s unfinished and in parts rather misguided.
Unfinished Business
Editors are gone, as are views, replaced with generic parts. I could get behind that, but gone as well are editor inputs objects. So telling an editor what file to open and making that decision persistent requires custom logic - and possibly a lot of that if you relied on the flexibility editor inputs gave you. You might see the MInputPart in the documentation, but apparently that was never implemented and is now deprecated. I think the only reason it’s still in the documentation is to taunt people. Of course, even if it did work, an URI based scheme only brings you so far if you have an editor that is supposed to receive objects from many different sources.
Many classic services have no e3 equivalent. For example, the IFocusService lingers around, but it’s very unclear whether I can rely on it once we’re e4 only.
No documentation
The documentation for new e4 specific stuff is largely missing or automatically generated and not helpful at all. I dare you to find any information in the documentation of [MToolItem](http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fe4%2Fui%2Fmodel%2Fapplication%2Fui%2Fmenu%2FMToolItem.html) that isn’t obvious from the method names. What’s particularly missing is overview information: What do the different parts in the application model actually mean? What’s the difference between a MPart and a MPartDescriptor, and which one do I need? What’s the lifecycle of a MPart exactly? What is the point of context activation?
The best source of information are the rather terse [Vogella tutorials](http://www.vogella.com/tutorials/eclipse.html), but these are task-oriented, not concept-oriented. If you want to do something that no Vogella employee wanted to do yet, you’re largely on your own.
Loose coupling. Like Spaghetti
I like the idea of dependency injection in theory, but I’m not sure about the practice. And I have no idea whether that is an Eclipse thing or not, but it still irks me.
The basic idea suffers from two problems: You want all dependencies passed in externally instead of getting them from some global nebulous set of singletons and what not. That’s valid. But you also don’t want gigantic constructors with 200+ arguments for complex classes. Not that you should have classes like that anyway, but a complex editor implementation can reasonably require access to most services Eclipse provides, even if it is just passes them on to helper objects.
The solution is more or less to put all that global state in a map, then pass that map as the argument to every constructor, and allow it to create new versions of the same map internally. Only they chose a more complex version that also has a lot of syntactic sugar, to make sure it runs really slowly. Eclipse has a reputation to maintain, after all.
As a result, you still have no clear idea what part of the application needs access to what unless you search for type names, and now you also have no idea where it’s coming from. It’s not so much that it’s bad per se, but it definitely does not realize the advantages that dependency injection was meant to provide.
And while we’re here already: The way event handling is done via dependency injection is just insane.
Horribly bad ideas
I honestly don’t get the application model, and not just because there is no real documentation on it. I have no idea why it’s here at all, what problems it’s meant to solve, and how it thinks it has solved them. And most of all, I don’t get why so many Eclipse developers are so damn happy about it. “Look at this”, they go, “I change the window’s title in the application model, and the window’s title actually changes! And I can even do that… at runtime!” And then they’re surprised when I don’t applaud.
But hey, whatever, I’ve been able to write helper methods and helper classes to get around any problem in e4 yet. The real problem of the application model is that it seamlessly merges user state and declarative application code into one giant ball of mud. And then it makes that mud persistent, which is just as unpleasant as it sounds.
Because suddenly, changes in user state get the opportunity to conflict with changes to declarative application code. Will my new context menu show up if the user has moved any editors around? For that matter, will my old context menu continue to show up? Surprisingly often, the answer is no, and never for any good reason I could discern. By merging what absolutely had to stay separate, they built a giant bug-producing machine.
And they know it. The closest thing to an official recommendation is to [simply disable persistent user state](http://www.vogella.com/tutorials/EclipseRCP/article.html#tutorial_clearpesistence). Only during development, in theory, but they sure don’t provide a better way to deal with the problem once I release an update of my app. In my opinion, this wins the very highly contested price for least user-friendly thing ever done in Eclipse.
Oh, there’s a workaround, but it’s one that nobody will tell you about, and it’s the most WTFy thing I ever implemented, to the point that I still can’t quite believe that this is what it takes. But I’m doing it anyway: I wrote my own code for serializing the application model to an XML file and back, making 100% sure that I only touch the parts that the user can change (i.e. what editor is where), but not the parts that are declarative program code. It’s been a few months since I implemented this thing, and I still sometimes wake up in the night and shout “There must be something better! Some simple flag I missed somewhere!” Do drop me a line if you found it.
Handlers
Finally, command handlers. The new way of writing them is good. Having the validation logic in the handler itself as opposed to an XML file somewhere is better. Good choices all around.
Less good: Why can I have only one handler per command per part? I kind of need several different “delete” handlers for different parts of some more complex editors, thank you very much, and I have only limited interest in creating one giant monster handler that contains the delete logic for absolutely everything. Of course it’s possible to work around that; I’ve managed to work around every little thing in e4 except the application model weirdness so far. In this case, write one handler that creates an internal list of other handlers, then asks each whether it can execute and the first one to shout yes gets to do the job. But I don’t get the logic that says I have to write stuff like that.
I also don’t quite get why some handlers exist and others don’t, but that’s less of an issue.
No tool support
Why is it that so many new things are released without good tool support? Do people somehow think that’s optional? I don’t see it. For example, to port from e3 to e4, there is an awful lot of getting information out of one XML file, translating it, and putting it into a different XML file. It’s boring, tedious and straightforward. And the one and only tool I found for that is one I wrote myself (No; you can’t have it. Nothing personal, but I have no idea what hoops I’d have to jump through to get something developed internally released as Open Source here).
The tools that do exist regularly stop accepting copy and paste and have no useful search. Most of them aren’t part of the platform proper, but require a separate download. It all feels very experimental. I went back to editing the XML files by hand.
Overall
Overall, e4 is still very far from done, and that’s frustrating. But in a few places, even the core is wrong or at least questionable. And while it looks like Eclipse 4.6 will solve a few issues I’ve been having (Generics for Databindings! Hooray!), they don’t seem even interested in solving the big ones.
Written on January 22nd, 2016 at 09:43 pm
