 |
Code Generation
Posted by davidrupp on November 15, 2004 at 05:34 PM | Comments (8)
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 {
doSomethingBrilliant();
} catch (UnthinkableException neverGonnaHappen) {
respondAuthoritativelyAnyway();
}
}
// 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...
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
The problem with code generation is that even the best of the generators often generate rather poor code.
And of course many will happily (and often without blushing or warning you) remove swaths of your own code (written to overcome problems in the generated code or to implement those things the generator marked with something like "your code here" whenever they are called upon to do their thing.
For reasons like that many people (myself included, having suffered more than one generator and even written one (partially functional)) are extremely wary of these robotic coders.
I will use functions in my IDEs to generate class and method templates and other macros to reduce the boilerplate code I need to type but I won't let some tool determine what I want.
Posted by: jwenting on November 16, 2004 at 06:51 AM
-
Sure, Java is several levels of abstraction above what is actually happening, but it provides a very tight abstraction (as opposed to Joel's infamous leaky abstractions). For the most part, I can code and debug in Java as if there was nothing below it.
Posted by: coxcu on November 17, 2004 at 06:21 AM
-
I do not consider code generation as an evil. But, it becomes an evil pretty soon when you have to maintain the code it generates. As long as the code generation happens in backend and we deal only with the necessary abstractions, it is a Good Thing. In case of Aspect J, I do not have to maintain the generated code, and hence is desirable. If the generated code mis-behaves, I just don't use AspectJ and switch to Java until AJ fixes the problems. That said, I think the code being generated by current IDEs for GUI handling to be generally messy, and we end up having to maintain them.
Posted by: vhi on November 17, 2004 at 06:54 AM
-
Code generation is a great technigue. Sometimes we seem to have forgotten that dynamic code can be just as good and much more elegant. Code generation also tends to make us lazy on optimizing sections since it's *automated* and not-my-code.
Posted by: smartinumcp on November 17, 2004 at 07:37 AM
-
Code Generators are neither good nor bad, they are simply tools. Like other tools, they can be of varying quality and can be misused/abused. I think some things to look for in good code generators are:
Things you would normally look for in evaluating any other tool such as reputation, usability, support, cost, etc.
Generated code should not need to be edited.
Code should be generated from a "source" file. This implies that the code is re-generatable.
You should be able to integrate the code generator into your build process
The last two items are important because they usually eliminate the need to edit generated code. Editing generated code is dangerous because custom code may be overwritten and can be less readable. Code generators that can regenerate code from a "source" file allow the code to be modified and then regenerated. This is desireable because the "source" files can be put under version control and code can be regenerated during the build process.
Posted by: hammer on November 17, 2004 at 01:10 PM
-
Hibernate, per se, only 'generates' SQL code, not Java code - is this the code generation you were referring to? That is true of almost all OR mapping tools including EJB CMP. Of course there are tools that will generate one or both of classes and hibernate mapping files given a database schema, either as a once-off or repetitive exercise, and things like Xdoclet which can generate configuration from comments in Java source files, but is that the same thing? Your point is well taken though. There are already so many forms of 'code generation' in use in modern toolsets that to reflexively object to its use is unproductive.
Posted by: scotartt on November 17, 2004 at 05:21 PM
-
I took it to mean code generation in general.
Generating SQL can work well for simple queries but if the required query gets complex code generators generally start to break down or at least produce SQL that's far from optimal.
That said, they can work well for producing initial boilerplate code for later modification and tweaking.
The problems start when you have large scale generation of program code. There code generators are, almost to a man, created to generate the code that's easiest to generate rather than the code that's easiest to maintain.
Again, not always a problem if the generated code doesn't have to be maintained or modified but for such code you have to ask whether the investment in a code generator was worth the time saved from writing the code yourself (obviously if the code generates a large volume of code that may be the case but if you need that much static code a thirdparty library may be a better choice).
But if that code needs tweaking or wholesale modification the problems quickly become unsurmountable.
Take VisualAge Java as an example.
It would generate massive amounts of code, large parts of which were highly inefficient and often plain incorrect (partly due to bugs in the generator, I admit). Sadly whenever you might change that code the next time you saved the file VAJ would (without so much as telling you) undo those changes.
And VAJ is not the only generating tool by far to work this way.
Forte/Netbeans has the same problem (or had, I've not used it to generate code in 4.0 and never used the 3.x releases).
On the other side of the equation is Borland JBuilder which is a dream to work with. It generates pretty decent code and any modifications you make to that code are kept and taken into account at all points.
Of course if that code contains errors the code generators will barf or produce unexpected results but that's a price I'm willing to pay as I'd have to fix those errors anyway.
In all I use generators only for boilerplate code like getters and setters these days (and for class and function templates) and for refactoring.
Eclipse does a good job at that and doesn't force me to not modify anything it does on pain of having my edits reverted to what the tool thinks the world should look like.
Posted by: jwenting on November 19, 2004 at 01:30 AM
-
The only successful code generation tools are those which produce an end product which is orthogonal to the source which produced it ( i.e.
javac->vm bytecode, cc->intermediate code->assembly->machine code, etc ) as in the examples you cited as successes. Generated code is problematic when the end product is used in conjunction with the source which generated it ( GUI builders ).
Posted by: wwwjames on December 01, 2004 at 11:15 AM
|
java.net RSS Feeds
