This chapter discusses the different approaches to code generation and looks at best practices for applying code generation techniques to the development of enterprise software for the J2EE platform.
Applying Code Generation Techniques to the J2EE Development
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I don’t like the trend among Java developers of generating code using IDE wizards and so on. This is terrible since GUI/IDE-driven code generation cannot be automated, and its usually not very flexible. For example, instead of using a method taking a closure to encapsulate an iteration pattern, an Eclipse user will insert a “template” consisting of half a page of boilerplate code, and fill in the blanks. This leads to maintanance problems down the road, when a change has to be made to every single duplicated snippet, rather than one central location.
It is the sign of a broken design.
It generates more code == more chances for it to go wrong. You are better off finding a way to call the same generic code with arguments (classic delegation) – using dynamic proxies, annotations, whatever. Code generation sucks.
Also, byte code “augmentation” should be called byte code “obscurantism”, same principles but even worse than the above.
It is not really a sign of broken design of your code, the problem is, that modern J2EE frameworks tend to artefact a lot and tend to split tasks into many different files.
The reason for this is, that it is easier for bigger teams not to have the one single entry point where everybody meets and causes revisioning conflicts.
The downside of this is, that you often end up with a config file mess you cannot really handle the nice and simple way.
What code generation can do for you is to keep track of all the config artefacts without causing you headaches, it can give you a headstart on a clean web frontend design with raw backend classes which just have to be filled with logic.
What code generation cannot do for you is to write an app, but saying, once you have to apply code gens because the design is broken is not totally true. I see code generation more like a barebone design generation and bookkeeping service, for all the stuff I dont want to do myself.
The funny thing is once I applied xdoclet like generators to my projects, my speed basically increast 3-4 times, that much was spent on the steady bookeeping, self inflicted errors in the self written configuration files etc…
I am going to have to agree with the first two posters. I am going on my 6th year of J2EE development, and I have never seen any good come out of code generation. Yes, you can turn out a lot of code really quickly. However, all you end up with is a bunch of code no one knows anything about. Take that code and mix in about 4 years of developers comming and going from a project, and you have yourself a completely unmaintainable code base.
My current project uses Torque, which generates ORM classes for us. Torque is basicly a dead apache project. Everyone on the team is sick of it, and we desperately want to go to Hibernate. Which uses reflection to accomplish the same thing. So the previous developer in his rush to save time, left us with this generation framework, which we now get to rewrite.
Do yourself and your fellow coders a favor, stay away from code generation. Please.
I really like code generation, It is especially useful if you have to code in a programming language like C++ or Java. Do yourself a favour and get a good book, like “Code Generation in Action”
http://www.codegeneration.net/cgia/
Also read what the samba guys think about code generation: http://lists.samba.org/archive/samba-technical/2005-January/038951….
Sorry, to say that, yes, Torque is not really that good, but dont expect to be able to live without code generators for Hibernate in the long run.
Hibernate uses reflection, yes, but you still have the problem, that you hammer out the Mapping Classes and the database descriptor files, which are xml.
The main problem I see with going from Torque to Hibernate is, that you think you might go to heaven.
No, Torque basically is just a subset of hibernate, you still have to deal with mapping classes, but what you get rid of is the forced burden of having query objects, you still can use them if you want but you dont have to.
But having hibernate without any decent codegens, is a pain as well.
Face it, it depends on where you apply the code gens, but at at one point you really have to apply them.
Code Generation when used properly can be very good for a project.
Problems arise when code is generated then modified. This is not the thing to do. The generation process is part of the build process. If there is something wrong with the generated code then you have to modify the template or generater NOT the resultant code.
I think far too many people consider that Wizards in IDE’s are what code generation is all about. ie it generates a framework for you to fill in.
These days code generation is being done more at runtime (Hibernate SQL) or as part of a complete application generation (MDA). It is a powerfull technique being used more and more.
Cheers
David
XDoclet helps J2EE development hugely (in particular EJBs) – generating deployment descriptors and associated interfaces means you’re left to focus on application development rather than J2EE artefacts.