Code generation needs to be as reliable as the sun rising for it to be viable.
I recently have been doing ETL work with Talend, it generates a large quantity of java code out of its drag and drop UI. I'v had issues with it violating the rules of java (Too large methods), the model and the code being in sync and so on. Debugging is almost impossible with runtime errors indicating issues at the wrong line numbers. In short, the use of Java under the hood has been a hindrance (to the order of I'd say a couple of lost days in a several week project). So unless you can promise me it'll always work (and by always I mean, the same way that a compiler generates bytecode 'always' works), I'd avoid a solution based on it. On Jun 14, 5:11 pm, Kevin Wright <[email protected]> wrote: > This sort of thing has definitely taken root in scala-land. Consider the > @BeanProperty annotation: > > class Foo { > @BeanProperty var x > > } > > generates getX and setX as used by java stuff expecting beans (i.e. spring) > > we also have @BeanInfo, which can be applied to a whole class and generates > accessors for all members. > > On 14 June 2010 05:20, Bill Robertson <[email protected]> wrote: > > > > > > > I added code generation to our project about a year and a half ago. > > > .java --> javac --> @annotations --> .java (and .h) > > > There is a wafer thin layer of native code that interacts with a > > message bus that we need to talk to. It has no real message format, > > you get five void pointers and you have to know how to pick out the > > data (or you define for your clients how to format the data). In our > > case the annotations describe how the data is un/marshalled for the > > native layer. We generate (quite readable) dispatching and > > unmarshalling code, and the header files contain code that can write > > the data to the bus in the correct format (think tie classes and > > client stub classes). > > > Annotation processing in the compiler like this is quite powerful, > > although its a bit difficult to get started with it. It has been a > > huge benefit, because the code is simple enough to write in an > > automated fashion, and also a real pain to get right if you were doing > > it by hand. Also, like you mentioned, the annotations become the > > canonical description of the data layouts (at least when we're the > > callee), and the .java and .h artifacts are always in sync. Well, > > unless you cheat, then its just comedy when things fall apart. > > > I also added another bit of code generation to the project recently. > > > .g --> antlr --> .java > > > This type of code generation has been around a long time too. Again, > > easy to describe to a computer and stupidly hard to get right if > > you're doing it by hand. I wouldn't put antlr's code into the "quite > > readable" category, but its readable enough. > > > On Jun 5, 1:01 am, Christian Catchpole <[email protected]> > > wrote: > > > 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> > > > > > <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> > > <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]<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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
