The eclipse committers responded to my bug right away, early in the morning after I submitted it. Here's the response:

------- Additional Comment #1 From Dirk Baeumer 2005-08-26 06:31
[reply] ------- John,
I really encourage you to investigate further in this topic and try to provide a
patch for it that can be included into Eclipse.
I favour solution one. The only porblem I see with it is that
${type_declaration} can represent a type containing more than just an empty
body. For example if you check any of the "Generate method stubs" options on the
wizard how will this go together with the type body you are providing. So you
need more than just one variable. The templete has to look more like this:
{$ype_declaration_header} {
// A comment
{$main_method}
}
So we need variable for the main method, constructor and abstract inherited
methods as well.
The "procedure" for getting code into Eclipse is as follows:
- the code should be provided as a patch against a reasonable "latest" version
of the Eclipse code (e.g. against the latest integration build). The code
can be found in the Eclipse CVS repository. The project you are looking for
is org.eclipse.jdt.ui (some basic steps how to get the source can be found at
the end of
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-ui-home/r3_2/main.html#Overall_Planning)

- you have to provide test cases as well. The tests has to go into
org.eclipse.jdt.ui.tests
- all code patches have to be provided as attachments to bug reports. We can
use this bug report for this
I am not the expert for code templates and Martin (the expert) is currently out
of office. But as a starting point you might want to have a look at the class
StubUtility which is the facade for all template based code generation.

- - - - - - - - - - - - - - - -

I read it later that day, and was excited they were so positive about the idea. Especially interesting was Dirk's idea about template variables that show where to put the generated methods inside the class. I had also spent some time considering how to place generated methods, but hadn't considered using template variables to indicate their location.

In considering how this would work, I started getting uneasy about the user experience with mutually exclusive template variables and with the template variables for the positions of methods inside the class being coupled with one declaration template variable and not another. This implies some complex and confusing user experience, so I chewed on it for a while and came up with another idea, expressed in my next comment to the bug, composed here.

- - - - - - - - - - - - - - - -

Dirk,

Thanks for your reply, and I appreciate the encouragement.

I studied the source for a few sessions and thought about your ideas of other template variables to show the location of generated methods. That makes things harder to implement, but it will definitely make a better user experience. The way I had originally thought of it (and the way I still want to implement it as a first iteration before I take on the additional complexity) would have the comments generated in the right place inside the class, but all the stub methods would just be generated at their default location, which I'm assuming (hoping) is at the top of the method. Then, for a second iteration, I'd add the template variables to indicate where the different types of generated stub methods should go, and allow them to be interspersed with the comments.

After considering your suggestions and my original ideas for a while, I became more uneasy about the user experience if we allow alternate versions of the template variables (${type_declaration} and ${type_declaration_header}) and then offer other template variables that the user has to be aware are coupled with only the ${type_declaration_header} version, and further require the user to understand they have to manually place their class brackets. It just sounds like there are a lot of failure cases and a lot of potential user confusion.

What I came up with after some headscratching is a new suggestion. Instead of offering an alternate ${type_declaration} version, why not have ${type_declaration} insert a user-definable "sub"-template like ${filecomment} and ${typecomment} currently do? That way, the template variables available for showing where the generated method stubs go in the class can be offered only in the ${type_declaration} editing context, and we no longer have to worry about the users understanding how they are coupled. Along with that, the code behind the type stub generation can put in some protective default behavior if the user forgets to add one or both brackets (default placement is right after the class declaration header for the open bracket, and at the bottom off the template for the close bracket). Finally, the default definition of the "sub"-template can be set to the current behavior, taking care of any backward-compatibility user expectations.

In addition, this leaves open the future possibility of allowing users to define different templates for the different types: interfaces, classes, annotations, enums.

Let me know if this sounds like a plan, or if anyone over there has any further suggestions, and I'll get started.

As far as process, I will get a CVS download set up. Up until now, I have been downloading the source from your download site, but that was just to do some preliminary surfing. I like to do test-driven development, so I'll try to get some bare-bones test cases written first. That way, I can work through the logistics of building and running the tests before I get very far. Or perhaps I'll just try to mimic the current behavior with the new user-definable class template variable, so the current test cases will run.

- - - - - - - - - - - - - - - -

That's all for tonight - next, as promised, I will attempt to get a CVS build up and running, and to run the current JDT tests...