I think 2 is a solution but 1 can cause more problems that it solves - because code generation is simply a transformation from one model to another. So, if you can, why not just use the original model as it stands, rather that create source and compiled artefacts. We find though that code generation is often just used for binding. Its used to fulfil language level requirements. eg. with ORM we export DB schemas to beans because we need something to compile against.
I think code generation is fundamentally a bad idea but obviously necessary in some circumstances. It can highlight a discrepancy in a language and / or a platform. I use janino to implement interfaces. But it's done at runtime, in memory and essentially hidden. So it's a means to an end. And the code generated does the minimum to satisfy the binding. So you would question any code gen that is more than a binding. If you can, use the "information" / model etc in it's original form, then surely that's a better way to go. But as Robert suggests (I think), if its somewhat transparent, it's just "getting a job done" and it should neither be here nor there. The problem of course is when it affects the lives of actual programmers who write code that interacts with the generated code. On Jun 5, 12:32 pm, Robert Casto <[email protected]> wrote: > Something like ... > > Description --> tool --> Java --> javac --> bytecode --> jit --> cpu > > As software gets more complicated and is required to do more things there > are only 2 choices. > > 1. Write more code and generators can help here. > 2. Languages that simplify the problem domain. > > A code generator is really like a compiler. Its output is something you > don't necessarily want to read. It does a lot of work for you and you hope > that it is doing things correctly. I can't remember the last time I had to > look at bytecode to debug a problem. I have had to look at the Java > libraries a few times, but most of the time I stay above and trust that > things are being done correctly. Generated code is the same thing. I don't > care what the JSP, AOP, GWT, etc got compiled to. > > These code generators could be what we think of compilers today. The > alternative is to push this logic down into a language but all you have done > is made it simpler to write more code. Whether it is expressed as Java or > yet more bytecode, it feels like the same logic which has to be created in > order to keep me at a high enough abstraction layer so I can get work done. > > I would venture to say that out industry has been doing this since the > beginning. We now have hardware that can encode and decode MP3 data. We have > GPU's for handling graphics data and rendering pipelines. Everything gets > pushed down a level once the method is well known and standardized. I think > we are way past having to rely on 'magic' since my line above shows 6 steps > before what you wrote hits the CPU. We'll probably see a few more layers > added before we retire. > > Robert > > > > > > On Fri, Jun 4, 2010 at 9:36 PM, Casper Bang <[email protected]> wrote: > > Yeah but I was talking more about discrete generators at various steps > > in the tool-chain and at runtime, not just a compiler. > > > On Jun 4, 10:42 pm, Kevin Wright <[email protected]> wrote: > > > Java --(javac)--> ByteCode --(hotspot)--> Native > > > > Byte"Code" is not a misnomer, code generation has been common for years > > > > Yes, it's common, and it's mainstream > > > > On 4 June 2010 21:34, Casper Bang <[email protected]> wrote: > > > > > Of course we've always had code generation and scaffolding tools, but > > > > I get the feeling that it's gaining popularly and breaking into the > > > > mainstream (i.e. not just Groovy, Rails etc.). > > > > > GWT uses generation to the extreme for obvious reasons, Lombok uses > > > > generation to make up for stale language evolution, Spring has always > > > > been into low-level AOP kind of things, but their latest Roo framework > > > > seems to embrace generation even further. > > > > > 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? > > > > > -- > > > > 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]<javaposse%2bunsubscr...@googlegroups > > > > .com> > > <javaposse%2bunsubscr...@googlegroups .com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/javaposse?hl=en. > > > > -- > > > Kevin Wright > > > > mail/google talk: [email protected] > > > wave: [email protected] > > > skype: kev.lee.wright > > > twitter: @thecoda > > > -- > > 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]<javaposse%2bunsubscr...@googlegroups > > .com> > > . > > For more options, visit this group at > >http://groups.google.com/group/javaposse?hl=en. > > -- > Robert Castowww.IWantFreeShipping.com > Find Amazon Filler Items easily! -- 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.
