Look, you can already have a look at the presentation I gave at Javapolis. It is about the advantages of working with code generation if you have big chunks of presumably (but not certainly) identical code. For the sound, you'll have to wait for the Parleys movie.

SlideShare | View | Upload your own

4 Responses to “Javapolis: Code generation with giant CRUD”

  1. Tom Klaasen Says:
    @hmmz: see above.
  2. -marc= Says:
    So why do we need *luck* with the option 'design everything generically'? Isn't the abstraction/modelling needed for making the code generation system exactly the same as the abstraction modelling that would be needed in such design? Each time I see bulk code generation like this I can't help wondering why it really needed to happen at design-time (many java files) and couldn't just be solved at run-time (generic, more free typed classes)? IMHO, the size and need of the problem suggests taking a complete different approach, not automating the known approach which just doesn't fit the new scale. Not that it all matters that much: discussions like this tend to smell like gender-of-angels kind-of discusisons. Specially in Java -land where 'bytecode' itself can be seen as generated code and modern use of annotations, runtime decorations, and AOP are blurring the runtime-designtime line even more. Anyway, one important remark about code-generation stuff I'm missing here is about the hidden cost of interfacing with generated code: 'service' classes get generated at virtually no cost. But re-generation of them force update work in all the clients that interface with it. As a general rule of thumb I would make the recommendation to (almost) never interact with 'generated' code, i.e. not assign the same 'value' to their public interfaces.
  3. hmmz Says:
    I saw your presentation at JavaPolis, and I'm a bit sceptical. You told us what you did at your project without providing us some a general CRUD code generation program. Why? What was the point of your presentation anyway?
  4. Tom Klaasen Says:
    @marc, Part of the problem was the lack of knowledge: there was no way to know which classes would remain 'generic' and which wouldn't. It wasn't even certain if there would remain generic classes, or if everything would become hand-coded. As for the interfacing with the existing code: most of that interaction was done the other way around: the generated services would callback to some hand-coded classes, and they would execute the real meat of the code. As it turns out, we really don't have that much generated code left now, now that we know the domain better. But it certainly helped us at getting us started, given the uncertainties that we had at the beginning of the project. I prefer a nice and clean design as much as the next guy, but such a design often demand for a very deep insight in the problem. And the problem itself has shifted a lot during the project. That's why I believe that our code-generation approach allowed us to remain flexible when it was necessary, and afterwards we were able to clean out all the generated files as we go ahead. That was kind of the message I was trying to give.

Sorry, comments are closed for this article.