Erich Gamma

+ Follow
since Nov 08, 2003
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Erich Gamma

Given all the recent Eclipse questions I just wanted to mention that there's still time to get to EclipseCon 2004 (Feb 2-5 in Anaheim). Most of the Eclipse open source developers will be there. In addition, the program is cool (but I'm biased ).
EclipseCon Program
EclipseCon Program Chair
(fyi - I wouldn't have posted this message without getting the permission from Thomas Paul)
oops, just noticed that I didn't give you my answer on this question: first question to our authors would be, what motivate you two masters of software development to write such a book - on Eclipse?

I wrote the book because:
* by now everybody knows that Eclipse can be used as a Java IDE, but Eclipse is more than that. It is a general platform for building all kinds of things. Eclipse is fun to extend and therefore I wanted share this with others with a book that focusses on writing plug-ins.
* I knew that writing a book will be intense, so I wanted to make this book fun for me as well. Working with Kent is fun and I always learn something when I program with him. I was more than happy that he accepted my invite to work on this book with me.
* This book was an opportunity to capture things I've learnt and worked on during the last ten years (design patterns, JUnit, tools, exploring large oo-systems).
I see Dan - you are not giving-up that easily This is fair since you and the other authors wrote over 800 pages on Eclipse (and I have a high respect of your book).
Let me give you another example for why I'm not convinced that you need to enforce an API with selective exports. Not exporting a class is a similar decision as declaring a class final. The decision has the same impact for the client. They have to accept it and there is no way to work around this decision.
Here is the example, in an earlier version SWT declared most of its widget classes as final. This has turned out to be too harsh, there are cases when you would like to subclass even if the original implementor didn't see a need for it. Therefore this was changed to "intent final". This means the class is not declared as final, but in the Javadoc/API it is expressed that the class is not intended to be subclassed (we have a sidebar on this in the book). This makes the intent clear, but clients still have an option to work around your decision. This was a lesson to me that declaring the intent is more important than enforcing it. Declaring a class in an "internal" package makes the API intent clear enough.
BTW, I fully agree, that a checker tool for finding internal class uses would be really useful. I'd use it to validate a plug-in, but I wouldn't use it to enforce which classes are visible to clients.
Let me just return the kisses and say thanks for the opportunity for communicating with all of you.
Here are some concluding remarks:
* about asking questions on eclipse - if you have more questions on eclipse than please don't hesitate to use the newsgroups on In this newsgroups you not only get answers from Kent and me but from the entire Eclipse community. In particular if you ask your question wisely and show that you have invested into a problem then you will get a good answer.
* on reading the book - if you read the book and get stuck on the interlude in chapter 12 then please read on. This chapter is the "black-belt-chapter" in the book. Kent and I rewrote this chapter multiple times, but the problem we describe is in the same complexity range as meta-level programming (testing a JUnit flavor with JUnit involving running 3 Java VMs). The complexity level drops aftwards again and it will be an easy read with what I hope interesting topics.
Nope - JDT doesn't know about plug-ins - complain one layer above in PDE
Hi Dan,
(glad you like the book)

Do you believe it is too restrictive to list only those non-internal packages in the <export> clause? Is it overly draconian to only list interfaces?

Selective export is problematic since you only get informed about the problem at run-time and not at build-time. I therefore consider selective export to be "draconian". The naming convention for packages makes the intent explicit enough. Not exporting any classes at all is OK - if you want to express that a plug-in isn't meant to be extended.
This is correct - the focus of our book is about the fun of extending eclipse.
If you are interested in MDA then you might want to check out the Eclipse Modeling Framework EMF.
Eclipse provides all kinds of searching and there is also a call hierarchy view.
In addition there is a plug-in that integrates JDepend.

I am looking at using Eclipse not for IDE development (though I have done some of that) but as the base for a more standard client application.
The drivers for me are the modular approach of plugins and (I am hoping!) easy distributed maintenance through its remote update features.
Now I know that the Eclipse 3.0 development is going through the pain of seperating the core framework from its IDE roots to allow just this. (Shame on me - I have not had time to follow the 'M' releases to see exacly how far they have got).

The generic workbench will make its first appearance in M5 which will be out Nov 21.
Ed Burnette has already made an example available at:

Will this change significantly affect plug-in development.

the plug-in development story will be the same, you can now just use plug-ins for general application development. The API breakage is minimal (some packages got moved, and some methods got replaced). We have converted last week and the migration is smooth.

Or more pertinently for the authors, should I wait for edition 2 ("Now including Eclipse 3") of their book?

I wouldn't wait with starting contributing to Eclipse until version 3... you want to start NOW!
Lasse's answers above are all correct.
I just wanted to point out that the Eclipse team is also working on providing a "generic workbench". This is the Eclipse workbench without any IDE specific UI items (like Build). When building applications on top of the generic workbench you can not only leverage SWT but also the plug-in mechanism, workbench layout etc.
In fact we just went through this migration last week and a first cut is available in the 3.0 stream.
Actually Eclipse is architected since day one into a Platform and a separate JDT layer. So you could always use Eclipse as an application platform. What we do in 3.0 is to simplify this even further, i.e., clients don't have to disable or remove plug-ins etc.
yep - we don't cover integrating a debugger, all we do in the book is to provide some forward pointers to the Java debugger that is integrated in the Eclipse SDK.
Eventually there should be a an article with an example debugger integration. However, whenever we think we have an example for the article (e.g. integrate a ruby debugger), then someone else has already done it<g> So it cannot be that hard... see for example This is an Eclipse ruby plug-in that contributes a debugger.
If you want to learn more about implementing debuggers then you might want to consider attending EclipseCon 2004 ( There will be a technology exchange on how to implement a debugger.
I recommend that you check-out the 3.0 plan:
It provides you with the release dates and spells out the compatibility rules between 2.1 and 3.0.
I remember that at an Eclipse Code camp Hans Doktor presented the JBoss IDE (which is an eclipse plug-in). It had a really nice XDoclet integration for code assist/completion.