Why write another code-generator

TOC

There already exist so many tools that can be used for code-generation- Velocity, JET. There is also the cool DOM/AST API from eclipse. Velocity and JET are both template based  general purpose generators akin to scripting languages. 

1. As your code generation needs get more complex the templates can become complex or you end up building a template library unless your templates are very carefully designed. Programmers are quite comfortable with using an object oriented code generator something akin to a servlet generating web-content. It can be handy in simplifying the coding of the logic in the code-generator. However another problem that emerges is that of method, constructor, initializer body content which often is best implemented using a scripting templating system. The code-generator used by the RB plugin is object oriented and has object representations for classes, interfaces, methods, etc. For building   method, constructor, initializer body content one can use velocity or JET as an option where its usage adds elegance and maintainablity. The solution is similar (but not the same) to the popular MVC approach involving servlets and JSPs. 

2. There is a stage 2 for this java code generator (I am somewhere at the end of stage I) wherein I will be writing a parser to parse  templates written for JET (the .javajet file) and velocity (say a .javavm file) and generate code-generators with the same concepts as the JET java code-generator'-generator but with one vital difference. 

The generated code-generator will not have code like  Instead the generated code-generator after stage-II will  have code like 
The generated code generators have a method- public String generate(Object argument) which contains the following The generated code generators  will have a method- public String generate(Object argument) which will contain the following
stringBuffer.append(TEXT_1);
if(flag){
stringBuffer.append(TEXT_2, +....);
}else{
stringBuffer.append(TEXT_10);
}stringBuffer.append(TEXT_11);
if(flag){
stringBuffer.append(TEXT_12);
}else{
stringBuffer.append(TEXT_13);
}		 if(flag)
{
someMethod = new Method("get" expr + "Msg", 
"java.lang.String", 
GeneralAccessLevels.PUBLIC, 
false, false, true, true, false, clazz, 
comment);someMethod.addParameter(new NameType("locale", "java.util.Locale"));
new Content(someMethod, ContentLocator.get("someKey", arg1);
}else{
.........
outerClazz.toJava();
  There will also be generated a single property xml file associated with the code generator to hold content like the method content inside CDATA sections. Method objectss will fetch their content from this using someKeys the above code passes.
  Otherwise for obtaining the method contents the generated code could also conatin helper methods- methods other than "public String generate(Object argument)" generated in the code-generator with appropriate method parameters for the helper methods. These helper methods could be edited by even editing the properties xml.

Existing (as of now in stage I) Benefits of using this codegenerator:

  1. It takes care of computing the import statements automatically. 
  2. In the generated rb plugin there is no restriction on what should be the parameter names etc of the generated code because if there is any chance of collision the generated code is self adjusting and ensures ther is no name collision.
  3. It is simpler to use than DOM/AST API as unlike DOM/AST API it is limited in purpose. A user of the code generator has only to deal with the package com.raghuraman.codegen  containing  classes like- OuterClass, OuterInterface, Field, Method, Constructor, Initializer, NameType, Content, NestedClass, NestedInterface, GeneralAccessLevels, CodeFormatter. All the public api is only in the package com.raghurman.codegen. Users need not be concerned with other packages and subpackages. 

Actually I should not call it a code generator but rather code-generator-model classes.

As of now the RBPlugin is using this codegenerator for the sake of convenience. This is not a rigid stand. I can replace my code-generator with a conventional ".javajet" or velocity based template if needed.