Power-using Eclipse 3.0M8 with Templates

Eclipse is one powerful IDE. I’ve been using it for a few weeks and in this article, I will be reviewing a few of the features that make it such a wonderful tool.

I’ve been a Vim user for the longest time. Vim has always been a great development tool, but with the complexity of Java development nowadays, I’ve found that IDE’s are no longer candy: they have become a necessity.

I’ve used a number of IDE’s. My first love was Forte. Then, someone explained to me that Forte was based on Netbeans. So I tried Netbeans and I liked it. It was my main IDE for almost two years. But I was still using Vim periodically because some editing was easier in Vim than in Netbeans.

Then, one of my colleagues (Michel, it’s all your fault!) introduced me to IntelliJ IDEA. I was hooked! IntelliJ remains my favourite IDE, even more than Eclipse. But I don’t have the funds to pay for a license, so I looked for the next best thing.

I’d been hearing a lot about Eclipse so I decided to try it. My first use of Eclipse was during the 2.1 era. At that time, it had a bad bug which froze the interface when using cetain versions of GTK+. But late last year, the 3.0 releases began showing up and the bug was gone. I started looking closely at Eclipse and I liked what I saw. I adopted it and since then, I’ve been trying to locate all the little things that can speed development time.

This isn’t an introduction to Eclipse, it doesn’t cover every aspect but it covers enough nifty features to hopefully make you want to give it a spin.

Automate it!

The greatest element of modern IDE’s, I find, is the automation of a lot of repetitive, boring and not very educational tasks. For example, creating new classes (screenshot). It’s always the same: insert the package declaration, put some Javadoc, the class name and maybe a couple of other things.

Most IDE’s have facilities to automate creation of classes. But what if the way it creates them is not the way you need them to be? For example, I have a client who likes his code to look like this:

/***********************
 * Class: ClassName
 *
 * © 2004, This company, All rights reserved
 **********************/

package com.foo.package;

/**
 * Class: ClassName
 * 
 * This class does something.
 *
 * Created by: My Name
 * On: Creation date
 */
public class ClassName {
    
    private c_iAnInteger;
    
    //////////////////////////
    // getAnInteger()
    /////////////////////////
    /**
     * Put some text here
     *
     * @return
     */
    public void getAnInteger() {
        return c_iAnInteger;
    }

    //////////////////////////
    // setAnInteger()
    /////////////////////////
    /**
     * Put some text here
     *
     * @javadoc
     */
    public void setAnInteger(int p_iAnInteger) {
        c_iAnInteger = p_iAnInteger;
    }

    //////////////////////////
    // aMethod()
    /////////////////////////
    /**
     * Put some text here
     *
     * @javadoc
     */
    public void aMethod() {
        ;
    }

}

As you can see, it’s pretty far from the Java Coding Standards. After creating one or two classes like that, I quickly saw that I needed to automate this or I’d lose my mind! That’s where Eclipse’s templates come into play.

Templates for classes

Templates are pieces of code that you tell Eclipse to use when it is generating code for you. You can use special variables that are expanded to insert appropriate code in the generated code. So in the end, Eclipse does everything that doesn’t require any thinking to accomplish, while you have fun writing real code.

This is what a template to generate the above class looks like:

/***********************
 * Class: ${type_name}
 *
 * © 2004, This company, All rights reserved
 **********************/

${package_declaration}

${typecomment}
${type_declaration} 

So what does all this mean? Chances are that just by looking at the above code, you have a pretty good idea what it does. Everything that is not a variable will be inserted as is. Variables look like this: ${string}. In the above snippet, these are the variables used:

${type_name}: This is the name of the class. In our example, it is expanded to ClassName.

${package_declaration}: The package declaration. Eclipse will generate the package declaration for you automatically, depending on where in your source tree the new file will be created.

${type_comment}: This inserts the comment for the class. Comments templates are defined separately, as we will see later.

${type_declaration}: This is the actual code for the class, with its name, the type modifiers (private, public, static, etc.) and any automatically generated methods.

Once the template for the class is to our liking, we can concentrate on the templates for the various pieces of code.

Templates for methods and comments

The next step is to generate methods. Eclipse allows us to define templates for various types of methods: getters, setters, other methods, constructors and catch blocks. For our purposes, we need to define getters, setters and methods.

This is the template for the getter:

return ${field};

and for the setter

${field} = ${param};

For methods, it’s slightly different:

${method_body}

Simple and elegant. Just how it should be! So now, when we ask Eclipse to generate a getter and a setter for us, it will create the body and the declaration for us. But what about the comment?

There is separate set of templates for controlling automated comments. There is support for seven types of comments: getters, setters, constructors, types, fields, methods and overriding methods. In our example, we need to change the ones for getters, setters and types. Let’s begin with types.

The comments for types are the ones that will appear when you generate a new class. So in our case, we want the comment template to look like this:

/**

 * Class: ${enclosing_type}

 *

 * This class does something.

 *

 * Created by: Laurent Duperval

 * On: ${date}

 */

The interesting element you see is ${enclosing_type} which is the name of the type for which the comment is being generated. In this case, it will generate ClassName for us.

Yes, I hard-coded my name. The templates are user-specific, not system-wide. Since I will always be the one to create the code, I’m hard-coding it. It is possible to have Eclipse insert your userid if you wish, however. Just use the ${author} variable.

Finally, the date is inserted. It will look like this: Mar 30, 2004. I’m not sure if you can change the layout according to your locale. That exercise is left to the reader.

For methods, the template will look like this:

//////////////////////////

// ${enclosing_method}()

//////////////////////////

/**

 * Put some text here.

 *

 * ${tags}

 */

The ${tags} variable automatically inserts the needed Javadoc tags for us. To complete the Javadoc, we will only need to add the text.

The comments for the getters and the setters are more problematic. Unfortunately, Eclipse doesn’t (yet?) allow us to insert the name of the getter directly in a comment. So using ${enclosing_method} is not an option. What to do? We have a couple of options: we can either convince our client to change the coding standars, or use editor templates instead of code templates.

The principles of editor templates are very similar to that of code templates, except that there is more interaction with the user. With an editor template, variables are filled in as you type instead of being automatically generated. In our case, it’s not ideal but it’s better than nothing.

Our editor templates are defined in the Editor instead of the code generator. As you can see in the screenshot, there are a number of pre-existing code templates distributed with Eclipse.

The code for our getter template will look like this:

//////////////////////////

// ${name}()

/////////////////////////

/**

 * Get the value of ${value}.

 *

 * @return the value of ${value}.

 */

public ${return_type} ${name}(${arguments}) {

    return ${value};

}

Ant the one for the setter will look like this:

//////////////////////////

// ${name}()

/////////////////////////

/**

 * Set the value of ${var_name}.

 *

 * @param ${arguments} the value to set

 */

public void ${name}(${arguments}) {

   ${var_name} = ${arguments};

}

In order to use these templates, we need to give each of them a name. Since I’m a graduate of the Business School of Branding and Unforgettable Marketing, I decided to call mine getter and setter. Now, to use the new templates, we type their name, followed by Ctrl-Space. Eclipse will insert the code for us and walk us through every variable defined in the template, so that we can give those variables a proper value. This screenshot shows how that looks. To change from one variable to another, we need to press the Tab key.

Admittedly, it isn’t as convenient as automatic code generation, but it’s better than typing everything by hand.

Now we are able to generate methods, getters and setters with the proper Javadoc. Yes, we’re almost there. The only thing left to do is to take care of those pesky variable names.

Automating variables names

When Eclipse generates a method for a getter or a setter, it capitalizes the first letter of the field and prefixes get or set to the getter/setter name. But a method that looks like getC_iAnInteger is just plain awful. Luckily, Eclipse can be told how to recognize different variable names.

If you have coding conventions that require you to use specific prefixes or suffixes when creating variable names, you can give Eclipse a list of those prefixes and suffixes. Then, when you generate a getter or a setter, Eclipse will strip your prefixes and suffixes and generate nicer-looking names.

You can generate prefixes for fields, static fields, parameters and local variables.

Now when you create getters and setters, pretty much all the boring work is done for you. A field that looks like c_iAnInteger will generate a decently named getter: getAnInteger().

Another bonus is that when you create new variables and press Ctrl-Space, your dropdown list will offer to create variables for you which contain your prefixes or suffixes. However, if you have many suffixes and many prefixes, this can be a problem more than anything else.

Now get to work

We now have all the pieces we need to make sure that our generated code conforms to a given coding standard. To use them, use the Wizard to create a new Class. Give your class a name, and watch how all that beautiful code appears before your amazed eyes. Then, add a new field and ask Eclipse to generate a setter and a getter for you (or do it manually if you created an editor template). They both should be generated with the proper formatting.

Finally, to create a new method, you need to type some code in the class, select the code you typed and refactor that code into a new method (by pressing Shift-Alt-M). Eclipse will replace the code by a method call. A new method will be created for you, the code you highlighted will be the body of the method, and the comments will look like what we defined in our template.

Templates are just part of what makes Eclipse such a great tool. If you aren’t satisfied with your IDE and you want something better, take Eclipse for a spin. You might just like it enough to adopt it. I know I did.

I used to be one of those l33t vi coders who sniffed at anything with buttons and menus and wizards. However, the latest generations of IDEs have made me a convert. I admit that I sometimes pull up Vim to do minor code changes to a Java class, but that reflex is fading fast.

As for IDEA, yes, I still miss it sometimes. I even find myself a bit annoyed when familiar keystrokes don’t give me the expected results. But if I can forget the name of the girl who gave me my first kiss, I’m sure I can forget all about the IDE I was using last summer.

About the author
Laurent Duperval has been a developer for the past ten years. He is a budding speaker and an active member of the OpenOffice.org mailing lists. He wishes he could contribute more to the OpenOffice.org and the Mozilla projects. He’s a big comics fan.

---

If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.