code generation : Java Glossary

Code generators can crank out simple applications like hotcakes, however, in the real world, applications are never completely straight forward. How do you handle the logic beyond what the stomper can do?

• You extend the stomper. This implies the stomper is code you maintain and extend as needed. It may start out as one-size-fits all but quickly becomes specialised to your company’s problems. This is the approach I use to generate all the ANT scripts for my website. It is also the technique I use to generate all the HTML boilerplate. If you don’t have the source code, or can’t understand the stomper code because it is poorly documented or made of spaghetti, you cannot use this approach. In general, this approach will be most satisfactory since you can tune it precisely to your needs, and you can port your entire system to new platforms or even new languages. You are not dependent on any other company to stay in business and keep maintaining your tool. You understand your own code far better than you will ever understand anyone else’s. It won’t have complicated features you don’t need. Further you save the bloated costs of general purpose report generators.
• The stomper provides a toy script language to write your extensions. I detest this approach. Frequently the toy language is not capable of doing the work you need to do. It is typically buggy and poorly documented. You now write code that can’t be reused in any other context.
• The stomper provides stubs where you can write Java code that will be inserted. The problem with this approach is you need an intimate knowledge of how the stomper works to know what you can and cannot do in each stub. Further, if there is no stub for the task you need, you are up the creek. It is difficult to arrange communication between different stubs. You waste more time trying to fool the stomper into generating the code you want than it saves.