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

  1. 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.
  2. you will have to solely rely on the comments on top of auto-generated source to prevent developers from doing so.
  3. 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:

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

  2. augment the classes using bytecode generation at runtime?

What has been your experience with either of these approaches?

  • 1
    "you will have to solely rely on the comments on top of auto-generated source to prevent developers from doing so" Nope. You can also give the generated file a file name like "machine_generated_file_1.xxx". While not everyone reads comments, most will know the file name at least. Jun 24, 2014 at 23:03
  • 1
    @Thomas: that doesn't work too well in Java, where the source file name has to match the class name and the entire class definition has to reside in that file. Oct 20, 2014 at 6:39

6 Answers 6


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.

  • 3
    +1 great, particularly the not checking your generated sources into version control. That's the ONLY way to do it, of course. Apr 23, 2011 at 6:44

I would not like this approach one bit. Too much mystery for my taste.

I'd prefer aspects or decorators, because you have to actually write them instead of generating them AND you make clear what you're doing when you weave them in.

  • 3
    Also generated code can be a maintenance nightmare as you then have to fix the code that generates the faulty code, not the faulty code itself. It always sounds good, but beware.
    – cjstehno
    Apr 21, 2011 at 15:24

From what I've seen, source code generation works best if:

  1. You don't have any reason to modify the class's code once it's been generated, or
  2. You won't have any reason to re-generate a class's code once you've modified it (scaffolding approach), or
  3. You're working in a language like C#, which allows you to make classes span multiple files. (You can have one file with auto-generated code, and another with your contributions), or

Based on your question, I'm guessing none of these is probably true. While I haven't personally done bytecode generation, I've noticed that some well-used tools like GWT have chosen that approach, so it's probably preferable.

However, I'd ask a colleague to listen to what you're ultimately trying to accomplish and see if there's not a better way using more standard Java practices.

  • The way you make 1. happen is to always generate the generated files. That way you have no need to touch them.
    – Ira Baxter
    Apr 22, 2011 at 1:56
  • I would disagree with 1, since that is the entire idea behind scaffolding, a pretty widely accepted practice. Jun 14, 2011 at 17:44
  • @Ira Baxter: Precisely. If you can always use generated files, that's fine. If you need to be able to override behavior in certain cases, the generation framework must support that so you don't have to manually modify the code. Jun 14, 2011 at 18:55
  • 1
    @ironcode: I was originally thinking of code generation where the code needs to be re-generated on a regular basis (a la "update model from database schema"), which is what the OP sounds like he's doing. But broadly speaking, you're right: I added a new #2 to include the scaffolding idea. Jun 14, 2011 at 19:00

You can have your build process generate the code, jar it up, and include it on the classpath of your dependent project. This will prevent the issue with rogue devs changing the generated source, you don't need to version the generated jar just the meta data it was built from.

This was the approach I've used in the past with tools like XMLBeans and it worked pretty well.

  • How do the rogue devs debug the generated code, or is it assumed to be bug-free?
    – quant_dev
    Apr 23, 2011 at 20:21
  • Attach the source, but generated code should be bug free. If you find a problem with the generated source then you need fix your generator.
    – nsfyn55
    Apr 25, 2011 at 18:57
  • "If you find a problem with the generated source" - you need to be able to debug it, then. So you need to attach the generated source. I'm not saying that you will fix it my modifying the generated source (that's stupid), but you need to see the generated source.
    – quant_dev
    Apr 26, 2011 at 6:40
  • isn't that what I said - attach the source.
    – nsfyn55
    Apr 27, 2011 at 20:28

The Eclipse Modeling Framework does really superb code generation, but is complicated to get to grips with. It is apparently able to allow user code additions in the model code without reverting those changes each time the model is regenerated. Also, the Mattise UI editor in Netbeans does all the generation for the user interface, and keeps it up to date.


Actually in managed c++ forms you have both automatic and manual codes mixed together in the .h file. Automatic code is updated every time you open form in designer mode, modify something and save. Works just as well as having generated code in a separate file.

Not the answer you're looking for? Browse other questions tagged or ask your own question.