In response to my question regarding Java source code generation, I received thi

Question

In response to my question regarding Java source code generation, I received this answer warning me about potential maintenance problems:

mixing auto-generated code always pose a risk of someone modifying it in future to just to tweak a small behavior. It's just the matter of next build, when this changes will be lost.
you will have to solely rely on the comments on top of auto-generated source to prevent developers from doing so.
version-controlling - Lets say you update the template of someMethod(), now all of your source file's version will be updated, even if the source updates is auto-generated. you will see redundant history.
His proposed alternative is enhancing classes at runtime using bytecode generation.

My thinking was that injecting generated code into existing source code files would enhance maintainability, because it makes it obvious what is going on instead of performing some operations behind the scenes.

Should I:

create a tool to add generated code to existing source code; or

augment the classes using bytecode generation at runtime?

What has been your experience with either of these approaches?

Explanation / Answer

I have done a middle sized Java project (ca. 300 classes) with multiple Maven modules with my domain classes auto generated (ca. 100 classes) from a DSL done with the superb Eclipse Xtext project and I would do it again :)

Here I will give hints how I (till today) successfully come around the cumber stones mentioned:

Since my project was build with maven I used the maven way to handle auto generated code, that means even my xtext dsl and generator project is handled by maven and at every full build I create all generated code new (as it should be). See: building xtext projects with maven tycho. So in my project I only have to do a "maven package".

I divided my generated code and my hand typed via inheritance (i dislike the c# way to span a class in multiple files):

/* Generated code, will not be in revision control */
abstract class AbstractFoo {
//getters and setters
//collection accessors
//helper methods like toString equals hashCode
}

/* Generated one time, will be in revision control */
class Foo extends AbstractFoo{
//business logic if needed
}
With an Xtext generator project it is possible to define files that should only be created one time, so my concrete classes i have created only one time and kept then in my Git repo. The generated concrete class is nothing more then a 2 liner so you can use the class even if you add no methods to it.

For the two templates (abstract and concrete) I have created two test class templates one for the abstract class and one for the concrete, but the concrete test class is again only just generated one time and a two liner.

In my maven module where the generated code is located i have used this layout (almost the maven conventions):

myproject/src/main/java -> concrete generated classes, one time
myproject/src/test/java -> generated tests, one time
myproject/target/generated-sources/mydsl -> abstract generated classes, always
myproject/target/generated-sources/mydsltests -> auto generated tests, always
So when i change the template only the template in the Xtext generator project will change in my revision control, since I do not include the (always) generated sources.

So I would suggest you to give Eclipse Xtext a try, when you start with the example projects you will have something prototypish running in less then one hour.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.