Overview:

Whenever you find yourself writing repetitive code, but can't seem to factor out commonality, one possible solution is to use meta-data based code generation. This basically works by factoring out the *information* that is common, rather than the *code*. Using the information for each class, you can then generate specific code for the situtation at hand. Examples of this arise often in EJB development: value objects, home and remote interfaces, MVC forms (Struts), data access code (CRUD).

Forces:

You find yourself writing similar code repetitively, but can't see any way to factor out commonality into base classes.

You have multiple implementation platforms, and need slightly different code versions for each.

Solution:

1) Create a MetaData information file. This can be an XML file, a database table, or other store that captures the information about your domain problem. For example, for data access, you might capture the name of your object, and each property, along with metadata such as the intended database column name, and datatype.

2) Create a CodeGenerator. This is a class that can read your metadata, and can generate output code or files that implement the target functionality.

Consequences:

1) If the generated classes are modified, they may not be able to be re-generated based on metadata changes. This can be alleviated by using a smarter code generator that support merges. In some cases, you can subclass the generated code to make changes, leaving the base class free to be regenerated.

2) It is possible to overuse code generation, leading to proliferation of machine produced code that developers cannot maintain. This can be somewhat releived if the developers are responsible for the code generation templates and can understand and modify them.

Related Patterns:

Strategy
Interpreter (Little Language)


Example:

Need to produce value objects for my domain, as well as database access code.

1) Metadata (XML file description)

<data-objects>
   <object name="Customer" table="CUSTOMER">
      <property name="name" column="CUSTOMER_NAME" type="String"/>
      <property name="address" column="ADDRESS" type="String"/>
      <property name="ID" column="CUSTOMER_ID" type="Integer"/>
   </object>

   <object name="Order" table="ORDER_ENTRIES">
      <property name="customerID" column="CUSTOMER_ID" type="Integer"/>
       ...
   </object>

   ...

</data-objects>

2) Codegenerator

public class CodeGen {

   public void generateCode( String metadata) {
      // parse metadata
      Document data = new Document(metadata);

      // for each object, generate a data access and a value obj
   }

}

I use this pattern as often as possible because I am very lazy. In addition, the feeling you get when you know that you can adapt to changes very quickly is amazing.

A couple of thoughts:

1) Make the metadata easy to modify and document it clearly. If you don't, other developers won't be able to modify the system and at least two things will occur: You will wind up having to make all metadata changes, and developers will create custom code to substitute for what they don't understand about the metadata.

For me, this means keeping metadata in a simple format. This rules out XML :-) Usually I use an INI format. It's true! It's not only simple to edit but ensures that you don't put information that's too complex in the metadata.

2) You should never need to edit generated code. If you do you lose most of the flexibility of a code generation scheme.

3) Think about a scheme for customization. Since we should never edit generated code, we need to think of how to customize it. I tend to do this by making the generated code extend an abstract class if that class exists.

4) You don't have to use the same language. You can create code generators in any language you like. Personally, I've been hacking Perl longer than I have Java, and it's much better suited to text manipulation (which code generation ultimately is).

The in-house system we have is written in Perl and generates entity beans (bean, home, remote, pk), session beans that wrap around entity beans (bean, home, remote), data transfer objects, entity queries and relationships, and all XML deployment descriptors. It works great and runs very quickly.

5) Generate as much as possible. Once you've gone down the code generation path, you might as well use it wherever you can. For instance, I know it's just an example but the original pattern has datatypes being put in a metadata file. Forget that! We've got JDBC and DatabaseMetaData -- create a program that takes database connection info and a list of tables and generate your metadata instead!

Chris

Thanks for the input, Chris. I pretty much agree with all of your observations, except maybe for INI files ;) For me, in situations where the metadata is nested, XML is the only way to go. INI files are great if you have pretty flat metadata. Of course, metadata has a way of "unflattening" over time (or rather, you find yourself flattening things that aren't naturally flat).

I do agree, though, that you should use the simplest format that works for you. For some projects, this means INI files. I have even been involved in projects where all metadata was stored in the database. The advantage of this was that off the shelf database editing tools (ie. MS Access, Foxpro) could be used to administer the metadata.

Documentation is VERY important. Developers who don't understand your metadata will simply not use it, or worse, misuse it. I've found that heavily documented example metadata files work pretty well (developers love to cut and paste).

In my experience, these kind of patterns are very useful when they are used by the people who develop the pattern. However, once new people come in, it is often very confusing for them to learn all these new patterns.

I think one of the biggest virtues of a project is simplicity and clarity of code. Unfortunately, these patterns make development faster often at the cost of these virtues.

I am normally against these kind of patterns unless there is some kind of pressing need for them. Otherwise, I'd rather write the code than generate it..

I agree with you in certain cases -- if you're creating a new, relatively small system it can make more sense to code by hand rather than generate.

In our case, we're adapting a sizable product that has an existing (and well-designed) schema of 500+ database tables. Coding each of these by hand (even allowing for consolidation) would be a nearly impossible task given our resources.

As a sidenote, I'm always surprised by the lack of discussion about using J2EE technology to adapt existing systems as opposed to creating new ones. I understand that talking about creating new systems is simpler, but IME I very rarely have this luxury. Maybe people who are using EJBs around existing systems just don't have any questions or are too busy to answer them :-)

There are very different sets of problems when creating the two systems. Most EJB books touch on them only briefly. Some design patterns books discuss them -- the excellent "Design Patterns Explained" tackled it head-on.

Chris

Regarding INI files: I probably should have mentioned that I use a customized INI file reader :-) It basically allows for two levels of nesting, plus multi-valued keys. For instance, take the following (probably going to look terrible):

[bean]
name = Foo
table = App_Foo

[relate FooGroup]
type = one
field_map = fooGroupId >> foogroupGroupId

[query lastNameAndActivity}
where = {fooLast} = ? AND {fooIsActive} = ?
param_type = String
param_name = lastName
param_type = Boolean
param_name = activityStatus

There are five separate keys here representing two nesting levels: 'bean', 'relate' and 'query' at at the first level, while 'relate.FooGroup' and 'query.lastNameAndActivity' are at the second level. In addition, the configured query has two lists, one for 'param_type' and one for 'param_name'.

This is as complex as I like my metadata (and configuration files, for that matter) to get. I seriously, seriously considered XML for this. But two things in my experience with XML led me to discard it:

(1) People have a tendency to use the basically infinite nesting capabilities in XML to create grossly complex configurations. It doesn't happen all at once, but it happens.

(2) XML sucks rocks to edit by hand.

I also don't use a database for a couple of reasons:

(1) I like keeping it under normal version control (CVS)

(2) We need to be able to generate code and work with it offline. That might not be a requirement in other places.

In any case, as the Perl community says, "There's More Than One Way To Do It" :-)

Chris

<quote>
create a program that takes database connection info and a list of tables and generate your metadata instead
</quote>

Sounds like Middlegen: http://sf.net/projects/middlegen/

Check out the CVS version. It makes it very easy to write plugins.

Aslak

To me this is a process, not a pattern in the GoF sense. What I would like to see is a pattern for writing good Java-source/testscript/documentation generators.

Anyway, I think what you are saying is right and even important.

It's definately a methodology to follow in certain situations.

I use the JavaSource classes from JaxMe (see sourceforge) to assist me.


Sean

http://www.mousetech.com/EJBWizard.html
http://www.mousetech.com/EJBWizard-howto/install.html
This is code EJB/JSP code generator - it's using templates, it's open source and saves a lot of time.

This works for very simple things. A couple of thoughts:

1) Build scripts are excellent for this. Ant has wonderful @[email protected] string replace-on-copy tasks that allow you to put this into the build.xml

2) Use factories. A very common pattern is where you want a different configuration for an object depending on whether you are deployed for clientx or client y. Create an abstract toolkit for all the objects that should be different, and specify the factory class in you web.xml or other config file.

String toolkitClassName = /*how ever you get your config info*/

Toolkit toolkit = (Toolkit)Class.forName(toolkitClassName);
MyObject = toolkit.createMyObject();

3) If Data is what is different between your apps, use a sijple holder object (ClientConfiguration). Again, specify the actual class in you deployment file.

One nice things about code generators is that they give you compile time type checking, with the run time perfomrance improvements that implies.

Wait until templates make it into Java. That should replace code generation for the most part. I think it is coming in 1.5, but don't quote me.

Adam

   "2) Use factories. A very common pattern is where you want a different configuration for an object depending on whether you are deployed for clientx or client y. Create an abstract toolkit for all the objects that should be different, and specify the factory class in you web.xml or other config file."

Factories are nice, but actually, the intent of this pattern is for situations where you *can't* use factories or other abstractions. Patterns like factories (e.g. using reflection and dynamic class loading) don't solve this problem, because at the end of the day, you still need to write specific code for each situation. Again, assume you need 100 nearly identical classes that aren't the same (ie. they represent 100 different database tables, or 100 different factory recommended settings). Now imagine that these 100 things change relatively frequently.

"Wait until templates make it into Java. That should replace code generation for the most part. I think it is coming in 1.5, but don't quote me. "

Templates will support type-safe containers, behavior etc., and will go a long way towards eliminating *certain* types of code generation, but I wouldn't say "for the most part". Again, I'm describing things that may or may not be Java classes (config files, SQL generation, documentation, JSPs, etc.) that need to be repetetively produced that by definition *can't* be elegantly factored into base classes, factories, etc. unless you want to manually write a factory for 100 different objects.

"Wait until templates make it into Java. That should replace code generation for the most part. I think it is coming in 1.5, but don't quote me. "

The proposed Java Generics mechanism can mostly be described by the term "hidden type cast". It can't even begin to be compared to, for example, C++ templates which are a Turing-complete language in and of themselves.

Basically, you won't be solving any code generation problems with Java Generics (templates).

God bless,
-Toby Reyelts

I'm surprised no-one has yet mentioned the various code generators that use metadata captured in Javadoc tags. Like

    http://xdoclet.sourceforge.net/
    http://www.beust.com/cedric/ejbgen/
    http://vdoclet.sourceforge.net/

Of course, the Javadoc approach has it's own limitations: it's really only relevant when you want to generate artifacts based on existing, hand-crafted Java code. But it's pretty useful in those cases; for example, generating EJB deployment-descriptors and interfaces from a tagged bean-class.

Having written my own code generator (www.tallsoftware.com) over the last 12 months I know the pros and cons.

The pros are massive amounts of code very cheaply. And its all valid and best of breed - ie all the error checking you can want.

The cons are to do with complexity and the rate of change. Complexity is to do with knowing when to stop. Its so tempting to add more and more bells and whistles, in effect, reinventing your own high level language to generate the exact java statement you want. i.e. this is silly, use java. And the other is how you handle fundamental swings in technology - ejb 2.0, struts v's velocity v's tiles v's etc. The rate of change issue effects every project, but with a code generator you feel you should keep up, after all, a single change cascades to all the generated code. Again, watch out, you will spend the project budget on the code generator and not the project.

Know when to stop!

Jonathan
ps LowRoad does struts, bmp ejb, value objects, form/action, config files, deployment descriptors and so on ad infinitum.
   http://www.tallsoftware.com

On javadoc-based generation....

This is a reasonable approach when your metadata is somehow class-related, which is true for some EJB scenarios, and maybe for "aspect oriented" approaches such as adding dynamic logging capability.

I don't think this approach (e.g. with JDK 1.5) will solve the world's problems, since it basically violates the separation of metadata and implementation code. You're pretty much stuck with an annotated Java class as your metadata source, which is fine for some situations, and not for others. It also does make tooling a bit harder (not to mention the "nesting problem" described earlier).

You can take a look to Scriptor generation.

This product is an IDE dedicated to the creation of code generators which takes a UML model as input and produces text files as output (java, xml, html, properties, sql, etc...).

It provides wysiwyg facilities to describe the "code" you want and allow you to map it to UML modeling elements.

Creating a code generator based on a specific UML design for a specific architecture is no longer a pain with this kind of tool.

Take a look at :
http://www.sodifrance.fr/NTmigration/mvt_qualitec/produits/scriptor_us.htm

A limited version is available for evaluation.

Richard.

There could be a different way to deal with the ‘cons’. You implement complex new things always in Java and never do so in xml. The xml only describes how to invoke the complex new features in general ways that will be used 80% of the time. It is not really a question of knowing when to stop but knowing how to scale. If you need a feature you can’t stop. Instead you just implement the feature so that it can be invoked using xml in addition to its java api.

This is pretty much in line with the Web Services efforts. Most java api are too low level for uses by SOAP. This is similar to the pattern to use value objects to reduce the communicate overhead of ejb invocations. For SOAP and metadata driven patterns you need to create a facade that takes the instructions/parameters in a high level manner.

You are right, Jonathan Gibbons, we should know when to stop, I too had developed a Generator which takes template and churns whatever the language code you want with all the data objects, factories, User input screens, navigation and search mechanisms, and even EMail templates....
 So we should really know when to stop or we will be generating thousands of pages of code.

Toby's Hypothesis: Anything you can do by generating code, you can also do through dynamic proxies.

Dynamic proxies are nice in a few ways.

- Your implementation is always up to date with the interface. This is powerful, in that you may replace the implementation without generating an entirely new set of classes and having to re-compile and re-deploy. In fact, you can replace the entire implementation dynamically at runtime.

- You don't duplicate a lot of code. There tends to be a massive amount of duplicate code present in generated classes.

- The implementation code is easier to debug. Code-generated code is usually messy and hard to understand. Code-generated code is also specific to a certain case, so it can be hard to see how the bug maps back to the code generator itself.

God bless,
-Toby Reyelts

"- The implementation code is easier to debug. "

Oops. Forgot to mention that the implementation is much easier to write than for code generators - since the code you are writing is actually the implementation - not code that writes the implementation.

God bless,
-Toby Reyelts

At Javelinsoft (www.javelinsoft.com) we have written a code generator called JGenerator which uses a similar idea. Instead of basing the code generator on a single format we can read our meta data in from a number of formats (Jdbc, DTD, properties or XML) to a standard relational/object model.

JGenerator can create In-Memory, EJB, Jdbc or JDO beans all to the same interface. This allows you to transparently switch the technology (JDO/EJB/JDBC) under the covers. And yes it really does work seamlessly. This is because we base it on component-oriented designs rather than object-oriented designs: the data is cleanly seperated from the architecture.

We've used the software on a wide range of products (from www.JobsHive.com, portals, FpML, neural simulations - as well as the petstore and MS Northwind) and have shown if you get the design right you can use flags in the meta data to effectively program with patterns. The trick is to have a deep understanding of the semantics rather than tackle code generation at the simple syntatic level. For example the sql indexes should be seen as commonly used ways of navigating into the data, so by default where there is an index a findBy is added to the Session.

A couple of comments on what people have said:

dynamic proxies - well if you do it properly the dynamic proxy code would be basically identical to the code generator code - so you're going to take a bit speed hit, and for simple projects (<10 tables) you may end up with more code in the proxies than is generated out.

"implementation is much easier to write than for code generators" - absolutely not true. Alot of the code we generate would be a really hard to get right by hand consistently across large projects. For exmaple we create java docs in our code that most people just don't bother with. I *really* disagree with this point.

Java doc generation - this assumes/restricts a one-one mapping between objects and other entities code generated, such as XML and Tables. I considered javadocs as a possible option and couldn't justify building a project that was crippled before I even started. Plus we wanted to read from multiple sources (eb JDBC) and wanted our interfaces to be created for us. There are no standard sets of APIs that can be used to generate java. Bean Descriptors, Java classes+java docs, XML Jdbc. XML Schemas. Nothing.

When we created highly optimized EJB code - till the pips squeak - our code to meta-data ratio is 100:1! Any functionality we could was put in the super classes. We were surprised too. Perhaps this just shows the current (bloated)state of the OO market.

Best of luck with your efforts.

Robin Sharp

Robin Sharp wrote:

---
dynamic proxies - well if you do it properly the dynamic proxy code would be basically identical to the code generator code - so you're going to take a bit speed hit,
---

It's possible that dynamic proxies can perform worse, because the implementation code is generic. On the other hand, dynamic proxies can perform better, because you only have a small constant number of classes in memory instead of some linear K * N.

Either way, for most cases, it won't make much difference, because the actual work being done will dwarf the work that is done differently between the proxies or the code generated code.

---
and for simple projects (<10 tables) you may end up with more code in the proxies than is generated out.
---

You can't have it both ways. If you've written your code-generator well, so that work is factored out from code-generated classes into super-classes and other participants, you're going to have almost the exact same overhead as the dynamic proxies plus the additional K * 10 generated classes to go along with it.

The whole statement seems like a red-herring anyway. I bet you could poll every single person who has visited The Server Side, and not a single one would be working on a project with less than 10 tables. The whole point of code generation / dynamic proxies is solving a recurring task.

---
"implementation is much easier to write than for code generators" - absolutely not true. Alot of the code we generate would be a really hard to get right by hand consistently across large projects.
---

Your statement doesn't make any sense to me. By the very nature of code, it's easier to just write it than to write code that generates it.

---
For exmaple we create java docs in our code that most people just don't bother with.
---

I don't understand this statement either. With dynamic proxies you don't generate code (per se), so you don't have anything to javadoc.

---
I *really* disagree with this point.
---

No offense, but it doesn't sound like you've actually ever used dynamic proxies yourself. As for myself, I've written a very significant body of code-generating code. In fact, I'm considered writing a book on generative techniques that addresses both code generation and dynamic proxies. If you do have insight into dynamic proxies related to practical experience, I'd like to hear it.

All that said, I'm not saying that dynamic proxies are always better than generating-code - In fact, you can often use the two solutions together, complementary. I just believe a lot of people aren't aware of dynamic proxies and their potential in generative programming.

God bless,
-Toby Reyelts

Dynamic proxies may perform better if you have limited memory - say a phone - but I wouldn't choose proxies in that case either.

I can have it both ways performance and size. The complex code in generators is often substantially larger than the code it generates.

Actually I do take offence. I have used dynamic proxies quite alot. They have their place, and using them on substantive bodies of code isn't one of them. Theres' some super classes that we use in our jbeans download, in the proxy package. If you had bothered to do your research before huffing and puffing.

Of course implementation is easier in generators. I've generated systems with over 100 entities = 1000+ classes. Try heeping that lot in sync by hand. Even with 3 entities = 30 classes + XML + SQL etc, etc. Then get told to add something across all that code. No way.

God help.

Robin

Robin Sharp wrote:

---
Dynamic proxies may perform better if you have limited memory - say a phone - but I wouldn't choose proxies in that case either.
---

Memory can always make a difference - from preventing paging to keeping instructions and data on processor cache. My point is that there is a trade-off when using generated code.

---
I can have it both ways performance and size. The complex code in generators is often substantially larger than the code it generates.
---

My experience says otherwise. Your case is only true if all the information is available to you primarly at generation time and it is highly amenable to static optimization. It often works against you when you want to dynamically optimize your system. This is why the -O option means nothing to the javac compiler and why HotSpot does its optimizations at run time.

---
Actually I do take offence. I have used dynamic proxies quite alot.
---

I'm sorry that you take offense. I guess I'm confused, because your arguments against using dynamic proxies don't make any sense to me - like generating javadoc.

---
They have their place, and using them on substantive bodies of code isn't one of them.
---

[sarcasm]
Oh well - I guess Sun's use of them in the Java class library was just plain silly. I also imagine that everybody considers the folks who wrote JBoss to be fools for using dynamic proxies in their application server.
[/sarcasm]

Seriously, my point here is that dynamic proxies have already been used in substantive bodies of code.

---
Theres' some super classes that we use in our jbeans download, in the proxy package. If you had bothered to do your research before huffing and puffing.
---

What are you trying to say here? That your product doesn't use code generation naively? I never said it did. I've never even looked at your company or your product - much less made a single statement about it.

My point was that non-naive code generation generally requires a runtime codebase just like dynamic proxies. You seem to be proving my point.

---
Of course implementation is easier in generators. I've generated systems with over 100 entities = 1000+ classes. Try heeping that lot in sync by hand.
---

Are we even talking about the same things here? You don't have _anything_ to keep in sync if you use dynamic proxies, because you generate everything at runtime (Well, the dynamic proxies are generated for you at runtime). That is one of the very benefits they hold over code generation. By their very nature, dynamic proxies are always in sync.

---
God help.
---

Seems like you're taking my points about dynamic proxies and code generation as personal hits against you, Javelinsoft, JGenerator, or all of the above. I'm sorry you feel that way.

Personally, I just prefer discussing the relative technical merits. I apologize if my comments about your seemingly lack of experience with dynamic proxies threw this conversation off in the wrong direction. It wasn't meant to belittle you or your company.

God bless,
-Toby Reyelts

Would you mind posting a simple example of dynamic proxy code.
TIA
JF

Yes, I would like to see the the Java code for "code
generation purpose". The example shows us:

2) Codegenerator

public class CodeGen
{
public void generateCode(String metadata)
{
    // parse metadata
    Document data = new Document(metadata);

    // for each object, generate a data access and a value obj
   }
}

The fact is to do reasonable code generation by Java coding,
you will be walking the same path of an XSLT processor.
More specifically you will be accessing (XPATH) your
XML metadata by Java code and you will be generating
your java code(may be dynamic proxy) like XSLT. So may
I know how "simple" will be this part of Java coding?

On the other hand, offline (i.e not using dynamic proxy)
Java source code generation based on XML model and
using XSLT script looks more appealing to me. I have
implemented this concept in a large project (60% gen
code).

Soumen Sarkar.

Since my original post seems to have sparked some interesting dynamic proxy vs. code generator debate, in particular how "hard" one is versus the other, let me add some clarification.

My original post described a Java class for doing the code generation. That was a rather dramatic simplification of what I've actually done. In practice, I use a templating language, together with XML for metadata in most cases. One easy way to generate code is to use a template engine such as Velocity. (jakarta.apache.org/velocity)

Its basically equivalent to writing something like a dynamic web page in JSP. You put your metadata into a "context", then use templates to navigate the metadata. Al of the basic code, comments, formatting, etc. are part of the template, so it stays clean, and easy to maintain. You just have simple conditionals, variable substitutions, and loops in the template.

Example (assume there some known metadata in an object called class).

public class $(class.name} {
    public ${class.name} () {
    }

    public String toString() {
       String retval = "${class.name} contents: ";
#foreach ($item in $class.fields)
       retval += "${item.name} = " + this.${item.name};
#end
       return retval;
    }

    // member vars
#foreach ($item in $class.fields)
    private ${item.type} ${item.name};
#end

}


Its rather obvious that if you can make something generic easily, you should do that instead of generating code (this includes proxies and other approaches). Again, I'm suggesting this approach for situations where you can't do this, and have repetitive code to write and test. And note, the code you generate is just an implementation...the metadata and templates are what you maintain.

Dynamic Proxies are quite interesting, as they allow you to consoidate your security, marshalling , and even object creation code in a single place. I know that is how JBoss does it. I guess this is one of those solutions that Java Generics would not solve. You can do it with code generation ofr Dynamic Proxies. Are there other ways to solve this problem? Is this the problem that Aspect oriented Software is attempting to solve?

One place I've really liked the code generators were from converting tables to beans. While you could do this with a dynamic proxy, I really wouldn't want to. I guess I would say my general rule would be, use code generation where you would want to be able to extend the code, and Dynamic Proxies where you would want to be able to keep implementation details secret.

I still haven't decided how to set up a rearchitecture of our current setup, which I want to move to EJB 2.0 eventually. I'd love to generate XDoclet based Code off our current Database Tables and the existing Session Beans. That may be asking too much.

Have you looked as Aslak's tool Middlegen?
(http://sourceforge.net/projects/middlegen)
"Middlegen is an Graphical EJB development tool that can be used in conjunction with the XDoclet engine. It connects to a preexisting database and generates CMP Entity Beans (Java source files with XDoclet tags)."

-And Middlegen has recently been refactored, so that the source code templates are using Velocity. Basically, the templates have access to some context $variables which let you loop over tables, columns, relationships etc. Example:

public class $table.destinationClassName {
   // fields
#foreach( $column in $table.columns )
   private $column.javaType ${column.variableName};
#end

   // relations
#foreach($relationshipRole in $table.enabledRelationshipRoles)
   private $table.getClassName($relationshipRole) $table.getVariableName($relationshipRole)#if($relationshipRole.targetMany) = new java.util.ArrayList()#end;
#end

-But you'll need the CVS version of Middlegen for this ;-)

A release is planned within a few weeks (I hope). -At the same time as the next XDoclet release.

The foilware is here:
http://boss.bekk.no/boss/middlegen/

I am biased towards the javadoc approach (even wrote an article on it for javaworld - plug plug), only since it seemed appropriate for my relatively simple needs. Not to start a flame war here but I think .Net has got this thing right (or more right) with the introduction of attributes. This makes meta-data part of the language itself, you can query for it using reflection on the class and define your own custom attributes. The notation is right near the class source code itself - similar to the javadoc approach.

here is a good link for more info...
http://www.oreillynet.com/pub/a/dotnet/excerpt/prog_csharp_ch18/index.html

The java side seems to want to go in a similar direction from what i can tell so far. See http://jcp.org/jsr/detail/175.jsp

A Metadata Facility for the JavaTM Programming Language

- Mark

Umm... I think I can do that in the GNU m4 text processor. A tool that goes back to the 50's :)

Umm... I think I can do that in the GNU m4 text processor. A tool that goes back to the 50's :)

Gimme a break. m4 might be similar to Velocity. -But none of these tools can read database metadata.

Aslak

Take a look at the server side paper

https://www.theserverside.com/resources/article.jsp?l=XMLCodeGen

In our large Java project, 60% of code is generated,
in the following areas:

* EJB code generation from UML model in XML.
  This goes like this:

  - Express entity-relationship model among EJBs in UML
    and capture that in XML form.

  - Use XSLT scripting on UML/XML model of EJB to generate

    1. HOME, REMOTE, BEAN classes
    2. XML deployment descriptor
    3. SQL schema for entity beans

  Custom code is "mixed" with generated code via
  inheritance as it is done in CORBA.

* SNMP manager side code generation. This goes like this:

  - Somehow convert SNMP MIB in XML form. For example some
    MIB browsers compile SNMP BIB and has option to export
    compiled MIB in XML/HTML form.

  - Use XSLT scripting on SNMP MIB in XML form to generate
    manager/agent side code genration.

* Application configuration. This goes like this:

  - Express application configuration in XML schema.

  - Use XSLT scripting on XML schema to generate code for
    file/db based persistence and GUI forms.

I am very much into XML/XSLT based source code generation.
If you need further info, you could contact me at:

sarkar_soumen at yahoo dot com

Soumen Sarkar.

You might be interested in the Code Generators article here:

http://www.softwarereality.com/programming/code_generation.jsp

The article introduces generators as a welcome addition to your agile toolkit. It finishes with a reference section and list of (known) generators. (If you know of any others, please let me know - I'll add them to the list)

The article includes input from Robin Sharp and Dino Fancellu from Javelin Software (authors of JGenerator).

Hi,

you might also be interested in the latest approach by
the OMG team called Model Driven Architecture (MDA)
where generating out of a model plays an important role...

http://www.omg.org/mda/

my 2 cents
* generating is usefull when there are a lot of changes,
  not only changes of requirements, also changes in
  infrastructure, platforms, extensibility, organisation...
* generation is not usefull if you write sth. only once
  and are goingt to change it never again

? did somebody had a project that did not change ?

you also asked for tools...

[commercial break]
  ToolName: ArcStyler
  Infos: www.ArcStyler.com
  Description:
  it supports not only the generation-part,
  it covers the whole development process and supports
  users from launching a project until deployment and
  does also refacturing, and and and...

  ...just have a look at it...
  (btw. the used generator has not changed for a
   couple of _years_ and it is hand written ;-) )
[commercial break]

- Kalle
(guess what company i work for ;-)

I can't resist:

<vendor-plug>

iQgen is innoQ's Model Driven Software Generator. It reads UML model information from XMI files and generates code based on templates written in JSP syntax. Modifications to existing code are preserved. iQgen supports all major CASE tools (e.g. Rational Rose, MID Innovator, Microtool Objectif, and Togethersoft's Together) and can generate everything imaginable from EJB/Java source files to SQL DDL scripts to test drivers.

You can download a pre-release version (the final release is due soon) of iQgen from http://iqgen.innoq.org.

</vendor-plug>

Regards,
Stefan

I have used this approach with three different languages and now we have built a whole application around this concept.

Using the struts framework we built a set of classes and database structure to manage security/users/menus/connection pooling etc.

We then use the code generation utility to build our JSP pages, Form Beans, Action Beans edit the struts-config.xml and also provide the hooks into our foundation classes.

We use the metadata to give us field names, lengths, datatypes etc for the JSP pages and also build the select, insert, update and delete statements.

Using this approach we can build a fully functional web page in seconds.

Of course it looks ugly and there's no real validation but that's phase II.

I'd estimate our development time to be cut by over 60% for basic data entry screens.

Owen

Another solution is to use JSP to handle code generation:

class <%= Entity.getName() %> {
<% Iterator ifields = entity.getFields();
   while(ifileds.hasMore()) {
     Field field = ifields.next();
%>
     private <%= field.getType() %>
             <%= field.getName %>;
     public void set<%= field.getName()%>(
                    <%= field.getType %> newValue) {
        <%= field.getName() %> = newValue;
     }
   ... and so on ...
<% }
%>
}

The Entity, Field objects are loaded from an XML file and the code generated by CatorXML or any other Java/XML ampping tool. So the amount of code to be written is very low. I test with Tomcat/Castor, that's simple to write or modify, that's work and use a standard technology.

To simplify the syntax, you can also use the JSTL.
My 2 cents.

Nice. We often have requirements that change on us during the dev. cycle. This means we have to go back and do another generation of code - but we loose the custom changes/additions that we've made. Any suggestions around this?

Use inheritance to modify the behavior of the generated code.

I use a simple templated code generator, that originated as a perl script a couple of years ago and was rewritten by my colleague as a neat delphi app. It is freeware and called beanmaker, available from www.cylog.org , pick up his fixed width fonts while you're there.

Joe

check out xcodegen.
It generates DDL scripts, DTO and DAO classes from a XML Metadata descriptor

oups, the link is xcodegen

Couldn't agree more. Both xcodegen and iqgen have a bit of a way to go before they offer the kinds of everyday usefulness you find in Blistered Little Finger. Conceptually, it couldn't get simpler and it offers declarative association management, which, when your talking code generation of relationl entites is both quite a feat and the first thing on your shopping list. They will also do bespoke versions. Cooler than Toplink!