While comments are certainly an important part of code documentation, and become much appreciated later on during maintenance and support phases of an application, they can be quite tedious to write, particularly in cases where you are documenting the obvious. In some situations you may be able to get away without writing comments for these types of methods, but in some situations your IDE or Javadoc report may still flag those methods as missing Javadoc comments and so it’s best to put them in anyway.

JAutodoc is a super Eclipse plugin for assisting you with writing comments. It comes with customizable method prefix mappings to comment phrases. For example, if your method begins with ‘add’ the phrase ‘Adds the’ will be placed in the comment. Thus, if the method name was ‘addEmployee’ the comment text would be ‘Adds the employee’. If the method were ‘isActive’, the method text becomes ‘Checks if is active’. All of the mappings are customizable from the plugin properties.

It can be set to use the Eclipse comment formatter, to replace the existing Javadoc or to complete it, as well as optionally add a todo annonation to it for future review. It fills out all the parameters passed and return parameters as well.

You can highlight an individual method and right click and choose JAutodoc from the menu, or select the entire source of the class and complete all the javadocs. It saves a lot of time getting the skeleton of your javadoc comments in place, allowing you to focus your commenting time and energy on writing meaningful descriptions where necessary.

To read more about the plugin and download it, see the JAutodoc web site.

I haven’t tried this yet, as on my current project we are deeply emmersed in Jasper Reports, but this will be interesting to take a look at.

Eclipse BIRT 2.0 Release

While I’ve been working in Java for the past 7 – 8 years, I definitely do not label myself as a Java -loyalist. I’m an Internet Application loyalist, and I want to do whatever it takes to get the apps done right and done fast. I agree with Andreessen’s statement that Java’s complexity has grown by leaps and bounds. The learning curve has become too steep, and many IT departments are finding it difficult to train an employee in all the technologies needed to go in and make a simple change to a module on their web site. When you have to know Spring, Hibernate, Struts, Tiles, SQL/RDBMS, and make edits within all these technologies in order to add one field per the client, it becomes utterly ridiculous.

It may be fun for us developers, and we love all the separation of the various layers of the application, but it’s no good for the client, and that’s who pays us. So we as Architects, Analysts, Designers, and Developers better come up with something that provides for much faster turnaround time.

If you haven’t yet read about Groovy, here is an article on Sun’s web site about it. I like the idea, as you should probably have guessed from my complaints about Java. Just looking at some of the examples reminds me of the fun years I had developing simple things in Perl. No, this won’t replace Java development in general, but it could be used for some very simple applications, from Unix scripts to simple web sites.

The report I’m working on now requires a running count for each line item within a group. Fortunately, Jasper has an easy way of doing this, by simply using $V{groupname_COUNT}, where groupname is the name of your group.