Occasionally we get questions along these lines on the newsgroups:
Does anybody know how X is coded in Eclipse?
The simple answer is yes. Everybody can know how it’s coded. The source code is out there for all to see.
You have a couple of choices when it comes to viewing source code from Eclipse projects. If you want to do it the hard way, you can use the handy ViewCVS utility to browse through the various CVS and SVN repositories.
But nothing beats just having the source code included as part of your configuration. If you’ve downloaded the “Eclipse Classic” or “Eclipse for Plug-in/RCP Developers”, then you already have the source code for the Eclipse Platform, RCP, JDT, PDE, and more. If you need to see code from other projects, you can very often get the “source code” bundles from the project’s update site in the form of an “SDK” feature (many projects have opted to include their SDKs on the Ganymede update site).
Assuming you have the code, finding the right place in it can be challenging. This is where a handy little tool known as the “Plug-in Spy” comes in handy. When you invoke the Plug-in Spy (by hitting Alt+Shift+F1), it pops up a window showing information about the view/editor/dialog that has focus. The information includes such things as the name and package of the class that implements the view, and the bundle (plug-in) that defines it. From the pop-up window, you can even jump directly to the class definition via hyperlink. It’s pretty handy stuff when you’re trying to figure out how things are implemented.
Here’s what it looks like when you use it to find the class that implements the “Select Working Set” dialog (it can’t determine which bundle defines the dialog).
Having that first hook into the code is pretty handy, but it’s often better to see it in motion. Drop a breakpoint somewhere in the class (the constructor or perhaps a createDialogArea method is a good place to start), create a Debug Configuration that includes all the plug-ins in the “Target Platform” (see below) and launch. The Debugger will open up when your breakpoint is encountered.
You can merrily (or gloomily, your choice) step through the code to see how it is actually invoked.
I think this is screaming for a screencam demo. I’ll see what I can cobble together…
