On 17/06/10 03:30, Karsten Silz wrote:
On 4 Jun., 22:34, Casper Bang<[email protected]> wrote:
So is this a general tendency all around, code generation becoming
mainstream? I've traditionally feared the day I can't do full round-
trip engineering in plain view but depend on magic generators and
IDE's (perhaps due to experiences with JDeveloper and the ADF
framework). Is this a good thing or a symptom of inferior languages
and lack of expressibility?
In general, I prefer "code interpretation" at run-time to code
generation. Let's take an ORM like Hibernate. Through XML or
annotations, I define the persistence strategy a POJO. At runtime,
these are interpreted by the ORM. If I add a field, I add an
annotation / update the XML file. If Hibernate becomes smarter, then
I don't change anything because the "interpreter" gets updated and is
active at runtime (yeah, this is simplified since moving to a new ORM
version can induce pain).
Now if I generated the persistence code for the POJO instead, then I
need to re-generate the code again for a new field. And if the ORM
becomes smarter, I somehow need to know to regenerate the code again.
To me, and that's subjective, the interpretation mode is better.
We have been using a Maven plugin to generate Java code as part of the
normal build cycle. That removes quite a few issues you mention and by
using JAXB to read the XML input and Freemarker to render the Java code
it is a surprisingly simple code base by itself. We also tried to make
the generated code very much like what we would write ourselves, which
means it is easy to understand a bug in the generated code. Tracing it
back to the Freemarker template that generated it is usually trivial, too.
I think as so often the trick is to keep it (a) simple and (b)
automated. The approach we took basically means you write a domain model
in Java, whack some JAXB annotations on it and then pass the model into
Freemarker templates to render Java code. The whole thing is executed as
part of the normal Maven builds, which means once you have configured
the POM entry you can forget about it, you never actually call the code
generation itself, it always happens as part of the normal compilation
process. It also works in Hudson and similar tools without any
additional configuration (assuming you deployed the generator plugin
somewhere the Hudson build can grab it).
We used this approach to create a full Java web application using
Restlet and Freemarker as solution domain. The only two things that
turned out to be hardish where the fact that we really needed a really
deep understanding of the JPA mappings and that Freemarker emitting
Freemarker templates are confusing. The former is an intrinsic JPA
problem, it just doesn't normally get exposed as much (you get away with
just making the cases you have work), the latter could be avoided by not
using Freemarker in the solution space. But both problems were (a) not
all that bad and (b) only affected a very small fraction of our overall
work.
I would definitely do this approach again. One day I might write it up
-- I actually started a draft for a couple of blog entries, but never
got around to fix them up.
Regards,
Peter
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
