Skip to main content

Code Generation

Posted by davidrupp on November 15, 2004 at 5:34 PM PST

At the Rocky Mountain Software Symposium this past weekend, a few of the presenters took the time to gauge audience reaction to their topics by asking questions like, "What do you think of this?", and "What's keeping you from using [insert technology name here]?". In the case of technologies like Hibernate and AOP/AspectJ, the answer was usually something like, "We think it's cool, but we're worried that it does code generation. How do we know we can trust the generated code?"

I always chuckle a little when this question comes up. Don't get me wrong -- I think it can be a legitimate concern, particularly if the code-generating product is new or naively implemented. But it makes me think about how much we programmers take for granted today.

For example, I think we have lost sight of the fact that "generated code" is pretty much all that computers deal with, not the precious original source we tinker with in our fancy IDEs. As much as we like to anthropomorphize our computers (with the interesting corollary that we "theomorphize" ourselves; but that's a subject for another blog), they don't really know or care about the language/platform/paradigm silliness we humans engage in.

Here's what's not happening inside your computer:

Your code:

public class MyIncredibleClass implements Runnable {

  public void run() {

    try {


    } catch (UnthinkableException neverGonnaHappen) {




  // etc.


Your computer: (sounding like Helen Hunt; your internal celebrity voice may vary) Oooh, a classic implementation of the Worker pattern. With robust exception handling! I like the way you think, Mister. Tell me more! Ohhhhh, yes. YES!

Here's what's really happening:

Your code: (see above)

Your computer: (sounding pretty much like your toaster) blah, blah, blah; L R1,$1000; SLL R1,2; ST R1,$1000; NOP; NOP; NOP; blah, blah, blah,...

So, if you're not writing NextKillerApp v0.0.1a003 in straight assembler language, you can be assured that some generation/augmentation/translation is happening betwixt your app's source code and wherever it ends up running. Nobody sits at the Rocky Mountain Software Symposium thinking, "Geez that javac tool is cool and all, but..." Because we take these things for granted.

Here's the deal -- if you use:

  • a compiler
  • a pre-processor
  • any "high-level" language
  • a third-party library
  • EJB
  • RMI
  • JSP
  • dynamic proxies
  • lots of other stuff

  • you're taking advantage of -- nay, actively relying on -- code generation. And these are, for the most part, tools that we have no control over. If MajorCorporateBrandTool introduces a bug when it's decorating your code, what can you do about it? Open a problem ticket with MajorCorporation and argue with them for a month about whose fault it really is? Then sit back and wait six more months for the next service pack to be released? Blech.

    So I say let's cut code generation some conceptual slack. Take some time to get familiar with Hibernate and AOP. Figure out how they work and what kind of code they're likely to generate. Here's a good one -- read the source code. Can't do that with MajorCorporateBrandTool.

    Now, if you'll excuse me, I need to get back to Helen...