Automated Code Generation (Page 4)

<< Introduction & Message Forum

<< Page 3 (How do Code Generators Work?)

Types of Code Generator

Code generators are distinguished by two main factors:

	The type of code being generated
	The approach taken by the generator to create the code

Another important distinguishing feature is the quality of the code being generated. Choosing a suitable generator for your project is like interviewing a prospective candidate to join your programming team. What is the programmer's background? What is their understanding of the issues involved, e.g. do they have a grasp of scalability, failover, transactions, security and so on? Are they actually any good as a programmer, i.e. do they write quality code - by that I mean clean, consistent, readable, efficient, extensible, bug-free?

The same questions are equally valid when evaluating a code generator. Essentially, a generator encapsulates the years of experience of the programmers that created it. It should, therefore, deal with "real-world" issues with a drive towards producing a system that will hold up under stressful conditions. If the generator's "spec sheet" boasts about its adherence to pure J2EE design patterns, or reads like a Java API list, then warning bells should start ringing.

APIs are about getting the job done: producing the software. So are code generators. That does not mean that the two are mutually exclusive, but it does mean that the importance of strict adherence to a standard set of APIs is lessened when you are using a good code generator. This is especially the case if you think of the code generator as being an API generator in its own right. This approach really liberates the project team to concentrate on finishing the project without worrying about time consuming "work-arounds".

For example, EJBs (particularly entity beans) have come under a lot of fire for being not entirely up to the job. Writing EJBs usually involves implementing design patterns on top of the standard EJB patterns to work around their limitations. This process can be time-consuming, repetitive and frustrating. Why not let the generator do the dirty work for you? If the end result is a robust, scalable system that matches your requirements, then it doesn't make a scad of difference what API the generator itself uses behind the scenes.

In other words, when choosing a generator, try not to get too hung up on whether the generator supports certain APIs (EJB 2.0, JDO etc) to get its job done. Concentrate instead on the quality and usefulness of the code that it actually produces.

What Types of Code Can be Generated?

The possibilities are limitless. It takes a keen eye to spot the subtler parts of a project that can be generated. However, the most common areas are:

	Database API (business objects or EJBs, transaction support)
	EJB deployment descriptors (often the most time-consuming part of an EJB project)
	SQL (DDL code for creating a database schema. This is normally generated from an Entity Relationship model, e.g. from ERWin or Rational Rose)
	XML processors (e.g. wrapping Java classes around an XML document)

Some more eclectic, but equally valid, uses of code generators are:

	JSP tag libraries and beans (can be used as a bridge between the JSP page and the data-access components, e.g. EJBs)
	JSP data-aware web page components
	Swing data-aware components (for client GUIs where a web-page interface is not required)
	Enterprise alerting API (e.g. monitoring a corporate database for aberrant conditions)

Note that the database API can be a set of EJBs, but does not HAVE to be. By applying EJB design patterns, a dedicated EJB-like server can be generated in minutes, totally tuned and optimised to your own database (without any generic overhead). In other words, rather than generating code that runs in an engine, the generator is creating the engine itself. This results in much faster, leaner, more scalable code (however if your project requires enterprise-grade features such as server clustering & failover, then EJB with a best-of-breed server such as WebLogic would be a better option).

What Approaches do Code Generators Take?

The diversity of approaches taken by code generators almost matches the number of applications they can be used for.

A problem that affects all database API generators, is that the meta-data provided by the database itself is really not as "rich" as it should be. Therefore, some additional information needs to be provided.

A surprisingly common approach is to use XSL to transform XML into Java source code. Whilst admirable, this approach is slightly problematic, in that XSL (which definitely has its place in other applications) can quickly become as unreadable as a Perl script. Therefore, the script used to generate the source code can quickly become difficult to maintain. This is a situation that is better avoided when generating an API - something that forms the core of your project, and therefore needs to be as close to "bug-free town" as it's possible to get.

Another approach I have seen is to use the JavaDoc tool to generate code from a heavily annotated skeleton class.

A more suitable approach is to use a properties file or XML file to contain the additional meta-data and processing directives. The JGenerator product uses a properties file. It also offers a "bootstrap" tool that generates the first pass of this file from the database meta-data, to give the programmer a head-start. Then the programmer can easily go in and fill in the gaps.

>> Page 5 (Advantages & Disadvantages)

<< Back to Programming