And now, a little rant. Eclipse is, first and foremost, a Java IDE. It tries very hard to be extensible and flexible, so the Java functionality itself, like everything else, is a plug-in, or rather a set of plug-ins called the JDT (Java Development Tools). Very good.
But unfortunately, there is a lot of code in the JDT that does quite generic things, like showing the error markers in the Project Explorer, or on the editor tabs. I often find myself digging through the JDT sources to figure out how the big guys do things, only to find out that they implemented quite common functionality in the JDT that would also benefit many other language-specific plug-ins. Other plug-in writers who want to use this functionality have a choice: either have their plug-in depend on the Java Development Tools, or reproduce all the code in their own plug-in.
Depending on the JDT plug-ins would be a shame, because we’re trying to build a Haskell IDE here. Even though most Eclipse users will have the JDT already installed, we do not want to have to package it with an eventual “Hasklipse” (I hope that name doesn’t stick…) distribution containing an Eclipse platform for Haskell development. Moreover, it is not even always possible to use the classes from the JDT directly: often, they subtly depend on some Java-specific treat.
The alternative, copying and pasting to your own plug-in, is therefore often the best option. It is not pretty, but it works, and it allows you to customize the code to fit your own plug-in better. But I sure wish it wasn’t necessary. For a poor Haskell plug-in developer, even more modularity would be very welcome.
EclipseFP GSoC '09 
July 1, 2009 at 00:37
I feel your pain. I did some work a while back on a Clojure plugin for Eclipse and came to the same realization, after pouring through the sources of several other languages’ plugins for inspiration. I won’t name names, but it seems to me that almost everyone doing serious 3rd party language plugins pastes code heavily from the JDT, or bears the shame of linking to JDT’s internal naughty bits.
Perhaps this will get better with projects like LTK, Xtext, etc. over the long term? I am tempted by this vague idea of making Eclipse metacircular with Xtext.
July 1, 2009 at 00:51
More and more features have been pulled from the JDT into the Platform and are available for all language impls to reuse.
Some things could be modularised better, but overall 3.5 is pretty good.
And for your example: I’m not sure what you mean – if you create an error marker on an IResource, it’ll get shown in the Project Explorer (at least if you set them to type Error or Warning). Not sure how you want to make that any easier;
July 1, 2009 at 01:08
Keep in mind that anything the JDT exposes becomes API and thus must be maintained as backwards-compatible “forever” (or at least until e4, whichever comes first). Thus, moving something out of “internal” status limits the team’s freedom to refactor and/or alter the design, eliminate dead code, and other such “drastic” changes.
The culture/philosophy of the “framework” teams on Eclipse projects (those that primarily produce plug-ins that are intended to be extended or used by other plug-in developers/teams) is EXTREMELY conservative when it comes to exposing things as public. Like you, I have been frustrated more than once by that philosophy (usually in SWT or JFace code), but I do understand their reasoning. It is a difficult balancing act that they must perform and I respect that; however, like you, I wish that sometimes they’d lean a little more towards the “enabling” rather than”directing” mindset, as described by Martin Fowler (http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.html).
July 1, 2009 at 09:32
Instead of pasting it into your own codebase, wouldn’t you be better off pasting it into a small seperate plugin and have your Haclipse depend on it? That way you are building the first step into sharing sections of the JDT across plugins.
July 1, 2009 at 11:24
Good to see that I’m not the only one who is annoyed by this. But I also largely agree with Eric: what the Eclipse folks are doing is a tricky balancing act, and I do respect that.
murphee: It’s org.eclipse.jdt.ui.ProblemsLabelDecorator that causes the problem decorations to appear, but only
if (obj instanceof IJavaElement).Marten: Maybe. But I, being a quite inexperienced Eclipse developer, would not be the right person to start such an effort. Even though I try to read all relevant docs carefully, most of the time I’m not sure whether I’m doing things “the right way” and am mostly guided by what works and what doesn’t. Moreover, I am hardly the right person to decide upon the public API of such a common plug-in.
July 1, 2009 at 15:46
I have ran in such situations more than I care to remember. However there’s very nice thing about Eclipse: community, if you like to contribute you just ask for it by creating a bug; provide a patch and comments on how it would benefit as a public API.
July 1, 2009 at 21:34
While certainly not perfect, the Eclipse project DLTK may be what you are looking for: in essence, the JDT generalized to provide a convenient base for the development of many different language editors.
July 2, 2009 at 18:03
Eclipse is, first and foremost, a Java IDE. It tries very hard to be extensible and flexible, so the Java functionality itself, like everything else, is a plug-in, or rather a set of plug-ins called the JDT (Java Development Tools).
I know where you are coming from, but I think you got this backwards. JDT is the best Eclipse-based IDE I know, but Eclipse was not built to be a Java IDE. Eclipse has always been about being an extensible platform (initially for IDEs, later expanded to be a RCP). JDT helped a lot to drive the evolution of Eclipse, but if today it was completely dropped, we could still develop for the Eclipse using another OSGi supporting Java-IDE (PDE would be missed though).
July 8, 2009 at 10:38
[…] Little rant on modularity […]
July 15, 2009 at 17:40
I really wish this little dialog fields module was public:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/wizards/dialogfields/
Really nifty set of widget combinations.