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


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


  • 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



  • 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
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo