- What Is Code Generation?
- Passive Code Generators
- Active Code Generators
- Attribute-Oriented Programming
- Introducing XDoclet
- Working with Actively Generated Code
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Working with Actively Generated Code
So far, we have covered the reasons why code generators are a valuable tool for the rapid developer and how code generation techniques can be applied to the development of J2EE solutions. In this section, we examine a set of guidelines for working with actively generated code.
Guidelines for Code Generation
Although active code generators such as XDoclet increase productivity on a project, the code generated must be carefully managed as part of the project build process. Failure to achieve this aim can result in confusion among developers as to which code can be modified and which code is the responsibility of the generator. Confusion of this nature negates the rapid development advantages code generators offer.
The guidelines look to avoid this confusion, enabling the full benefits of code generation techniques to be achieved.
Generate Code as Part of the Build Process
Actively generated code is a disposable commodity. It can be quickly reproduced at near zero cost. Consequently, making the code generator part of the build process offers an effective method for ensuring all built code is an accurate reflection of the metadata upon which it is based.
Executing the code generator only when it is believed the underlying metadata has changed presents the risk of the code becoming out of sync with the source metadata. This risk can be easily mitigated by ensuring all code is generated afresh as part of a regular build process.
Keep Generated Code Separate from Other Source
To safeguard against the problem of a developer accidentally modifying generated code, it is good practice to have the build process generate the code in a directory separate from that of other source. In this way, the generated code is treated as if it were a compiled binary.
Alternate source directories are useful in this scenario. They enable the generated source to be cleanly separated from handwritten code and allow an IDE to correctly recognize the code as part of the application.
Do Not Place Actively Generated Code Under Source Control
Placing code that is actively generated under source control invites developers to mistakenly modify code that will be overwritten the next time the code generator is run. This practice also makes the build process complex, because it must integrate with the source control system.
To avoid these problems, generated code should not be placed under source control. Instead, place the metadata used by the code generator under source control if this is possible. Likewise, if the code generator has been produced inhouse, it should also reside under source control. With this approach, the build process gains an additional step:
-
Compile the code generator.
-
Run the code generator against the metadata.
-
Build the application from all sources.
It is possible to forego building the inhouse code generator, instead relying on previously built binaries. However, this approach risks failing to pick up on rule or pattern changes within the generator, which might otherwise impact the code generated. While compiling the generator may slow down the build process, it has the advantage that all generated source is guaranteed current.
Be Wary When Using Refactoring Tools
Refactoring tools have become a popular feature in many IDEs. They allow the software engineer to make sweeping changes to the code structure across the entire code base. They are a powerful development aid and are used extensively on projects adopting an agile development process.
Refactoring tools, however, show little respect for the distinction between generated code and handwritten code. The impact of a refactoring exercise can easily result in generated code being modified inadvertently by the tool. This is a problem, because the amended code will be overwritten when the code generator is next run.
Where an inhouse code generator is used, the responsibility falls to the developer to ensure the code produced by the generator reflects the changes applied by the refactoring tool.
Attribute-oriented programming tags, as used by XDoclet, are also vulnerable to this practice. As XDoclet tags are embedded within comments, they are usually overlooked by refactoring tools. Consequently, the generated code becomes out of step with the rest of the code base once the doclet engine is run.
Fortunately, the Java compiler can help to detect such problems, as can a rigorous testing schedule. Nevertheless, caution must be exercised if refactoring tools are to be used in conjunction with active code generators.
Avoid Mixing Active and Passive Code Generation
The guidelines outlined so far have focused on ways to avoid actively generated code from being inadvertently modified by developers. Unfortunately, the need to modify actively generated code is sometimes inescapable.
When this situation arises, several options are available to protect the modified source from being overwritten:
-
Modify the code generator.
In preference to updating the code, if an inhouse generator is used, modify the code generated to reflect the required code changes.
-
Extend the generated code.
The object-oriented paradigm offers many ways to extend the functionality of software components, including inheritance and composition. In some cases, the Decorator pattern may also prove effective. Consider these software engineering approaches before modifying any generated code.
-
Use merge tools.
A suitable merge tool, as is commonly used with merge-based source control systems such as CVS, enables modified code to be integrated with generated code. However, unless a trivial merge is the result of the union of the two code versions, a manual merge with the tool is required. Such an automated build system would be extremely cumbersome to implement.
-
Don't do it.
Finally, modifying actively generated code is problematic at best, regardless of what methods are used to manage the result. Think hard before taking this step, and proceed only if all other options have been exhausted.
The last point cannot be overemphasized. Having to guard against accidental code loss in the modified code adversely affects the productivity gains offered by active code generators. Keep it simple, and leave the generated code alone.