Code Generation Architecture: A Proposal

Codegen is Everywhere

• Entity from DB
• JSF from Entity
• REST from Entity
• Java Desktop App from DB
• UML
• Visual Web "InSync" codegen
• BPEL orchestration editor

Problem

• No incremental changes
• Loss of flexibility - hardcoded to a particular architecture/framework
• Can't afford one-off support for all popular frameworks

Proposal

• Take a look at how UML does it
  • Template-based (FreeMarker)
  • Supports incremental changes through unique identifiers in comments
  • Fine-grained control of what gets regenerated through directives

• Advantages:
• Templating allows flexible and multiple codegen from a single metadata definition (database, entities, pages, etc.)
• Takes advantage of popular open source templating language
• Uses standards-based scripting
• Allows user to refine what they want generation to look like
• Allows community to provide alternate codegen templates
• Allows us to support multiple architecures/frameworks within a single codegen implementation

References

• How UML supports incremental changes
• The UML code generation module is uml.codegen. The package of intereste is org.netbeans.modules.uml.codegen.

Challenges

• Writing templates is a black art
  • UML team is looking at how to improve this, but not their first priority
• This can mean major rewrites for some functionality
  • UML team was able to rewrite their codegen in 4 months

Proposed approach

• Do it with one project first (smallest one, or least risky)
• Refine, review, adjust, etc.
• Expand to other projects over time